alt Hacker NewsAI, activity, and outcomes in software engineering
Comments
This is something that Brooks had reflected on already in "The Mythical Man Month":
"One occasionally reads newspaper accounts of how two programmers in a remodeled garage have built an important program that surpasses the best efforts of large teams. And every programmer is prepared to believe such tales, for he knows that he could build any program much faster than the 1000 statements/year reported for industrial teams. Why then have not all industrial programming teams been replaced by dedicated garage duos? One must look at what is being produced."
Brooks argues that the coding that happened in the garage is only a fraction of what you need for the final product:
"It costs nine times as much. But it is the truly useful object, the intended product of most system programming efforts."
What we're seeing right now does not feel much different. You can greatly accelerate a first draft, a greenfield project, an experiment, or at least the initial iteration of one. Changing a live production system or a widely used library is an entirely different proposition.
I am shipping so much more, but I don't know that our customers would necessarily know it. Total rewrites that needed to be done but were getting pushed off due to the scope are now getting done. Security issues are getting patched. Support ticket open to resolution time is dropping. So yes, shipping a lot faster to create a much better project rather than just focusing on features.
More tickets and larger tickets, full migrations that used to take 4 weeks coordinating with 3 teams are now a single PR done in a day.
edit: if you're seeing a slow down in PRs, it's more likely that 10 of your 10x'ers are slinging code in 3-4 plus accounts in codex on the side during their shift on 8 startups.
I feel like I'm going crazy with all the people questioning the impact of AI in software development.
I think people already have forgotten how long and arduous software development was just a few years ago.
The biggest bottleneck now is CI/CD/Experimentation with respect to engineering, and product alignment with respect to the business.
The excitement of LLMs has been around the productivity of the engineers, not the quality of the projects. Traditionally, we have bottlenecks at review and QA stages for new work, and a lot of orgs turn on the firehose of new code without fixing those bottlenecks.
If you want to drive at high speed, you need to build a highway first.
We are. A month of work turned into one day.
Don't simply answer the question from the title -- you won't be addressing the substance of the presentation or really any other substantive issue.
Either watch the presentation if you want to spare the time (a big ask even at 2x speed) or move on.
The presentation is about the results from an actual investigation on why a particular group only saw modest improvements in shipping. It will probably be more relevant to groups more like the group studied (a large dev org) than others.
The general idea is that there is a process pipeline between code change and shipping, and LLMs don't necessarily speed up all the steps at the same rate, especially in large, mature products.
We are definitely shipping faster. Does that turn to better products? Not necessarily.
We can build an app in minutes with Claude Code, Codex, Cursor but deployment of new apps still requires a human to sign-up, browse a dashboard, create API keys, enter a credit card, etc. This means for less technical users, deployment might not even happen.
I would want to see more cloud providers embracing fully-autonomous deployments for new users, I created this benchmark to track progress here: https://github.com/cloudishai/ai-deploy-bench
We definitely see more broken features that was removed after a short amount of time.
In order to ship faster, we need significant improvements in efficiency when it comes to reviewing code.
That may or may not include shipping without reviewing code. Something I think is a real option to consider as LLMs and agents become more capable.
The reality is, any point where a human is involved is now a bottleneck. Even when that human is using an agent to write code. This will apply to the review process as well.
It feels this way, doesn't it? At least until we focus on something besides pure efficiency.
Who is not shipping faster? We definitely are.
I'm shipping much more when I don't care about code quality. I've built a bunch of fun, greenfield side projects. And prototyping at work is also much faster. But when it really comes down to the details, conversations with colleagues, and really delving into what we want to build, designingthe userexperience, getting the details right, still take time.
I think the recent article by Rober Haas on why Postgres release is delayed is giving a very good insight into the general "why".
At least in our case, we are shipping faster. The rate of bugs has gone up, but still proportional to the behavior changes.
I'm shipping faster, but not as fast if the output was the same as before. AI allows for deeper code, all the nice to haves you wouldn't normally do. Test coverage is now fully complete as well, and I mean full tilt mocks and every edge case, not just the happy path plus bugs found in testing.
> why aren't we shipping faster now?
We are. ~300% as of late-summer when I calculated. Models have gotten markedly better since then.
I work for a midsize company within retail and we are definitely shipping faster?
We are shipping at a significantly faster rate both internally and externally.
Predisposition first: I am a cynic about AI (and concerned about skill atrophy) but I am teaching myself how it all works from the open source harness/open weights local model side of things. I'm also recovering from burnout that left me unable to work.
What I see in the real world that is speeding up:
- slop clones of major apps for which I have zero professional respect and with which I just won't ever engage
- quite rapidly improving open source developer tooling. More sandbox and container management stuff here, a new cross-platform non-electron database app there
- obviously, AI tooling apps are maturing much more quickly than apps did before
- iOS/iPadOS: a few improvements and new native, non-web-shelled apps — suddenly Amazon Prime's video app is better than ever before, apps that were clearly HTML wrappers have native apps
- there is a downturn in the quality of other things (macOS and iPadOS themselves are both janky in ways that feel like they should have gone away)
- rapidly worsening web experience — small fonts, low contrast, too much furniture, worsening copy.
What I see in my world:
- fewer blank page problems
- more pathways to do things — a CMS-backed, closing-on-two-decade-old website I thought would need scrapping and rewriting has a pathway to framework modernisation/standardising and then automatic rewriting
- I feel as a freelancer more able to take on jobs my own way, knowing I am less lumbered with any choices I make and should find it easier to hand over anything an LLM can help maintain
- no real improvement in how easy it is to build good content or good designs
- clients who often won't do the thinking/decisions you ask them to do anymore. They are no longer slow to answer, but the answer will be slop.
I am writing code 5-10x faster and I can feel it go, but I'm still waiting 2 days for the IT to install something on my useless locked down laptop, still waiting a week for a trivial corporate firewall change, still waiting 2-3 weeks for business to make up their minds about whatever the hell they want to sell now. So I am shipping faster, but actually not.
We're shipping at the same rate but with a team of 10 instead of 24 we used to be
I don’t know who your “we” is, but the “we” I’m involved with is shipping faster.
Who are we?
Google Search: 1998
Gmail: 2004
Google Map: 2005
Google Docs: 2006
Chrome: 2008
vs
Claude 3 (+ tool calling, web search): 2024
Claude Code: 2025
Claude Design, Sheet, Data: 2026
"We" (whatever it means) are shipping faster now, no?
We're shipping bugs at light speed
AI has accelerated coding but what happens before and after coding has not accelerated much.
Pre coding : Requirements, grooming, solutioning (cross product specially), design, LLD
Post coding: Cross product testing, E2E integration testing, CRQ approvals, Deployment, pilot, roll out.
SWEs don't just do coding. AI has only solved that and testing to an extent.
We definitely are.
We are.
At least at Block our velocity have gone way up. One big unlock was designers building their own features not making it a developers problem.
Our biggest bottleneck is PR reviews but we are also gradually solving that.
You're not shipping faster?! holy moly. I'm orders of magnitude faster with fewer scope-cutting calls.
We are shipping faster. Shipping speed depends on a variety of factors. That said, the ability to generate and validate designs, code, tests, data, performance and security evals, etc is increasing the speed of delivery for many organizations - I'm a consultant and I see it every day.
I also see companies that don't know what they want to build, suffer from toxic culture etc -- they are not faster because their core problems never had much to do with software development.
Sure, there are plenty of developers clinging to the "old way" or using AI in ways that add complexity and slow things down but I don't see this as the dominant group.
The bad guys are. :-)
Speak for yourself, mate
The question should be: why isn't software improving?
Claude Code TUI, probably the poster child for AI-driven coding, itself is still going to sh*t.
Most if the issue I’ve faced working on production software in team environment is to be able to defend you PR and story the changes and understand it to a level to be able to defend it. For PoCs and demos it can accelerate a lot but not for many other use cases.
I'm a one-man operation with an equities markets analysis product. I'm definitely shipping faster. Fixing bugs and adding features literally 100x faster as well as implementing some very complex math that I likely could not have done on my own previously.
I don’t want to watch a 21 minute video right now.
But does it say what quantifiable evidence they have to show software teams are NOT shipping faster now?
Because we spend time writing clickbait articles
We are but it’s weighted towards the independent and never-coded-before side of the ecosystem at the moment.
we are...
We are.
The trillions-dollars question is how come software itself doesn't get improved by (at least) an order of magnitude, if not more.
More to the point, the price of RAM that has gone berserk. Easy solution, let's then make our OSes, browsers and almost all the relevant software that we use day to day an order a magnitude more nimble, for example if a Chrome instance now eats 1-2GB of memory then make it it at most 100-200MBs of said memory while doing the exact same things (if not more). The much lauded AI revolution in code-writing hasn't created that, not sure if it will ever do, it will just add slop after slop after slop, in fact it wouldn't surprise me if the memory requirements for something like Chrome won't increase as a result of the recent vibe-coding mania.
But by this point the AI zealots are already running the asylum, so nothing to be done.
We are. This has got to be clickbait.
Unfortunately, this is one of those HN submissions where people are just knee-jerking to the title without even checking what the submission is. Of course, it doesn't help that it's a long video conference presentation with a "handout" that's beautiful but a little hard to read through on its own.
However, for those that are actually curious, the submission is not itself a cynical or dismissive take. The question in the title is interrogative and contextual, not rhetorical and universal, and the presentation tries to break down some of the bottlenecks and challenges that are leading to AI integration having a different impact on software engineering output than some people might expect.
Rather than suggesting those bottlenecks/challenges are universal or intractable, it just enumerates some of them and presents some survey analyses on how widely encountered they are.
It's actually pretty interesting and the kind of thing that engineers and those who work with them want to be reflecting on, so that they can better engineer their usage and processes around AI itself.