While I agree with your sentiment, very strongly actually, there has always been a tension between what I'll call "engineering teams" and "product teams". The engineering teams want the long-term platform stability, performance, etc. The product teams want to push that new feature out, quick! The overall business needs both (types of thinking and doing) to survive, of course, but not all leadership sees the world through the lens engineering team lens. I'd argue most actually lean the other way, which is understandable though unfortunate. I'd also posit that since these product teams are often "closer to the business", those people typically win favor with the real decision makers.

These new tools only exacerbate this issue.

I've spent most of the past two weeks trying to get my AI to stop writing so goddamned much code. It's great that I can, say, completely switch between two databases, but I wish the AIs would develop a concept of energy spend or something and spend maybe a moment checking whether something is already implemented in the code base before blasting out 2000 new lines defining a new database access layer, and also rewriting random code it shouldn't be touching for some task hundreds of lines at a time just because it can. I don't care how easy it is to write some tests that sort of kind of cover it hopefully maybe... no new code is as tested as the stuff that has been doing it in the field for years already.

Just because it has the power doesn't mean it should be used.

I'm not asking for everything to be some sort of beautiful code whose concision would lead Knuth to tears. I'm just asking that you not slather dozens of existing functions with three new parameters and dozens of lines of code each that basically do nothing, to cover a use case that I accidentally vaguely alluded to, if you read my prompt a certain way, but isn't really what I was interested in.

One thing I've spotted several times throughout this year: the larger volume of code leads to exactly the sort of problems it always has. It just happens real fast now, with fewer people. Problems that used to take years to erupt now manifest before an MVP ships, but people just sweep it all under the rug in the name of moving fast.

Idk imo code is and has always been a liability. Like the toilet paper bear says "less is more"

We used to understand that code was harder to read than it is to write. It follows, directly, that better engineering discipline means shipping LESS code. Less to support, less to understand, means a product that is easier to maintain and extend.

Now, token calculators spew out code at a pace no human can match, which completely removes the barrier of effort - which was one of the largest natural counters to shipping massive amounts of slop.

I'll be impressed by a coding model when it writes less code than a human, and spends more time refactoring than it does just adding new layers. Until then, this vibecoding is just madness.

agree 100%

it really isn't a flex ppl think it is when they're burning tokens churning agents that are working for "hours" doing work

we don't need to read or write code anymore, but we do need to write (as humans) the instructions for agents.

having ADRs, product specs, acceptance criteria, etc. that are properly maintained leads to agents working for just a few minutes and pumping out reliable code.

the more vague the work for agents, the more randomness and inefficiency there will be. that leads to bugs, constantly re-writing code, etc.

imo ofc, i'm not yet running a billion dollar company so maybe i'm wrong.

One of the most uncomfortable truths about our profession is that there is literally no floor to how shitty software can be and yet still make people billions of dollars.

> There is a (very) long tail of truly abysmal software that people are forced to use all the time.

We generally call it “enterprise software,” and it’s usually abysmal because the people buying/funding it are VP-level executives who care about compliance/reporting/visibility and who never have to actually use the software.

This actually comes up on HN pretty regularly. Or used to; like many topics it’s taken a back seat to AI.

Any good product leader will tell you, sometimes not building something is actually good for the customer. Slower dev cycles have you the ability to take time with decisions and make adjustments. The obsession with shipping more code is making things worse for users and I would argue, damages the company in the long run.

Eveyone has a backlog. What happens when you clear it in a month? Do you suddenly have better ideas about what you want to build? Do you suddenly have better intuitive designs? Do you have more users or the same users using the product twice as much? In most cases, the answer is no.

AI gives you the speed to execute when you need to, but knowing what to build and how will still remain a bottleneck.

Now the real question is "is the revert rate the same because you still have the same process, or do you fix-forward more often now, so your revert-rate is because of higher-severity incidents?"

Ehhhh:

1) You can merge a "new change" to fix a merge, instead of reverting

2) It's unclear whether the substance of their individual PRs are the same. Never thought I'd want an LOC metric.

3) Really, I'm going to double down on the idea that merges could be fixing merges. Also happens to increase the merge metric.

I mean we (huge tech company with ~2000 devs) literally never actually revert anything, in my 2 years here I have quite literally never reverted a commit. We have a staging/release cycle that means nothing ever needs a revert, you just fix issues in followup commits on trunk

This is another one of the infinite meaningless metrics that AI cash burners love to use without context

Is your company making 5x more? Are your customers 5x happier? Are you getting paid 5x more?

What’s the point of doing 5x more?

It was the article that used metrics related to engineering velocity as evidence of success. It makes sense to ask how this is impacting their business metrics. The company is not in the business of shipping more code. I don’t see how asking how this ties back to core business results is thinking about it at the wrong level.

Funny you should say this… there another post on HN about engineers using AI are going to make PMs redundant!