Writing code is a small part of everyday's job of a software engineer. The article's table reflects this fairly well.

AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities. If code generation speeds up by 5x while those bottlenecks don't, you've mostly increased the team's work queue rather than its throughput.

With the current capabilities, models still need constant babysitting and course correction. An engineer who lacks the skills to guide them can end up creating more work for the rest of the team. AI makes it easy to generate code faster than you can understand it, and that cost is paid during code review, debugging, and maintenance by colleagues, whose confidence in that engineer's skills may be affected by his use of AI.

What looks like a productivity gain for one engineer can become a productivity loss for the team as a whole.

▲ swiftcoder 4 days ago | parent | next [-]

> you've mostly increased the team's work queue rather than its throughput

Amdahl’s law remains unbeaten

	▲	LilBytes 3 days ago \| parent \| next [-]
		https://en.wikipedia.org/wiki/Amdahl's_law For anyone who hadn't heard this before, like me. <3 In computer architecture, Amdahl's law (or Amdahl's argument[1]) is a formula limiting the speedup of a task as resources are added to the system executing that task. The law can be stated as[disputed – discuss]: `the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used.[2]` It is named after computer scientist Gene Amdahl, and was presented at the American Federation of Information Processing Societies (AFIPS) Spring Joint Computer Conference in 1967. Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors.
	▲	senko 3 days ago \| parent \| prev \| next [-]
		Of course you can beat it (in this context). You can cheat (by shifting the work around). Started to write up a comment, got a bit wordy, turned into a blog post: https://senkorasic.com/articles/ai-amdahls-law
	▲	3 days ago \| parent \| prev [-]
		[deleted]

▲ mingusrude 4 days ago | parent | prev | next [-]

> AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities.

Integration, testing, deployment and production validation activities are also, depending on you setup, available for AI to work on. It depends on the type of stack that you have and how your hosting is set up but with an AI-friendly set up there's a lot of time to be saved here too.

▲

acdha 4 days ago | parent | next [-]

This is largely true to only the extent that you you have a machine-verifiable measure of quality. If not, you’re putting more pressure on the humans who can actually reason and understand business goals. This cascades: tests are what make LLM code generation work but if you have an LLM write the tests you are then pushing further down the road the point where you learn that the first LLM was going in the wrong direction.

▲

zombot 4 days ago | parent | prev [-]

GP: > With the current capabilities, models still need constant babysitting and course correction.

You'd be opening yourself up to even more babysitting. Would that really save time, or improve quality? I'm not convinced, to put it mildly.

	▲	andrekandre 4 days ago \| parent [-]
		well, that is a problem with automation in general i think; if you go too far instead of a simple process a complicated processes get encoded in the automation and if it hits an edge case or breaks for whatever reason the babysitting kills productivity (this is just my experience anyways) also, as far as quality goes, once something is automated that potential breakage puts a cap on how much improvement/quality you can achieve later... i'd guess llms are a bit more malleable there, but idk, i still see this issue even with skills and such...

▲ Yopolo 4 days ago | parent | prev | next [-]

Besides that i still think its wayy to early to put AI in front of center of everything, the current progress at least makes it clear that is not going to stay as it is.

Noneetheless, if the blog article already determines a gain of 15% and you have to factor in the cost of tokens, the company should still reduce the team size by 10-20% or by 1-2 people per 5-10 person team.

Which is still a massive issues for everyone who writes code.

Btw. when i was writing code full time (not being an architect), i for sure wrote like 90% of my time code.

I'm doing an experiment though having a code review agent becoming better and better doing code reviews how i would do it. Which leads also to a skill which fixes issues before the code review agent even has to find them.

We can now automate cases which were unthinkable. We can even keep the code review quality if i leave (Its not perfect yet but its better than what we had before)

▲ joe_fishfish 4 days ago | parent | prev | next [-]

Good summary. Theory of constraints in action.

▲ warent 4 days ago | parent | prev | next [-]

Very well said.

Programming has always felt like converting thought-stuff into something that the computer can understand. That's still the same, it's just a different language, and much faster.

My hot take is: if people are saying AI code is bad, yet they're using cutting-edge models like Opus 5, then those same people are writing bad code even without AI.

I'm finding that AI today can write excellent code, as long as you plan, review, and help it along with a little guidance.

	▲	bibimsz 4 days ago \| parent [-]
		more and more of the thought stuff is being done by AI, let's not kid ourselves.

▲ jorisw 4 days ago | parent | prev | next [-]

Perfect summary of what's going on today

▲ Alessio97 4 days ago | parent | prev [-]

[flagged]