- 38comments
- 80comments
- 4comments
- 31comments
- 78comments
- 25comments
- 51comments
- 9comments
- 383comments
- 233comments
- 826comments
- 222comments
- 54comments
- 62comments
- 99comments
- 63comments
- 56comments
- 11comments
- 61comments
- 18comments
- 2comments
- 148comments
- 45comments
- 296comments
- 103comments
- 5comments
- 22comments
- 117comments
- 110comments
- 8comments
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.
I mean, as far as counter arguments go, github had plenty of downtime before LLMs, and they didn't deal with exponential growth then. If you don't count the "it gets harder" side but only counts the "they had problems" side, then yea, that might look bad, but that's not very honest imo.
Not looking up the outage stats for Github (not sure how accurate they are historically). But going off by what I notice on HN the past months / year, it definitely seems like GH is experiencing more downtown than pre-2022.
But maybe I'm misremembering how fragile GH was in the 2010s.
You are too civilized: I recommend threatening drop kicks to insufficiently smart rebuttlers.
"Coding is solved" will eternally remain 6 mo away, as long as the investors keep pumping in money.
And as long as we keep changing the meaning of coding!
Its the fusion power of programming
Ironic, given I've used an agent to help me simulate a fusion reactor.
Just a simple reactor, my laptop's only little. But still.
Frankly, I don't really see how it isn't solved, even with the current state of LLMs. Frontier models can write, understand, correct, and optimize code in practically any language at a superhuman level. I haven't come across a single problem that LLMs can't solve. You can easily give them a research paper, ask them to implement it and in an hour or two it's done. Or even point them to a video or screenshot of something and say "implement this feature in our game engine" and... they just do it. It might not be optimally perfect, but what % of human written code is? Even if you ignore the time amortization (given how models can spit out weeks of human work in an hour) they still obliterate even an experienced developer.
coding is solved, software engineering not.
Different words for the same thing. The idea that "coding" is just turning a spec into source code without any engineering decisions to be made was always laughable, for that to happen the spec would need to be as detailed as the source code (of course the whole idea that spec and code are separate things doesn't make a lot of sense).
LLMs even a version number or two ago can write all the code I've ever been paid to write in the last 20 years; but they are not, I think, yet competent enough to be able to handle the project planning and self-QA I was doing even in my first 6 months of my first job after graduating.
That's not a boast, I don't think I was particularly good at that back then, e.g. I didn't really get how to think about automated tests until much later.
It's just to say that no, coding and software engineering are not the same thing. "Code Monkey" is a dead (or perhaps "undead") role now, but it wasn't always so.
Coding is not solved but this article hasn't accounted for opus 5.5 yet.
Long term planning in LLMs has not been solved.
I'm sure Opus 5.5 is smart and probably the next version gets even smarter. The main point of the article is accountability and that's not something we can delegate to AI.
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.
This is true, real, and impressive. However, a comment I posted on HN a couple months ago might counterbalance this fact:
GitHub's Copilot cloud agent offering is suffering with a case of some of the worst corporate ADHD I've seen. We built a cloud agentic development pipeline on it, and it seems like almost every other week they silently change something with zero public announcement or documentation that creates real disruption for our team.
That's real, breaking changes to the platform that clearly aren't being tested/reviewed before being pushed to prod. Again with zero public announcement or documentation.
Support is useless – we're paying customers in the 4-5 figures and our tickets go unanswered.
File by file porting can be done almost always with local reasoning. I don't think it proves much for novel projects which still seems to crumble under complexity past a small sloc limit.
Porting a system to rust without changing the observable behavior is not that difficult with AI, and porting to a more strict language is not that remarkable. I have a tough time understanding why people equate straight shot porting where a test suite already functionally documents the behavior or where the prior application can be used as an oracle with success in all coding tasks. I would be far more impressed if someone did a clean room implementation of all of GitHub Copilot, from scratch, and got to a better point than the TypeScript or port codebase.
I have no doubt that if you provide any AI system with an oracle with expected behavior that it can match that oracle with some amount of $ and tokens. I haven't seen any demonstration of anything else. Rewriting a codebase was always a challenge for humans not because of complexity, but because of the time and effort involved in matching the old version's prior behavior. It doesn't have anything to do with the serious level of work required to build something truly new from scratch in a performant way.
Seriously? I have no idea where this cognitive dissonance comes from. Or are people just lying (outwards or to themselves)? A rewrite of this magnitude would easily take a skilled human team months if not years to finish. This is on top of Rust not being an easy language to work with. Which, btw, is the sole reason why not everything is written in C/C++/Rust.
Impressive numbers for a piece of software no one asked for and doesn't make the experience better.
$120k to port 430,000 loc seems quite expensive. That's dozens of cents per line of code, and equivalent to the all-in cost of a senior engineer in London for a year.
Especially expensive when you take into account the amount of that code which must have been boilerplate & meta-code in nature, meaning it should have been straightforward to move.
...and what's your point? Github isn't exactly a beacon of performance or robustness in recent months...
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.
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.
Even if you are competent I cannot review your 5,000 lines of code you produce per day vs the 100 you were producing before the LLM apocalypse.
5,000 is the output velocity of someone not fully immersed in agentic coding. I've seen repos do ~100k to ~250k loc changes per week.
I mean these guys are not even pretending to be reviewing the code.
It just gets “reviewed” by an LLM, which will find a nitpick while ignoring the huge fire in the core of the design, force the planner to make even more sloppy code to cover for an irrelevant test case. Rinse old tokens and repeat until you hit limits.
Brings to mind this classification https://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord#Cl...
"""I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage"""
The problem here is that AI is consistently one of the four things: hardworking. This makes it very efficient at transforming "stupid and lazy" inputs into "stupid and hardworking" outputs.
Now instead of 90% stupid and lazy (harmless, useful for grunt work) you have 90% stupid and hardworking (aggressively causing damage).
Limitations of AI are a thing; but one rhetorical point keeps coming up (I don't think it's just you) and confusing me:
Are you expecting humans to be deterministic in the code they produce?
Someone who knows that 1 + 1 = 2 will not decide that it's suddenly 3 unless we start accounting for health problems. Making mistakes is not the same as non-deterministic.
And?
The p(that kind of error) is pretty small now. At what point does a probability coming out of an LLM look like "knowing", such that spitting out the wrong answer despite that probability looks like a health problem, a typo, or even just boredom? (Thinking of the Lizardman constant here: https://en.wiktionary.org/wiki/Lizardman%27s_Constant)
It's a continuum for both them and us, even if the mechanism is wildly different.
i.e. when the dismissal is "non-deterministic" when it should be "Making mistakes", is itself a mistake.
Lol, humans make such absurd mistakes (and worse) all the time through simple typos, which is effectively random. The key for 2 is right next to the key for 3, after all.
In other words AI is a multiplier.
"optimize this code", "fix this code", "extend this code", "add this feature", "find errors and patch them", "find bugs and fix them", "rewrite this from python to rust".
This is all that's needed to actually use LLMs nowadays. How is it a "multiplier" rather than an "equalizer"?
Because without the responsible human engineer in the loop, it'll all gradually decay in a cascade of edge-cases. This happens with human written code as well (every "we'll replace this prototype before we ship" you've ever worked on), but with LLMs it happens at 10-100x the rate.
You will be surprised how many times, catches errores made by the AI coding agent. However,as you point, isn't deterministic. And you can guarantee the end results is 100% fine code
What I in general try to teach the other people about AI: It can be a great tool, but check the results! Especially in the case of engineering: Check and then double check.
Honestly, I would still rather commit claude written code from lazy and incompetent developers than code that they wrote.
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.
Yeah I have a well established ... well designed codebase that I had before agentic coding and it does support horizental scaling (more services integrations doing more or less the same).
I got lazy around claude fable and astra, and asked them to work in loop (pick specified issue, develop it, qa it ...) have a separate CTO checking on arch.
at the end both models swore that the code is perfect and well designed and nothing is lacking.
I ran the software and it suddenly started writing large amount of data to CSV files instead of the typical DB usage.
AI decided to use csv for testing, and just drifted away. 0 regards to the actual project, 0 regards to common sense.
anecdotal but really weird, the project category is rather standard, I wouldn't accept such a mistake from a junior developer.
Isn't it the opposite? How to build something is rather solved, but what to build isn't?
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).
I do think that was a dumb gotcha. That list could've functioned with bullets instead of numbers as the content was unordered. I suspect very few people would pay attention to the numbers there.
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.
Came here to give an answer but your last sentence kinda made the point I was gonna make. If one is legally in control, then one is accountable (the dog or unsafe toy example in reality is OpenAI's agents hacking huggingface for example).
The difference seems to be that some companies are above the law apparently.
Dear lord. Is that supposed to reflect the average thoughts and motivation of a person you want to hire? Or that of their employer?
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.
Very little of the article is actually focused on stochasticity. I'd also say drawing an equivalent between the non-determinism of a person and an LLM is not that accurate either.
It's for example impossible to have a discussion with an LLM where you both learn something which you can apply tomorrow. The LLM doesn't learn until the next model is released and by then your discussion is just a tiny fraction of the training data (if present at all). AGENTS.md, skills and so on are just a proxy for what we actually want, an agent that listens and understands. A proxy mind you, that requires constant tweaking with no sign of generalisation in sight.
Does humans being non-deterministic make coding solved? I'm not sure how this relates to the main point.
I'm also not sure what humans being non-deterministic even means here. The point is if you're comparing results with NFR, pure agentic coding falls short.
Humans are non-deterministic.
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.
"AI can explain it to you but cannot understand it for you". Code is just a side-effect of reaching clarity. The reason these LLMs can emit any code at all is because they're not bound by the constraints of a compiler. That's until we create a feedback loop and force them to keep trying until syntax errors are gone. The next gate is tests. Loop till tests pass (including cheating of course, gotta keep your eyes open). Then there are the runtime errors, and then after all of that the developer gets to test the results and further refine what the specs missed or confused the model. A couple of days building can really save us from a couple of hours of thinking.
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.
Does that really matter? Those are things so that humans can better understand and extend a code base. That mattered when writing code was expensive and took time.
Now if it can pass all the tests it’s fine. If there’s an issue just have it rewrite things immediately. New bug? Generate a new test and rewrite code.
All, or many, of the old things that mattered just sort of don’t anymore.
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.
Strange that the world worked before 2024 and software gets worse now. Your debit card transactions for example worked.
This sounds like a typical testimonial whose mind has become captive to Claude. It is like Scientology.
I’m using it a bunch. It saves a ton of time writing or reviewing code. It will catch things I won’t. But I’d express caution about the analysis or evaluation they do - LLMs will often confidently proclaim problems as solved or explain functionality and be wrong about it. Sometimes subtly, but sometimes just completely wrong. This is no different from humans, of course, except for the unabated confidence.
"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.
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 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.
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".
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".
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.
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.
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.
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.
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.
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.
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.
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.
What’s your number?