Rendered at 09:39:37 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pantelisk 13 hours ago [-]
While I agree with the premise, I think this angle only applies on work one was going to do no matter what. The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue.
So the comparison is not only "built with and without LLM" but "would you even build this if you didn't have the LLM?". The gap in productivity in this case is much more wide.
overfeed 12 hours ago [-]
> The real power of these tools is that there are so many ideas people would like to try, but never have the time or motivation to pursue.
This can be a negative multiplier: code I thought I wanted that gets immediately abandoned is a net-negative if no one else wants it (lets face it, this is the safest default posture for software of unknown providence).
In isolation, instant-abandonware takes up hdd space, burns dependabot's CPU-cycles, and wastes human attention when appearing in search results. In aggregate, it floods the zone with a deluge of forks with imperceptible differences between them, based on nit-picks, legitimate stand-out products will have a much harder time going forward.
mardef 12 hours ago [-]
Not every engineering effort is a product in search of market fit or a community.
Some things are already very useful as just a one shot. I just made a quick app to help me pack for a trip, it updated forecasts every day, let me know when rain entered the forecast at one of my stops and gave me a checklist that helped me quell my travel anxiety.
The greatest thing that LLMs have done is allow many to achieve things that they couldn't have before. I'm incredibly disinterested in "I can do the same thing I was already doing x% faster"
twister2920 10 hours ago [-]
> gave me a checklist that helped me quell my travel anxiety.
it's truly fascinating how many positive descriptions of AI gesture at emotional management. I think that's the killer feature of this technology -- it makes people feel good, capable, reassured -- without the risk and vulnerability of interacting with another human.
I use Google Weather for my forecasts btw, no need to vibecode an app for that
overflow897 8 hours ago [-]
Gathering forecasts for each leg of a trip only on the particular days for the particular location is tedious. Anyone can do it with google weather but why spend the time when you don't have to.
I can keep track of my expenses on a napkin but i'd much rather use a spreadsheet or dedicated app especially when that app is effectively free.
overfeed 12 hours ago [-]
> Not every engineering effort is a product in search of market fit or a community
I think you misunderstood my point: by "legitimate stand-out products", I meant exactly that, with no connotation of commercialization. Maybe you can agree that having a high signal-to-noise ratio for (open source) projects is a desirable goal?
> Some things are already very useful as just a one shot.
I agree. I too have made or forked about a dozen apps and tools in the past few months. It would be dishonest not to consider the flipside, that this software is overfitted to the needs of a single person. Further, this hyper-bespoke software typically feature-complete within moments of the final prompt, and I have,on occasion, completely forgot about the tool/app I spent a weekend created, it clearly wasn't worth the effort I put in.
> The greatest thing that LLMs have done is allow many to achieve things that they couldn't have before.
Let's not pretend there isn't a cost to this.
mkl 1 hours ago [-]
> by "legitimate stand-out products", I meant exactly that, with no connotation of commercialization
The word "product" implies commercial.
overfeed 5 minutes ago [-]
> The word "product" implies commercial.
I disagree; but see where you're coming from. I'm chuckling at the irony of my word-choice: I initially had used "project" but nixed it because of its frequent association with Open Source. I instead opted for "product" as a broader term. For the sake of clarity, my original comment is referring to commercial and non-commercial software projects/products.
jatora 5 hours ago [-]
This is wrong. Someone else wanting it is irrelevant. If it solves a need you have, that is a win. Not every piece of software needs to be a market fit. Not everyone wants to grind out an existence marketing software. And rapidly that type of business is going to go byebye
jcelerier 11 hours ago [-]
> This can be a negative multiplier: code I thought I wanted that gets immediately abandoned is a net-negative if no one else wants it (lets face it, this is the safest default posture for software of unknown providence).
obviously not ? negative result is still a result, just like in science. It adds new information ("approach X does not work" / "is useless") which is the only thing that matters
steve_adams_86 10 hours ago [-]
You made me do a double take with "providence". I think the word you wanted is "provenance", which comes from latin "provenire" (pro -> forth, venire -> come). English has too many similar words.
Unless you only run code that's protected by God. That's probably not a bad policy if you can verify it.
We’re at the point where people who talk too fancy get accused of being LLMs, and the people who make human mistakes get scolded for grammar.
jwiz 4 hours ago [-]
It seems like constructive criticism rather than scolding.
If I were running around saying "providence" instead of "provenance" I would want someone to tell me.
nathell 13 hours ago [-]
I think the ideas worth pursuing still require substantial time and motivation, even with LLMs. Otherwise you just end up with a half-baked sloppy artifact that nobody will ever use or study, for a net negative benefit to humanity.
bloaf 8 hours ago [-]
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.
supersour 12 hours ago [-]
Yes this is true to some extent. I've been using LLMs to run some computer vision tests, and I've certainly noticed myself running into the trap of "just one more AI experiment", or "just one more change" while neglecting to actually properly integrate the learnings into my mental model.
However, without an agent running its own experiments on a cloud GPU, would I realistically have invested my limited work hours and tried evaluating 10 different models, each with 10 different tuned parameters, to solve my specific use case?
Or would I have tried 1-2 models and spent my time trying to optimize those models?
I think there is some merit to the spray and pray approach when one is in the exploration phase of the solution space.
Also, on more than one occasion now, I have had fable halve the inference latency of a model simply because the original implementation from an academic included unnecessary GPU-to-CPU-to-GPU transfers or similarly inefficient operations. Those optimizations came at essentially 0 time cost to me and I can verify that the outputs are byte-identical. Pretty sweet!
jatora 5 hours ago [-]
People need to abandon the notion of every tool you build needing to fit the market. This is not the direction of software anymore when developers can all build tools that are bespoke to their own workflows and needs.
arjie 12 hours ago [-]
Well, I’m happy just to make half baked slop for myself. Highly personalized software that is poorly implemented and yet yields the result I desire.
E.g. software that generates these models that I can print
There were so many things that no one will ever study and won’t give humanity any benefit but I use everyday to make my life better. That’s enough. The value far exceeds $200/mo. I’m getting it for cheap and now that I have my GPUs and my models they can’t even take it from me in the future if they wanted, haha!
LLMs allow for human flourishing on a massive scale. One of the best inventions to occur in my life. Up there with the Internet/Web. Truly a marvelous time.
rayiner 12 hours ago [-]
> There were so many things that no one will ever study and won’t give humanity any benefit but I use everyday to make my life better
Agreed. I haven’t been this excited by computers since I got broadband DSL in 1998.
coderatlarge 10 hours ago [-]
i consider it as a very specialized subset (subgenre) of video games for a very narrow audience
rayiner 5 hours ago [-]
You know how non-coders basically build crazy business apps in Excel? LLMs, even if they don't get any better, seem at least 10x more useful than Excel. Why do you say it's for a narrow audience?
switchbak 12 hours ago [-]
In this last week, I've performed experiments in an almost fully automated way - parallel to my main work, and easy to orchestrate.
This has led to 3 parallel pieces of adjacent work that each speed up our build by quite a drastic margin. When combined, this is a massive improvement. None of this would have happened in the old days, as the research itself takes a long time to babysit and a lot of options to check.
So I very much agree - the activation energy can be a lot lower on some kinds of tasks, and some of those get big returns for small inputs. It's not all like that, but part of the game is identifying when you can spot those high return efforts.
rsoto2 6 hours ago [-]
Figured out a better way of explaining it:
dev A knows exactly what the program should do and how to verify the AI output
dev B thinks they know what they are doing but are actually misguided by bad psycophantic AI output they have incorrectly verified.
both work on product C
rsoto2 6 hours ago [-]
or the AI could lead you to a completely unusable experiment and lead you to believe it was successful wasting weeks of work. Not saying it will happen to you, but there is a huge "survivorship" bias already in software for what tools are useful or not. Maybe it's the person and not the tools.
jaapz 2 hours ago [-]
Not even just building stuff with LLMS.
I'm doing analysis on stuff that we previously simply couldn't do in my company, it would take way too much time or effort, and we didn't have the manpower.
pron 10 hours ago [-]
Yes, but only in the programming sense of productivity, not in the economic sense. When prices stop being subsidised and the novelty wears off, this will boil down to the question of how much money is that worth? We're already seeing an inflation in such projects, which are becoming hard to even show off. It could be similar to 3D printers. Fun and valuable, with a market size of $25B, but not quite world-changing (I'm not saying AI won't be world-changing, only that this tinkering aspect may not be).
SkepticalWhale 13 hours ago [-]
Yes but I’ve seen some devs waste a lot of time using AI to build something that was a bad idea to begin with.
Without AI they might have first spent more time validating the idea was worth it.
marssaxman 11 hours ago [-]
For me it is exactly the opposite. AI makes it so easy to create test fixtures and run experiments that I now spend much more time validating ideas than I could ever afford to do before. When I write code for production, it's not "this ought to work", it's "here are the figures showing how well this works, on this dataset", where the dataset is also much larger than anything I would have used before, because I used AI to generate the tools which collected and organized it.
skydhash 9 hours ago [-]
> it's not "this ought to work", it's "here are the figures showing how well this works, on this dataset"
The thing with constraints is that you focus of the thing with high value first. So you focus on the most promising ideas first or choose experiments that can get rid of most ideas. Instead of trying to validate each ideas and generate what is most likely noise to the decision process.
Like if I ever hire an assistant, I want like one to three options that are closely aligned to my needs, not a bible size report on 42 choices.
rayiner 7 hours ago [-]
Isn’t it better to be able to quickly test ideas and see what works and what doesn’t?
petesergeant 13 hours ago [-]
> Without AI they might have first spent more time validating the idea was worth it.
Seems optimistic
rayiner 12 hours ago [-]
LLMs open up huge possibilities to do work that you otherwise wouldn't do. I vibe coded a PDF viewer yesterday in a couple of hours using Claude and Grok. I've been itching for a native Mac app that meets some very basic requirements: one window with file tree on the left and tabbed view on the right, with the ability to call out to pdfgrep and jump to results. Like Zotero, but with better multi-file search and a viewer that doesn't choke on big files. Claude built it for me in an hour, and Grok iterated a couple of times to make it better. I didn't look at a single line of code. It's now my default PDF viewer, and I used it today to do a bunch of my real work.
It's a braindead simple program that mostly hooks together pre-existing functionality, it just so happened that none of the widely available apps had the specific mix of features I wanted. I could probably have done it myself in a week if I took time off my non-coding day job to figure out Swift and AppKit. But I wasn't going to do that. I’m psyched. I hate web apps and now I can just write my own for all the little things I use every day.
waynesonfire 9 hours ago [-]
Cool story bro. I used a llm to help me name a variable.
tails4e 13 hours ago [-]
Yes, I work in hardware design ans the cost to code up the RTL for an idea and compare it to the existing code in terms of PPA, its very expensive in terms of engineering time. This week I had 5 different architecites coded, pushed through a functional test bench, bit accurate models created and then run through ppa analysis all done via llms. So its a task tbis project could not afford to do without llms, but can save us 10% in ppa
sdevonoes 12 hours ago [-]
Im not so sure if this is a pro or a con. Take two extremes at product building: brute force vs deep research first. I guess llms allow you to experiment quickly with many approaches and see what sticks. Without llms, you need to spend more time researching and thinking what’s the most economical approach. Im biased towards the non-llm approach
nicman23 4 hours ago [-]
the real power is making the bot search a large code base for the relevant code you want to change
infecto 13 hours ago [-]
Agree so much. So many small bugs, nits, tweaks I just send off to an LLM agent to figure it out.
moron4hire 13 hours ago [-]
Those sort of ideas are unlikely to yield major benefit, though.
This is basically replicating the plight of the solo open source dev, writ large. Individual programmers have long built the thing they've cared about on their own time (essentially "for free" because, despite kindergarten economics theory, a programmer cannot usually monetize a marginal hour). And it usually goes that the project never gets adopted anywhere. It might acrue more features and total man-hour effort than most of what FAANG does in open source to drown out the solo devs. But the market will decide that "no organizational buy-in" is a signal the project doesn't matter. Other developers will decide, "if he could do it, so could I" and also not adopt.
Same exact thing is happening and will continue to happen with all these generated "but we wouldn't have done it otherwise" projects. It's just very, very unlikely to go anywhere.
That which took very little effort to create will receive very little effort to promote.
bloaf 7 hours ago [-]
I don't think this is the right framing, because I think it confuses the means and the ends.
Its like making a jig in woodworking. The measure of the jig's success is not whether it gets re-used or widespread adoption, its whether it made it easier to achieve some actual objective. Because the jig is a means to some other end.
Lots of these "we wouldn't have done it otherwise" applications are means, not ends.
breuleux 7 hours ago [-]
That is true, but that suggests that the value of software is reverting to the value of a jig. Software that gets deployed to millions of people gets a large valuation because it provides small convenience times a million. In the era of bespoke software, you’re basically 100x-ing the production of a millionth of the value of commercial software. That’s why it isn’t all that impactful in the end and I think it’s worth highlighting.
keeganpoppen 13 hours ago [-]
that and 2x is "i'm 5'10" and i round up to 6'" low.
5555watch 12 hours ago [-]
I'm probably a weird outlier. Coming from academia, it's ranging from 1x to infinity-x (as in, certain tasks wouldn't even be touched if not for AI).
For stuff that I'm used to (R) I can write nice and compact spaghetti (long %>% pipes). I'm not comfortable when a working script doesn't fit the screen (plus a few scrolls max). My style is probably easy only to me. When I teach, I don't teach it in particular.
AI gives me thousands of lines of codes for those. 10k once. It's cool if it suffices to source it all, but working with that is not pleasant.
But if I can reproduce a paper in a one-shot (it used to be an hour, but recently it got so much better), that's a task that would not have been even attempted years ago. And I'm talking about a methods paper with no available Github (or, as often happens, when the existing Github is useless)
andy99 11 hours ago [-]
I would have said 0x to infinity-x. Some stuff I think it would be a good idea and waste a bunch of time and then give up and just write it myself. And like you say, there’s lots of stuff I would just never have done, basically any kind of front end for example, if I didn’t have an LLM to do it.
I also do mostly research or one-of script development, for which I find LLMs less useful, as I want simplicity and I want to understand exactly what is happening. The only time I find LLMs help really there is if there’s some part I can abstract away like writing and interface to an api or something.
billdueber 11 hours ago [-]
For me, I find the biggest benefit is that I actually do all the things I know I’m supposed to do, but usually don’t bother if I’m the only audience.The first time a model asked me, “do you want me to wrap this in an easy to use CLI?” I was like, “Yes. Yes I do.”
hellohello2 12 hours ago [-]
Interesting. Framing it as 1x to infinity-x matches my experience too. I've have good success with it reproducing papers with existing code, but not such much with one-shotting new code. Do you have any particular setup for this i.e. special validation prompts or multi-agent stuff or do you just ask something like reproduce paper X until it gets results Y?
5555watch 11 hours ago [-]
I used to chat with "the paper" until both me and the AI were roughly on the same page at what's happening. It's important, as a "full read" of the "full paper" is not always used efficiently if not discussed, I've noticed. I then ask it for a detailed step by step realization (of the algorithm, or the paper/section/whatever), plus some context. Then I pass this as a prompt to a fresh new instance, and task it to implement in full based on the description (Gemini Deep Think was quite good with that).
Now I feel like 5.6 Sol Ultra is capable of doing roughly the same with its Agents, so it's getting easier in my experience. With the Codex, it can adjust or correct until the output is suitable.
I'm sure it depends on the field and the method.
hellohello2 7 hours ago [-]
Thanks a lot for sharing! I'll try the discussion to unpack context, that sounds interesting. I end up having such discussions in separate chats anyways to understand what's happening so it makes sense to do it upfront.
hollowturtle 11 hours ago [-]
I have many problems dealing with statements that use Infinity, especially if I think about the math or physics implication of that :)
cherrylemonsoda 11 hours ago [-]
[flagged]
jvuygbbkuurx 12 hours ago [-]
Infinity is a ridicilous statement. Even the work that wouldn't have been done before is now time away from work that needs to be done. At worst it's negative x.
DrJokepu 8 hours ago [-]
Pretty sure this was one of those so-called “jokes” I have read about in a research paper once. American humor tends to rely on overstatement. This is contrast with British humor that more often builds on understatement.
5555watch 11 hours ago [-]
It's a division by zero. We can change infinity to 'undefined'
Xcelerate 6 hours ago [-]
I have a weird issue with using AI for coding. I can code something entirely by myself at my baseline speed; call it 1x. Or I can use Claude to do it, and it does it in 1/10 - 1/4 of the time. The problem, however, is that to review Claude’s code properly takes 2-3x the amount of time it would have taken me to write it all by hand.
So my two choices are basically “YOLO, LGTM” and hope I can revert if it breaks something, or to just write all the code by hand from the start. With the increased pressure for output, I’ve noticed both myself and coworkers tending more toward “commit and hope it works” over time. It’s sort of perverse incentives in a way...
taberiand 6 hours ago [-]
The models are good enough these days that I see it like managing a team of juniors. The LLMs need guidance and oversight, and about the same amount of time I'd spend reviewing code from a junior I spend on the LLM output. I think generally it's best practice to work in a way that "commit and hope it works (because it passes all the CI/CD automated testing and verification, and it's a change gated behind feature flags and has an identified and minimal blast radius, etc)" is possible
t-writescode 6 hours ago [-]
This is what I've seen. There has been a middle-ground though, that I've seen. I was using Jetbrains' AI Assistant, or whatever it's called, during an interview for the (nearly) first time, and I only used it as auto-complete, but it was consistently, surprisingly, very accurate. I literally did write it faster. I scanned the literal next line, in the context of what I was writing, with all that context in my brain, and I saw what it wrote and went "yeah, that looks good". I'm a very fast typist (~> 100 wpm) and I still found it beneficial for writing out work fast. Further, since everything is still in my mental context and I can evaluate it at the same time, I feel like I can trust that type of code more.
But maybe that's just me.
stephenr 4 hours ago [-]
How long ago was this?
I tried their "local ai autocomplete" thing a few years ago for a little while and it was hot garbage. It guessed the right/acceptable completion about 30% of the time at best.
I haven't looked at it since.
t-writescode 2 hours ago [-]
Within the last, like, ... 3 months, I think.
mrbnprck 2 hours ago [-]
not to forget the cognitive strain of the constant back and forth between LLM and you.
One challenge is when knowing how the code should look like, the LLM solution always looks weird, and one tries to maunally steer against it, so accepting a bit of "good enough" is unavoidable to gain some productivity
encyclopedism 4 hours ago [-]
Economics drives behaviour more than people think. Your employer cares about results. It's 'YOLO, LGTM' all the way down now.
gashad 14 hours ago [-]
This reminds me of themes I recently saw in [Harness Engineering is not Enough: Why Software Factories Fail](https://www.youtube.com/watch?v=Ib5GBkD555M) (Warning: the last 3 slides seem like an advertisement). One thing I liked is how Dex has a little graphic he glossed over showing software development is
- 25% planning & aligning with other teams
- 25% coding
- 25% testing/verifying
- 25% code review/rework
One argument was that agentic coding speeds up that coding part a bunch. So maybe there's 2x speedup in coding. But that's only a small speedup in the totality of everything software engineers do.
altern8 13 hours ago [-]
AI is great because my job is a lot easier, but it produces some extremely crappy code that would've NEVER passed a code review 1 year ago.
You could argue that it speeds up development by 5X or more, but then it slows down testing/verifying, code review, and in many cases it makes it impossible to review/rework by hand.
I just do what I'm told at work but even though I'm sure I'm in the minority I'm extremely skeptical that LLMs can produce any good-quality code.
Looks to me like we've just lowered the bar--by a lot--and stopped looking at the code that goes out. Every time I look into how Claude implemented something it's completely insane, with no way to refactor it or maintain it in the future.
serial_dev 13 hours ago [-]
> it produces some extremely crappy code that would've NEVER passed a code review 1 year ago
The 10x speed up comes from the fact that we have all given up on properly reviewing each others code and we just say “meh, it will be fine, lgtm”
QwenGlazer9000 12 hours ago [-]
This. The bar has never been lower.
dools 10 hours ago [-]
Code review has always been pointless
SkyPuncher 4 hours ago [-]
I realize this like a decade ago. Security is basically the only thing I care about in code review.
I’ve come to realize that I don’t actually care what your code looks like. I’m going to need to learn it from scratch every time I use it. It’s going to look weird and foreign to me no matter what. It’s not worth my time nit-picking things that simply do not matter.
zhoujianfu 6 hours ago [-]
I’m glad somebody said it!
metalspot 9 hours ago [-]
[dead]
altern8 12 hours ago [-]
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.
elcritch 12 hours ago [-]
I read this a lot, do you have examples of this? Last year the code produced by LLMs was pretty sloppy, but recent SOTA models seems pretty good to me. I'm curious if I'm missing something or it's folks using different models or difficulty levels.
altern8 11 hours ago [-]
From my experience, a snippet of code will look good.
But LLMs seem to have a hard time getting the big picture and reusing code that is already implemented and ALMOST does what you want vs. rewriting everything from scratch.
AI code is extremely difficult to read and follow. It's littered with hundreds of lines of comments and notes, often referring to other notes in other parts of the codebase, and often extremely out-of-date.
Claude seems to me to still focus on getting things done vs. doing it properly, so from my experience it would pretty often mess up your whole codebase just to be able to finish its task, vs. stopping and rethinking the approach.
After a few passes of that, with duplicate code with no underlying coherent vision, hundred of thousands of lines of documentation written as walls of text in markdown and weird coding decisions, your codebase is impossible to work out for a human.
I use Claude Opus 5 at high to plan, Claude Opus 5 at low to execute the plan.
I make it build things in small changes, I give very specific instructions about the architecture, and I make sure to point out existing functionality that can be used instead of writing something from scratch. But it's a lost battle because Claude can't learn and it's basically a black box.
It pretty shitty, but that's what they pay me for so I just do it.
jaggederest 10 hours ago [-]
> It's littered with hundreds of lines of comments and notes, often referring to other notes in other parts of the codebase, and often extremely out-of-date.
Adjustable by tooling and prompts - my favorite is a ban on comments >2 lines, a tagged index system for effectively in-repo RAG with short documents on each tagged topic like INFRA-DATABASE-SETUP.md - enforce with tooling that the tag matches the doc and vice versa. Enforce that any PR that has a tag change in it has the relevant doc changes.
> Claude seems to me to still focus on getting things done vs. doing it properly, so from my experience it would pretty often mess up your whole codebase just to be able to finish its task, vs. stopping and rethinking the approach.
Tell it your values - "I value correctness over getting things done, and getting things done properly over speed" solves many of those problems. I've actually spent a portion of today rejiggering my values documents because the models have improved enough I no longer need to be quite so careful about scoping.
I was having those same problems, but particularly using Fable / Sol to do the meta-work has largely eliminated them over the last ~3-4 months. Codebase is now a lean mean token-conserving machine.
elcritch 7 hours ago [-]
Thanks! Many of your issues sound more agent / LLM specific than LLMs in general. At least compared to my experiences.
It also aligns with what I saw from Claude & Claude Code when I used it last year for a while. Now I use Codex and don't see (nearly) as much of that sort of behavior.
> But LLMs seem to have a hard time getting the big picture and reusing code that is already implemented and ALMOST does what you want vs. rewriting everything from scratch.
Yeah that's probably the weakest point of LLMs still. GPT-5.6 Sol got much better at this for me. I still usually end up doing 2-3 iterations of prompts and exploration to clean up various things but usually it's pretty light work now.
> hundred of thousands of lines of documentation written as walls of text in markdown and weird coding decisions, your codebase is impossible to work out for a human.
Okay Claude definitely seems to have an issue there. From what I've seen from coworkers using Claude it generates reams of endless docs. I resist the urge to `rm docs/planning*.md`! I don't think they get how bad Claude is at that.
A month back I tried the latest DeekSeek and it made reams of text back and forth with itself, but the code it output was reasonable and it didn't make pages of markdown files either.
> I make it build things in small changes, I give very specific instructions about the architecture, and I make sure to point out existing functionality that can be used instead of writing something from scratch.
That's a bummer. I found that once the models start having problems that it cascades.
I've also been able to keep steady progress on a 70k+ LOC GUI side project without the endless whack-a-mole of bugs using Codex and Sol. Squash a bug, review architecture, move on, etc.
whateveracct 14 hours ago [-]
> 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?
t-writescode 13 hours ago [-]
Well, there’s probably several reasons:
1) because they’re not doing those others spheres of work
2) because they don’t think about the work
nor how tired they are afterwards
3) they’re proselytizing AI work as the future and
that conflicts with that vision
4) the other shoe hasn’t dropped
5) they really don’t see it
6) some people genuinely hate programming and this
helps them skip that.
I’m sure others as well.
ChadNauseam 13 hours ago [-]
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.
steveBK123 14 hours ago [-]
The other hard to measure part is that I see/hear a lot of LLM usage going towards dev work that was never prioritized before.
Suddenly devs who were cranking out features with no interest in infrastructure are attacking giant refactors to make the code more understandable to the LLM.
Other devs are using LLMs to build themselves quality of life SDLC tools completely separate from the core code base.
Plenty of other examples of this.
leoedin 14 hours ago [-]
The quality of my bash scripts is 100x what they used to be. Proper help messages, flag parsing, functions, internal variables, using sed all the time (I could never wrap my head around that).
Of course, the main issue is that they’re completely undebbugable now. My bash scripts used to be a sequential list of commands, now they’re 500 lines of variable laden functions.
Is my life any better? Dunno. But it’s satisfying (until there’s a bug)
nasretdinov 14 hours ago [-]
> the main issue is that they’re completely undebbugable now
Well, that means the quality actually dropped then :). Looking impressive isn't equal to quality, understandability and reliability is
gmassman 13 hours ago [-]
Not necessarily…. As with all engineering choices there are tradeoffs involved. There can be both advantages and disadvantages to using AI to build scripts. And more likely than not you’ll need AI to help debug the scripts when they have issues. Real tradeoffs to consider.
xboxnolifes 12 hours ago [-]
100x UX quality, not DX quality.
mckee_plus_plus 13 hours ago [-]
I switched to js for dev related scripting after seeing how much python scripting is used for portable c++ projects like chromium.
A node glob() or a regexp string.replace call is probably easier to read than spaghetti shell.
And your llm might do a much better job of creating clean, readable and testable code.
metalspot 9 hours ago [-]
llms are 100X for me, but only 10X goes into actual shipping code. the rest is all on doing the dev process the way it actually should be done: incremental POCs, refining specifications, modularization, exhaustive test suites with 95%+ logical unit test coverage, fuzzing unit test coverage, exhaustive e2e testing, with a fuzzer harness over e2e tests for long term simulation and scale testing, bechmark gated self improvement loops for performance optimization, etc. i guarantee you i can ship higher quality 100% llm generated code than any human.
t-writescode 6 hours ago [-]
It scares me how much of this is true - people truly weren't doing all of this before; but like ... some of us (like myself) were, and we were trying to push other people to write good code like that - code that helped everyone else's future velocity be faster - including our own on the next MR and the next one after that.
I'm glad you're doing all those right things; but, really, some of us were already doing most of, if not all of that. And some of us (like myself) were doing it very quickly, too, since we'd been doing it that way over a decade and constantly getting faster.
move-on-by 14 hours ago [-]
Just one more data point but this is what I’m seeing too. The extreme ‘ruthless’ prioritization has stopped and devs (who want it) have breathing room to make the enhancements they’ve been wanting all along. Turns out what is good for AI is also good for regular old school SDLC. All you have to do is say it will make AI more effective.
senderista 10 hours ago [-]
You missed documentation. There was never time for that until now.
sensanaty 40 minutes ago [-]
IME LLM docs are worse than useless the majority of the time. It's like most LLM writing, an inscrutable wall of text that simultaneously says nothing and too much at the same time.
coffeebeqn 14 hours ago [-]
I use CC to do the testing and verifying in multiple deployment environments. It’s faster at things like coming up a plausible test payload or ten, querying a bunch of metrics from datadog, querying and verifying state from a db before and after testing, scanning all the deployed logs for relevant errors. For me that has been more of an uplift than the coding. I still feel like communication it’s worst at. So writing tickets, getting a decision out of a group, documenting only the important things, etc. it’s still not that good at
agumonkey 13 hours ago [-]
Agentic tools changed the workflow in our org, we were very tense before with a simple yet careful team process.. Since last winter we're now pushing a lot more but the teamwork (which was brittle before) is now mostly gone, everybody can roll on its own, but the review process didn't scale and now monthly deliveries are full of "seems to work". nobody checks properly, nobody reviews, nobody tighten any bolts.. and nobody cares much anyway, the system allows it.
lazopm 14 hours ago [-]
The way I see it you should calibrate the way you work with LLMs based on how confident you are on that specific area, and if it's your responsibility to own/understand it. Here's how it feels for me:
* Learning stage: 0.5x - 1x. I change my system prompt to teacher mode, taking the productivity hit for actually learning the system/tool pays off dividends later. I change my system prompt to "teacher mode" and slowly loosen it as I get more confident.
* Working-knowledge: 2x - 3x. Once I am ramped up enough I feel like I can get a decent productivity boost. Most of the time is spent at the planning stage. This is my mode for areas I don't really own or care about, just need to get work done.
* Mastered: 10x+ I have been doing web front end for 12+ years, I can quickly review plan/implementations and for my initial prompt I already know most of what I want built.
1x == my speed before AI
Aurornis 13 hours ago [-]
> * Mastered: 10x+
This really needs to be calibrated to the type of work and complexity.
I can actually believe that LLMs would speed up basic web dev work in small, simple codebases 10X for simple requests.
These conversations usually turn into people talking past each other because they’re working on different things. For other less routine and more complex work, expecting a 10X productivity boost is not realistic at all. It doesn’t matter how good you get at writing prompts and reviewing plans. LLMs just don’t solve everything for you in a good way. Some times the true nature of the problem is revealed while implementing it and by deferring everything to an LLM you spend days throwing tokens at the wrong thing. There is a lot of work where the LLM speed up comes from helping you quickly search docs and codebases and double check your code, but handing the entire thing off to an LLM isn’t reasonable. These tasks aren’t going to reach this mythical 10X productivity boost that is genuinely achievable for much simpler work.
klibertp 13 hours ago [-]
> Some times the true nature of the problem is revealed while implementing it and by deferring everything to an LLM you spend days throwing tokens at the wrong thing.
If you look at the code the LLM spat out (and you really, really should!) you will immediately notice that its shape is not what you thought it should be. You might not notice immediately if you're learning, but if you really "mastered" the domain, you will "just" see it. You will also recognize the problem with your assumptions, and immediately (or after some research) correct the prompt.
Looking at the diffs for everything the LLM does slows you down, of course. Not looking - or looking and not recognizing problems, for one reason or another - can be initially faster, but a single pathological case can eat both the time saving and tokens. For domains you truly "mastered", the current models can generate code as if they read your mind (because you can be that precise in the prompt, and quickly), so it's really glaring and very hard to miss when they somehow misread your mind.
It only works at the "mastered" / "unconscious competence" stages, and only in those narrow domains you truly mastered, but it does seem to work. Is it 10x? No idea, but there is a marked change in the speed boost when crossing from conscious to unconscious competence area, with everything else (harness, model) staying the same.
NoDodgeQuestion 10 hours ago [-]
What they are saying is there are domains where there's no such thing as an expert who has the unconsious competence to immediately notice the LLM made glaring mistakes.
Zigurd 14 hours ago [-]
Some domains don't have the established regularity of architecture that it takes to achieve 10X efficiency. Two I can think of off the top of my head are embedded systems, with a variety of sensors, outputs, processing power, and memory, and novel protocols like ATProto, for which training data is thin on the ground.
dev_hugepages 14 hours ago [-]
Hey, could you share the prompt you're using for "teacher mode"?
leleat 13 hours ago [-]
Someone posted their AGENTS.md some time ago, that is used in practice to teach their students[1]. That might be useful to you in this context as well.
I'm probably in the 5x-10x range, but we are a very small team, and we've been accumulating a backlog of ideas over the years. I drive the architecture, and have almost complete autonomy over the work I do. I think someone in my shoes will see a greater result than someone trying to do the same thing in large team, with all the usual process and ceremony, only wanting to go faster.
RegW 11 hours ago [-]
Where as I'm stuck in a big team with a legacy codebase and lots of business rules, performing small incremental changes. So I spend my days banging the Esc key and shouting "Shut the f**k up!".
Luckily I work remote. I'd turn it off again, but my usage is monitored and I don't want to look like a Luddite.
So may be .75x to .8x range.
xXSLAYERXx 7 hours ago [-]
In my experience a legacy codebase is where LLM shines. What would take days to grok is understood and explained almost immediately. There was a bit of job security with being the one whose worked with IIFEs to manage state.
You must know the codebase well if the LLM is slowing you down.
bdcravens 4 hours ago [-]
Some of our biggest wins were in a legacy code base, where changes would require a lot of archaeology. I feel like Claude (and probably most coding LLMs) really shine when optimizing fat blocks of SQL, given the complex relational calculus.
bigbuppo 10 hours ago [-]
There's someone I know that jumped head-first into AI... they have embraced everything agentic. While setting up mail on their new iphone they encountered a problem. They had claude go through and do a bunch of tests against the server... allegedly. It didn't do any actual testing, though it did generate a long-winded report of what it pretended to try, fully blaming the server the whole time.
Actual problem: he typed in the wrong password
throwuxiytayq 9 hours ago [-]
Not sure what your point is, could you clarify? Are you saying that your friend is stupid? Or do you mean Claude is stupid? Both?
chr15m 6 hours ago [-]
Claude lies, like all LLMs today.
xbmcuser 5 hours ago [-]
I am not a programmer but for me the return is 100x as I am automating stuff that I knew could be automated but did not know how to but at the same time it was not worth the effort to write it down and pay someone to code it for me. But now I have created so many python and bash scripts that save me hours and hours a month. In my opinion the people that can most take advantage of the programing capabilities are people that least use it for such or know the how they could automate a lot of the repetitive tasks they have to do at work or on their own time.
globular-toast 3 hours ago [-]
Now that you only work 3 days a year, what do you do with all the spare time?
spaqin 8 hours ago [-]
I'm pretty sure that just a year or two ago, software engineers were saying that coding was only a small part of the job; the rest is meetings, dealing with requirements, design, testing, maintenance. So, how can we expect a 10x boost in a productivity from improving a small part of the job - especially now if we have to clean up any mistakes the LLM makes?
zug_zug 8 hours ago [-]
Yeah that's a good point, in order to see a 10x gain it would require at minimum coding be 90% of your day [7 hours, 20min) (or somehow for AI to replace meetings)
361994752 8 hours ago [-]
Now you actually have very long meetings with AI, if you consider all these long design / explorer / post-poc conversations "meetings".
bthornbury 12 hours ago [-]
for me, almost all of the work is specs
I am no longer:
- reading docs for hours and hours
- typing (barely at all)
- writing code
- manually doing tight debug loops
- using an IDE
to do this I had to give up reading or even controlling the code and focusing on behavior/design-level control (not superficial, still dictating overall technical architecture)
i have agents doing everything from writing the code, verifying the code, hardening, increasing test coverage, analyzing behavior, algorithmic perf improvements, managing/deploying to cloud resources, etc... (pretty much everything)
and I am accomplishing projects that would take months or years in a fraction of the time.
that's way more than 10x.
somehow, this is harder and more cognitively demanding than writing code
twister2920 9 hours ago [-]
> to do this I had to give up reading or even controlling the code and focusing on behavior/design-level control (not superficial, still dictating overall technical architecture)
how do you verify the behavior? are you still writing or at least reading tests or just doing manual testing?
LearnYouALisp 10 hours ago [-]
How much does it cost in GPU rental?
bthornbury 10 hours ago [-]
codex pro plan currently
fg137 12 hours ago [-]
I recently removed about 50% of code in a feature submitted by a colleague, because it's a pile of over-engineered mess that either never gets used or caused trouble for us. We probably would not have added the code in the first place if we actually discussed the design. With the code removed, the feature is now much simpler and more maintenable.
And that's the second time this happened over the past few months.
ericol 13 hours ago [-]
I'm not sure about the x, but the first thing that arises from that is, I feel like in my case it's way higher than 2.
The 2nd thing is, how do I measure that.
---
In my case, the details of my work (Kinda DevOps, kinda Senior Dev) makes it that having an LLM to do the heavy lifting allows me to do things not only faster, but better, and across domains I do not hold expertise on.
An example of the effect of LLMs in my daily work is that I'm in the middle of a PHP upgrade for a rather large legacy application, and the "heavy lifting" is really out of the scale, letting me concentrate on what really matters, while at the same time if I do keep "the harness" tight I'm certain the results are the correct ones. Also correcting course is just as cheap.
Not having to worry on the tooling on exchange has the incredible desirable result of my velocity being incomparable to what it was before.
Then we have the side effect of how easy to do transfer knowledge: Rather than telling the QA guy how to do the work specific for this task, I defined a set of files (.md documents, skills, an off-the-shelf customised MCP server) that assist QA into doing the work in a way that helps me do my job better and faster.
There's also a clear possibility that what I'm doing will expand to the rest of the team I am in, completely altering the way in which we approach development.
If we take 'x' as 'mileage', yours might vary. Mine has, and I'm baffled at the positive net results I AM getting.
Also, this what I do (coding?) is extremely fun again.
Being able to work close to the speed of thought is the best high.
soperj 13 hours ago [-]
> allows me to do things not only faster, but better, and across domains I do not hold expertise on.
How would you know it's better when you have no expertise?
heaney-555 13 hours ago [-]
Because it produces the desired output. The purpose of a program.
There are many domains where an intelligent human can act as a discriminator for output without knowing exactly in precise detail how the process itself works.
cataphract 9 hours ago [-]
Producing the desired output is the purpose of the program, but it's not the only consideration: there's performance, maintainability, security, and so on.
fc417fc802 12 hours ago [-]
That is certainly true, but there are also many cases where someone without core expertise who believes themselves to be a capable discriminator actually is not.
legohead 10 hours ago [-]
Totally depends. The real question is what's your average productivity increase?
I had a task to completely gut out a codebase to share with a vendor. I gave them my estimate - 2 weeks. Asked Claude to do it, and was done in an hour. Reviewed the changes, and it was perfect. This is an outlier of course, and it was a pretty basic codebase. But it's real world stuff.
Overall though, if I had the mental fortitude to work for 8 hours straight, I could easily average 5x my "normal" performance. But most days I can't perform at that level. Also I admit I am not a fast developer, I do a lot of testing and verifying as I'm paranoid.
watso 14 hours ago [-]
You still have to know what you’re doing. That came from years of doing it by hand. Where is that necessary experience going to come from for the current and future generations of juniors?
ipaddr 12 hours ago [-]
In 10 years llms will handle it all from start to finish.
kazinator 12 hours ago [-]
We have passed peak LLM already. In 10 years, something might be handling "it all" from start to finish, but it won't be LLMs.
peheje 13 hours ago [-]
Shipping. Breaking stuff. Fixing it. And discovering, repeatedly, that the tool sounded much more confident than it had any right to.
Like always. This is why the average carpenter you hire in 2026 still won’t do a perfect job, despite carpentry having existed for thousands of years.
danans 7 hours ago [-]
> I have not yet taken up woodworking as a contingency plan for "Software Engineer" becoming an extinct profession
Between "stable" and "extinct" are many stages of software engineering labor market change, continually more difficult (for labor) as we move toward the latter state.
Software engineering is likely to become a skill/tool attached to another harder to automate ability going forward rather than a vocation/craft on its own.
To the extent that software engineers are employable, they will likely need some other x-factor adjacent to software skills, whether in the science, business, creative/artistic, or social domain. I've already seen this trend emerging in the startup world.
scelerat 10 hours ago [-]
I recently, with the help of Claude Code, made a tool which involved a database, two separate apps surfacing and interacting with various aspects of the data, and a user base of dozens, with some semi-specific domain knowledge on my part and an intention of re-using and building upon the minimum viable result.
OP's description very much mirrors my experience. I was able to do many things much more quickly with the help of the LLM, but there is no substitute for actual users interacting with the tool, saying, "I like this," or "no, this is wrong or needs work," or even, "here's something none of us thought of before, but now this tool makes me think XYZ would help us and might be achievable." That whole interaction takes real time and I don't know how you replace it with coding agents.
Secondly, on the matter of code structure, just on a qualitative level, I can see that claude will do things very efficiently on the way to a goal I give it, but it can't read my mind and know that I may want to repeat a specific pattern across two client apps. Or that its shortest-distance solution makes extensibility or broad applicability difficult. That I might want to share code and structure things in a certain way. Not without me saying so or, in many cases after it has built something workable, duplicating refactors I make with an eye for reusability or maintenance. Making those changes in time is important if you don't want to burn tokens later as the LLM tries to unravel its own spaghetti. And again, whether I am coding those intentions directly, or writing out detailed instructions in english, all of that takes time.
mindwok 10 hours ago [-]
I’ve been vibe coding apps professionally for the last year and 100% agree with your first take. I really underestimated how much work there is in what I just call the “coordination” of developing software.
Users pointing out things that are missing, or me forgetting to tell them I’ve added something, or both of us having a different idea in our minds of what something should do. It’s still extremely time consuming.
baron3dl 13 hours ago [-]
I won't argue this title isn't the author's experience, but it's misleading to rest a quantitative claim on a qualitative argument, while also refusing to fully exploit the technology.
From a firm that has fully embraced agentic engineering, they offered topline stats on their measurements of a 4x boost from November to February, and 8x on top from February to May. That's 32x since November 2025, coding with LLMs.
And like whatever, this is second hand and I'm not going to disclose the source. Actual hard, published, and peer-reviewed research is needed here to backup quantitative claims. 2x, 10x, 32x, whatever.
taf2 12 hours ago [-]
yeah i can't say if it's 2x or 10x or 100x i don't know. i just know i barely open vim anymore. I still find my rate of development is limited by how much my single mind can hold at any given time. I am however accomplishing with a much higher rate of confidence many many more daily tasks usually by 10am... the limit is usually my willingness to imagine and think critically about an idea with enough clarity to result in something that make sense. It's a different energy then normal development but similar enough.
wwind123 5 hours ago [-]
I think it'd take some time for people to figure out what kind of harness or workflow would work best with each individual codebase or team culture. AI certainly can help speed things up a lot, but for now the humans driving the AI need discipline to follow good software-engineering practice, or at least have multiple AI agents critique each other's work, instead of just pushing out whatever one AI agent writes.
throwaway0123_5 12 hours ago [-]
I agree with the general premise with respect to current SOTA, but for making nice plots that I would've never otherwise made or learned how to make (to the same standard), easily 100x.
HarHarVeryFunny 11 hours ago [-]
Even if that 2x were a representative number (although another HN story today says 1.1x - 10% improvement), what really matters is whether companies are overall seeing any AI spending return on the bottom line.
There is a lot of reason to suspect that at most companies, especially more established non-startup ones, there will close to zero bottom line benefit, because these companies already have free paid-for developer capacity (developer down time between project cycles) that presumably they would be utilizing if there were reason do to so. In a startup environment where there is zero down time, then productivity may at least show up in reduced time to market.
I think Uber's current experiment of limiting AI spend to 10% of salary per developer is interesting since it implies that spending more will not even recoup the extra token cost, although it does remain an experiment. Maybe they will see a revenue increase related to AI spending and choose to tweak that limit up, but it's also entirely possible that all they are doing is reducing developer workload by giving them a productivity tool, and there will be no financial benefit.
encyclopedism 4 hours ago [-]
I agree the bottom line ROI largely isn't there and won't be in the future either. The upside for companies is not the bottom line but the potential savings from hiring fewer developers or cutting jobs.
As AI based development processes continue to improve, the confidence level employers will have in safely cutting jobs will increase. The longer term impact of AI is HR savings rather than introducing new capabilities into business.
sitzkrieg 8 hours ago [-]
maybe i’m an edge case but for 99% of the day to day work i do (embedded, not x86), llms will confidently give me wrong code so many prompts in a row it’s a 0.5x factor. when i venture out to something more normie, like webdev on either side, it does better but still takes more time than if i sat and did it myself once over. i’m not exceptional, but certainly understand everything that has been generated at any rate.
i think LLMs are only a useful multiplier if you’re working on the plumbing parts, it’s never useful if you’re doing anything novel really.
if this bothers you, i am sorry and i wish you the best with your reddit trained auto complete. i write new code
jeffybefffy519 7 hours ago [-]
I do a lot of novel work, that is not setting up a webapp - and totally concur on the novelty point with LLM's failing hard.
deergomoo 14 hours ago [-]
> As for documentation, I've found this simple instruction to vastly improve LLMs' output:
> Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.
This is quite validating as I came to the exact same conclusion myself. We’re required to use an LLM for every task at work that touches code†, and I was really struggling to get Claude to stop with the long waffly comments that reiterate the next few lines of code in 3x as many characters, making contextless references to subtasks in whatever harness du jour we’re using this week.
No amount of examples or explanation of what I wanted would make it stop. And then I realised of course, I’m asking something which has no concept of meaning (or, indeed, anything) to only add meaningful comments. More fool me I guess.
Of course, it’s ultimately pointless given all of my colleagues are regularly opening PRs with more comments than code anyway. 80% of my code review responses these days are just increasingly exasperated “pointless comment, please remove”.
† This is just as infantilising as it sounds, by the way
openasocket 14 hours ago [-]
+10, I can't stand AI-generated comments. Half the time they are paragraph-length translations of every 5 lines of code into English prose, or just regurgitating whatever prompt they were given. When they actually try making high level comments they are worse than useless. It's really hard to put into words exactly why. It's something about how they are very verbose, but at the same time vague and stated in a slightly-off manner. Or they will introduce new terminology not reflected in the code's nomenclature, sometimes terms that are just synonyms for terms that the code already uses. Something about it makes me instantly distrustful of any information the comment may actually convey.
monknomo 14 hours ago [-]
locally correct and globally incoherent is how they seem to me. I, and a number of folks I have talked to, find some of them incomprehensible. Like each sentence makes sense, but the overall thing does not.
wannabe44 13 hours ago [-]
It's because they don't really have a mental model. RL with Verifiable Rewards can reward working code, but it can't tell you whether the prose make sense or not. In theory RLHF should be good with this. In practice, it appears to be a measure difficult to quantify and steer. I am not an insider though. So it's just a theory.
kaffekaka 13 hours ago [-]
I have the same impression. It is an interesting phenomenon. Is it one of the ways we will gradually learn that AI in the form of LLMs is fundamentally lacking?
I use AI all the time, it gives a tremendous boost in speed for many tasks and it is most certainly here to stay, but there is something off about certain things, like code comments. Like a weird person.
Hupriene 13 hours ago [-]
I kind of wander if the comments are intentionally bad, providing programmers something to bike shed about. A sneakier approach to the flattery the models used to so use so heavily.
sync 14 hours ago [-]
You can create a PostToolUse hook [0] which will automatically chastise Claude to shrink comments to one line. It's not perfect but better than the sea of prose it tends to generate by default. Bonus is that it would apply to your colleagues as well!
Good thinking! The multiline paragraph comments drive me up the wall.
No amount of agents.md / commit to memory updates has stopped agents from littering the code base with useless comments.
Think I'll add it to pre-commit hooks getting called by posttooluse
nevertoolate 14 hours ago [-]
> We’re required to use an LLM for every task at work that touches code
Why not just write the code in the prompt so LLM can paste it.
fibonacci112358 13 hours ago [-]
I have the opposite problem with Code, it barely writes any comments even for fairly complex C++ code blocks (systems programming stuff), have to prompt it to add extra details about why it did something. Request in agents.md doesn't seem to help much.
NichoPaolucci 13 hours ago [-]
I'm in the same boat. We have very little documentation where I work, and one of my goals was to improve that as I got onboard. We have a newer dev that started ripping +3K, +5K, +10K line PRs against our documentation repository.
I have tried to shut it down, it immediately nullifies the docs and make it genuine slop.
I truly believe that documentation should be human written and human readable. It's all of the stuff that AI does NOT pick up on. Small inconsistencies, only the necessary details. IE: Don't just rewrite the code that we have into readable english (We are software developers after all. We can read code.) - comments / documentation to me has always been the "in between the lines" stuff that can't be put into the code.
resters 10 hours ago [-]
If you're getting 2x you are likely at the limit of your own ability to coordinate or plan intelligent work effort, and you have plateaued such that even when models are twice as powerful as they are today you will still be getting 2x of your own human throughput.
We all have a limit after which we lack the attention (or attention to detail, or time, or energy, etc.) to meaningfully manage it.
Similarly, a manager may be able to handle a team of two very well but end up poorly managing a team of 20.
It used to be that knowing how to write code was a big factor in productivity. Now it is less of a factor compared to the many other cognitive and metacognitive faculties that working with agentic teams demand.
skmurphy 11 hours ago [-]
I can accept the author's premise that LLMs double coding productivity today.
Semiconductors following Moore's Law increased their density, which is a reasonable metric for effectiveness, by 40% a year for several decades. Leaving aside projections of AGI in two years, it's still a substantial impact if we can figure out how to increase coding productivity by 40% a year for two or three decades. I don't think that gets us to AGI or the Singularity, but it's similar to the impact of the steam engine, steel, or electricity.
These are "normal technologies" that were transformational, and that may be the path we are on with LLMs.
kazinator 11 hours ago [-]
> LLMs' increased rate of adoption in 2026 is largely due to them becoming reliable enough to run effectively in automated feedback loops
Is that really from improvements in LLMs, or from improvements in the feedback loops?
jwpapi 11 hours ago [-]
I think for small projects you need to scale the coders mental model, which afaik works in the fastest time, when you let ai do the exploration and planning, but coder needs to write the code itself and then ai verifies. That generates the best of world codes and the coder at least has written the code. It’s scalable.
In projects that are so big that no single coder or no small group of coders is sufficient to grasp I don’t have personal experience, but my guess would be that they are just a cluster of other small projects.
est 5 hours ago [-]
I feel LLM can only build what's known and popular.
Sailing into the relms of lesser explored area are painful.
It's like an intern but never learns, only getting replaced by better interns.
tmsh 11 hours ago [-]
I think it matters a lot to understand the kernel of AI in the past 10 years. It's the only way you can truly appreciate the exponential. It looks flat unless you see the dramatic leap in transformer architecture and scaling laws and reinforcement learning. I know it's been hyped to death but you have to see how those things are truly exponential at their core to appreciate how it's not just walking up one step or two steps faster and how it's walking up buildings etc.
msephton 13 hours ago [-]
Does the number × depend on how big your thinking is? If you are only 2× then you need to think bigger, aim higher, etc. I think the limit on the 2× is not the ai? Where is the limit now? I think it's unknown.
trey-jones 13 hours ago [-]
Definitely feels like a lot more than 2x to me. Any time it feels like the agent is taking a long time I have to look in the mirror and say to myself "What could you have done in 5 minutes?"
Alwayshasbeeb 11 hours ago [-]
Sometimes small tools are all you need, even if they're slop.
About a month ago I pirated an Argentinian movie and the only subtitles available in my language were out of sync and at a different speed/framerate so adjusting for delays wasn't enough. I was unsuccessful at fixing it with VLC and every other "online tool" I could find.
Knowing a srt file is just text with timestamps I vibe coded a python script to take in sample times throughout the movies so it could recalculate the rate and shifts and replace them in the file. It worked on the first try using only the deepseek web chat interface and my terminal.
Without AI I theoretically could have sat down with a pen and paper to figure out the math adjustment, then looked up python input handling syntax which I already forgot, typed something out and then hammered it into shape through trial and error over a few hours. But the friction and time investment of doing that would have been so great I would have just given up on watching the movie instead.
ed_mercer 7 hours ago [-]
> the dark ages of 2025
This made me chuckle. I do think we are seeing exponential improvements over the years and that we don't always notice it happening because we're right in it.
localhoster 13 hours ago [-]
When I approach a new area or task I first explore it, by hand, and implement, by hand, the task.
This way, I get a deeper understanding and it gives me some momentum to llm the rest of the related tasks.
Till I loose enough grip to "re-dive in" that area and to again, do stuff my hand. Some tasks, I only do by hand, and some tasks, I only use llm for.
Really depends on the task, my the project and on, and honesty, my instrest and availability at the moment.
geraneum 13 hours ago [-]
> Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.
The precise and rigorous practice of “engineering” in 2026.
SwellJoe 11 hours ago [-]
I was saying it's a 3x multiplier for me during the Opus 4.8/GPT 5.5 era. Now, I don't think I'm notably faster than that, but I'm taking on projects I couldn't have done without LLM assistance, and not just because of time, but because of knowledge.
It's become a lever that allows me to learn as I go while tackling problems that are far beyond what I already know. I know a lot, I've programmed for decades in a lot of languages in a lot of domains. But, with the current crop of the best LLMs, I can reach for bigger problems...and actually make progress. I've read books about DSP for audio, and have done little toy projects in the past, but with LLMs, I'm building complex and working synthesis engines in a couple of weekends. That would have required a few months of study and experimentation before. So, that's a huge multiple. Like 100x.
For things in my area of expertise? Probably still just 3x, maybe 4x, because it makes fewer mistakes I have to fix in code review. It still writes terrible docs, as the post mentions...they don't understand user desire, so they simply can't write documentation for a user to actually use. You can't prompt them to make really good docs, but I can usually prod their docs into coherence a bit faster than writing it myself.
But, it's the lever for doing things I've never done that is such an addictive thing. Which, I imagine is how non-technical people feel shipping their first web app or whatever with these things. For basic work, I think we're at a point where almost anyone can use an LLM to make working software (not necessarily secure or stable software, but working). But, I think we're also at a point where an expert can make that lever really do something, and I hope that means we'll begin to see extremely ambitious new software in addition to all the throwaway junk that's been proliferating at a frightening pace.
In short: Maybe don't make another fucking "memory" system for your chatbot so they can be your friend who remembers your birthday, and instead work on something meaningful.
bartleeanderson 10 hours ago [-]
I am able to coax much more of the kind of thing you suggest that LLMS can not do by having it generate deterministic code and then narrate over the results. Hopefully that is not too negative and gives some helpful guidance.
sbinnee 10 hours ago [-]
I wholeheartedly agree on readme. AI generated readme irks me off almost immediately.
p0w3n3d 12 hours ago [-]
My measurements are Claude is 6x - 10x on prototyping and MVC then it starts to be 2x at most. You can also witness 0.5x (asking simple tasks might require more time than performing them by oneself)
robofanatic 13 hours ago [-]
I think LLMS have reached to a point where now its just about money. you have to decide whether you really want to spend your tokens to do X or you can just do it yourself and use the tokens for something else.
rglover 13 hours ago [-]
I mean the "x amount" is relative to your existing skill level, right?
It's worth asking ourselves "why does the x amount matter?" I get the desire to define KPIs to estimate productivity gains. But this all seems to be—rather rapidly—leading to an increasingly dehumanized reality (both figuratively and literally) so we can...produce more software? I love building software, and I enjoy using LLMs to help me do it, but there's just this weird vibe I can't quite shake about how we're trying to quantify all of this.
iLoveOncall 14 hours ago [-]
Even this is overstating it IMO.
I already convert from multipliers to percentage of increase, so when someone claims 10x they very likely mean +100% productivity, and here 2x means +20% productivity, which seems about right. Nobody that was normally productive before LLMs has suddenly 10x'ed their output now.
The problem is that 20% productivity when it comes to generating code, really doesn't translate in 20% productivity increase overall, when you take into account the fact that the code quality is worse, the fact that writing code is actually not the majority of your time spent, and that people get burnt out from the usage.
jdlshore 13 hours ago [-]
2x is 100% increase.
iLoveOncall 13 hours ago [-]
I know, and I'm saying that 2x claims should be interpreted as an actual 20% increase, and 10x claims as an actual 100% increase. People are just bad at estimating their own productivity.
didibus 9 hours ago [-]
Ya, I feel 10% to 50% increase seems more realistic, when I see 100% to 900% increase claims it seems a bit extrapolated, at least I don't feel I'm seeing it at my work. And then it depends if we imply a given feature/fix/enhancement takes half the time as before, or we imply that we can get twice as many features/fix/enhancements done in the same amount of time as before. Those are not equivalent. I think the latter might be more accurate as to how it helps.
kaffekaka 4 hours ago [-]
Yes, people (myself included) have a strong tendency to use hyperbolic factors, "ten times", "100x" because true estimates are very hard to do.
jaxn 6 hours ago [-]
This ignores that non-developers have gone from 0x to 0.5x.
segmondy 13 hours ago [-]
200x coding with LLM
cherrylemonsoda 11 hours ago [-]
Link 1 impressive thing
Rustwerks 13 hours ago [-]
I've found a variant of the Gell-Mann Amnesia effect with regards to LLM coding. They're really magical if you're not familiar with the language, domain, or frameworks you are trying to use. But if you're familiar with those things then you'll often catch them lying to your face and producing a lot of plausible nonsense.
cyanregiment 13 hours ago [-]
0.25x because I scope bigger now and then I may get a few "free" React components but largely doing all that work of putting it together.
Wouldn't trade it though. Feel like I can overall do more with less time and energy.
At the end of the day, AI is making me work more (good thing). If you count that as productivity, then sure.
didibus 9 hours ago [-]
> AI is making me work more (good thing)
How is that good?
robomartin 5 hours ago [-]
Well, it's interesting. I've been using LLM's for coding for over two years. My findings are somewhat consistent: Feed it jobs in small chunks and it can be a great auto-complete, beyond that and it turns into a mess very quickly.
I'm two weeks into a project that has been interesting and also has confirmed the above yet again. I am porting a Windows application written in Python to C# using Avalonia UI.
I have never used C# or Avalonia UI. I've written Windows applications in other languages, never C#. I don't know the language, libraries, etc.
At first I told Codex: Here's the source code, port it. I just had to run that test.
Well, it didn't end well. I'll describe it as a frustrating set of prompts that seemed to result in the implementation going in circles with constant problems being introduced, breaking-fixing-breaking, etc.
I then started again with a clean repository and played the role of the architect with full documentation in the form of code. File-by-file, I had it port modules to effectively develop an operational foundation for the classes, methods, properties, abstractions, hardware interfaces, etc. in the original Python program. That went well, was very fast and a good experience. I am running Codex in JetBrains Rider and the integration is excellent. The native OpenAI Codex application is an absolute dog...it pegs all my cores at 100% while doing nothing.
Once all the underlying infrastructure was ported and, to the extent possible, individually tested, I threw UI integration at it. This happened quickly and OK from it's-ugly-but-I-can-use-it perspective. Codex seems to be way out of its element when it comes to UI/UX understanding. Funny examples like placing a button on top of an image with the image covering the button because it had a higher z order. Or finally placing the button at the correct z order but making it transparent on-hover. Funny stuff when you are moving slowly and you see it happen. It just proves that there is no understanding whatsoever.
With all of that and the experimentation, I'll estimate that a six month project will be cut down to three to four weeks. Another month and it will probably be a much better program with new features and more advanced capabilities.
And I have not touched a single line of code. Developing solid prompts is the absolute key, something that you can only really learn by doing and through lots of experimentation.
Yes, of course, I fed it working code. I think it could be very different if I were to start something from a blank slate.
alfiedotwtf 14 hours ago [-]
> As such, I use LLMs mainly to produce a rough draft of the code which I then iterate on heavily, at least until I like the general structure.
Weird… I would have said this was how it was about 2 years ago, but no way in 2026.
heaney-555 13 hours ago [-]
So many of the AI takes posted to HN are outdated.
badsectoracula 13 hours ago [-]
People are still figuring out how to use LLMs/AI and considering how feelings based and hard is to reproduce many of the results people get, a lot of the improved approaches are basically at "trust me bro" reliability.
TBH i expect it'll take several years before people largely settle on what works good and what works bad (or doesn't work) and that's assuming things wont chance in a massive way during that time.
And this isn't really anything new, people rarely come up with some new way of programming and have everyone learn and understand best uses from the start - it takes years (and that is assuming everyone will agree that'd be something worth bothering about).
troupo 14 hours ago [-]
> Never write READMEs, docstrings, or comments.
I found that latest codes don't write comments in code by default. And when they do, they write stupid shit like "This was code that did X, it was now removed".
You have to explcitly prompt them to write comments in code. They are still useful for you, the user. But are arguably useful for the model, too, given how many of them (especially Claude) only reads small chunks of files. So I'd rather have code comments than it reproducing a picture from incomplete data.
wongarsu 13 hours ago [-]
A small mention in your user-wide Claude.md (or Agents.md or whatever you use) about the desired types of comments goes a long way. The typical "why, not what", clarifying larger-picture stuff, and everything else you find in every book on code quality
All these hot takes that LLMs are -10x, 100x, 2x are kind of silly. It really depends on:
What you are using it for? What language, what framework, how many LOC, what domain, how much docs can the LLM read, etc etc.
What are you optimizing for? Cost? Human knowing how your code works? Getting something out the door?
How Good You Are at Prompting the LLM for THAT specific set of parameters?
I find AI can save me like 5x time on something, and in other cases it's wasted 5x time. Overtime I'm hopefully learning how to use it better.
techpression 13 hours ago [-]
I spent 30min with Opus 5 generating some CSS and components for my Phoenix LiveView template project (which I use for starting new projects). Then I spent around 5 hours parsing and cleaning up the output. I could of course not have done that, but since it's my spare time project I can care about the code and quality.
I did get wins for sure (and I did save time), and I'm sure most people wouldn't even spend five minutes cleaning up, but this is definitely one place where people talk about different things regarding whatever x speedup they get.
kypro 12 hours ago [-]
> but since it's my spare time project I can care about the code and quality.
I suppose it's yet to be seen, but I'm seeing a lot of spaghetti code being dump into the codebase I'm working on at the moment by other devs. I don't think it's wrong per se, but human code would have thought more about the right abstractions and trade-offs for future maintainability.
There is a gap right now between what an AI can and can't do, and I don't think it's just a time and cost limitation either. It seems like current AIs are very good at writing good code at a surface level, but very bad code when you zoom out a little.
We have a lot of non-technical people committing code these days to constrained microservices and from time to time things break and I'll take a look and I'm always just like wtf am I reading? You see code so bad that you'd immediately fire a human engineer had the wrote it. Thing like explicit hacks to bypass errors that it should not be bypassing or mock data to fake some API that it wasn't able to access. Stuff which literally no human coder I've ever worked with would be contemplate doing...
I think it remains to be seen if the 2-10x speed up some are claiming to have today will persist if the junk code continues to grow.
techpression 10 hours ago [-]
Everyone can drive really fast if you give them a fast car, but very few can stay on the road when driving fast.
LLMs are like free supercars for everyone, except people know nothing about how supercars work or how to drive them. Same thing with software, going fast is incredibly hard if you do it for any period of time, and I think this is something we will read more about in a couple of years, not that human written code never turned out to be complete disasters, but I believe with LLMs we will see at a completely different scale.
And yes, car analogies suck.
imoverclocked 14 hours ago [-]
... the official return of pair programming! The best part: LLM's save you from having to argue with a human. Added bonus: now you get to master two tools instead of one.
14 hours ago [-]
hungryhobbit 14 hours ago [-]
>As such, I use LLMs mainly to produce a rough draft of the code which I then iterate on heavily, at least until I like the general structure
Tell me you just started with agentic programming without telling me you just started using agentic programming.
Look, don't get me wrong: new folks learning tech should absolutely write articles about it! But their claims might very well change once they learn more .. and I strongly suspect that will be the case here.
_se 14 hours ago [-]
Tell me you're bad at software engineering without telling me you're bad at software engineering.
mckee_plus_plus 13 hours ago [-]
Tell me you're bad at people skills without telling me you're bad at people skills
pdsOne 13 hours ago [-]
Such is life.
cherrylemonsoda 11 hours ago [-]
Tell me you're alive without telling me you're living
amelius 11 hours ago [-]
Just wait until inference becomes 10x faster/cheaper.
tristor 14 hours ago [-]
My observation is that AI tools generally make people /less/ productive. They are more productive in that they produce more stuff, but they are less productive in that the stuff they are producing has lower inherent value delivery. The primary place where I see this in software teams as a Product person is in document creation. If you are using an AI tool to produce internal documents, this is likely a net-negative value activity that actually reduces the overall productivity of the team. Why? Because writing is thinking. By handing off document creation to an LLM for a document that's supposed to communicate important details between teams (e.g. technical design docs, requirements docs, strategy docs) you are actually handing off thinking, or rather handing off not-thinking as AI tools cannot "think". The outcome of is poorly "thought out" slop that generates more work for everyone involved to resolve /or/ everyone simply ignores the document and the previous processes stop being useful.
If anything, I'd say AI tools in /most/ enterprises as people are trying to use them now are at least a -30% of productivity. If used correctly for taking a human-written/thought requirements doc, converting it into an interactive prototype that can be critiqued and ultimately included as part of the solution alignment within the requirements doc, and then is handed to an engineering team that is effective at using humans and AI to produce code, then it's probably a benefit. But most businesses lack the internal rigor, quality culture, and data governance to support properly applying AI tools in a high context manner internal to their business.
wannabe44 13 hours ago [-]
Have you worked with codebases where people produced slop even before LLMs? In such codebases LLMs are a godsend. They can churn around huge amounts of code and find needles in the haystack.
tristor 10 hours ago [-]
Since I'm on the Product side these days, I don't spend much time delving into the codebase at this point in my career. I can believe it though, as I've done quite a few personal side projects using langchain and various harnesses. The problem I see is not necessarily that LLMs build things badly (although I know that can also be true), its that because people are using LLMs to generate documents, we are then building the wrong thing entirely (whether with an LLM or not, whether badly or not).
Removing human thought from the process of development is generally a net negative, IMO.
7 hours ago [-]
esafak 14 hours ago [-]
This is a dated take to me. I think the next stage in unlocking productivity is so called "loop engineering"; figuring out how to effectively not read all the code while ensuring quality. To me that means implementing statistical quality control and formal methods.
Before I get there I have to figure out how to reliably audit plan adherence. The problem is that when the specs are in natural language, as they are, you need a fallible LLM to verify it.
fibuladev 12 hours ago [-]
We built a conversational terraform platform at work, you describe what you need for your infra and it produces the terraform code following company standards and rules. What is important for us is the LLM never writes any code. It just extracts a structured spec from the conversation, and a deterministic engine (plain python, no LLM) renders the code from approved modules only. So there is no "code quality" discussion at all, and since the spec is structured and not natural language, you don't need another LLM to verify it, the risk moves to the extraction step which is small and easy to eval. But probably this only works in narrow domains where the output is composable from approved blocks (IaC, config etc), and its not a new idea, just old discipline behind a chat interface. But in that slice the speedup is way beyond 2x.
esafak 12 hours ago [-]
tf is yaml anyway, and llms can output it natively in structured output mode.
fibuladev 12 hours ago [-]
Sure, structured output gives you valid syntax, but thats not the problem we are solving. Our engine simply cannot produce anything outside of the approved module registry (pinned versions, mandatory tags etc). LLM with structured output still can produce plausible but wrong configs. Also same spec always renders the same code, thats what reviewers and auditors actually care
pornel 14 hours ago [-]
I agree that removing human from the loop is the next stage, but we're not there yet beyond small programs.
Agents left alone tend to create so much tech debt, that once the program becomes so messy that they can't fix one bug without creating two new bugs, it's too late to even clean that up.
The program will be super tidy in superficial aspects that linters catch (everything neatly formatted and verbosely commented), and roughly appear to do what it's supposed to do, but everything in between will be "I can't even".
We need something else than formal methods, because the problem is usually in lack of simplicity - you get four versions of the problem solved in four times in four in different ways, each uniquely flawed and just incompatible enough with the others that unifying them is too big and hairy for the agent, and will result in eight different glue adapters written in the process.
petesergeant 13 hours ago [-]
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.
Personally i'm only using local LLMs that i can run on my 7 year old PC (that also has a GPU with 24GB VRAM because reasons :-P) so i'm not sure how much that experience matches what others are doing (though roughly speaking what i see people complain about Claude doing doesn't feel that different from what i see the local stuff doing, so i guess the drawbacks aren't scaled down as model sizes increase).
I'm not sure about 1x, 2x or 10x increase as these metrics are about code written but that isn't a productivity metric (something pretty much every half-decent programmer would agree with before LLMs - remember stories about Bill Gates saying that more LoCs being good for software is like more weight is good for airplanes or Bill Atkinson's story about adding -2000 LoCs to improve QuickDraw?).
But they can certainly help "get you going" faster in that if you're stuck on something (for whatever reason - including "that feels too much drudgery") or have issues starting something, you can have an LLM take a stab at it and it'll produce "something". Sometimes it is enough by itself, but more often than not it'll need tweaks (either directly or having the LLM do it). I got to make a bunch of things i couldn't convince myself to do - e.g. an image viewer that doesn't suck (based on my arbitrary judgement), a game database, a script to convert a git repository into static html pages that kinda look like GitHub, etc.
They can also help find (and sometimes fix) bugs or other "code smell" issues. They're not that great for exact results (without tool calling -and knowledge on how to use them effectively- at least) but when it comes to fuzzy / vague stuff like "check out this code <code dump here> can you spot any issues?" they always tend to find some stuff (even if it is hallucinations :-P but sometimes they find actual issues too or whatever hallucination they come up with reveals some actual issues with the code that you didn't spot by yourself). I've been dabbling with Rust recently and asked Qwen 3.6 35B-A3B to judge my code and it wrote "6.5/10, will compile but looks like C in Rust" :-P.
The article says:
> Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.
And sure, LLMs aren't that great about those (i do let them leave whatever comments they want though and remove them later myself - i think those comments help during the generation/prediction - basically how they "think", kinda like the reasoning phase), but they can be very good at things like "here is the code, here is the documentation for it, spot discrepancies" (i had Devstral Small 2 do this and it hallucinated a few discrepancies but also found real stuff i missed in the docs).
I've tried to use Devstral Small 2 for some API docs but found it'd sometimes make assumptions about what function do or how. One approach that might work, but i haven't tried yet, is to write the "guide" myself, then have the LLM write the function docs using both the guide and the code as reference. The reason i think this will work is because it got things 95% correct just having access to the function code alone (and without the rest of the codebase), so the "guide" would help it reach 99%. I do not expect it to get to 100% so a manual edit pass will need to be done anyway (and i have an idea for a tool to assist in the manual edit pass for that - a tool that i'll probably get an LLM to write - BTW good luck coming up if all that stuff would increase or decrease productivity for an actual product and not some random stuff i'm toying with :-P).
One other thing i've also found LLMs useful recently is to have them use the stuff you make and see how they try to use it. I have an old project, a GUI toolkit i've been hacking on every now and then since 2011 or so, though it was never a priority. Yesterday i decided to dump all the header files to Qwen 35B-A3B (i use 4bit quantization that gives me a 256k context - it isn't particularly smart but it is neat to not have to micromanage context size like i have to do with Devstral Small 2 or Qwen 27B where both of them aren't very usable speedwise at anything above 32k context sizes).
Then i asked it to just make a few small programs and it did[0] (the shot shows a paint app, a calendar, a todo list and a unit converter). Pretty much every program found bugs in the library :-P and gave me ideas on how to improve things.
In general i get the impression that LLMs aren't great at architecting things but if you do the architecture yourself and write them a framework to use, they should do a fine job at it.
More than 2x for me. The models are accelerators, but the biggest gains came from building workflows around them. I spend most of my time documenting what I want, while implementation and much of the surrounding work become relatively cheap. I've found that AI amplifies engineering experience more than it replaces it. The better you are at framing problems and evaluating solutions, the more productive it becomes.
Ozzie-D 8 hours ago [-]
[flagged]
dan_gee 14 hours ago [-]
[dead]
what_hn 14 hours ago [-]
Does a 60x speedup count? Are you still copying and pasting from chatgpt, because if so your definitely doing it wrong.
forlorn_mammoth 14 hours ago [-]
Wait, how about an infinite speedup? A friend of mine couldn't code, and now he can. So he is infinity-x better at coding thanks to LLMS!
Take that, you mere 10x-ers! Your days are toast!
dgellow 14 hours ago [-]
Left behind, as the infinite-x rockstar developer roars off on their motorbike, trailing a plume of dust behind
prmoustache 14 hours ago [-]
If 60x was a thing, we would see many fantastic products appearing on the market, every product would have improved or goten major new interesting features. Yet it hasn't really happened.
klibertp 13 hours ago [-]
10x or 60x of very little is still not much. "Working programmers" unable to write FizzBuzz exist.
10x or 60x of a negative value is a 10-60x bigger problem than that initial negative value. We all regularly commit things that are actually net negative.
Finally, 10x or 60x more productivity channeled into yet another static site generator, CMS, or programming language doesn't really help in improving products or developing new interesting features.
In short: LLMs offer real productivity gains, but they are still tools, and they are very new, so we misuse them a lot, in various ways (not limited to examples above). Unless they replace programmers and can consistently produce better than average code (even if they fail catastrophically in a few cases), they won't fundamentally change programming. They did change a lot, but not enough to get the result you're describing.
wongarsu 13 hours ago [-]
I believe I have seen 60x improvements on certain classes of bugs. Just not on development as a whole
And I've also seen the other side, where vibe coding on projects that had bad code quality to start with leads to bug riddled messes. Projects with beautiful and elaborate test harnesses, that break seconds after contact with a real human user
iLoveOncall 14 hours ago [-]
[flagged]
throwitaway222 10 hours ago [-]
Skimmed, it's using the word llm a lot, no instances of the word Agent, codex, claude. The person writing this isn't using LLMs correctly.
So the comparison is not only "built with and without LLM" but "would you even build this if you didn't have the LLM?". The gap in productivity in this case is much more wide.
This can be a negative multiplier: code I thought I wanted that gets immediately abandoned is a net-negative if no one else wants it (lets face it, this is the safest default posture for software of unknown providence).
In isolation, instant-abandonware takes up hdd space, burns dependabot's CPU-cycles, and wastes human attention when appearing in search results. In aggregate, it floods the zone with a deluge of forks with imperceptible differences between them, based on nit-picks, legitimate stand-out products will have a much harder time going forward.
Some things are already very useful as just a one shot. I just made a quick app to help me pack for a trip, it updated forecasts every day, let me know when rain entered the forecast at one of my stops and gave me a checklist that helped me quell my travel anxiety.
The greatest thing that LLMs have done is allow many to achieve things that they couldn't have before. I'm incredibly disinterested in "I can do the same thing I was already doing x% faster"
it's truly fascinating how many positive descriptions of AI gesture at emotional management. I think that's the killer feature of this technology -- it makes people feel good, capable, reassured -- without the risk and vulnerability of interacting with another human.
I use Google Weather for my forecasts btw, no need to vibecode an app for that
I can keep track of my expenses on a napkin but i'd much rather use a spreadsheet or dedicated app especially when that app is effectively free.
I think you misunderstood my point: by "legitimate stand-out products", I meant exactly that, with no connotation of commercialization. Maybe you can agree that having a high signal-to-noise ratio for (open source) projects is a desirable goal?
> Some things are already very useful as just a one shot.
I agree. I too have made or forked about a dozen apps and tools in the past few months. It would be dishonest not to consider the flipside, that this software is overfitted to the needs of a single person. Further, this hyper-bespoke software typically feature-complete within moments of the final prompt, and I have,on occasion, completely forgot about the tool/app I spent a weekend created, it clearly wasn't worth the effort I put in.
> The greatest thing that LLMs have done is allow many to achieve things that they couldn't have before.
Let's not pretend there isn't a cost to this.
The word "product" implies commercial.
I disagree; but see where you're coming from. I'm chuckling at the irony of my word-choice: I initially had used "project" but nixed it because of its frequent association with Open Source. I instead opted for "product" as a broader term. For the sake of clarity, my original comment is referring to commercial and non-commercial software projects/products.
obviously not ? negative result is still a result, just like in science. It adds new information ("approach X does not work" / "is useless") which is the only thing that matters
Unless you only run code that's protected by God. That's probably not a bad policy if you can verify it.
edit: Oh right, there's an OS for that https://en.wikipedia.org/wiki/TempleOS
If I were running around saying "providence" instead of "provenance" I would want someone to tell me.
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.
However, without an agent running its own experiments on a cloud GPU, would I realistically have invested my limited work hours and tried evaluating 10 different models, each with 10 different tuned parameters, to solve my specific use case?
Or would I have tried 1-2 models and spent my time trying to optimize those models?
I think there is some merit to the spray and pray approach when one is in the exploration phase of the solution space.
Also, on more than one occasion now, I have had fable halve the inference latency of a model simply because the original implementation from an academic included unnecessary GPU-to-CPU-to-GPU transfers or similarly inefficient operations. Those optimizations came at essentially 0 time cost to me and I can verify that the outputs are byte-identical. Pretty sweet!
E.g. software that generates these models that I can print
https://wiki.roshangeorge.dev/w/Blog/2026-06-30/Modeling_a_W...
https://wiki.roshangeorge.dev/w/Blog/2025-12-01/Grounding_Yo...
Or blog post authoring software
https://wiki.roshangeorge.dev/w/Blog/2026-04-25/The_rise_of_...
There were so many things that no one will ever study and won’t give humanity any benefit but I use everyday to make my life better. That’s enough. The value far exceeds $200/mo. I’m getting it for cheap and now that I have my GPUs and my models they can’t even take it from me in the future if they wanted, haha!
LLMs allow for human flourishing on a massive scale. One of the best inventions to occur in my life. Up there with the Internet/Web. Truly a marvelous time.
Agreed. I haven’t been this excited by computers since I got broadband DSL in 1998.
This has led to 3 parallel pieces of adjacent work that each speed up our build by quite a drastic margin. When combined, this is a massive improvement. None of this would have happened in the old days, as the research itself takes a long time to babysit and a lot of options to check.
So I very much agree - the activation energy can be a lot lower on some kinds of tasks, and some of those get big returns for small inputs. It's not all like that, but part of the game is identifying when you can spot those high return efforts.
dev A knows exactly what the program should do and how to verify the AI output
dev B thinks they know what they are doing but are actually misguided by bad psycophantic AI output they have incorrectly verified.
both work on product C
I'm doing analysis on stuff that we previously simply couldn't do in my company, it would take way too much time or effort, and we didn't have the manpower.
Without AI they might have first spent more time validating the idea was worth it.
The thing with constraints is that you focus of the thing with high value first. So you focus on the most promising ideas first or choose experiments that can get rid of most ideas. Instead of trying to validate each ideas and generate what is most likely noise to the decision process.
Like if I ever hire an assistant, I want like one to three options that are closely aligned to my needs, not a bible size report on 42 choices.
Seems optimistic
It's a braindead simple program that mostly hooks together pre-existing functionality, it just so happened that none of the widely available apps had the specific mix of features I wanted. I could probably have done it myself in a week if I took time off my non-coding day job to figure out Swift and AppKit. But I wasn't going to do that. I’m psyched. I hate web apps and now I can just write my own for all the little things I use every day.
This is basically replicating the plight of the solo open source dev, writ large. Individual programmers have long built the thing they've cared about on their own time (essentially "for free" because, despite kindergarten economics theory, a programmer cannot usually monetize a marginal hour). And it usually goes that the project never gets adopted anywhere. It might acrue more features and total man-hour effort than most of what FAANG does in open source to drown out the solo devs. But the market will decide that "no organizational buy-in" is a signal the project doesn't matter. Other developers will decide, "if he could do it, so could I" and also not adopt.
Same exact thing is happening and will continue to happen with all these generated "but we wouldn't have done it otherwise" projects. It's just very, very unlikely to go anywhere.
That which took very little effort to create will receive very little effort to promote.
Its like making a jig in woodworking. The measure of the jig's success is not whether it gets re-used or widespread adoption, its whether it made it easier to achieve some actual objective. Because the jig is a means to some other end.
Lots of these "we wouldn't have done it otherwise" applications are means, not ends.
For stuff that I'm used to (R) I can write nice and compact spaghetti (long %>% pipes). I'm not comfortable when a working script doesn't fit the screen (plus a few scrolls max). My style is probably easy only to me. When I teach, I don't teach it in particular.
AI gives me thousands of lines of codes for those. 10k once. It's cool if it suffices to source it all, but working with that is not pleasant.
But if I can reproduce a paper in a one-shot (it used to be an hour, but recently it got so much better), that's a task that would not have been even attempted years ago. And I'm talking about a methods paper with no available Github (or, as often happens, when the existing Github is useless)
I also do mostly research or one-of script development, for which I find LLMs less useful, as I want simplicity and I want to understand exactly what is happening. The only time I find LLMs help really there is if there’s some part I can abstract away like writing and interface to an api or something.
Now I feel like 5.6 Sol Ultra is capable of doing roughly the same with its Agents, so it's getting easier in my experience. With the Codex, it can adjust or correct until the output is suitable.
I'm sure it depends on the field and the method.
So my two choices are basically “YOLO, LGTM” and hope I can revert if it breaks something, or to just write all the code by hand from the start. With the increased pressure for output, I’ve noticed both myself and coworkers tending more toward “commit and hope it works” over time. It’s sort of perverse incentives in a way...
But maybe that's just me.
I tried their "local ai autocomplete" thing a few years ago for a little while and it was hot garbage. It guessed the right/acceptable completion about 30% of the time at best.
I haven't looked at it since.
One challenge is when knowing how the code should look like, the LLM solution always looks weird, and one tries to maunally steer against it, so accepting a bit of "good enough" is unavoidable to gain some productivity
- 25% planning & aligning with other teams
- 25% coding
- 25% testing/verifying
- 25% code review/rework
One argument was that agentic coding speeds up that coding part a bunch. So maybe there's 2x speedup in coding. But that's only a small speedup in the totality of everything software engineers do.
You could argue that it speeds up development by 5X or more, but then it slows down testing/verifying, code review, and in many cases it makes it impossible to review/rework by hand.
I just do what I'm told at work but even though I'm sure I'm in the minority I'm extremely skeptical that LLMs can produce any good-quality code.
Looks to me like we've just lowered the bar--by a lot--and stopped looking at the code that goes out. Every time I look into how Claude implemented something it's completely insane, with no way to refactor it or maintain it in the future.
The 10x speed up comes from the fact that we have all given up on properly reviewing each others code and we just say “meh, it will be fine, lgtm”
I’ve come to realize that I don’t actually care what your code looks like. I’m going to need to learn it from scratch every time I use it. It’s going to look weird and foreign to me no matter what. It’s not worth my time nit-picking things that simply do not matter.
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.
But LLMs seem to have a hard time getting the big picture and reusing code that is already implemented and ALMOST does what you want vs. rewriting everything from scratch.
AI code is extremely difficult to read and follow. It's littered with hundreds of lines of comments and notes, often referring to other notes in other parts of the codebase, and often extremely out-of-date.
Claude seems to me to still focus on getting things done vs. doing it properly, so from my experience it would pretty often mess up your whole codebase just to be able to finish its task, vs. stopping and rethinking the approach.
After a few passes of that, with duplicate code with no underlying coherent vision, hundred of thousands of lines of documentation written as walls of text in markdown and weird coding decisions, your codebase is impossible to work out for a human.
I use Claude Opus 5 at high to plan, Claude Opus 5 at low to execute the plan.
I make it build things in small changes, I give very specific instructions about the architecture, and I make sure to point out existing functionality that can be used instead of writing something from scratch. But it's a lost battle because Claude can't learn and it's basically a black box.
It pretty shitty, but that's what they pay me for so I just do it.
Adjustable by tooling and prompts - my favorite is a ban on comments >2 lines, a tagged index system for effectively in-repo RAG with short documents on each tagged topic like INFRA-DATABASE-SETUP.md - enforce with tooling that the tag matches the doc and vice versa. Enforce that any PR that has a tag change in it has the relevant doc changes.
> Claude seems to me to still focus on getting things done vs. doing it properly, so from my experience it would pretty often mess up your whole codebase just to be able to finish its task, vs. stopping and rethinking the approach.
Tell it your values - "I value correctness over getting things done, and getting things done properly over speed" solves many of those problems. I've actually spent a portion of today rejiggering my values documents because the models have improved enough I no longer need to be quite so careful about scoping.
I was having those same problems, but particularly using Fable / Sol to do the meta-work has largely eliminated them over the last ~3-4 months. Codebase is now a lean mean token-conserving machine.
It also aligns with what I saw from Claude & Claude Code when I used it last year for a while. Now I use Codex and don't see (nearly) as much of that sort of behavior.
> But LLMs seem to have a hard time getting the big picture and reusing code that is already implemented and ALMOST does what you want vs. rewriting everything from scratch.
Yeah that's probably the weakest point of LLMs still. GPT-5.6 Sol got much better at this for me. I still usually end up doing 2-3 iterations of prompts and exploration to clean up various things but usually it's pretty light work now.
> hundred of thousands of lines of documentation written as walls of text in markdown and weird coding decisions, your codebase is impossible to work out for a human.
Okay Claude definitely seems to have an issue there. From what I've seen from coworkers using Claude it generates reams of endless docs. I resist the urge to `rm docs/planning*.md`! I don't think they get how bad Claude is at that.
A month back I tried the latest DeekSeek and it made reams of text back and forth with itself, but the code it output was reasonable and it didn't make pages of markdown files either.
> I make it build things in small changes, I give very specific instructions about the architecture, and I make sure to point out existing functionality that can be used instead of writing something from scratch.
That's a bummer. I found that once the models start having problems that it cascades.
I've also been able to keep steady progress on a 70k+ LOC GUI side project without the endless whack-a-mole of bugs using Codex and Sol. Squash a bug, review architecture, move on, etc.
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?
- 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.
Suddenly devs who were cranking out features with no interest in infrastructure are attacking giant refactors to make the code more understandable to the LLM.
Other devs are using LLMs to build themselves quality of life SDLC tools completely separate from the core code base.
Plenty of other examples of this.
Of course, the main issue is that they’re completely undebbugable now. My bash scripts used to be a sequential list of commands, now they’re 500 lines of variable laden functions.
Is my life any better? Dunno. But it’s satisfying (until there’s a bug)
Well, that means the quality actually dropped then :). Looking impressive isn't equal to quality, understandability and reliability is
A node glob() or a regexp string.replace call is probably easier to read than spaghetti shell.
And your llm might do a much better job of creating clean, readable and testable code.
I'm glad you're doing all those right things; but, really, some of us were already doing most of, if not all of that. And some of us (like myself) were doing it very quickly, too, since we'd been doing it that way over a decade and constantly getting faster.
* Learning stage: 0.5x - 1x. I change my system prompt to teacher mode, taking the productivity hit for actually learning the system/tool pays off dividends later. I change my system prompt to "teacher mode" and slowly loosen it as I get more confident.
* Working-knowledge: 2x - 3x. Once I am ramped up enough I feel like I can get a decent productivity boost. Most of the time is spent at the planning stage. This is my mode for areas I don't really own or care about, just need to get work done.
* Mastered: 10x+ I have been doing web front end for 12+ years, I can quickly review plan/implementations and for my initial prompt I already know most of what I want built.
1x == my speed before AI
This really needs to be calibrated to the type of work and complexity.
I can actually believe that LLMs would speed up basic web dev work in small, simple codebases 10X for simple requests.
These conversations usually turn into people talking past each other because they’re working on different things. For other less routine and more complex work, expecting a 10X productivity boost is not realistic at all. It doesn’t matter how good you get at writing prompts and reviewing plans. LLMs just don’t solve everything for you in a good way. Some times the true nature of the problem is revealed while implementing it and by deferring everything to an LLM you spend days throwing tokens at the wrong thing. There is a lot of work where the LLM speed up comes from helping you quickly search docs and codebases and double check your code, but handing the entire thing off to an LLM isn’t reasonable. These tasks aren’t going to reach this mythical 10X productivity boost that is genuinely achievable for much simpler work.
If you look at the code the LLM spat out (and you really, really should!) you will immediately notice that its shape is not what you thought it should be. You might not notice immediately if you're learning, but if you really "mastered" the domain, you will "just" see it. You will also recognize the problem with your assumptions, and immediately (or after some research) correct the prompt.
Looking at the diffs for everything the LLM does slows you down, of course. Not looking - or looking and not recognizing problems, for one reason or another - can be initially faster, but a single pathological case can eat both the time saving and tokens. For domains you truly "mastered", the current models can generate code as if they read your mind (because you can be that precise in the prompt, and quickly), so it's really glaring and very hard to miss when they somehow misread your mind.
It only works at the "mastered" / "unconscious competence" stages, and only in those narrow domains you truly mastered, but it does seem to work. Is it 10x? No idea, but there is a marked change in the speed boost when crossing from conscious to unconscious competence area, with everything else (harness, model) staying the same.
[1]: https://news.ycombinator.com/item?id=48359858
Luckily I work remote. I'd turn it off again, but my usage is monitored and I don't want to look like a Luddite.
So may be .75x to .8x range.
You must know the codebase well if the LLM is slowing you down.
Actual problem: he typed in the wrong password
I am no longer:
- reading docs for hours and hours
- typing (barely at all)
- writing code
- manually doing tight debug loops
- using an IDE
to do this I had to give up reading or even controlling the code and focusing on behavior/design-level control (not superficial, still dictating overall technical architecture)
i have agents doing everything from writing the code, verifying the code, hardening, increasing test coverage, analyzing behavior, algorithmic perf improvements, managing/deploying to cloud resources, etc... (pretty much everything)
and I am accomplishing projects that would take months or years in a fraction of the time.
that's way more than 10x.
somehow, this is harder and more cognitively demanding than writing code
how do you verify the behavior? are you still writing or at least reading tests or just doing manual testing?
And that's the second time this happened over the past few months.
The 2nd thing is, how do I measure that.
---
In my case, the details of my work (Kinda DevOps, kinda Senior Dev) makes it that having an LLM to do the heavy lifting allows me to do things not only faster, but better, and across domains I do not hold expertise on.
An example of the effect of LLMs in my daily work is that I'm in the middle of a PHP upgrade for a rather large legacy application, and the "heavy lifting" is really out of the scale, letting me concentrate on what really matters, while at the same time if I do keep "the harness" tight I'm certain the results are the correct ones. Also correcting course is just as cheap.
Not having to worry on the tooling on exchange has the incredible desirable result of my velocity being incomparable to what it was before.
Then we have the side effect of how easy to do transfer knowledge: Rather than telling the QA guy how to do the work specific for this task, I defined a set of files (.md documents, skills, an off-the-shelf customised MCP server) that assist QA into doing the work in a way that helps me do my job better and faster.
There's also a clear possibility that what I'm doing will expand to the rest of the team I am in, completely altering the way in which we approach development.
If we take 'x' as 'mileage', yours might vary. Mine has, and I'm baffled at the positive net results I AM getting.
Also, this what I do (coding?) is extremely fun again.
Being able to work close to the speed of thought is the best high.
How would you know it's better when you have no expertise?
There are many domains where an intelligent human can act as a discriminator for output without knowing exactly in precise detail how the process itself works.
I had a task to completely gut out a codebase to share with a vendor. I gave them my estimate - 2 weeks. Asked Claude to do it, and was done in an hour. Reviewed the changes, and it was perfect. This is an outlier of course, and it was a pretty basic codebase. But it's real world stuff.
Overall though, if I had the mental fortitude to work for 8 hours straight, I could easily average 5x my "normal" performance. But most days I can't perform at that level. Also I admit I am not a fast developer, I do a lot of testing and verifying as I'm paranoid.
Like always. This is why the average carpenter you hire in 2026 still won’t do a perfect job, despite carpentry having existed for thousands of years.
Between "stable" and "extinct" are many stages of software engineering labor market change, continually more difficult (for labor) as we move toward the latter state.
Software engineering is likely to become a skill/tool attached to another harder to automate ability going forward rather than a vocation/craft on its own.
To the extent that software engineers are employable, they will likely need some other x-factor adjacent to software skills, whether in the science, business, creative/artistic, or social domain. I've already seen this trend emerging in the startup world.
OP's description very much mirrors my experience. I was able to do many things much more quickly with the help of the LLM, but there is no substitute for actual users interacting with the tool, saying, "I like this," or "no, this is wrong or needs work," or even, "here's something none of us thought of before, but now this tool makes me think XYZ would help us and might be achievable." That whole interaction takes real time and I don't know how you replace it with coding agents.
Secondly, on the matter of code structure, just on a qualitative level, I can see that claude will do things very efficiently on the way to a goal I give it, but it can't read my mind and know that I may want to repeat a specific pattern across two client apps. Or that its shortest-distance solution makes extensibility or broad applicability difficult. That I might want to share code and structure things in a certain way. Not without me saying so or, in many cases after it has built something workable, duplicating refactors I make with an eye for reusability or maintenance. Making those changes in time is important if you don't want to burn tokens later as the LLM tries to unravel its own spaghetti. And again, whether I am coding those intentions directly, or writing out detailed instructions in english, all of that takes time.
Users pointing out things that are missing, or me forgetting to tell them I’ve added something, or both of us having a different idea in our minds of what something should do. It’s still extremely time consuming.
From a firm that has fully embraced agentic engineering, they offered topline stats on their measurements of a 4x boost from November to February, and 8x on top from February to May. That's 32x since November 2025, coding with LLMs.
And like whatever, this is second hand and I'm not going to disclose the source. Actual hard, published, and peer-reviewed research is needed here to backup quantitative claims. 2x, 10x, 32x, whatever.
There is a lot of reason to suspect that at most companies, especially more established non-startup ones, there will close to zero bottom line benefit, because these companies already have free paid-for developer capacity (developer down time between project cycles) that presumably they would be utilizing if there were reason do to so. In a startup environment where there is zero down time, then productivity may at least show up in reduced time to market.
I think Uber's current experiment of limiting AI spend to 10% of salary per developer is interesting since it implies that spending more will not even recoup the extra token cost, although it does remain an experiment. Maybe they will see a revenue increase related to AI spending and choose to tweak that limit up, but it's also entirely possible that all they are doing is reducing developer workload by giving them a productivity tool, and there will be no financial benefit.
As AI based development processes continue to improve, the confidence level employers will have in safely cutting jobs will increase. The longer term impact of AI is HR savings rather than introducing new capabilities into business.
i think LLMs are only a useful multiplier if you’re working on the plumbing parts, it’s never useful if you’re doing anything novel really.
if this bothers you, i am sorry and i wish you the best with your reddit trained auto complete. i write new code
> Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.
This is quite validating as I came to the exact same conclusion myself. We’re required to use an LLM for every task at work that touches code†, and I was really struggling to get Claude to stop with the long waffly comments that reiterate the next few lines of code in 3x as many characters, making contextless references to subtasks in whatever harness du jour we’re using this week.
No amount of examples or explanation of what I wanted would make it stop. And then I realised of course, I’m asking something which has no concept of meaning (or, indeed, anything) to only add meaningful comments. More fool me I guess.
Of course, it’s ultimately pointless given all of my colleagues are regularly opening PRs with more comments than code anyway. 80% of my code review responses these days are just increasingly exasperated “pointless comment, please remove”.
† This is just as infantilising as it sounds, by the way
I use AI all the time, it gives a tremendous boost in speed for many tasks and it is most certainly here to stay, but there is something off about certain things, like code comments. Like a weird person.
[0] https://github.com/chrisvariety/branch-fiction/blob/deb37f2b...
No amount of agents.md / commit to memory updates has stopped agents from littering the code base with useless comments.
Think I'll add it to pre-commit hooks getting called by posttooluse
Why not just write the code in the prompt so LLM can paste it.
I have tried to shut it down, it immediately nullifies the docs and make it genuine slop.
I truly believe that documentation should be human written and human readable. It's all of the stuff that AI does NOT pick up on. Small inconsistencies, only the necessary details. IE: Don't just rewrite the code that we have into readable english (We are software developers after all. We can read code.) - comments / documentation to me has always been the "in between the lines" stuff that can't be put into the code.
We all have a limit after which we lack the attention (or attention to detail, or time, or energy, etc.) to meaningfully manage it.
Similarly, a manager may be able to handle a team of two very well but end up poorly managing a team of 20.
It used to be that knowing how to write code was a big factor in productivity. Now it is less of a factor compared to the many other cognitive and metacognitive faculties that working with agentic teams demand.
Semiconductors following Moore's Law increased their density, which is a reasonable metric for effectiveness, by 40% a year for several decades. Leaving aside projections of AGI in two years, it's still a substantial impact if we can figure out how to increase coding productivity by 40% a year for two or three decades. I don't think that gets us to AGI or the Singularity, but it's similar to the impact of the steam engine, steel, or electricity.
These are "normal technologies" that were transformational, and that may be the path we are on with LLMs.
Is that really from improvements in LLMs, or from improvements in the feedback loops?
In projects that are so big that no single coder or no small group of coders is sufficient to grasp I don’t have personal experience, but my guess would be that they are just a cluster of other small projects.
Sailing into the relms of lesser explored area are painful.
It's like an intern but never learns, only getting replaced by better interns.
About a month ago I pirated an Argentinian movie and the only subtitles available in my language were out of sync and at a different speed/framerate so adjusting for delays wasn't enough. I was unsuccessful at fixing it with VLC and every other "online tool" I could find.
Knowing a srt file is just text with timestamps I vibe coded a python script to take in sample times throughout the movies so it could recalculate the rate and shifts and replace them in the file. It worked on the first try using only the deepseek web chat interface and my terminal.
Without AI I theoretically could have sat down with a pen and paper to figure out the math adjustment, then looked up python input handling syntax which I already forgot, typed something out and then hammered it into shape through trial and error over a few hours. But the friction and time investment of doing that would have been so great I would have just given up on watching the movie instead.
This made me chuckle. I do think we are seeing exponential improvements over the years and that we don't always notice it happening because we're right in it.
Really depends on the task, my the project and on, and honesty, my instrest and availability at the moment.
The precise and rigorous practice of “engineering” in 2026.
It's become a lever that allows me to learn as I go while tackling problems that are far beyond what I already know. I know a lot, I've programmed for decades in a lot of languages in a lot of domains. But, with the current crop of the best LLMs, I can reach for bigger problems...and actually make progress. I've read books about DSP for audio, and have done little toy projects in the past, but with LLMs, I'm building complex and working synthesis engines in a couple of weekends. That would have required a few months of study and experimentation before. So, that's a huge multiple. Like 100x.
For things in my area of expertise? Probably still just 3x, maybe 4x, because it makes fewer mistakes I have to fix in code review. It still writes terrible docs, as the post mentions...they don't understand user desire, so they simply can't write documentation for a user to actually use. You can't prompt them to make really good docs, but I can usually prod their docs into coherence a bit faster than writing it myself.
But, it's the lever for doing things I've never done that is such an addictive thing. Which, I imagine is how non-technical people feel shipping their first web app or whatever with these things. For basic work, I think we're at a point where almost anyone can use an LLM to make working software (not necessarily secure or stable software, but working). But, I think we're also at a point where an expert can make that lever really do something, and I hope that means we'll begin to see extremely ambitious new software in addition to all the throwaway junk that's been proliferating at a frightening pace.
In short: Maybe don't make another fucking "memory" system for your chatbot so they can be your friend who remembers your birthday, and instead work on something meaningful.
It's worth asking ourselves "why does the x amount matter?" I get the desire to define KPIs to estimate productivity gains. But this all seems to be—rather rapidly—leading to an increasingly dehumanized reality (both figuratively and literally) so we can...produce more software? I love building software, and I enjoy using LLMs to help me do it, but there's just this weird vibe I can't quite shake about how we're trying to quantify all of this.
I already convert from multipliers to percentage of increase, so when someone claims 10x they very likely mean +100% productivity, and here 2x means +20% productivity, which seems about right. Nobody that was normally productive before LLMs has suddenly 10x'ed their output now.
The problem is that 20% productivity when it comes to generating code, really doesn't translate in 20% productivity increase overall, when you take into account the fact that the code quality is worse, the fact that writing code is actually not the majority of your time spent, and that people get burnt out from the usage.
Wouldn't trade it though. Feel like I can overall do more with less time and energy.
At the end of the day, AI is making me work more (good thing). If you count that as productivity, then sure.
How is that good?
I'm two weeks into a project that has been interesting and also has confirmed the above yet again. I am porting a Windows application written in Python to C# using Avalonia UI.
I have never used C# or Avalonia UI. I've written Windows applications in other languages, never C#. I don't know the language, libraries, etc.
At first I told Codex: Here's the source code, port it. I just had to run that test.
Well, it didn't end well. I'll describe it as a frustrating set of prompts that seemed to result in the implementation going in circles with constant problems being introduced, breaking-fixing-breaking, etc.
I then started again with a clean repository and played the role of the architect with full documentation in the form of code. File-by-file, I had it port modules to effectively develop an operational foundation for the classes, methods, properties, abstractions, hardware interfaces, etc. in the original Python program. That went well, was very fast and a good experience. I am running Codex in JetBrains Rider and the integration is excellent. The native OpenAI Codex application is an absolute dog...it pegs all my cores at 100% while doing nothing.
Once all the underlying infrastructure was ported and, to the extent possible, individually tested, I threw UI integration at it. This happened quickly and OK from it's-ugly-but-I-can-use-it perspective. Codex seems to be way out of its element when it comes to UI/UX understanding. Funny examples like placing a button on top of an image with the image covering the button because it had a higher z order. Or finally placing the button at the correct z order but making it transparent on-hover. Funny stuff when you are moving slowly and you see it happen. It just proves that there is no understanding whatsoever.
With all of that and the experimentation, I'll estimate that a six month project will be cut down to three to four weeks. Another month and it will probably be a much better program with new features and more advanced capabilities.
And I have not touched a single line of code. Developing solid prompts is the absolute key, something that you can only really learn by doing and through lots of experimentation.
Yes, of course, I fed it working code. I think it could be very different if I were to start something from a blank slate.
Weird… I would have said this was how it was about 2 years ago, but no way in 2026.
TBH i expect it'll take several years before people largely settle on what works good and what works bad (or doesn't work) and that's assuming things wont chance in a massive way during that time.
And this isn't really anything new, people rarely come up with some new way of programming and have everyone learn and understand best uses from the start - it takes years (and that is assuming everyone will agree that'd be something worth bothering about).
I found that latest codes don't write comments in code by default. And when they do, they write stupid shit like "This was code that did X, it was now removed".
You have to explcitly prompt them to write comments in code. They are still useful for you, the user. But are arguably useful for the model, too, given how many of them (especially Claude) only reads small chunks of files. So I'd rather have code comments than it reproducing a picture from incomplete data.
What you are using it for? What language, what framework, how many LOC, what domain, how much docs can the LLM read, etc etc.
What are you optimizing for? Cost? Human knowing how your code works? Getting something out the door?
How Good You Are at Prompting the LLM for THAT specific set of parameters?
I find AI can save me like 5x time on something, and in other cases it's wasted 5x time. Overtime I'm hopefully learning how to use it better.
I did get wins for sure (and I did save time), and I'm sure most people wouldn't even spend five minutes cleaning up, but this is definitely one place where people talk about different things regarding whatever x speedup they get.
I suppose it's yet to be seen, but I'm seeing a lot of spaghetti code being dump into the codebase I'm working on at the moment by other devs. I don't think it's wrong per se, but human code would have thought more about the right abstractions and trade-offs for future maintainability.
There is a gap right now between what an AI can and can't do, and I don't think it's just a time and cost limitation either. It seems like current AIs are very good at writing good code at a surface level, but very bad code when you zoom out a little.
We have a lot of non-technical people committing code these days to constrained microservices and from time to time things break and I'll take a look and I'm always just like wtf am I reading? You see code so bad that you'd immediately fire a human engineer had the wrote it. Thing like explicit hacks to bypass errors that it should not be bypassing or mock data to fake some API that it wasn't able to access. Stuff which literally no human coder I've ever worked with would be contemplate doing...
I think it remains to be seen if the 2-10x speed up some are claiming to have today will persist if the junk code continues to grow.
Tell me you just started with agentic programming without telling me you just started using agentic programming.
Look, don't get me wrong: new folks learning tech should absolutely write articles about it! But their claims might very well change once they learn more .. and I strongly suspect that will be the case here.
If anything, I'd say AI tools in /most/ enterprises as people are trying to use them now are at least a -30% of productivity. If used correctly for taking a human-written/thought requirements doc, converting it into an interactive prototype that can be critiqued and ultimately included as part of the solution alignment within the requirements doc, and then is handed to an engineering team that is effective at using humans and AI to produce code, then it's probably a benefit. But most businesses lack the internal rigor, quality culture, and data governance to support properly applying AI tools in a high context manner internal to their business.
Removing human thought from the process of development is generally a net negative, IMO.
Before I get there I have to figure out how to reliably audit plan adherence. The problem is that when the specs are in natural language, as they are, you need a fallible LLM to verify it.
Agents left alone tend to create so much tech debt, that once the program becomes so messy that they can't fix one bug without creating two new bugs, it's too late to even clean that up.
The program will be super tidy in superficial aspects that linters catch (everything neatly formatted and verbosely commented), and roughly appear to do what it's supposed to do, but everything in between will be "I can't even".
We need something else than formal methods, because the problem is usually in lack of simplicity - you get four versions of the problem solved in four times in four in different ways, each uniquely flawed and just incompatible enough with the others that unifying them is too big and hairy for the agent, and will result in eight different glue adapters written in the process.
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
I'm not sure about 1x, 2x or 10x increase as these metrics are about code written but that isn't a productivity metric (something pretty much every half-decent programmer would agree with before LLMs - remember stories about Bill Gates saying that more LoCs being good for software is like more weight is good for airplanes or Bill Atkinson's story about adding -2000 LoCs to improve QuickDraw?).
But they can certainly help "get you going" faster in that if you're stuck on something (for whatever reason - including "that feels too much drudgery") or have issues starting something, you can have an LLM take a stab at it and it'll produce "something". Sometimes it is enough by itself, but more often than not it'll need tweaks (either directly or having the LLM do it). I got to make a bunch of things i couldn't convince myself to do - e.g. an image viewer that doesn't suck (based on my arbitrary judgement), a game database, a script to convert a git repository into static html pages that kinda look like GitHub, etc.
They can also help find (and sometimes fix) bugs or other "code smell" issues. They're not that great for exact results (without tool calling -and knowledge on how to use them effectively- at least) but when it comes to fuzzy / vague stuff like "check out this code <code dump here> can you spot any issues?" they always tend to find some stuff (even if it is hallucinations :-P but sometimes they find actual issues too or whatever hallucination they come up with reveals some actual issues with the code that you didn't spot by yourself). I've been dabbling with Rust recently and asked Qwen 3.6 35B-A3B to judge my code and it wrote "6.5/10, will compile but looks like C in Rust" :-P.
The article says:
> Never write READMEs, docstrings, or comments. I will write those myself later. And yes, I really mean this.
And sure, LLMs aren't that great about those (i do let them leave whatever comments they want though and remove them later myself - i think those comments help during the generation/prediction - basically how they "think", kinda like the reasoning phase), but they can be very good at things like "here is the code, here is the documentation for it, spot discrepancies" (i had Devstral Small 2 do this and it hallucinated a few discrepancies but also found real stuff i missed in the docs).
I've tried to use Devstral Small 2 for some API docs but found it'd sometimes make assumptions about what function do or how. One approach that might work, but i haven't tried yet, is to write the "guide" myself, then have the LLM write the function docs using both the guide and the code as reference. The reason i think this will work is because it got things 95% correct just having access to the function code alone (and without the rest of the codebase), so the "guide" would help it reach 99%. I do not expect it to get to 100% so a manual edit pass will need to be done anyway (and i have an idea for a tool to assist in the manual edit pass for that - a tool that i'll probably get an LLM to write - BTW good luck coming up if all that stuff would increase or decrease productivity for an actual product and not some random stuff i'm toying with :-P).
One other thing i've also found LLMs useful recently is to have them use the stuff you make and see how they try to use it. I have an old project, a GUI toolkit i've been hacking on every now and then since 2011 or so, though it was never a priority. Yesterday i decided to dump all the header files to Qwen 35B-A3B (i use 4bit quantization that gives me a 256k context - it isn't particularly smart but it is neat to not have to micromanage context size like i have to do with Devstral Small 2 or Qwen 27B where both of them aren't very usable speedwise at anything above 32k context sizes).
Then i asked it to just make a few small programs and it did[0] (the shot shows a paint app, a calendar, a todo list and a unit converter). Pretty much every program found bugs in the library :-P and gave me ideas on how to improve things.
In general i get the impression that LLMs aren't great at architecting things but if you do the architecture yourself and write them a framework to use, they should do a fine job at it.
[0] http://runtimeterror.com/pages/iv/images/d50c436990db203a07f...
Take that, you mere 10x-ers! Your days are toast!
10x or 60x of a negative value is a 10-60x bigger problem than that initial negative value. We all regularly commit things that are actually net negative.
Finally, 10x or 60x more productivity channeled into yet another static site generator, CMS, or programming language doesn't really help in improving products or developing new interesting features.
In short: LLMs offer real productivity gains, but they are still tools, and they are very new, so we misuse them a lot, in various ways (not limited to examples above). Unless they replace programmers and can consistently produce better than average code (even if they fail catastrophically in a few cases), they won't fundamentally change programming. They did change a lot, but not enough to get the result you're describing.
And I've also seen the other side, where vibe coding on projects that had bad code quality to start with leads to bug riddled messes. Projects with beautiful and elaborate test harnesses, that break seconds after contact with a real human user