--- title: Coding is not solved | daily.dev description: A long opinion piece argues that AI coding tools have not solved software engineering, distinguishing cheap code creation from the harder, costlier work of... canonical: https://daily.dev/posts/coding-is-not-solved-v8peh1uj6 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Coding is not solved | daily.dev og:description: A long opinion piece argues that AI coding tools have not solved software engineering, distinguishing cheap code creation from the harder, costlier work of... og:url: https://daily.dev/posts/coding-is-not-solved-v8peh1uj6 og:image: https://api.daily.dev/og/posts/v8peh1Uj6.png og:image:alt: Coding is not solved og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Coding is not solved **[Lobsters](https://daily.dev/sources/lobsters)** · 43 min read · 0 upvotes · 0 comments ## Summary A long opinion piece argues that AI coding tools have not solved software engineering, distinguishing cheap code creation from the harder, costlier work of maintenance, reliability, security, and scalability. The author, an early AI adopter who built his own harness and AI products, contends LLMs remain fundamentally stochastic and struggle with logic, making them unsuitable for accountable, low-risk-tolerance domains like healthcare, finance, and aviation. The piece catalogs where AI genuinely helps (mapping, generation, reduction, search) versus where it shouldn't be used, critiques Anthropic's Claude Code for shipped bugs and Boris Cherny's 'coding is solved' stance, disputes claims like 'taste is leverage' and 'agent is the new compiler,' and argues engineers must retain deep understanding to stay accountable, closing with predictions about new engineering roles (technical PMs, AI managers, AI deployment/quality engineers) that may emerge as the economics of software shift. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why do critics say Claude Code has quality problems despite Anthropic's 'coding is solved' messaging Reported GitHub issues describe the Claude Code CLI binary installer silently deleting itself after installation, and users being charged extra usage despite having available plan capacity alongside false rate limit errors. Anthropic controls the model, harness, leaked system prompt, and runtime (Bun) end to end, which critics argue makes these flaws harder to excuse as someone else's fault. _Anyone weighing Claude Code against other AI coding tools can track real-world issues like these on daily.dev._ ### What are good use cases for AI coding tools versus cases where AI should be avoided AI works well for proof-of-concept work, personal software, throwaway automation with high risk tolerance, and natural-language mapping tasks like translation or format conversion. It should be avoided for legally accountable systems, embedded or low-power applications, privacy-sensitive operations, and any task deterministic code (regex, SQL, a simple function) can already do faster and more reliably. _Developers deciding where AI fits their workflow can compare these tradeoffs on daily.dev._ ### Why can't AI be held accountable for code it generates the way a human engineer can AI cannot suffer consequences such as fines, job loss, or prison, so it can never be held legally or professionally accountable for its output. Responsibility requires control, and a model with jagged, inconsistent intelligence and no memory of consequences cannot be controlled the way a human employee can, making the human who ships the code the one ultimately accountable. _Engineers navigating AI-assisted workflows can weigh accountability questions like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 1082 comments across lobsters, hackernews (as of 2026-10-01). **TL;DR:** Reaction is deeply split: many argue the piece misjudges current LLM capability and that 'software was always buggy anyway,' while others strongly agree that speed-obsessed AI adoption is degrading quality and accountability in critical systems. **Sentiment:** 20% positive · 40% mixed · 40% skeptical **The case for** - LLMs can automate exhaustive fuzzing, tracing, and scenario analysis that would be impractical for humans to do by hand. - Some argue AI-generated codebases can be made more understandable than human-written ones if paired with clear architectural docs, ADRs, and acceptance criteria. - A few see LLMs as effective at finding and fixing long-standing, hard-to-diagnose bugs. **The pushback** - Many argue LLMs don't truly understand or logically reason about code, so testing and tracing don't equal comprehension. - Several say the real problem is organizational: executives demand 3-5x velocity while cutting the QA/SRE roles needed to safely review AI output. - Some contend AI is accelerating the production of low-quality 'slop' at unprecedented speed, citing perceived rising bugginess in daily software. - Skeptics dispute the 'reading code isn't understanding' argument, saying distinguishing battle-tested, trusted libraries from freshly AI-generated code is essential and currently impossible for the latter. - Commenters working in healthcare/finance/defense pushed back on the idea these fields are rigorously verified today, saying codebases there are already brittle and poorly understood regardless of AI. **By community** - hackernews (heated): A long, contentious thread with camps arguing over whether software quality has genuinely declined post-2024, whether LLMs 'understand' code, and whether critical industries were ever as rigorous as claimed. - lobsters (mixed): No substantive comments were provided, so no clear take can be drawn from this source. **Hottest debate:** Whether the current wave of AI-driven coding has made software worse/more fragile than before, or whether people are romanticizing a pre-2024 era that was already full of bugs and technical debt. **Open questions** - Is software quality actually declining post-AI-adoption, or is this perception bias/rose-tinted nostalgia about pre-LLM code? - Can AI-generated code ever become 'battle-tested' and trusted the way long-standing libraries are, given trust and fragmentation concerns? - What happens to on-call, incident response, and accountability structures as teams shrink due to AI-driven productivity claims? **Highlights** > 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. > — [efficax on hackernews · 26 comments](https://news.ycombinator.com/item?id=49878532) > I mean, I think the problem isn't that the LLM doesn't know how to code, it's that companies are expecting 3-5x velocity with the bottleneck of code review and testing becoming much more severe than before if you're an MBA-brained exec who doesn't actively use LLMs to code and you just believe whatever slop it outputs at first without checking it, you're not going to realize how recklessly it can be used, how you need to be critical and skeptical of its outputs, that you need to explore it's reasoning and logic (which is still really easy compared to understanding legacy code and barely takes any time!) say you also believe all this marketing hype about 'how dangerous (ie capable) AI agents are.' LLMs can do anything you think so you just say 'ship it' without building out the tooling and capabilities to enable faster code review and better tests. and to keep the shareholders happy, you start cutting jobs that you can't directly connect to a KPI (ie the platform/SRE team who would be the ones who can trial, onboard, and maintain those capabilities for your teams) and from this, suddenly a lot of debit card stops working and the only one getting the blame are individual SWEs trying to hit their sprint velocity. the fact that you fucked up the whole SDLC real bad with your incompetence gets you a golden parachute and you job hop to a better paycheck. rinse and repeat > — [paimapi on hackernews · 1 comments](https://news.ycombinator.com/item?id=49879308) > > Your debit card transactions for example worked. I've built payment rails. Six nines SLA, high capacity, resilient distributed systems. I haven't written a single line of code since February, and I don't think I ever will again. These systems are incredibly good at replacing much of our work. They're only going to get better. Rather than debating if these models are good (they are), we should be trying to figure out if most of us will still be around in three years. You don't need a two pizza team anymore. "Look to the person to your left and to your right. Only one of you will remain by graduation" kind of energy. I'm not sure all of us is going to be in this career much longer. We'll have to see what the demand side looks like. > — [echelon on hackernews · 7 comments](https://news.ycombinator.com/item?id=49879369) > The person they responded to refers specifically to "healthcare, finance, automotive, defense, power plans, aviation, manufacturing", areas where I'd at least hope that we aspire to understand what the code does. > — [boomlinde on hackernews · 5 comments](https://news.ycombinator.com/item?id=49880939) > In many codebases when you see this happening it is because someone reported a bug and the dev fixed the narrowest instance they could. Typically if(some specific case) do_fix() else do_normal(). Over time this fragments meaning in the source and makes it harder to reason about until it is a giant pile of slop. The thing the dev should do that often doesn't get done is to take the information about the undesired behavior back up to the design/spec level and rework the definition to account for it. This doesn't normally get done because it takes longer and it is conceptually more difficult than the patch. This is something that LLMs can accelerate significantly and the result is a shallower gradient of technical debt over the long term. > — [amoss on hackernews · 1 comments](https://news.ycombinator.com/item?id=49889036) **Source threads** - [lobsters](https://lobste.rs/s/iqapj6/coding_is_not_solved) · 1 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=49877988) · 570 points · 1082 comments ## Similar posts on daily.dev - [Why Some Companies Are Pulling Back on AI Coding](https://daily.dev/posts/why-some-companies-are-pulling-back-on-ai-coding-pfrs6ovwx) · SD Times · 2 upvotes · 1 comments - [The AI coding hangover](https://daily.dev/posts/the-ai-coding-hangover-5hylutrto) · InfoWorld · 1 upvotes · 0 comments - [Reasons to dislike AI coding](https://daily.dev/posts/reasons-to-dislike-ai-coding-eqykokja7) · Lobsters · 0 upvotes · 0 comments --- Tags: [#llm](https://daily.dev/tags/llm), [#ai-coding](https://daily.dev/tags/ai-coding), [#claude-code](https://daily.dev/tags/claude-code) [View this post on daily.dev](https://daily.dev/posts/coding-is-not-solved-v8peh1uj6) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Coding is not solved","url":"https://daily.dev/posts/coding-is-not-solved-v8peh1uj6","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/coding-is-not-solved-v8peh1uj6"},"datePublished":"2026-09-30T20:58:46.304Z","dateModified":"2026-10-01T08:04:13.037Z","description":"A long opinion piece argues that AI coding tools have not solved software engineering, distinguishing cheap code creation from the harder, costlier work of...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/20d41866f1620ca3c482bae50a0fad12?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/20d41866f1620ca3c482bae50a0fad12?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/coding-is-not-solved-v8peh1uj6","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"llm,ai-coding,claude-code","timeRequired":"PT43M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Coding is not solved"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/coding-is-not-solved-v8peh1uj6#faq","mainEntity":[{"@type":"Question","name":"Why do critics say Claude Code has quality problems despite Anthropic's 'coding is solved' messaging","acceptedAnswer":{"@type":"Answer","text":"Reported GitHub issues describe the Claude Code CLI binary installer silently deleting itself after installation, and users being charged extra usage despite having available plan capacity alongside false rate limit errors. Anthropic controls the model, harness, leaked system prompt, and runtime (Bun) end to end, which critics argue makes these flaws harder to excuse as someone else's fault. Anyone weighing Claude Code against other AI coding tools can track real-world issues like these on daily.dev."}},{"@type":"Question","name":"What are good use cases for AI coding tools versus cases where AI should be avoided","acceptedAnswer":{"@type":"Answer","text":"AI works well for proof-of-concept work, personal software, throwaway automation with high risk tolerance, and natural-language mapping tasks like translation or format conversion. It should be avoided for legally accountable systems, embedded or low-power applications, privacy-sensitive operations, and any task deterministic code (regex, SQL, a simple function) can already do faster and more reliably. Developers deciding where AI fits their workflow can compare these tradeoffs on daily.dev."}},{"@type":"Question","name":"Why can't AI be held accountable for code it generates the way a human engineer can","acceptedAnswer":{"@type":"Answer","text":"AI cannot suffer consequences such as fines, job loss, or prison, so it can never be held legally or professionally accountable for its output. Responsibility requires control, and a model with jagged, inconsistent intelligence and no memory of consequences cannot be controlled the way a human employee can, making the human who ships the code the one ultimately accountable. Engineers navigating AI-assisted workflows can weigh accountability questions like this on daily.dev."}}]} ```