--- title: 2x, not 10x: coding with LLMs in 2026 | daily.dev description: A software engineer shares a measured, first-hand assessment of LLM-assisted coding as of mid-2026. The core argument is that LLMs have crossed a key threshold... canonical: https://daily.dev/posts/2x-not-10x-coding-with-llms-in-2026-q2imfzgcu twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: 2x, not 10x: coding with LLMs in 2026 | daily.dev og:description: A software engineer shares a measured, first-hand assessment of LLM-assisted coding as of mid-2026. The core argument is that LLMs have crossed a key threshold... og:url: https://daily.dev/posts/2x-not-10x-coding-with-llms-in-2026-q2imfzgcu og:image: https://api.daily.dev/og/posts/Q2iMfZgCU.png og:image:alt: 2x, not 10x: coding with LLMs in 2026 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. # 2x, not 10x: coding with LLMs in 2026 **[Hacker News](https://daily.dev/sources/hn)** · 5 min read · 0 upvotes · 0 comments ## Summary A software engineer shares a measured, first-hand assessment of LLM-assisted coding as of mid-2026. The core argument is that LLMs have crossed a key threshold — they can reliably operate in automated feedback loops — but this doesn't translate to a 10x productivity boost. The author estimates a 2x improvement at best, because LLMs still struggle with code maintainability, documentation quality, and architectural judgment. Key practical insights include: using LLMs for rough drafts then iterating heavily, banning LLMs from writing documentation entirely, and noting that a working implementation now represents only ~20% of the work rather than 80%. The author is skeptical that further model improvements alone will close the gap, suggesting the bigger gains will come from industry retooling around existing model capabilities. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 315 comments across hackernews (as of 2026-08-03). **TL;DR:** The community largely agrees that LLMs provide real productivity gains, but debates whether the multiplier is 2x, 10x, or 'infinity-x' for tasks that wouldn't have been attempted otherwise; a significant thread questions code quality, review standards, and whether speedups in coding translate to overall productivity gains. **Sentiment:** 40% positive · 40% mixed · 20% skeptical **The case for** - LLMs enable 'infinity-x' productivity for projects people would never have attempted without them — personal tools, experiments, hardware design exploration. - Experienced developers in mastered domains report genuine 10x+ speedups because they can quickly validate LLM output. - LLMs lower activation energy for validation and experimentation, enabling more thorough testing and data-driven decisions than before. - Bespoke, small-scale software for personal or niche use cases is now accessible to non-coders and time-constrained developers. - LLMs free up time for previously neglected work like refactoring, documentation, and infrastructure improvements. **The pushback** - Code quality has dropped significantly — AI-generated code is often undebuggable, architecturally incoherent, and would not have passed code review a year ago. - Amdahl's Law applies: coding is only ~25% of software engineering work, so even a large coding speedup yields modest overall productivity gains. - LLMs can lead developers to rapidly build and abandon bad ideas, wasting time that might otherwise have been spent on validation. - AI-generated comments and documentation are widely criticized as verbose, vague, and misleading rather than genuinely helpful. - Lowered review standards ('LGTM, it'll be fine') are creating technical debt and shipping broken features that would previously have been caught. **By community** - hackernews (mixed): Commenters are split between genuine enthusiasm for productivity unlocks — especially for tasks never previously attempted — and serious concerns about code quality, review standards, and whether raw coding speedups translate to real-world output improvements. **Hottest debate:** Whether LLM-assisted productivity gains are real and large (10x+) or illusory due to lower code quality, reduced review rigor, and the fact that coding is only a fraction of total engineering work. **Open questions** - How will junior developers build the foundational expertise needed to evaluate LLM output if they never write code by hand? - When AI subsidies end and novelty wears off, will the economic value of all this bespoke/tinkering software justify its cost? - Is there a sustainable way to maintain code quality and architectural coherence in LLM-heavy workflows without human review? - Can formal methods or statistical quality control replace human code review in agentic pipelines? **Highlights** > Let's apply it: - 25% planning & aligning with other teams - 25% coding - 25% testing/verifying - 25% code review/rework I'd say that thanks to LLM assistance I'm 10x faster at coding, code review/rework, and testing/verifying. (LLMs can partially automate testing/verifying too, and the code is higher quality now as well so less testing/verifying is necessary). So that leaves us with: - 92.5% planning & aligning with other teams - 2.5% coding - 2.5% testing/verifying - 2.5% code review/rework Obviously, that makes zero sense as a split. If you saw any organization doing that, you'd suggest having fewer teams, more silos, etc. Maybe you have designers produce code, instead of showing the designs to coders and having the coders implement it. Maybe you force all your engineers to dogfood the product that way they can identify issues themselves rather than needing QA teams to do it. And so on. so the last category, "planning & aligning with other teams", falls too. > — [ChadNauseam on hackernews](https://news.ycombinator.com/item?id=49115521) > We have entered the era of small software, and no one knows what it will grow to. Here's an example: my office has a few cars for employees to use as rentals. The number is small enough that it would never be worth any serious software dev to build a tool to manage, but large enough that its a moderate amount of work for someone to manage the requests/getting supervisor approvals/schedule changes due to breakdowns. AI one-shot that guy a tool. Its now dead simple, he's got a calendar, automatic emails going to people's supervisors with click-here-to-approve links, rescheduling options, fleet management. It doesn't even look bad. Who cares if its using some un-backed-up sqlite database in the backend, has some placeholder tab for a feature he changed his mind about, or violates the DRY principles a bunch or uses some inferior authentication mechanism. Its an in house tool, isn't mission critical, and it makes his life significantly easier. Basically everyone is now a few prompts away from their own bespoke tools, and only they will be able to judge the benefit thereof. Edit: to tie this more directly to the article, I would argue that this is an example of "infinity-x" coding, because the user was in fact not capable of coding a solution on their own without AI. > — [bloaf on hackernews](https://news.ycombinator.com/item?id=49118123) > This will be a deeply unpopular opinion, but I have an 80k line Go project I've created where I haven't read the source, but would absolutely stake its quality against most hand-written projects of a similar size[0]. Recent LLMs struggle with the author's stated issues only inline: they're entirely capable of going back and evaluating codebases to find architectural issues and LLM slop signatures, especially when you use other models to check one model's output. This wasn't true until Fable-class models, but it's true now. 0: https://github.com/pjlsergeant/byre > — [petesergeant on hackernews](https://news.ycombinator.com/item?id=49115363) > Yes, exactly my point. BUT, to me if we hadn't lowered the bar MASSIVELY, it would NOT be fine. I've seen people at my work that will push or even deploy features that don't do what their main purpose is and they just dismiss the issue saying it's a bug. As an example, a button that's supposed to open a modal window if you click on it. If you go test it and the modal doesn't open, they'll say "oh, there's a bug". You developed or even deployed something that is wrong and completely useless. Just one year ago, this would be unheard of and you would've gotten a really hard time for it. Now it's just a bug and part of how we're doing things. Like I said, I just do what I'm told at work but to me this is just wild. There's no way it won't come back to bite us. > — [altern8 on hackernews](https://news.ycombinator.com/item?id=49116011) > > So maybe there's 2x speedup in coding. But that's only a small speedup in the totality of everything software engineers do. Amdahl's Law should be familiar to anyone with a 4y computer science/engineering degree. Why aren't they applying it to their own throughput? > — [whateveracct on hackernews · 2 comments](https://news.ycombinator.com/item?id=49114499) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49047839) · 168 points · 315 comments ## Similar posts on daily.dev - [Software Development in 2026](https://daily.dev/posts/software-development-in-2026-q2wl4qawy) · Beam Bloggers Webring · 4 upvotes · 0 comments - [My LLM coding workflow going into 2026](https://daily.dev/posts/my-llm-coding-workflow-going-into-2026-vi9oycjke) · Elevate · 176 upvotes · 5 comments - [The Future of Software Development is Software Developers](https://daily.dev/posts/the-future-of-software-development-is-software-developers-clpbexose) · Hacker News · 8 upvotes · 2 comments - [LLMs and performative productivity](https://daily.dev/posts/llms-and-performative-productivity-yvgqj9ifi) · Lobsters · 0 upvotes · 0 comments --- Tags: [#llm](https://daily.dev/tags/llm), [#productivity](https://daily.dev/tags/productivity), [#ai-coding](https://daily.dev/tags/ai-coding), [#vibe-coding](https://daily.dev/tags/vibe-coding) [View this post on daily.dev](https://daily.dev/posts/2x-not-10x-coding-with-llms-in-2026-q2imfzgcu) ```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":"2x, not 10x: coding with LLMs in 2026","url":"https://daily.dev/posts/2x-not-10x-coding-with-llms-in-2026-q2imfzgcu","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/2x-not-10x-coding-with-llms-in-2026-q2imfzgcu"},"datePublished":"2026-07-30T19:47:46.893Z","dateModified":"2026-08-03T10:46:40.083Z","description":"A software engineer shares a measured, first-hand assessment of LLM-assisted coding as of mid-2026. The core argument is that LLMs have crossed a key threshold...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6588417d765d35b3c6a6217c6d784264?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6588417d765d35b3c6a6217c6d784264?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","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":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/2x-not-10x-coding-with-llms-in-2026-q2imfzgcu","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"llm,productivity,ai-coding,vibe-coding","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"2x, not 10x: coding with LLMs in 2026"}]} ```