Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience current models are pretty bad at this.

> Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability

My experience is a little different. For higher abstraction languages the output is largely acceptable in my work. I always consider that LLMs don't know what I don't tell them and they have limited context to work from. Coding issues I often identify:

* Efficiency. Marginal by default. Coding efficiency problems often appear because LLMs dont usually consider the entire codebase or future plans (although they do guess at some futures). Sometimes they write/name things in ways that are lazy/wasted cycles. Most of the time, they don't.

* Security. Marginal by default. I say they do pretty good. Considering all the failure modes, not so much.

* Maintainability. Marginal by default. Mostly due to the careful consideration of modularity, upgrade paths, etc. while often taking wildly different approaches to solutions without having specific broad instructions. Even then, there can be big gaps in quality.

* Observability. Not acceptable by default. There's usually some consideration and can often one-shot.

* Portability. Not acceptable by default. Good, if you specify what those targets are. Regardless, testing validates this above the coding and models are very good at hitting functional test targets. This is less of an issue in something like Java ofc.

Yes. I use these models day in and day out, on all sorts of tasks. I cannot believe I hear people say that coding is solved.

Correctness is not a binary thing though.

I doubt many people here are brave enough to claim their code does what is supposed to do in every conceivable case. Maybe you have high confidence in the correctness of parts of the code. Correctness of an application is murky though. Things we build are never fully correct, merely correct enough. Like maybe you're responsible for the UI in a web app and you're using your expertise to ensure it gracefully handles display across browsers and a gamut of screen sizes/form factors. But are you also verifying how it works when localized with an RtL script? Are you checking every change you make against CJK?

And there is another problem: LLMs generating too much code, code that is doing more than was asked. And that cannot be fixed by tests. Usually, we create tests for wanted behavior and expected exceptions. But we don't create tests for undesired behavior.

"Coding" is just a poor term for this, as there's so much room to weasel different meanings out of it. At every company I've worked in past 20+ years the "coders" were engineering a product from wrong or unclear requirements and specs from non-technical people. The act of coding was secondary (but an important throttling function to make us stop and think about what is even possible or makes sense.) Never did FAANGs, so YMMV.

Really doubt we are near that being solved with non-technical folks + LLMs. I'm seeing people gleefully rebuilding products with the exact same blind spots in their understanding/logic using LLMs. Claude, etc are not seemingly able to "AGI" around goofy asks. The CSS looks a little nicer than their legacy products though, lol.

second sentence of the article: "Just because the code is formally correct doesn’t mean that it is not introducing unnecessary abstractions, creating duplicates, or just making bad decisions overall. This is not a groundbreaking observation, most people who have vibe-coded a project, have realized that each additional feature can sometimes lead to an explosion of lines of code (LOC)."

I think this is a two things can be true situation, where our colloquial meaning of coding is not quite adequate to indicate the full range of criteria that really matter, but also, that criteria as a totality (maintainability, reliability etc) is something that can also be targeted and optimized for.

This reminds me a bit of a PhD Comics webcomic that confidently claimed we would "never" cure cancer, on the grounds that cancer is not one thing. And I don't know that we will ever actually cure cancer, but that wouldn't be the reason. Correctly noting the problem space is bigger than a layperson would initially appreciate is a lot of things, most of them helpful, but the one thing it's not is a formal a demonstration of optimizing against the problem space as a whole.

It's not solved, I agree. But if we pretend it is we can prepare for when it actually becomes solved, if ever, and measuring sloppiness is a worthy pursuit even if we never "solve code".

I just setup a large refactor with Astra and was feeling super lazy and let it mostly do it without my usual extreme micro managing.

The refactor ended up adding 22,000 loc.

I went in there and quickly read through it, laughed my ass off. Reverted the work tree. Micromanaged a new refactor. Net lines of code for something really elegant and easy to reason about was -3k loc in the project.

In case you are wondering why vibe coders are doing 30k loc a day, this is why.

This has been a problem in the software industry for a loooong time, though. Too many developers see "It works" as the end state, a signal that you're done. "It works" is just step 1.

Look, we are comparing against the average developer here And yes, they are obsolete

You come across as someone who has never worked on a real software project. Humans create tons of bugs on a regular basis. AI is already better than most programmers.

Amen. I sometimes wonder if all programmers are now marketing people who know shit about software development and engineering.

That is very well put and summarizes what distinguishes real software development from vibe coding.

Yeah, the author leads with a blatantly false claim that models are almost perfect at generating code. They are not. They write pretty bad code, worse than any capable human would.

And all of these things will be solved one by one.

It's astounding to me that people can see coding get solved and not think every single one of these tasks won't be solved too.

Why do you not think these things aren't going to be completely automated? What makes these tasks special?

Fable and Astra can one-shot video games with compelling novel game loops. They can do systems programming, distributed systems, robotics. I haven't found a weak point.

Seedance 2.5 can make video better than the manual labor of VFX artists, 3D artists, and animators.

Nano Banana and GPT Image can do a better job than graphics designers.

LLMs just solved a Millennium Prize Problem, and there are probably more that will fall in the coming weeks.

Just wait. All of these things will be solved.

There is no "stopping point".

Edit:

Don't anticipate that 2036 will look anything like 2026.

Will Smith spaghetti doesn't stay that way forever. Trillions of dollars will be spent on solving these problems. They will be solved.