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

Each situation has a different bottleneck, and it's almost never how fast you can write lines of code.

You would need: All engineers aligned on AI use. Invested in automating your: unit tests, integration tests, end to end tests / code quality controls / documentation quality controls / generated api docs / security scans / deployments / feature environments / well designed internal libraries / feature flags / reviews / everything infrastructure / have standards for all of these, so on and so forth. You need to lose your culture of meetings to fix miscommunication. You need to centralize product planning and communication. Stop having 100 different tools at the same time (Jira, Email, Confluence, Slack, Teams, GitHub, BitBucket, GitLab, Sharepoint, ...) where you keep snapshots of what you wanted to do, at some point in time. You need to have a high trust culture. You need to understand mistakes will happen more frequently. You probably don't have production incidents often, because you deploy once a month. You will go fast and the faster you go, even with a low failure rate mistakes happen more often, and you'll need to be prepared for that too. Unfortunately most organizations are missing 99% of the above, organizations like to have layers of communication scattered in all kinds of tools, because hey X tool fixes my problem, they need 2 hour meetings so everyone is aligned on where the button goes and whether the button has to be green or blue, and 10 engineers need to be present in the room too, so 20 engineering hours. Then they go to production once a month.

So if you have solved all that then the bottleneck becomes lines of code per minute, and you could rebuild most products in a few days.

For me personally, it ranges from 10x to 1x. On my own projects, and on projects where the development experience is really really great, easily 10x. We would never have brought that much live in these short timespans without AI assisted software development. In large businesses where 20 people need to stare at a Jira board to decide on the most basic things and give feedback through Confluence comments and emails.... Yeah the bottleneck is not how fast you can write lines of code.

- Writing new code it's probably 3x or so[1].

- Writing automated tests for reproducible bugs, it's probably 2x or so.

- Fixing those bugs I try every so often but it still seems to be a net negative even for Opus 4.5, so call it 0.95x because I mostly just do it myself.

- Figuring out how to reproduce an undesired behavior that was observed in the wild in a controlled environment is still net negative - call it 0.8x because I keep being tempted by this siren song[2]

- Code review it's hard to say, I definitely am able to give _better_ reviews now than I was able to before, but I don't think I spend significantly less time on them. Call it 1.2x.

- Taking some high-level feature request and figuring which parts of the feature request already exist and are likely to work, which parts should be built, which parts we tried to build 5+ years ago and abandoned due to either issues with the implementation or issues with the idea that only became apparent after we observed actual users using it, and which parts are in tension with other parts of the system: net negative. 0.95x, just from trying again every so often.

- Writing new one-off utility tools for myself and my team: 10x-100x. LLMs are amazing. I can say "I want to see a Gantt chart style breakdown of when jobs in a gitlab pipeline start and finish each step of execution, here's the network log, here's a link to the gitlab api docs, write me a bookmarklet I can click on when I'm viewing a pipeline" and go get coffee and come back and have a bookmarklet[3].

Unfortunately for me, a significant fraction of my tasks are of the form "hey so this weird bug showed up in feature X, and the last employee to work on feature X left 6 years ago, can you figure out what's going on and fix it" or "we want to change Y functionality, what's the level of risk and effort".

-----

[1] This number would be higher, but pre-LLMs I invested quite a bit of effort into tooling to make repetitive boilerplate tasks faster, so that e.g. creating the skeleton of a unit or functional test for a module was 5 keystrokes. There's a large speedup in the tasks that are almost boilerplate, but not quite worth it for me to write my own tooling, counterbalanced by a significant slowdown if some but not all tasks had existing tooling that I have muscle memory for but the LLM agent doesn't.

[2] This feels like the sort of thing that the models should be good at. After all, if I fed in the observed behavior, the relevant logs, and the relevant files, even Sonnet 3.7 was capable of identifying the problem most of the time. The issue is that by the time I've figured out what happened at that level of detail, I usually already know what the issue was.

[3] Ok, it actually took a coffee break plus 3 rounds of debugging over about 30 minutes. Still, it's a very useful little tool and one I probably wouldn't have spent the time building in the before times.

- LLMs are absolutely abysmal at PyTorch. They can basic MLP workflows, but that's it more or less. 0% efficiency gained.

- LLMs are great at short autocompletes, especially when the code is predictable. The typing itself is very efficient. Using vim-like shortcuts is now the slower way to write code.

- LLMs are great at writing snippets for tech I am not using that often. Formatting dates, authorizing GDrive, writing advanced regex, etc. I could do it manually, but I would have to check docs, now I can have it done in seconds.

- LLMs are great at writing boilerplate code, e.g. setting up argparse, printing the results in tables, etc. I think I am saving hours per month on these.

- Nowadays I often let LLMs build custom HTML visualization/annotation tools. This is something I would never do before due to time constraints, and the utility is crazy good. It allows my team to better understand the data we are working with.

This, yes. What I do now is use Claude but expressly tell it do not edit my code, just show me, I want to learn. I'm not a very experienced dev so often it'll show me a pattern that I'm unfamiliar with.

I'll use that new knowledge, but then go and type out the code myself. This is slower, in the moment. But I am convinced that the long-term results are better (for me).

They can be useful to one-shot code that you already know exactly what it should be. Because if you already have the mental model of what the code should be, you can read it x10 faster. The other useful thing is: complex multi-dimensional search. You can explain a process and it'll walk you through the code base. Useful if you already have knowledge of the code base and you need to refresh your memory.

In general, now, I'd consider LLMs extremely harmful. They can introduce very high-interest debt to your code base and quickly bring it to collections. The usage must be carefully considered and deliberated.