YHK - yet another hacker news clone

Aren’t we?

We are. This has got to be clickbait.

Because we spend time writing clickbait articles

We are.

We definitely see more broken features that was removed after a short amount of time.

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.

We are. A month of work turned into one day.

We definitely are.

I work for a midsize company within retail and we are definitely shipping faster?

We are definitely shipping faster. Does that turn to better products? Not necessarily.

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.

Who is not shipping faster? We definitely are.

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.

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.

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.

Speak for yourself, mate

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?

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.

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.

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 eat 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're shipping at the same rate but with a team of 10 instead of 24 we used to be

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.

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 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.

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.

We are but it’s weighted towards the independent and never-coded-before side of the ecosystem at the moment.

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.

I don’t know who your “we” is, but the “we” I’m involved with is shipping faster.

We are shipping at a significantly faster rate both internally and externally.

The bad guys are. :-)

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?

You're not shipping faster?! holy moly. I'm orders of magnitude faster with fewer scope-cutting calls.

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.

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.

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.

We're shipping bugs at light speed

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.

> why aren't we shipping faster now?

We are. ~300% as of late-summer when I calculated. Models have gotten markedly better since then.

we are...

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 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.

One dynamic that AI coding has introduced is that features grow and are more "complete" or "complex" after their first development iteration compared to coding pre-AI. An example of this is that I recently built a web crawler for an internal documentation site at my company. My design for scraping, parsing, vectorizing and indexing the data was far more complex/complete than if I had not used AI. This is primarily due to my lack of knowledge in the space and general time constraints for the project.

That increased complexity, while less costly than before, still added time/cost to the project in terms of cognitive load and testing that otherwise wouldn't have been there had the design been "dumber". This notion of increased design complexity could be thought of as a form of Parkinson's Law where the complexity of the design grows to fill the time available.

I think AI is certainly making us write code faster but how much time is really being freed up now that writing code is cheaper? I get the impression that we are often just finding other things to fill that freed up time with, increased design complexity being one of those things.

I must say the handout PDF backgrounds are adorable and clearly convey each of the speedup and slowdown points in the process.

A lengthy construction of "conventional wisdom" and "talking points" for mgmt who need apologia for their spending.

I'm more productive a shaving Yaks.