I don't get the obsession with more code. Whatever happened to good development practices? Many of which, if followed allow LLMs to work more efficiently ironically enough. I would rather hear that you've fixed bugs that have stumped your dev team for years, and have had next to no outages, to me that's more valuable than just slopping features out the door.

I think the HN crowd overestimates the quality of software. There is a (very) long tail of truly abysmal software that people are forced to use all the time. The reason it gets to be abysmal is because it’s often back-office admin software that helps people file forms for, say, logistics paperwork or school district expense tracking. AI-native engineering teams can create dramatic improvements for that long tail because the people running that software are either incompetent or checked out, and a pull towards average quality by AIs would yield great improvement.

none of these types of pieces of content focus on what was created for users, its always about how sky high their "shipping" metrics are (PRs merged, LoC, etc). it makes it extremely hard for me to care, as they all boil down to "im a dev who made some loops on loops on loops that writes a lot of code and spends a lot of tokens."

i will say, at least this article says "we merge 5x more and our revert rate has stayed the same." so thats at least a metric i can start to respect

The “more features != better” is still a valid principle IMO, and AI doesn’t help with that. Probably is making it worse.

Perhaps it shows that it does not matter how good your engineering is, or if you have sped up feature development 10x, if the shop is not providing value then who cares?

You're thinking about this at the wrong level. This org has made the decision to be AI-native. They aren't A/B testing being AI-native vs not being AI-native. That's the kind of thing "the market" does; if a company's markup is higher than another's it can attract more investment or its equity can trade for higher pricing on public markets.

I don't think it makes sense to A/B test "AI-native" vs other regimes of development unless you are a large, decentralized company like an F5 company or a Big Tech. How will a team of 25 (the size of the company if you read the thread) have enough output to even A/B test the difference?

They probably did not even think about asking customers.

since when does an engineering org care about revenue or customer satisfaction? Most software devs have no idea how the business they work for operates and think their direct deposit every two weeks is a fundamental law of nature. Also, many software devs are anti-customer and think customers are wrong even when the customer is talking to them one-on-one describing their needs in plain english.

LOC has no impact on revenue whatsoever. We've known about that for decades.

I've gone through a few recruiter screens lately and the number of people who mention "number of deploys per day" as a metric they are proud of causes my eyes to roll.

What can you possibly be doing as a product that justifies you releasing 60 times in a working day?

It's certainly better than the old models of releasing on a quarterly cadence with the test team and all that, but it feels like the metric has become the goal when you are releasing that often.

That's why I'm sceptical about the value of ai in software development. Much more can now be done but I don't see costumers paying more for it. The only way it can work is by laying off software engineers and saving money on their salaries.

[dead]