Ask HN: By what percentage has AI changed your output as a software engineer?

I've been building specific tools in languages and frameworks I don't understand, nor have ever found time to learn. So the producitvity boost is hard to measure; its a "what's 0 times how fast the LLM can do it" type of answer.

I have yet to see a study design that sufficiently controls for all of the variables. In general it seems that if you could do the work on your own, it may not save time, and in the long run, most all output needs to be reviewed, perhaps moreso than if you were composing it yourself... And the additional variables include things like finding out of the box solutions either with or without the model outputs, which is hard to control for as well. Even more impossible to control variables are model quality, training material related to the topic, and many more of those classes of issues that may not be publically available or even possible to trace fully. Truly, anecdotes are not informative of the general experience. It is literally the cliche that is mentioned on this site periodically "these are the lotto numbers that worked for me."

300%

For me it feels like roughly a 10–20x change, but mostly because I restructured how I work rather than just adding an “AI helper” on top.

In the last year I’ve shipped a couple of small OSS tools that I almost certainly would not have finished without AI‑assisted “vibe coding”. Everything I build now flows through AI, but in a slightly different way than just chatting with an LLM. I rarely use standalone ChatGPT/Gemini/Claude; almost all of it happens inside GitHub with Copilot and agents wired into my repos.

The big shift was treating GitHub as the interface for almost all of my work, not just code. I have repos for things like hiring, application review, financial reviews, and other operational workflows. There are “master” repos with folders and sub‑folders, and each folder has specific context plus instructions that the AI agent should follow when operating in that scope, essentially global rules and sub‑rules for each area of work.

Because of that structure, AI speeds up more than just the typing of code. Idea → spec → implementation → iteration all compress into much tighter loops. Tasks that would have taken me weeks end‑to‑end are now usually a couple of days, sometimes hours. Subjectively that’s where the 10–20x feeling comes from, even though it’s hard to measure precisely.

On the team side we’ve largely replaced traditional stand‑ups with AI‑mediated updates. KPIs and goals live in these repos, and progress/achievements are logged and summarized via AI, which makes updates more quantitative and easier to search back through. It’s starting to feel less like “AI helps me with code” and more like “AI is the main operating system for how our team works.”

Happy to share more about the repo/folder structure or what has/hasn’t worked if anyone’s curious.

Hard to self-estimate. The big change for me has been that I would now do more things than before. But maybe 2-5x.

I’m not sure you’re going to get any useful results from this question.

Some people find it useful, some people don’t, and unless what you’re using it for matches what they’re using it for (which you’re not asking) none of the results you get give you any insight into what you should expect for your use case.

Oh well, whatever. Here’s my $0.02; on a large code base that takes up to 30 minutes to do a local type check in typescript, the net benefit of AI is neutral or negative, because the agent can’t loop effectively and check it’s own results.

AI scaffolded results are largely irrelevant and don’t use internal design system components or tokens for UI and are generally useless.

Objectively measured ticket completion rates are not meaningfully impacted by the use of AI.

Out of date documentation leads agents to build incorrect solutions using outdated and depreciated techniques and services.

This is true across multiple tools and multiple models used, including sota.

1x

It is not more productive.

This reflects on my personal experience in the last 8 months of intense (and company mandated) AI usage at work.

At home, for small personal projects, I would say it’s closer to the 2x you describe, maybe as much as 3x for building and iterating on rich web UI using react.

In the cases where I'm already an expert and I'm working in a legacy system and/or on a hard problem, it's small change. Where I have no knowledge, it's an incalculable change because it's enabling me to (quickly) do things I could not before.

For example, I do not know rust but I've been using AI to make https://git.sr.ht/~kerrick/ratatui_ruby at a really rapid pace.

25%

It made me 2x slower, because with Claude's hallucinations I waste more time chasing dead ends than I gain from it in productivity.

0% productivity improvement.

Rephrasing the question: By what percentage has AI changed your input quality?

Answer would be around -50%. This is attributed mostly to the vast amount of search results that are AI generated and provide very low density information and miss conveying actual key learning points. This means you have to scan through 100% more text to finally get the information you need to solve the issue. I think this is a low estimate actually.

I'm learning Python on the job, with decades of experience in other languages. Asking an LLM noob Python questions is probably 5-10x faster than googling around and reading docs or tutorials, and almost 100% accurate. I also ask it about git commands I seldom use (I tend to confuse reset and restore, though not revert for some reason).

Introductory questions about a widely used language with great documentation and tons of tutorials are made for LLMs.

How would we describe the productivity gains brought on by engaging with tasks we did not have the ability or confidence to prior? The denominator looks like a zero in many places for me.

10x when working on a code base I'm very familiar with.

Basically, it amounts to being able to give detailed instructions to a junior dev (who can type incredibly fast) and having them carry out your instructions.

If you don't know the code base, and thus can't provide detailed instructions, this junior dev can (using their incredible typing speed) quickly run off the rails. In this case, as you don't know the code base, you wouldn't know it's off the rails. So you're S.O.L.

It really helps where the code I'm writing fits the broad description of boilerplate.

Need to integrate Stripe with the Clerk API in my Astro project? Claude's all over that. 300% faster. I think of it like, if there was a package that did exactly what I wanted, I'd use that package. There just happens not to be; but Claude excels at package-like code.

But as soon as I need to write any unique code – the code that makes my app my app – I find it's perhaps a touch faster in the moment, but the long-term result isn't faster.

Because now I don't understand my code, right? How could I. I didn't write it. So as soon as something goes wrong, or I want to add a feature, either I exacerbate this problem by getting Claude to do it, or I have to finally put in the work that I should have put in the first time.

Or I have to spend about the same amount of time creating a CLAUDE.md that I would have if I'd just figured out the code myself. Except now the thing I learned is how to tell a machine how to do something that I actually enjoy doing myself. So I never learn; on the contrary, I feel dumber. Which seems a bit weird.

And if I choose the lazy option here and keep deferring my knowledge to Claude, now I'm charging customers for a thing that I 'vibe coded'. And frankly if you're doing that I don't know how you sleep at night.

I'd say on average about 50% faster but it really depends on the task at hand. On problems that can be isolated pretty well like a new feature that is relatively isolated (for example building a file export in a specific format) it's easily a 10x speed up. One thing that generally gets less talked about is exploration of the solution space during manual implementation. I work in a very small company and we build a custom ERP solution. Our development process is very stripped down (a good thing IMO). Often times when we get new requirements we brain storm and make a rough design. Then I try implement it and during that phase new questions and edge cases arise, and at any time this happens we adjust the design. In my opinion this is very productive as the details of the design are worked out when I already know the related code very well as I already got down to implementing. This leads to a better fitting design and implementation. Unfortunately this exploration workflow is incompatible with llms if you use them to do the implementation for you. Which means that you have put more effort in the design up front. From my experience that means the gain in speed in such task is nullified and also results in code that fits worse into the rest of the codebase.

Very hard to estimate, depending on the domain, I'd say 1.5-2x as much.

When it comes to programming in languages and frameworks I'm familiar with, there is virtually no increase in terms of speed (I may use it for double checks), however, it may still help me discover concepts I didn't know.

When it comes to areas I'm not familiar with:

- most of the time, the increase is substantial, for example when I need a targeted knowledge (e.g. finding few APIs in giant libraries), or when I need to understand an existing solution - in some cases, I waste a lot of time, when the LLM hallucinates a solution that doesn't make sense - in some other cases, I do jobs that otherwise I wouldn't have done at all

I stress two aspects:

1. it's crucial IMO to treat LLMs as a learning tool before a productivity one, that is, to still learn from its output, rather than just call it a day once "it works"

2. days of later fixing can save hours of upfront checking. or the reverse, whatever one prefers :)

-100%. With this looming Shiny Toy plus other sub-optimizations at my last place of work, I decided to retire. Didn't want to deal with it.

~10x with Claude code.

Any positive change to my output is likely only because I now need to use it to supplement Google searching, because Google search is so damn awful nowdays.

I don’t know, it still feels like a productivity lottery to me. The simpler the task, the higher the odds of a big productivity gain, and it can be probably an order of magnitude quicker, especially if the output is very verbose, like frontend tends to be.

But I still haven’t dialed exactly what is too complicated for the LLM to handle (and that goalpost seems to still be moving, but slower now). Because it is almost always very close, I often end up trying to fix the prompt a few times before giving up and just doing it from scratch myself. I think in total the productivity gain for me is probably a lot less than 100%, but more than 0%.

There has been very little change for me. The one area where AI has been of use is for providing debugging suggestions in those circumstances when I am so short of ideas that I am contemplating posting a question on Stack Overflow. Only once has Chat GPT actually found a bug directly, but on a handful of occasions it has made suggestions which have yielded results when investigated further in traditional way (e.g. reading documentation). Still, At least the AI actually does something rather than ignore me or scold me for the way I have posed my question.

Infinitely, because I wouldn't be bothered to make the things I make without AI.

I simply have more fun doing my job.

At work, many of my colleagues are too busy to collaborate and brainstorm with me, who enjoys it a lot and have a lot of energy for it.

They are classic 9to5 and that's fine, but I like software development and talking about it.

So instead of only doing it by myself, or tiring out my colleagues, I collaborate with AI.

6-7%

It’s immeasurable. I use AI for powering through personal projects, which would not have gotten done without AI because I also have a job and a life. It allows me to focus on the product and requirements rather than the code. It’s hard to measure because the projects would simply not have gotten done without it.