I disagree on principle. Readability is not even close to the top of the list of why I want the code running on my systems to be "clean". Clean software demonstrates good faith by the developers and a competent, ground up understanding of the problem I am trying to tackle by running your software. Clean, to me, means the code is generally not doing more than it has to, resulting in lower attack surface, better performance, lower power usage and thus less environmental impact at scale, and just a tighter, more sensible, reasonable, easy to understand user experience. Maybe this doesn't matter much at your job, which seems to be where they're trying to replace people with these parrots, but it matters a lot on your computer, and it matters even more the other three billion computers.

Im not sure whose job it is to only write beautiful code.

If that's the case, zero programmers should be worried.

Beautiful code only tends to exist in open source.

> we may see the rise of “developer-less” companies.

I think the opposite trend will also emerge and more than offset this. Yes, vibe coded tools may fit the needs of low-stake applications for some companies, but if it was low-stake enough to start with, they likely didn't hire many devs, if any. More likely we'll see non-tech companies starting to hire a dev to build custom software (e.g., ERP) suitable for their use cases vs. buying SaaS and paying consultants to customize it.

Agree in general, it would be awesome for AI/LLM/whatever to act as an interface between devs and a highly efficient machine only coding language. All the abstractions we have built to make coding easier could be done away with. No C, no compilers, no HTML/CSS, just machines talking to machines without all the clumsy stuff humans need to make sense of it.

But... Anyone who has vibe coded knows that world is really far away, our careers will be over before it is here. This is like saying we should be telling kids to use Waymo instead of learning to drive. It is a nice dream but I am definitely not gonna bet on it.

This is the same old "developers are too focused on quality" story, is focusing on customers important? Yes. Is it the job of the "developer", usually, no.

I've seen it in juniors and in myself, entering into a company excited after hearing all these advices, and realizing that the job is really to "just code".

You do not communicate with the customer, you do not decide the business direction, you simply code, and make sure there are as little issues as possible (usually not stated explicitly), and that new features (as requested by management/customers) are implemented as quickly as possible.

I don't know how to respond to this "developers shouldn't focus on quality" argument any more. Is shipping fast important? Of course. Is understanding the customer important? Definitely. But why is there always this animosity towards "developers focused on quality"?

Where I worked my experience has been the exact opposite, many coworkers have been writing slop long before LLMs were popular, all kinds of horrible hacks, the constant talk about quality was not "we are working on quality all the time", but "quality is so bad my life is so painful".

So, my question to all that fight this "quality obsessed developer" is: Why have I never met any developer obsessed about the code quality, but I hear about them all the time?

EDIT: To be more concise, I think that the "perfectionist developer" is simply a scapegoat for the inherent difficulties and challenges of software development.

This is really all an issue of mapping.

A business maps org structures to reflect the problem spaces topology.

Code maps to reflect the topology and ontology of the problem spaces trying to be solved.

Spaghetti code is where there is no structural mapping, where every workflow/pipeline/process exists as if it is the only one and any code that fulfills that specific request will do.

Ain't nothing wrong with Spaghetti code... except, horrifyingly bad unintended consequences. Race conditions, data corruption, security holes.

Is your code a mountain where every drop of water that falls on it has a deterministic path to the base and little channels and protrusions can be dug or filled in locally and with ease, or is it a poorly knit sweater where any single thread failure, or need to change the pattern, causes unraveling and so altering the sweater requires massive disruption.

What really needs to be done is to stop using the term “vibe coding” for what really is similar to the “owner-builder” movement in the general contracting/construction industry. Foreman and GCs are not owner-builders. We need another name.

The irony of an article defending vibe coding that reads like it was vibe-written. The four "Why do we want X code?" paragraphs all end with the same sentence, the headers follow a neat structure no human would naturally land on, and it wraps up with a safely noncommittal "is this good or bad? Depends on who you are."

I long for articles that have been written in more time that it takes to read them.

I have a hunch we'll eventually swing back when we find the limits of vibe coding--in that LLMs also can only hold so much complexity in their heads, even if it's an order of magnitude (or more) greater than ours. If we make it understandable for humans then it'll definitely be trivial for LLMs, which frees them up to do other things. I mean, they don't have infinite layers or units to capture concepts. So the more symmetrical, consistent, and fractal (composable) you can make your code, the easier time an LLM will have with it to solve problems.

It is surprising that the author don't mention a very important point: you want to be able to modify your tool quickly to adapt to the evolving world.

That's a strong reason we want modular, concise, clean code: because tomorrow, we will want to solve a slightly different problem, and if you have a nice clean base, you can reuse it. If you don't, you need to rebuild from scratch (which may not be a problem with vibe coding) and rebuild the trust that the new tool is doing what it is supposed to do (which is a problem).

One definition of analysis is: The process of separating something into its constituent elements.

I think when someone designs a software system, this is the root process, to break a problem into parts that can be manipulated. Humans do this well, and some humans do this surprisingly well. I suspect there is some sort of neurotransmitter reward when parsimony meets function.

Once we can manipulate those parts we tend to reframe the problem as the definition of those parts, the problem ceases to exist and what is left is only the solution.

With coding agents we end up in weird place, one, we have to just give them the problem, or we have to give them the solution. Giving them the solution means that we have to give them more and more details until they arrive at what we want. Giving an agent the problem we never really get the satisfaction of the problem dissolving into the solution.

At some level we have to understand what we want. If we don't we are completely lost.

When the problem changes we need to understand it, orient ourselves to it, find which parts still apply and which need to change and what needs to be added, if we had no part in the solution we are that much further behind in understanding it.

I think this, at an emotional level is what developers are responding to.

Assumptions baked into the article are:

You can keep adding features and Claude will just figure it out, sure, but for whom, and will they understand it.

Performance won't demand you prioritize feature A over feature B.

Security (that you don't understand) will be implemented over feature C, because Claude knows better.

Claude will keep getting more intelligent.

The only assumption I think is right, is that Claude will keep getting better. All the other assumptions require you know WTF you are doing (which we do, but for how long will we know what we are doing).

If writing code is solving the wrong problem, then I actually like solving the wrong problem.

I absolutely hate this article. So you want me to learn, understand, and write code in a format an LLM can ingest so you can more easily copy and paste my knowledge? Seems like the worst of all possible worlds: I work for you for nothing, you and the LLM make money on my work, and you get to produce terrible software someone else has to maintain when you move on to the next "problem." How mercenary of you.

I think this article misses the mark from the people in my circle.

We don’t care about “clean code” (thats mostly just juniors yak shaving into a slow system anyway). We care about correct code -code that is solving the actual problem (as close to correct as possible anyway).

Using an LLM and expecting it to be more than 60-70% is a bad idea. And using it “as a tool” - we have a hard time believing a dev reviewed, understood, and verified 130,000 line PRs every day.

Additionally, it is still unclear if the generated code violates licenses / actually “becomes” your IP.

Guess who also benefits from well structured, clean, modular, well documented, and concise code?

Computers and LLMs!

What I find missing in the vibe coding discussions is precisely what we can't know, which is how this will work out over time in practice. A couple concerning data points I gleaned recently (sorry no references): - the LOC per PR is going up. - the number of bugs per LOC is going up.

I wonder whether 'enshittification' will hit the installed software base hard in the future and the software engineers tasked to fix it will not have been brought through the rigors of designing and implementing complex systems on their own, without LLMs.

This doesn't address the degradation that may happen when LLMs are increasingly trained on LLM output.

BTW I used to work in AI and I don't think scaling is a solution here.

> <good> code is easier to understand to debug, extend, and maintain [by people]

> But what if the next “person” isn’t a person?

There's certainly a hypothetical future where AI writes and maintains enterprise software and airline baggage control systems consisting of millions of lines of spaghetti code, codes that violates all the principles of good software design that we currently value, and everything turns out peachy.

Nobody but the AI understands the code, but it mostly works, and the AI fixes it when it doesn't. We lose the capability to understand and test the code ourselves, but the AI says "trust me bro - it's all been tested" (even though bugs keep turning up).

But, I doubt it.

First off, nevermind all the "parroting" nonsense, but LLMs are nonetheless auto-regressively trained and therefore fundamentally a copying technology, so as long at the LLM creators make an effort to train on high quality code, then what's generated should at least match those high quality patterns to some degree.

Secondly, human's hard-won best-practices for designing code are there for a reason, and it's not just because of the limits of our feeble minds to work with anything-goes spaghetti code. The reason why we prefer code that is modular, with thin/clean interfaces between modules, shortish functions, etc, are because these practices fundamentally do make for code that is easier to reason about, to test and debug, to update and extend without breakage, etc.

Per the Halting Problem, we know that ultimately the only way to know what code does is to run it, and therefore even if LLMs/AI were to exceed humans in general reasoning ability they would never gain some magical abililty to write arbitrarily complex/unstructured code and be able to successfully reason about what it is doing and it's correctness, etc. Following human best practices not only helps create code that is testable (possible to analyze and create test cases for all paths through a piece of code), but also code that can more easily be reasoned about, whether by man or machine.

In terms of where we are right now regarding AI's ability to write good quality code, it's perhaps informative to look at Claude Code, which is of late writing most of it's own code under the guidance of it's creator, and despite being something on the very simple end of the spectrum in terms of software complexity*, currently has about 5,000 issues filed against it on github.

* A minimal CLI agent is a few hundred lines of code vs for example the 15 million LOC of gcc.

This just seems confused about how software works.

If you’re operating exclusively at the level of business problems, you’ve always been “vibe coding”, by hiring developers to write code for you. The question of whether “good code” is important is not something you’re qualified to discuss as a technical problem, only as a resource management problem.

The developers will probably tell you they need to write “good code” and that, while it may seem expensive in the short term, it’s worth it in the long term. You can believe them, or not.

If you’re a developer, then you are operating at the level of code, not just business problems. And you do need to be able to read the code and make technical judgments about it, because that’s your job. If you aren’t doing that, you have no reason to be involved.

I think LLMs won’t be any better at maintaining spaghetti code than humans are. I don’t see why the principle of modularity, or any other “good code” principle, would change just because a computer rather than a human is reading the code.

> First, more people are going to try more ideas faster. This is good.

This is not good universally. Even if you become 10x coder along with your team, the users are not going to become 10x users instantly. They will pay the same and would want the software to be more or less same day to day. If you develop 10x features a week, they will just get frustrated after a while as your software become completely unpredictable by the amount of unneeded changes.

Does every photo editing app needs to be Photoshop? No, users come in all different capabilities and you as a project leader has to decide which features are gonna be important for your users, and for many apps that list is limited. We all think about an app which we used to like it in the past but became complete mess as more ideas were added. HN itself is a good example of not putting all ideas into a project.