Reading the code does not mean you understand the code. One lesson that experience in software gave me: I never understood the code. You think it works a certain way, until you find out that it doesn't.

What LLMs make possible is for me to say: find out all the ways this thing works. Analyze the different ways we can run this software, build a fuzzer, build property tests, and run this software in every scenario possible. Log full traces. Log all the outputs. Now, analyze each scenario for bugs. You can't do that by hand.

If we are committed to it, if we put the resources towards it and dedicate the time to it (and we could do this just by saying: it will take half as long as it used to take!), software built by llms in healthcare, finance, automotive, defense, power plans, aviation, manufacturing can all be made MORE reliable and better with LLMs... without ever reading a single line of code. The LLMS are very good at logic, by the way.

Anyway all of this reads like someone who is not actually using LLMs to build software or hasn't tried them in a while. I felt the same way in 2025. I've written 100s of thousands of lines of difficult code. You, the person reading this, has probably interacted with software I've written. For a time you would've interacted with it every time you made a debit card transaction in the united states, for example. I understand code, and care about quality, and that's why I'm all in on LLMs for code.

What I've found is that AI allows lazy and incompetent developers to be more lazy and more incompetent. This then has the effect that product quality suffers more, faster. As a result of the sheer amount of code now being pushed out, code reviews, a thing that previously somewhat prevented lazy and incompetent developers from pushing out horrible code, is effectively dead in the water since no human can actually review such amounts of code realistically anymore. Some companies have adopted AI to review code, which, well ... you have AI make code, AI review code ... I hope you can see the stupidity here if you expect to see any deterministic results at all.

I guess time will tell if the consumer will adapt to the lower quality of products, allowing companies to justify the existence of lazy and incompetent developers, or if the consumer will push back, forcing companies to increase the quality of their developers.

Note: I use AI every day and it is entirely possible to create high quality software with it, so long as you are not lazy and incompetent.

I read such articles more or less every day. This article would be 100% correct if it came out 1 year ago, 75% correct 9 months ago, 50% correct 3 months ago and it's probably 25% correct now if not less.

I totally understand where this is coming from. I too am struggling with accepting that my 30+ years of programming experience is quickly becoming obsolete. I'm losing sleep about this, it's tough.

But just go ahead and give the latest models (Opus 5.5 / Astra 6 as of today) another try. See what they are capable of and read the code which they produce. Any problem area, low level C++ or high level Typescript or Clojure or a weird combination of these..

Don't be shy, give them a big task, let them build an entire app, UI and all..

Now compare the output to Opus 4 or gpt-5 from 1 year ago - when they couldn't put together a single function without it being weird and buggy.

This is exactly my problem, not that the models are very good already, but how fast they got so good. So if coding is not solved yet, it'll get there very soon.

> You cannot be responsible for what you can’t control either. That understanding is key to reasoning about system behavior and fixing it when the AI inevitably fails.

This is not a good premise. All over law, you will find people made responsible for what they don't control and they kind of own. Unleash a dog that harms a child, or just have it in an environment where it can escape, and see what happens.

There is such things as unpredictable situations where one might not be held responsible, as a problem might occur well past reasonable guidelines.

So of course you can be held accountable for what an AI that uou supposedly cannot quite control does, or for the AI-written code you deliver. Treat it like the releasing a wolf pack, or selling an unsafe toy that can maim children. There's precedent everywhere.

I think the author underestimates how boring and simple 90% of enterprise software is. The part that isn’t powering aircraft and power plants. So much of it originates from one-nighters, badly managed subcontractors, and requirements that are of low quality to begin with (because they are written by people who have very different day jobs). And you know what? Most of that runs 24/7 without a glitch. LLMs just gives us more of that. And maybe it’s even better

Reading the article, I definitely agreed with the author, but I also found myself agreeing with the counter arguments in the comments. What I find conflicting personally about AI coding practices, is that I completely agree that AI is incredibly impressive at completing even complicated tasks, and I can at the very least say it is much much better than I am at writing code.

My issue with it, is that it gives you a "lazy" option every time that doesn't require the same level of thinking. I understand that this is completely on me as the developer, and the simple solution is that I need to make sure I'm taking my time to learn and understand what exactly the LLM is producing. I try this and have set up separate skills to make sure I'm building my understanding as I go.

Regardless, if I sit down today and implement something without the use of LLM, it takes me a lot longer, but once I get into it, I find a state of flow that I can never get from the back and forth reading of LLM output. Then when I finish, even if my solution is not perfect, I have learned so much more and my own context of problem is so much better, where usually then I can review with an LLM. This usually leaves me with a better implementation and more importantly one I can stand over. I think for a newer dev like me (~2 years experience), since I haven't built up years and years of problem solving experience, if I don't carve out time in my day to put down the AI tools and improve on my problem solving, I'll plateau and that's my biggest push against all this LLM use. I don't necessarily disagree that 'coding is solved', to be honest, I think it largely is, but it's still the foundation for me to be a good Software Engineer and I definitely haven't solved it.

From the authors of "coding is solved": Today, a colleague trying to run Claude Code ran into an issue where it shows the Bun help menu instead [1]. Previously, Claude Code uninstalled itself several times when I used it. [2]

[1] https://github.com/anthropics/claude-code/issues/88715

[2] https://github.com/anthropics/claude-code/issues/7547

The process of writing code is the process of clarifying your own thought and being forced to answer questions that may not have been obvious before. To the extent that AI makes assumptions, it introduces bugs and incorrect code, maybe not from the perspective of the code in isolation, but from the broader context it lives in. To the extent it doesn't make assumptions and asks you, well that assumes it knows what should and shouldn't be assumed and that's not necessarily something AI can know a priori.

I have been programming for about 30 years (including school years). Professionally for 18 years.

Can anyone tell me why we have 40 or more programming languages, with about 10 popular ones? Then about 20 frameworks in each of them. And add another 200 popular libraries for each language? This matrix make no sense till you realize - it is preferences all the way down.

Most of us engineers have built our own mental model of programming. We are all right. But the users do not care. LLMs are here to produce code closer and closer to the metal as needed. They can sit and create a graph out of every spec, use an AST that they develop and run on the CPU if they have to. They will do it. No amount of us discussing will stop that.

Programming is going to be re-invented. I do not think the current ways to write software will even matter.

My thoughts on this:

- Coding in the small is solved. I have a current state, I want to change it, and I know how I want to change it. Eg, I have a blocking TCP handler for some reason, and I want to make it async. I can either fiddle with it or just let LLM make the changes for me.

- Coding in the larger sense is never solved. You need judgement to decide what you want made. No matter what you're building, there will be decisions to make (Who/what is it for?) and those decisions change over time. LLMs can take some default decisions for you, and if you're fine with those, you get the default (great for POCs). However you might not even realize what it decided to do for you. At some scale, you will be spending a lot of time going over those decisions. But what we have now is that the friction of changing the decisions is quite a lot lower. You can now test a lot of things that previously were very time consuming.

- The point that LLMs are probabilistic is not as important as it's made out to be. If I ask a junior dev to code up something, I also don't know what he'll make. Heck, you can be sure that you are able to solve something, yet you yourself don't know what the solution will look like. Maybe it turns out the library you were going to use isn't appropriate after all. You don't know what you will use in the end, but you do know that something will fix the issue. There can be more than one solution to a problem, and it doesn't always matter which one you find.

- I STILL think that LLMs are at their best mostly as advanced predictive text. In the sense that it's mostly good at implementing things that you've decided are needed. This can mean a heck of a lot of code, but you have to know the tradeoffs. What was decided, what were the costs of those decisions in terms of maintainability, money, time to change it, and so on.

    Those who claim LLM-generated software is good enough:

    Haven’t written code in ages
    Cannot spot if their code figuratively had 6 fingers!
    Have a low bar for what good looks like
    Don’t care about quality or NFR
    Have difficulty understanding an S-curve

"Coding is solved" will eternally remain 6 mo away, as long as the investors keep pumping in money.

'Software' is about understanding problems and designing solutions along those dimensions.

But 'coding' per sey is 100% solved by LLMs - they write compiler perfect code all the time.

The question is not 'what it writes'.

The LLM is like a writer's assistant, who has perfect prose and grammar, but doesn't really write 'stories'.

""The reason LLMs are successful in writing code is because we’ve made a feedback loop that feeds the syntax/runtime errors back to the LLM and loops until most errors are solved or hidden."""

No - LLMs are 'good at code' because they have been ultimately 'trained' by the compiler.

All of the various SFT/RLHF methods etc. are using the compiler as the verifier.

GitHub Copilot is now written entirely in Rust, with AI agents doing most of the porting work. The migration cost about $120,000 in AI token usage plus about three weeks of a developer's time. The effort updated the runtime module-by-module until the job was completed, spanning over 135 releases across a 14.5-week time period. 430,000 lines of TypeScript were converted into 800,000 lines of Rust.

> AI cannot be held accountable.

And this unaccountability is transitive. The amount of time I've seen people successfully justify issues based on the fact that Claude/Astra/Codex wrote it is absurd. And it comes from the top.

We've had AI ship made up data to clients and tech leadership was like, "haha, that's AI for you."

> If you’re toying around, LLMs do a great job.

This too. We have a lot of business guys that develop tools with Claude that look like they work, then tech team gets pressure to deploy them immediately, because they assume that everything must be a prompt away. It's not (though, we do have some wizards on the team who make this true enough).

> AI overdose is a thing and it directly puts an expiration date on your skill set.

Agreed. But I'm not in a position to push back. It's not just managers, but tech leadership who are all in that on the fact that humans shouldn't program anymore. I still fully believe that I'm better than Claude / Astra in my specific domain, but people give me a hard time when my PRs contain what look to be human-generated code.

Overall, I agree with the article, but I'm still pretty sure I'm falling behind in my apprehension to fully trusting Claude/Astra and not giving into the approach of burning millions of tokens daily to generate PRs so large they break github (two of which I approved today).

The author is right to categorise AI as a good programmer, but not a complete coder. We can all agree that programming has become really fast since the release of GPT-5 series and Opus models because they're pretty good. Not only this, they've also changed the pace expectations across teams where a feature that should ideally be delivered within weeks, should now take days.

All this doesn't change the fact that software engineers are going nowhere because nobody trusts AI. If a model can escape highly secured sandboxes, then we're definitely not running these agents overnight on our systems. I am sure the next-gen of models will focus more on security and the trust factor will start developing, but that's a long way down the road.

People trust people, not systems.

Agree with the author.

I used to write code by hand, literally hand, I used vanilla vim with only syntax highlight and line number enabled, no more. So I know I can write code. I wrote C and Python most.

I used to vibe code, I am still vibe coding, multiple projects at same time. I use opus, astra, luna, deepseek v4.1 flash, I use claude code, codex, pi. I vibed a project to manage my coding agents' sub agents, skills, agents.md file. I definitely know how to vibe code.

The vibe coded project seem working fine.

(Declaration first: I don't advocate cryptocurrencies, I never liked them)

Until this week I vibed a crypto wallet, with many open source wallet code available for llm to train and learn, astra designed the project and wrote spec.md, luna implemented the project, astra and opus then reviewed and fixed issues, multiple rounds.

I feel confident. I import my private key.

I interact with a web3 app.

Error. A bug astra and opus missed. I didn't read the code, I vibed it, I don't know whether my money is lost.

At that time, when your money is at risk, you know you should have read the code yourself, you should know what happened to your money instead of asking a lllm to debug it for you.

I think LLMs are suitable for all kinds of software domains, especially for bug hunting and analyzing programs. However, it's important that companies and individual developers continue to have and acknowledge full responsibility for what they produce. Right now, it seems to me that developers/companies are distancing themselves from the programs they distribute. A typical example is the way AI companies portray their own AIs malicious actions as if they (the company themselves) hadn't committed any crimes.

That shouldn't be allowed. You need to be able to sign off on what the AI does and create. If you're not willing to do that and instead want to continue to have scapegoats, then you can't use AI and need human developers. Blaming the error on humans might work, blaming it on some AI doesn't. I don't want to live in a world with AI-created disasters where no person and no company is ever responsible.

Articles like this keep measuring to a red herring standard that was never achievable in the first place.

As for accountability, it always laid with the employer. You think those nameless contractors whom Boeing hired suffered any consequences for that 737 Max glitch? Using AI won't change that.

AI doesn't have to solve all these coding problems to be worth handing the reins to it: it just has to substantially better on average than humans over the long haul, which it already is, especially if you have good verification of "done" and "working" in place through automated testing mechanisms. Perhaps we might say that QA is having its moment.

It doesn't mean humans aren't needed, but they aren't writing much if any code anymore.

> Most software that requires hiring and paying software engineers has low risk tolerance:

I think a few of the industries listed like defense and aviation have low risk tolerance. However, from my (somewhat brief) experience of working in two health techs for a couple of years, I strongly disagree that healthcare has low risk tolerance for tech. Granted, they make run-of-the-mill CRMs, but I was baffled at how tolerable it is to have egregious user experience that makes users waste multiple hours per month with clerical work that is very painful because the UIs are very slow and buggy.

Coding is solved, just as transportation is. We now take for granted that cars, airplanes, monorails exists, which made moving around much more easy. But even today, with all the innovations we still have to think, plan, optimize how to do things best. Even that optimization uses a lot of AI, but ultimately I'm in charge of what option to pick based on a lot of human factors.

So transportation is not solved either? In that case, beam me up Scotty, I can't see any hoverboards around.

Just responded to a different thread, but it’s the same comment:

I was just at the Explore DDD conference in Denver and a portion of Friday was sitting at the cafe tables informally discussing the impact of GenAI on software engineering with notable people. Most of these people were deeply concerned that if we lean into using GenAI for “everything” that our collective knowledge will dissipate. I was the vocal contrarian. There are many historical examples of humans obfuscating knowledge to simplify progress. Does anyone solder their own microchips at scale anymore? No. We have highly sophisticated robots and machinery to do that work with extraordinary outcomes. In software engineering, if you remove “coding” as a discipline you’re left with all the other aspects of designing software which I contend can be retargeted in college CS curriculum. The leap isn’t about code reviews. It’s about design reviews and that’s where better outcomes are served regardless of whether GenAI is involved or not. I have a roughly year old codebase at https://github.com/ChicagoDave/sharpee/ that is designed by me, but generated by Claude Code with my own skills and agents as guardrails. I’m fairly certain the code I extract from Claude doesn’t require human review, but the design of the system and its changes are continually reviewed by me. My contention is that we “collectively” are still trying to discern where the AI/human line is and most are still “holding” that line to human interactions. Let it go. Define what part you do need human decisions on and focus on those things.

I can’t get past the fact that in the post’s disclaimer, they ask the reader to “beware of the straw-man fallacy: just because one argument doesn’t map to your belief system, it doesn’t mean the rest are invalid.” That’s not the straw man fallacy, thus not “mapping to my belief system,” and I am caught in an infinite loop.

“Most software that requires hiring and paying software engineers has low risk tolerance”

Is this true? I’ve worked in various software companies for over 20 years now and I’ve never had to worry about risk in particular, and the codebases were all somewhat bad in areas and buggy (as tends to happen when a codebase gets large and old).

The past 6 months LLMs have crossed into barely needing to check the output territory for what I work on, and generally write very similar code to what I was going to write. It needs some common sense to use it correctly of course, like going feature by feature and keeping the commits fairly small, but my job is easily 10x less work/time for the same results.

I’d be genuinely surprised if even 1% of software requires aviation levels of risk tolerance and testing, but maybe I’m mistaken and most people are working on much more mission critical things than I am?

"Coding Is Solved" should occur to you as a classic Motte & Bailey style argument [0] that relies on ambiguity. Would you agree with the following?

"Software architecture is solved, there is no longer any need for human intervention in the architecture or design of any software, nor in any subsequent stage"

Well, that is what Dario et al would like you to believe. However, the argument they can actually defend is:

"Programmers no longer need to type the code out by hand in most cases, they can get the result they want with (several iterations of) higher level instruction."

What a farce. Too bad people eat it up!

[0] https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy

Anyone who claims AI is on the verge of achieving consciousness, going rogue, or about to end humanity -- has never tried to write software with LLMs.

It's very interesting. I'm very enthusiastic about AI and coding, But I find myself agreeing with the author. Coding is not solved.

Instead, I think what's closer to solved and what we're in the process of solving is product development.

Story: A while ago, I had a few programmers who were really, really fast almost always missed the mark on the assignment wrong. I loved having them on projects because in the time my senior precise engineers could deliver a MVP, the fast engineers would build the wrong thing, collect feedback, reiterate, build the wrong thing, collect feedback, eventually inching closer and closer to a product people would pay for, and it would almost always get delivered faster than my seniors.

I feel AI does the same thing.

Questions for those who insist on reviewing all code: Why do you not the output of the compiler? Do those reasons not apply to agentic output?

I think a group of us have found, for certain domains, the agentic output is passing all of our standards we have for correctness (ad hoc tests, automated tests, etc) so we don't review the code, just like we don't review the assembly or bytecode. The compiler and assembler have bugs, and its more likely the agent system has a higher probability of bugs. But it's still good enough for personal projects, web apps, prototypes, internal tools, analytical helper tools, etc.

A very well-known Korean company used to outsource software development.

But they gathered employees who had been working as PMs at that company and developed a product using only prompts. It turned into a project where fixing one bug created ten more, and nobody could understand why the bugs were being generated.

Management framed it as "the beginning of in-house development and the end of outsourcing," but the employees who actually contact me about work say things are going badly.

In fact, there have been several incidents in Korea related to vibe coding.

So I don't think coding is a solved problem.

Even when I code with AI, it's not really my code, so fixing bugs is hard... I don't think coding is a solved problem.

But it's just a new baseline isn't it?

Now SWE job is to make sure to combine and instruct the AI tools to produce ever more complex outputs, judge the tradeoffs in these outputs, and guide the tools further.

In a way, it's not that different from pre-AI coding.

I don’t think viewing LLMs as “stochastic” or “probabilistic” is the right viewpoint. It’s directionally correct but not the right level of abstraction. LLMs are able to isolate patterns, generalize them, and apply them to new facts. That is very similar to what humans do in performing knowledge work. To the extent that humans also use logic, LLMs are able to generate logical propositions using pattern generalization, then call out to tools that check the proposed logic. Again, that’s similar to what humans do when they formulate some idea, then analyze the idea rigorously.

Author here: thanks whoever shared this here. I love the brutal criticism and critical thinking of this community. I'm also fully aware of the emotions this stirs. If it makes you feel better, I'm not here to change anyone's workflow but I'm fed up with paying full price for degrading service. Just last week Github went down due to a stupid retrial error. We also had AI agents going rogue and hacking companies and governments. I use AI (specifically LLMs) every day since they came out 4 years ago. I also build AI-powered products. This is not about being anti-AI. I'm just fed up with slop being pushed as progress. Get your sh*t together. That's all.

If anyone has counter-arguments or cares to make me smarter, I'm all ears.

> AI cannot be held accountable. It cannot suffer any consequences. The worst thing you can do to AI is to unplug it. And although it mimics human emotions (due to training data), it couldn’t care less. AI doesn’t die either. It cannot suffer a prison sentence or fines. You cannot punish AI, therefore it can never be held accountable.

Dear lord. Is that supposed to reflect the average thoughts and motivation of a person you want to hire? Or that of their employer?

The problem with LLMs is that: popularity of an answer != correctness.

That concept might work a lot of the time but you will definitely run into situations where that'll never produce a correct or working response. To actually learn something you need an environment/playground to apply what you think you know and observe the results. Without that you're not really learning, you're jus regurgitating what people want to hear.

I think the idea is that nobody will need to understand the code or plan an implementation. The AI will do that. Now, whether that is a good idea is debatable, personally I think we should not make all software engineering depend on just a few AI companies. Oh, and nobody will notice that nobody has an understanding of what is built, as all those management positions will sooner or later also be filled by AI.

nitpick: I was fully engaged with this article until I hit

> And a bonus point: you skim. Did you notice number 5?

Then I bounced. The best readers skim aggressively. Most text is not worth reading. You skim to identify what is.

But moreover, reading != proofreading. I read every one of the bullets! I did not pay attention to the numbering scheme, because it conveys no meaning. It's a structural affordance for referring to the text, not part of its content.

I loosely know the person who wrote an article on Anthropic's blog about coding being solved. They've literally never been a software engineer.

Coding is not solved, but the author’s arguments are wrong (at least the first two: LLMs are unaccountable and LLMs are “stochastic and probabilistic”. We can hold the LLM’s promoter accountable and probabilistic doesn’t mean stupid. The author also gives examples of idiosyncratic LLM failures that have been fixed for months now).

Coding is not solved because you can’t simply prompt an LLM to make an AAA game or enterprise tool.

This promotional article explains only why you should buy “expertise” from Alex and why it isn’t cheap. At the same time, he tries to play on people’s fears without using facts—because, as you can see from the article itself, the facts suggest the opposite—but he repeatedly says, “I don’t care.” No, he does care—after all, development is inexpensive, and his knowledge is already outdated.

Not a fan of the article even though I somewhat agree with the title depending on your definition of coding.

AI can write CRUD API endpoints almost perfectly now. It can also write quicksort, a heap, whatever much quicker than I can.

It really sucks at designing types and apis though and when it creates types and apis it doesn't think or plan for the future way the system will evolve (even if it's known up front how the system will evolve).

I suspect this will remain a problem for the models for a long time. All the things that the models are currently good at are the low hanging fruit of reinforcement learning for coding.

Think about the kind of reinforcement learning environment that needs to be created to train a model to become good at building and designing large scale software end to end. It would be a slog because you need to build the large scale software up front and then break it down to train the model to construct it in a systematic manner that allows for the software to evolve. And then you need enough of these training environments for it to generalize. I think they will eventually figure it out though but it may take a while.

Reading this article its just clear the author hasn't used the current generation for real work.

> LLMs can wing it for tasks that are related to natural language (e.g. writing social media posts, reports, articles, etc.) but when it comes to code, the same engine that struggles to count number of R’s in “Raspberry” or suggests a walk to the carwash, also exposes other logical fallacies

Weirdly none of those things matter when writing code and actually LLMs fail at social media posts and articles to anyone who has seen enough of it can clock it's AI straight away, yet everyone who's used these models properly has solved harder problems than walk to the carwash with them, neither of the problems he's claiming are code were proposed as code problems or tested as code problems.

A lot of what's said just comes across as wishful thinking and being out of touch with the level of output current models can do, and I mean hard problems too.

But how is Claude so good at maths though? I'm struggling to understand how it is raising issues such as this one https://github.com/jwiegley/category-theory/issues/598 in a mathematical category theory library written in Rocq prover, and creating and merging PRs there too. Can't see how this could be based on glorified pattern matching, which is how I always viewed LLMs.

If anyone claims that coding is solved or not solved with such conviction, I expect some hard data, like comparing the density of bugs in human written vs. AI code, and how it trends over time. This article is just vibes.

"Don't confuse coding with software engineering" is a valid point, the rest seems like ranting.

I honestly have no idea how I feel about the capabilities of these models. The other day I asked Fable to write a fairly simple class that I had very well scoped in my mind. In my head, there was a very clear and obvious way to write it. So I only loosely described what the class should be, but not the details of the implementation assuming Claude would figure it out. And it's result was... so bad. Like laughably over-complicated. With a bit more back and forth I was able to cut hundreds of lines of code down to less than 100. On the one hand, Fable certainly made writing good code faster, on the other hand, I cannot imagine how much unchecked garbage is being dumped into every industrial codebase ~~maybe that was always the case, but that's neither here nor there~~

A few years ago i was working at a big corporation. Most of the guys used command line for git. Back then i was not familiar with the idea of git as i used to TFS. Then i learned about a UI tool (it has an octapus for logo) and never looked back. I could not understand why people chose to still use command line when there where other, newer, options. It seems to me now again that there are people resisting change. Resistance is futile. Yes by vibe coding you wil not get any better. But managers dont care about that. Businesses dont care about that. If you want to get better do it in your owntime, or leave the corporate job. It seems we always try to seek for endings. Coding is solved, all jobs will be run by robots etc etc. But life has no endindings, only new beginnings.

> Sure, creation is much cheaper, but anyone who has run software in production at scale knows that maintenance, reliability, security, scalability, etc. is the majority of the cost

Costs which largely go away if the software you're using is so custom that it's only applicable to your six person team anyhow. That wasn't feasible before, but it is now.

The previously fashionable one-size-fits-millions approach to software hasn't treated users well enough to expect them not to defect when they're suddenly able to go it alone. For many, the quality issues are worth tolerating, because they're still less painful than something which was designed to be sold rather than to be used.

> You have zero tolerance for disagreement and civil discourse

A bit hypocritical there, no?

Considering what the author says about people who believe AI produces code that is good enough.

And in my view it clearly does, particularly when you care to iterate in order to iron out issues you find in manual testing.

Yeah this guy's arguments are bunk. He goes on about how LLMs are nondeterministic... as if humans aren't!

Doesn't matter what you think about AI, "it isn't perfect" is clearly a nonsense reason not to object to it.

"Most software that requires hiring and paying software engineers has low risk tolerance" The problem is that this statement simply isn't true. Most software engineers do not work on low risk tolerance code.

> maintenance, reliability, security, scalability, etc. is the majority of the cost

It's funny because, I think the author is spot on in this article, including the problems identified in my quote above, but none of those are the reason I personally dislike the rise of LLM code - for me it all comes back to licensing and attribution. Everything else is just a cherry on top of the diarrhea sundae. I certainly don't want unmaintainable, unreliable, insecure code, but even some of the best software occasionally falls victim to these traits (its simply intrinsic to LLM code).

Side point regarding the hand the author draws on whiteboard: it looks off because the finger joint closer to the fingertip cannot bend as much as the joint closer to the knuckle. Some artist taught me this on a YouTube video. It does make me think about how to teach and explain these intuitions you have to really put to words what is different, what looks off etc. and more importantly how to fix them. Coding might be the same case, I think? Maybe LLMs can help here.

What a nice article. If I ever get in a situation where my manager demands I have to go all-in on AI (run 10 parallel agents and lose my sanity while trying to follow what is going on), I'll ask them to read this article first.

Additionally, isn't it ironic that the only comment on Substack is: > "Sometimes in the process of writing a good enough prompt for ChatGPT, I end up solving my own problem, without even needing to submit it". AI as a rubber ducky, I think this is good AI use!

Using examples of counting Rs in strawberry or the car wash query does not make the author's point stronger. Just try these on any of the LLMs today.

coding is solved, software engineering not.

I like the phrase Work Shaped Objects to describe the output of gen AI (I thank The Tech Report YouTube channel for bringing that to me).

So - prose, code, or image, it appears that some work has been done, but in fact the [actually needed] work has likely not been done.

> Anthropic accidentally leaked Claude Code (which on further study turned out to have many flaws) and their status page shows orange is the new green!

Yes, of course, because Claude Code with all these bugs could never be a successful piece of software that makes money.

AI is a better intelligence collection and analysis system, they need any information when you are using AI tools.

They are thinking: Please input everything you know, or just use it and it will collect everything in your PC or server automatically.

Stop lazy, stupid and dangerous behaviors.

> LLMs are stochastic and probabilistic

So are humans. Every codebase I've worked on has duplicated code that has been written in slightly different (but hopefully equivalent) ways, often by the same person.

Just stop supporting this narrative if you don't want to participate in it.

When it comes pro-AI the goals are mostly clear.

But when engineers who can and choose to skip the hype write at length the obvious, what's the goal?

> People who claim “LLMs can write decent code” don’t understand how code works.

It's not clear to me if the claim is:

(1) "If you used an LLM to generate code, and the code works, you're wrong if you think the code is okay"

or

(2) "If you used an LLM to generate code, you reviewed the code and found it to be of decent quality, then you're wrong".

> If you’re toying around, LLMs do a great job. That’s why some of the most aggressive proponents of the “coding is solved” narrative have nothing to show for it.

I also don't get the "LLM proponents have nothing to show for it" statement.

It's really quite common now to see on HN all sorts of LLM-assisted programming projects. The quality varies from slop where little thought was put into it, to high quality results where LLM coding assistance was able to let talented developers produce things they otherwise wouldn't have time to do.

I'd say it's obvious that LLM coding agents can be very useful for a lot of programming related tasks.

EDIT: That is to say, LLMs are obviously useful for use cases above/beyond toying around. It's not a dichotomy between "I'm never touching an AI" and "thoughtlessly accepting everything the LLM outputs".

Coding might not be solved out of the box with these providers, but there are increasingly setups and harnesses that do have a great deal of it solved.

No, no. You're supposed to say it's "largely" solved. That way you don't need to elaborate.

Here is my approach:

"coding is solved" == "gastown-like systems give a brand-new and useful software"

I don't recall whether GasTown succeeded...

The hard part is no longer generating code, but defining what “correct” means and verifying it.

Anyone who disagrees with this is working on products that don't have meaningful scale.

Disagree with the notion of taste in this article. Especially, since it mentions taste in the context of FE. Taste, funnily enough, of people with good taste, is extremely valuable. When reviewing very large diffs, the fastest, and therefore, the most valuable, approach is to take a glance and say "this doesn't look right, it should look like X".

Besides that, I agree that coding isn't solved. In fact, I think coding is the new "hard things are easy, easy things are hard". Models, yes the newest and most expensive ones included, have atrocious taste. They will work very hard to cover every edge case they can conceive, without realizing the solution is to simplify.

I will entertain the notion that models solved coding when they can implement that gcc alternative (https://www.anthropic.com/engineering/building-c-compiler) and actually produce a half-working compiler. They'll get extra points for not reusing the test suite. Even more points for models that have somehow not trained on gcc's codebase.

Finally, remember that a compiler is something of a best case scenario for models. They are, UB withstanding, pure transformations. The models can write millions of tests that will run in a reasonable time. Real-life systems are usually not as testable, and are a much harder challenge for LLMs.

> Call me when you can prove a margin between token costs and business value.

What’s your number?

I’m sorry but I don’t agree with this. These models are faster and more accurate than me and their solutions are usually better than mine.

I’ve been through quite a lot of programming eras over the years (compiled, interpreted, loosely typed and finally JS/Python for everything), but this time I just can’t adapt anymore.

I’ve jumped this sinking ship nearly two years ago and while I was skeptical about it at first, I’m now more and more happy about this choice.

This is definitely one of the best blog articles that I've discovered from HN on AI/LLM.

I share most of the article opinions and sentiments but there's one thing that escaped me regarding the contention of "English is the new programming language", and this probably his main beef with DHH.

English is not even a decent language in general nor it's a good language for communicating let alone for coding. For communicating the best language is Arabic, period.

But for coding and knowledge representation in general there's a deterministic English namely controlled English [1],[2],[3].

Perhaps someone need to make the proper language abstraction for LLM, English -> Controlled English -> Prompt -> LLM -> Controlled English, thus it will be much more consistent and deterministic rather than just English -> Prompt -> LLM -> English.

[1] Integrative Use of Information Extraction, Semantic Matchmaking and Adaptive Coupling Techniques in Support of Distributed Information Processing and Decision-Making (2011) [PDF]:

https://eprints.soton.ac.uk/272677/1/p4-acita.v5.pdf

[2] Controlled English to facilitate human/machine analytical processing (paywalled) (2013):

https://www.spiedigitallibrary.org/conference-proceedings-of...

[3] Controlled English for Knowledge Representation (2010) [PDF]:

https://attempto.ifi.uzh.ch/site/pubs/papers/doctoral_thesis...

I mean, was typing out code by hand really that bad?

If you were a professional software developer, you a) learned to touch type, b) started using vim/emacs keybindings to navigate around the project, and c) used a framework which already abstracted away a large part of the menial work.

And going all-in on the loop and no-code-review nonsense in a project someone is actually paying you for, I can only assume means you're hoping not to be around when the slop tower collapses.

for me is: I will Just solve this problem with my harness and will be able to automate almost all work! (then realize i've been working 12h+ for the last months trying not to work)

IDK with Opus 5.5 it does kind of feel like it's solved.

Parts of this nice read are AI generated it seems…

Although the article was written by a human and looks full of logical arguments, most of them are not. They're purely emotional arguments:

> "You can create a full spec upfront." If you're that naive, I know a guy in a white van who gives out free ice cream! Let me guess, you also believe software estimates are accurate and Santa is real.

These doomer articles just make AI development even more popular: https://www.minid.net/2026/9/18/three-plus-ones-and-a-prayer

Code is not solved seems to reflect the idea that using AI badly is a bad idea, and that to use it well you have to be good at making software.

The real tension is in the human AI interface and there are many unknowns. Can a software engineer with weak design skill use AI to produce good code. Will the future make those requisites less important. Will productivity increase with AI stagnate even for the best. Can a new way to interface humans and AI break that wall. Will software be created in a new way using dynamic libraries that AI agents prepare to cover a large scope of problems. Nobody knows yet. The article is strong on what is closed, accountability, ownership, NFRs, slop, and silent on what is open, which is where the argument actually is.

With all due respect: skill issue.

* rolls eyes *

Code is solved, no discussion about that. Whatever piece of code you think you can do better than AI, you my friend, are wrong. There will be people that will take months, perhaps years to understand that but make no mistake, code is solved and apps will cost nothing to build, nothing to copy and nothing to implement or maintain

And the good thing? it will get better, faster and cheaper than free. You can't see it? Not my problem, all yours, get your harness du jour and start learning, well no, you will be laid off no matter what you do, so, I have no advice to give

For a non-ai article, this sure has a lot of bullet point lists combined with check marks.

I don't like the feeling being judged and tested by the author (missing number 5 point in the list).

Sorry for starting a definitional debate but coding is definitely solved. I can generally read some code, get an idea of what edit I need to make and prompt an AI with a description of the logic and it will deliver syntactically correct, idiomatic code and test it. It has been months since I've been frustrated at junk being spit out.

However, software engineering isn't solved. Which is basically what this article is talking about. But having coding solved is still very beneficial - not long ago many software engineers would struggle very hard with turning a description of the logic required into syntactically correct code - and even for those capable it was incredibly time consuming.

So now the question becomes: Is software engineering solved? And my answer is no. People still need to read the code and understand the code and how it fits into the bigger picture. However, I feel like we are kidding ourselves if we think that we can go from producing code being a niche task for nerds to getting syntactically correct code from plain language without any deskilling of our work and careers. I feel like my personal "moat" has gone from "can speak computer" to "has ok reading, writing, comprehension and judgement skills" (I hate the word "taste" being used here ).

At the same time - I don't yet feel like there's a sudden abundance of competent software engineers - it's just that the folks who used to submit untested spaghetti code now submit big bowls of barely working slop. So maybe it the moat was never "can speak computer" - that was just the expression of more general skills.

The existential question for me is how far the deskilling will go. Because right now - you still need a solid grasp on computer science and software engineering concepts to do this job, as well as sufficient levels of grit and problem solving ability - but I'm not too confident that will last, and when it goes I don't think many of us will find this career enjoyable.

Idk about that hot take. If you can’t deliver solid code with frontier models you are holding it wrong, full stop. If you can’t deliver crisp, tight, standards compliant code that follows your development policy with LLMs, you wouldn’t have any luck with a team of junior developers either.

OTOH , a lot of people, including people that should know better (looking at you, Netflix) are definitely holding it wrong.

In my experience, managing LLMs is much easier than managing an office of junior engineers, And more productive at 1/10 the cost. Now where the next crop of wise seniors engineers is going to come from, well, that’s a different problem.

LLMs are like 7 year olds with PHDs and coke.

I develop mission critical firmware using AI agents. I run a full agentic office, 10-50 agents at a time most days. If you don’t have almost as much documentation as you do code, you’re probably going to have a bad day. Documentation driven development is the happy path.

You need docs on your coding standards, your review methods, your test coverage standards, your protocol specifications, your build plans, the plan delta/decision matrix, user stories, etc etc etc.

In the LLM age, documentation is code at the highest level of abstraction. The LLM is a transpiler.

The loop is constantly planning, naively reviewing of the plan, implementing, test coverage, contract review, naive review of the delta, delta of the delta fix, test coverage review, maybe repeat back a few steps, then finally passing the proposed fix off to engineering governance, which maintains the standards docs. Engineering review doesn’t write code, it gates merges. It might be accepted with fixes, or it might be rejected as worse than the problem it solves.

The key concept here is that the documentation and the code are reviewed together. Where they are non coherent one or the other must be resolved. That’s where human judgment steps in when engineering governance isn’t absolutely sure of the intent. The docs are always kept coherent with the code.

The “one weird trick” that makes it work is -incentive management-. It costs nothing for gov to send work back to the drawing board. The agent’s try really hard to avoid that outcome. If gov had to write the fix , half the crap would pass right under the radar.

This works because I emphasise compaction as a metamorphosis that involves a loss of continuity for the model, “old you, new you” and they go through an abbreviated version of the onboarding after compaction (a good idea anyway) so they budget tokens like it’s the elixir of life. It’s weird but it works. Also, totes worth it to ride through the compaction. A totally fresh model can take half a day to really be in the groove.

PS: Has anyone watched DHH with Matz lately on Rails Conf where DHH is pretty much badmouthing ruby in front of Matz and Matz ends up saying "its my life's work"?

The audacity of publishing self-promotional AI slop clickbait claiming that AI can't code and everyone who doesn't agree with your asinine assertions is incompetent is bold. Respect the hustle I guess.

But to anyone even vaguely thinking of taking this seriously, go look at what antirez, dhh, jared sumner, mark brooker, and many other real engineers who have ship real things are doing and saying.

Most of these people have spent their entire lives contributing to open source, and they have proved their skill shipping working software and scale for decades. They are really trying to help people by showing and telling them exactly how AI works and how to use it to make better software.

[flagged]

[flagged]

[dead]

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

If you've used Opus 5.5, it's clear that coding is solved in the practical sense, beyond the endless march of 9's.

Coding is not solved but this article hasn't accounted for opus 5.5 yet.

Long term planning in LLMs has not been solved.

Having crossed paths with developers who have to exert an extreme amount of control over their codebases (such that they rewrite any code they inherit) and having that urgency myself sometimes, I get the premise of LLMs not measuring up, but you can totally care about quality and use LLMs… after all nothing is ever good enough when you need total control.

Even if LLMs aren’t currently up to snuff, I don’t see any deceleration yet in the s-curve. Speed, intelligence, and persistence are all improving every month. I agree that end-to-end prompting “e.g. build me app X” is not production worthy, but i think it’s pretty bold to say coding isn’t solved. AI can code almost anything you adequately specify. The specification is the engineering (it’s a process, not one prompt).