This weird trend reached an apex in a Feb 2026 OpenAI blog post [1], recently on the front page [2], which describes the process for building... something... written 100% by agents.
There is no description of what the thing is, no indication of what value it provides its users. The closest it gets is "the product has been used by hundreds of users internally, including daily internal power users".
But the fact that the thing has a million lines of code is repeated twice in the first few hundred words.
> "the product has been used by hundreds of users internally, including daily internal power users".
My guess is it’s an email filter.
> million lines of code
> written 100% by agents
Yeah, probably an email filter. Or maybe a JS menu for a departmental wiki that basically recreates jquery using MS JScript and transpiles it into JS 5.
The email filter team is trying to match the pace of innovation of the email generation team. At stakes is the ability for the employees to process the billions of mission-critical generated emails each of them receives each day.
The best strategy is to figure out what you are going to do after smoking weed before you smoke weed. So, draft your prompt and send it before lighting up.
The entire Linux kernel is about 40 million LoC, and only something like 16 million LoC after you remove drivers. I have a hard time imagining whatever OpenAI was talking about there having anywhere close to 6% as much utility as the Linux kernel, despite having 6% as many lines of code. And I have a hard time imagining it's anywhere close to maintainable, regardless of how powerful their LLMs might be.
To be fair, few things of any number of LOC have as much utility as the Linux kernel, and it's also a particularly dense example of code. There's plenty of other examples that have higher LOC / utility ratio without being vibe coded. For example, Google's monorepo famously has 2 billion LOC, which is a statistic I've heard long before LLM coding took over.
Clarification: Google claimed to have 2 billion lines of code in their repo ten years ago, and a commit rate of 50,000 changelists per day, both on exponential growth trends.
That's certainly a way to look at it. And that repo contains a "third party" directory which itself contains Linux, LLVM, and much of the rest of the open source world. But I would suggest that the largest of those thousands of applications probably has a transitive closure of hundreds of millions of lines of code.
I'm aware. I worked on that specific project (assuming we are talking about the same one) back in the day. :-)
There are certainly very large applications in that repo in the hundreds of millions of lines of code. But comparing the entire repo to single applications is not an apt comparison.
The Linux kernel is not in any way at top of big projects. A kernel, as the name suggests, deals with specific issues and tries to remain small.
The world’s biggest software is usually built over endless adapters of different data and a need to reconcile endless edge cases with laws, regulations and real world complexities.
When I was young, I remember a (joke) program from a book or magazine, called something like report writer or something. It was written in basic and you typed it in.
You would run it and it would say:
how many pages? _
You would type in a number, and it would generate that many pages of a complex-sounding report.
something like "the subsystem design interface is ..." blah blah
The reality distortion field is strong around anthropic. Anthropic posts tons of equally bullshit blog posts, written entirely by AI, saying absolutely nothing, to the front page and they consistently average many hundreds of upvotes.
I have to wonder if HN is astroturfed. Anthropic and OpenAI can post about a new model and it gets over to HN instantly and is full of glowing reviews of supposedly real people who supposedly have had prior access to it who supposedly think it's the best model yet.
Feels doubly so for Anthropic. There's just unbelievable level of glaze, and insane upvote velocity for "blog posts" that are essentially fluffed up feature documentation.
Somehow everything boris says has become the word of God. The dude is just an engineer, like you and me, who gets unlimited tokens for free.
Yeah, I sometimes catch these posts minutes after they were submitted and they're full of highly upvoted glowing reviews that maintain their momentum on the top of the page.
And this is hacker news. A place where famously the most upvoted comment is the one critical of the post.
Upvoter here. Nothing special -- I like Claude a lot. I found it more ergonomic to work with, and I think its models are state of the art. I believe I'm more productive especially in legacy crufty codebases.
I may not be representative of the universe or have a controlled, randomized study to back it up, but that's not what upvotes are for are they?
That's a fair point. To play devils advocate to myself, it's possible that the huge upvote share is due to a much bigger marketshare among our community.
Yeah, that was my guess too. Still a little disappointing to see fellow HNers reflexively fanboying a company that's the overwhelming dominate player in LLM coding.
I try to reserve my reflexive fanboy company/project votes for underdogs who need and deserve the help.
HN is probably astroturfed, but it is also one of those places where a lot of actual subject experts frequent. I don't find it unusual that a new model gets instantly posted here. It is also not unexpected that the most recently released model is the best model.
Heavily. There’s an amount of true believers who actually think RSI is going to happen any day now, but you can spot patterns amongst brand new booster accounts…
I real life I meet people who like AI and people who hate it, but nobody who’s on a personal mission to defend Anthropic from anyone that dares to question their hyperbolic marketing.
The tech field has always been full of naive technology boosters. HN might be heavily astroturfed for all I know but I am sure there are many real people in a state of constant excitement over the progress of AI.
Yeah it was very disappointing that so few details were provided. One of the reasons I think it's going to be an open source project or effort that is going to show, sooner or later, how effective these things actually are.
In their podcast interview, they mention that it's an Electron app that users download, and so they periodically create a new build. See section "Autonomous Merging Flow" here: https://www.latent.space/p/harness-eng
I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to, except apparently it was not satire at all, and indeed seemed to reflect the position of many CEOs etc when it comes to LLM code generation.
I do think that over the past few months, it feels like the hype around producing unmaintainable amounts of LoC has started dying down. More pragmatic and realistic takes are seemingly shared more openly, and are maybe even getting through to top leadership at some tech companies. Maybe not all is lost yet.
I once worked in a company where there was an 80% code coverage requirement. Some enterprising contractor had a script that generated a single file with its own covering test suite the size of which could be tuned to achieve 80% over the whole codebase. Mostly the code was untested.
And thanks to AI, we could generate extremely convincing reams of code whose only purpose is to be fake unit tested. Amazing. I sincerely hope I never need to use this nuclear weapon.
Or better yet: effectively fake unit tests. It is almost never the case that tests written by AI detect actual issues. At most they detect that has changed.
Yeah I’ve been thinking that LLM unit tests are basically snapshot tests. Just sorta ossify things in place. If they break, you just ¯\_(ツ)_/¯ and have the LLM fix them. It’s like they were never there!
So it’s just like the olden days of everybody ignoring tests, but we give anthropic a ton of cash
It has been incredibly hilarious to watch the C-suites sudden realization that tokens COST MONEY and immediately revise their guidelines for how employees should use AI.
Like maybe having every engineer generate 1 million lines of code per month every month…with no thought to how those lines of code would make the company money…or how many tokens would be burned to accomplish this at what cost…wasn’t fully thought through.
The word “slop” was a good choice to talk about the mass of code generated by AI. I think it resonates with non-tech people and it conveys disgust. It’s clear that we should avoid slop.
“Technical debt” never hooked management in the same way and we have found it hard to convince them that it needs to be addressed. Debt in general is something that can be a problem, but doesn’t need to be avoided or addressed until it is a problem so the can is kicked down the road.
To be fair, they are also different things, though there is certainly overlap...
To me, tech debt, captures the idea that we cut corners now to move faster, with the understanding that it will need to be "re-paid" and cleaned up later, otherwise we take on too much tech debt, and everyone knows too much debt is bad...
AI slop code means people feed their tasks to a model, trust it to drive the changes, they might do some cosmetic clean ups, then generate a 3 pager PR description they didn't even read themselves, then toss it over to the code reviewer, let that chump figure out what the hell I was doing while I ship 3-4 more PRs...
Technical debt is a indefinable quantity which makes it very prone to be abused to mean "I wish I could rewrite this in [insert some fashionable language, framework or coding style]".
AI slop is an easier concept to quantify. It's basically the code for which insufficient people in the organisation have a meaningful understanding of how it works or what it does.
> I do think that over the past few months, it feels like the hype around producing unmaintainable amounts of LoC has started dying down.
I wonder if a small part of this is more and more business and product people actually trying to incorporate AI into their daily workflows. I have seen this in both small companies I work for. People were very excited about getting Claude Cowork a couple of months ago, and while they use it daily, I would say they are rather underwhelmed compared to the magic they were expecting.
Complaints include the output being mediocre and verbose, it getting the most basic things wrong, hitting token limits all the time, and people going back to doing things themselves because it is faster.
Sure, there is some degree of holding it wrong in the beginning, but people are realizing that maybe, just maybe, there is still somewhat of a gap between what AI CEOs, LinkedIn grifters, and YouTube AI supplement peddlers claim and reality.
I suspect this is it. I'm 40, and the only tech person in my social circle. Many of my friends were all excited about using it for things like basic webdev and home networking. One shotting that type of stuff is very viable even if you don't know anything about the topic. Now that they are trying to use it for something they actually know about, suddenly it's unusable. It's a modification of Gell-Mann Amnesia.
> which basically read as satire to most engineers I talked to
Seemingly engineers get this wrong too. I'm reminded of when Cursor bragged about how many lines of code a group of agents could produce, with the underwhelming results of a barely working browser, when the same could be built with much less code.
But they highlighted the amount of code as they were proud over how much slop their constellation of agents had shit out, and these were supposedly engineers, really strange to see.
“Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.
And anyway, I’m pretty sure what people really mean by this “less is better” mantra is: the lowest amount of code that still accomplishes the goal and is still readable is preferred. Linux apparently has 40M lines of code, and I bet most of it is better than mine. Some things just take lots of code.
Which seems to leave room for these agent salesmen to pitch SLoC as a plus. We just have to believe those lines are all good ones. I that case, it would be impressive. I don’t believe it, but they are probably pitching to people who do.
> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right?
No, it's the perspective of a programmer who wants the project to not be bogged down too much in technical debt so every change gets slower and slower to implement, as everything gets more intermingled. A clean design helps you move faster for a long time, compared to a design that is fast to implement but makes it hard to move forward properly in the future, without resorting to shortcuts and/or hacks.
> Some things just take lots of code.
True. Rich Hickey does a good job differentiating between what's complicated because the domain is complicated, VS what's complicated because the implementation just ended up that way, even though with some more thought and design, could have been made a lot simpler.
> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.
I think it is (or should be) a goal & business-oriented concern as well, not just an engineer's who enjoys their craft.
More complex systems are worse than simpler systems (that accomplish the same), in cost, maintenance, fragility, ease of understanding, etc. Fewer moving parts usually result in higher reliability, fewer things that can break down or fail to interact properly, etc. That's a business concern too, not just engineering craftmanship or whatever. Business people should care about this too.
I don't think this is the same as bikeshedding over irrelevant details, something we software engineers are often prone to. Monstrous complexity does impact the business!
It's like we've all forgotten what technical debt means. We just say the phrase, but we have forgotten that it is analogous to actual debt. Every line of code produced should be treated as a liability to the company, like a bond they issued that they have to pay interest on in the future. You only take on the liability if it produces more business value than it costs to maintain. The goal is not to issue as many bonds as you possibly can.
It's a signal. It's not a strong signal, and you certainly should not base your entire perf on it, but if the number is unusually high or low, it's a signal that could warrant further investigation.
(I once worked with an engineer that had two PRs, both fairly small bug fixes, in a given calendar year, and when I looked more carefully, they did not have any other obvious output or impact.)
Strongly agreed. It is a signal. I did an analysis once at the end of the year. Work group of about 45 engineers. The CM system had a lot of steps, and work could get bounced around, but there was a step where some one "resolved" a software activity. Bug fix or new requirements, it did not matter. This step was when someone actually completed work and put into into the dev stream.
A quick DB query and the variance was substantial. A couple of people had over a hundred. About 10 had 2. For the year. The ramp up was slow, average was 8 to 10 a year.
Dig a little deeper. Those at the top were 'group leads' not only did they do IC work, they also got stuck with all 'paperwork' on the problem work packages. They had 'power', so they could override various things. So, they were doing a lot of work, and taking care of things. Good signal, matches what one would expect.
Those at the bottom. One of them had effectively been a 'systems engineer'; all of their time was working on requirements with the customer, making powerpoint, etc. Important work, so that signal was inverse of what it originally showed.
A couple were in the middle that had great reputations for technical expertise. They were spending almost full time in training / mentoring / very hard problems mode. Highly valuable, but not shown by looking at these numbers.
All the rest? 80% of the work was being done by 20% of the people. We could have dropped about 12 heads and barely noticed.
The problem is, you could not take action on this measure. It gave you a place to start, but you needed to know more about what was going on day to day.
Let's measure "executive performance" by counting how many "answered phone calls" per hour they have. If they don't answer enough calls, that's a signal, that they aren't doing anything useful, and should be depreciated as a result.
Trying to parse your sentence, which is ambiguous...
You're saying that the manager-of-managers would argue that the number of PRs should affect perf ratings? Or the MoM would push back against the line managers who were giving ratings based on # of PRs?
I also think starting to migrate to Azure just as their traffic/usage exploded from LLM use (plus I assume merging a bunch of poorly written early-gen LLM code as early adopter dog fooding) was poor planning by Github/Microsoft.
> I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to
Did those engineers not actually read the complete tweet? Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work". Which doesn't seem like satire at all..? It just means "develop mostly reliable AI-driven refactoring tools with good guard rails". Which seems quite sensible, actually?
> Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work".
Making a grand claim of a goal and not really having an explanation on how to achieve it isn't really much better. I could say "we want to scale food production so that one farmer could manage a million acres of corn a month", but that wouldn't really be sensible. A line of code is less work than an acre of corn of course, but I don't think it's at all apparent what upper bound for how much code is actually plausible for a single engineer to generate in a month and have any degree of confidence in. Given the absurd levels of hype around AI from non-engineering management in the past couple of years, it's not clear why the benefit of the doubt is earned here when there legitimate are managers and executives claiming pretty much exactly what you're claiming this guy wasn't.
I don't care - porting the current architecture - with all the known I wish I had done this differently's - doesn't gain much. See some developers I've worked with who love Rust for "safety", even though they just put everything in unsafe at the first sign of trouble instead of thinking about how this should work safely.
Porting to a new language is easy, but does nothing useful. What we need is to fix the mistakes of the past so we can get to the future. We need to make acceptable performance.
> Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work"
These are one and the same. Whether it's ported code or not doesn't change that. The framing device also doesn't matter, because it's the exact "Oh it's our goal" shtick that executives use in the former's case.
"It's just a measure" doesn't cut it in a world where every single AI measure immediately gets turned into a target by executives greedy for efficiencies that don't exist.
EDIT:
Right, I forgot. This is HN where everyone is a galaxybrain and "Port a million lines of code per month" is a totally reasonable goal for a single individual.
I can easily game writing 1M LOC per month by having the LLM write code in more verbose ways, with useless indirections and abstractions thrown in for good measure. I could even ask claude to write code that does nothing but just takes up line.
In contrast, converting 1M LOC of code per month is a much more solid measure, as long as you measure LOC of the source, not the new code. Sure, in the short term you can pick the easy/verbose things to port, but it's hard to do sustainably. A 5M LOC code base would still be expected to be ported in 5 engineer months.
Granted, you can still rush the work, not test properly, neglect good planning and engineering. Ported lines of code should not be the only measure (just like with any other measure). But it's a much less problematic measure than coding 1M LOC
If everything in the initial code is 300% covered with excellently documented tests that should be minimally changed during transition (if transition don’t reveal any corner case tests were missing, maybe the transition is not such a bright move after all), that seems a possible thing to consider.
Otherwise it really sounds like a recipe for unnecessary huge risk with dubious expected positive outcome.
Not saying don’t have fun, but on the other side maybe not with the core product of you cash cow already?
> "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work". Which doesn't seem like satire at all..?
Because many programmers don't believe that'd work. See the reaction to Bun's porting to rust. (I bet Bun will work and prove those programmers wrong, but that's another story.)
It is unmaintainable even if you spend 100k per month on tokens to have LLMs pretend they are maintaining it, if they slow down and make little ACTUAL progress. Sadly real progress is impossible to measure, if all you have is an overexcited """engineer""", a credit card, and so much cash spent you could hire all the best engineers you know and still have money for a porsche.
Well, software presumably has a goal of accomplishing something for some end-user, so the progress should be trivial to measure: are features/changes being completed?
The marketing ploys of OpenAI/Anthropic where agents build something that nobody uses might be hard to track given that there are zero users. But what about everyone using agents for real software? It's trivial to prove that agents make progress.
Yes that is the entire point. Measure features deployed in production and their value in gaining and retaining customers or users, cost reductions, reduced incidents and outages, etc.
Lines of code is completely irrelevant as a metric.
All else being equal, and assuming you are building the right thing, being able to deliver more correct lines of code is a good thing. The question is how to do it reliably, given that a human cannot possibly read all of it. The answer seems to me to involve spot checks with proofs of correctness and statistical quality control, the latter being things that can be automated. One issue I see is that the models are constantly changing and are therefore not well understood statistically.
If you are generating that many lines of code it’s also almost impossible to tell if you’re building the right thing. You need to deploy each functional change and measure if it’s giving you the expected outcome, before moving onto the next thing.
>All else being equal, and assuming you are building the right thing, being able to deliver more correct lines of code is a good thing.
Why? If you can deliver the same thing in fewer correct lines of code wouldn't that be preferable? At a bare minimum if you're still insisting on using AI to slop out your project, having it do things in fewer lines of code means you can fit more into your LLM's context window.
> If you can deliver the same thing in fewer correct lines of code
it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.
Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?
Without looking at the details, I expect that each network protocol has a checksum of some form, and there are likely a lot less than N different checksum algorithms. Similarly I expect several will have encryption - using one of a few standard algorithms (if any doesn't use a standard algorithm you have a strong case to say not supported). I also expect that there is a lot of protocol parsing - this can be done as custom hand coded for each, or using a parsing framework (and likely there are some places of generic code in between).
This is still not an argument for more lines of code. It demonstrates that lines of code are positively correlated with number of features, yes. But that's like saying the number of nails scales with the size of a house. More nails does not create more house.
> When a company says “AI made everyone more productive, so we need fewer people”, I want to see the evidence - and I don’t believe it exists today.
Because they're bullshitting and using AI as an excuse to correct from their covid era over-hiring while simultaneously making themselves look good to investors by showing they're embracing the hip new technologies to become a more streamlined and cost-efficient operation than ever.
> while simultaneously making themselves look good to investors by showing they're embracing the hip new technologies to become a more streamlined and cost-efficient operation than ever.
This is not anything new... It just has a new name...
That's a generous excuse. To me it looks like they're just trying to depress wages across the board. Given that _several_ rounds of layoffs have occured since then, this 6 year old excuse rings particularly hollow.
> investors by showing they're embracing the hip new technologies
I thought investors cared about returns.
> to become a more streamlined and cost-efficient operation than ever.
And a completely uncompetetive one as well. "We're using the same whizz bang technology that any idiot in their bedroom can use!"
It is endlessly... amusing (?) to me, that we as a community spent decades trying to make it clear that our productivity is not easily measured because what we're doing is complicated and long running, only for AI to come along and suddenly LoC, Nx multipliers, tickets / week etc are held up as useful if not objective measurements.
The reasons we rejected LoC and other measurements have not changed (broadly: code output isn't important, quality output is). AI has all the same problems people do. But for whatever reason we are throwing what we've learnt away. It's kind of embarrassing.
The non-technical people are in charge and they're not tethered to reality in the same way that engineers are. Objective reality will win in the end, but that doesn't prevent damage being done in the short term.
IDK, I do think a lot of it is LLMs enable people who were not in our community to come into it (in an eternal september kind of way) and they are going through all this from first principals and ignoring their elders, but I've also seen technical people suddenly measuring themselves this way. The most optimistic read of this is that they _feel_ productive, and that feels nice, and they want to share how that feels, and so they are reaching for these garbage metrics because they have nothing else.
> The most optimistic read of this is that they _feel_ productive
In addition to "feel productive", two other feels I think are flying under the radar:
1. You get a parasocial relationship with a "friend" (or at least conversation partner) who seems to "understand" you.
2. You get some form of gambling entertainment when you pull the lever and the output keeps landing on different sides of the jackpot you want.
While #2 has some overlap with classic creative struggle, I think it can at least be seen as a kind of junk-food verson, where the frequency is different and the health-promoting parts aren't present.
>we as a community spent decades trying to make it clear that our productivity is not easily measured
Did we? All I saw the last decade was increasing worship of the Github activity grid, from both engineers and non-engineers. IMHO the bazaar had already lost its way before this.
Maybe a particular group of software engineer cultivated the need for careful measures. But the programming field never escaped the idea of simple metrics.
That's because you would always have loosely involved but aggressive and demanding bosses (there is unfortunately an economic value to the boss whose primary task is forcing more effort out of the employee and who doesn't help coordination or anything else). So at best you had two intersecting clouds of approaches with actual accomplishment intersecting with LoC and related measurements.
The thing AI is that it provides all the tools to satisfy that loosely involved but demanding boss. So suddenly you are going to have a larger demographic of people who like LoC and feature-additions as metrics 'cause now they are easy.
If your A+ senior developer spends 8 months working on a feature that ultimately doesn’t get shipped or a MVP that gets killed, then you wasted that A+ senior developer and their productivity was the same as the other two B+ engineers that also worked on the project. This is actually a very common issue and usually ignored when it comes to things like hiring or assigning resources to a project. AI won’t change that in a meaningful way, your team may just finish their tasks a lot faster but the bureaucratic layer above will likely remain the same, which will make any AI coding gains negligible. Companies would have to be rebuilt from the top down for AI and that’s very unlikely to happen.
I think engineers tend to over index on this kind of thing being "waste". You didn't waste that investment, you paid for the option to ship that feature or MVP and the research into the question of whether it made sense to ship it.
That's cool but don't get heart broken when engineers leave after repeatedly being told the thing they worked on for months wont ship because someone at the top said so.
Not really? If those are people I'm close with, I try to express this perspective to them in 1:1s that things that don't end up shipping are not a waste for the reasons I expressed here. And most of those people (because they are simpatico with me, which is why we're close) tend to see it the same way I do, and not leave because of this. And if they do leave for this reason, I conclude, well, they just weren't really aligned with me on this particular perspective. And that's a bummer, but not everyone is gonna see things the way I do.
It's definitely that, which is very valuable, but it's also the optionality value additionally. You had the option to launch the thing, which you wouldn't have had if you had never worked on it at all. It's notoriously difficult to properly value optionality, but it definitely has value, and often a lot of value.
No, optionality very literally has value. If I buy an option to purchase some commodities at some price, and the market moves against me, I lose the price of the option. By your logic here, the thought should be "buying the option was wrong, because it didn't go my way and I lost the price of the option". But it's often the case that actually buying that option was a good move.
The kind of optionality I'm talking about in software projects is not so clean to account as the financial instrument, but it has real value in just the same way.
> sorry, but this just sounds like a rationalisation for "we built the wrong thing".
If it were so easy to decide what the right thing is to build before you build it then business would be easy.
That's the whole reason options have value. Having 3 shippable products ready to go when you can only effectively ship 1 puts the whole team in a much better position than choosing 1, focusing everyone on it, and hoping you hit the lottery with product-market fit.
So yes, an engineer may work on something that doesn't ship. That doesn't retroactively make their effort worthless, and that's not even counting the experience gained by the endeavor which may well pay off on the next round of products to ship.
> If it were so easy to decide what the right thing is to build before you build it then business would be easy.
It's not easy. That's why it's important to be straightforward and just move on without all the navel gazing.
> ... hoping you hit the lottery with product-market fit.
There's this thing called "research" where you talk to real people, instead of guessing.
> That doesn't retroactively make their effort worthless
No-one said building the wrong thing was worthless. Life is one continuous mistake.
---
we are saying mostly the same thing i'm pretty sure, especially in your other comment reply (https://news.ycombinator.com/item?id=48498912). although i feel you're dressing it up a little too much for my liking. i prefer being a lot more plain and direct about it (and probably a bit arsey).
ruthlessness is an asset when it comes to we built the wrong thing. ruthlessness gets us moving on faster.
I don't understand why you interpret "we should recognize that it's worth paying for optionality and sometimes we decide not to exercise the option and that's normal and fine" as naval gazing. I think it's the opposite, that feeling butt hurt about the projects you work on not shipping is what is naval gazing.
To me all your "I prefer being plain and direct" just sounds like someone who hasn't thought much about why building the wrong thing is not worthless, and why those continuous mistakes in life are worthwhile, and isn't really interested in thinking about things at more than the surface level.
It does seem like you aren't really disagreeing with us here. But you're just saying "don't make me think about why we agree about this!"
> It does seem like you aren't really disagreeing with us here.
I'm not.
> But you're just saying "don't make me think about why we agree about this!"
My position is that you're overcomplicating it with business doublespeak.
----
edit
> someone who hasn't thought much about why building the wrong thing is not worthless, and why those continuous mistakes in life are worthwhile, and isn't really interested in thinking about things at more than the surface level.
I have just spent the last two years writing over a thousand pages of very heavy introspective stuff about a bunch of stuff i've done, and things that have happened to me, over the last thirty years.
"surface level" is most definitely not the person you're speaking to.
Yes I understand that. The tendency of engineers to willfully refuse to understand what's going on in their businesses and scoff at the things they are refusing to understand by dismissing them as "overcomplicated" and "business doublespeak" is what my comment that started this thread was about.
Did you see the part in my big story time comment where i convinced the ceo his business strategy was wrong? do you think i did that with a flippant and dismissive comment?
Shouldn't companies figure this out before wasting tens of millions in budget + working hours? All I'm reading is that corporations are not taxed enough if they are okay with such opulent waste.
ceo had invested £1 million to build a data analytics platform. "democratising data analytics" in a very specific domain. essentially, competing with someone like databricks in a niche. although they had never heard of databricks before i showed up.
For that million pounds they got a job scheduler written in pure django with a halfway finished react frontend. the whole thing was constantly broken. there were multiple race conditions throughout the product. i joined well after the million pounds was all gone. three years after i joined i had fixed the worst of the problems by rewriting massive swathes of the thing.
i eventually convinced the ceo they'd been doing the wrong thing all this time -- they should focus on analytics + specific domain consultancy services instead of software products.
the major failure was no-one ever moved on from idea V1. they never moved to idea V2. which meant they never got to idea V3. instead, everyone spent a hell of a lot of time talking about how great V1 was going to be, and how they planned to build V1 and what V1 would look like, check out this status update about our progress on V1, check out this mock up on what V1 is going to look like etc. they had an agile consultant come in to tell them how to be more agile. a scrum-master to tell them how to scrum.
3 months after joining was the first time i mentioned apache airflow. they literally could have just stuck a nice frontend on top of it and written a backend data transfer library. job done. very cheap idea V1. unfortunately, the previous team of django developers could only see their trusty django hammer. edit -- and i should add their big £1 million budget too.
multiply the budget by 10x or more. exact same thing at some big corpo. bigger budget = room for more bullshit.
Yes, thanks for the story. This is what I was trying to say. The idea that it's completely okay for companies to misallocate billions of dollars across the industry while people are legitimately suffering do to myriad of reasons is just bonkers level of selfishness.
I worked at a company that had an $80,000 monthly AWS spend when the total users in question was less than 100,000. The most concurrent users was <500.
This obscene waste actually isn't health for society nor the economy.
Software engineering projects expand to fill the deadlines you set for them (usually going over). Same thing for budget. You'll waste a bunch of a million pound budget. People are forced to get creative and thrifty with a £20k budget.
> The idea that it's completely okay for companies to misallocate billions of dollars across the industry while people are legitimately suffering do to myriad of reasons is just bonkers level of selfishness.
Yes. The metaverse bullshit comes to mind. Something no-one wanted or needed, and exorbitant amounts of money spent on it.
Knowing what to build (and that it hasn't already been built or bought elsewhere in the company) requires bits of information / person-to-person networking / visibility into the state of the company that not all managers or VPs have.
In fact, most people don't have that knowledge, because they're busy with existing or "local" problems , or because they didn't know to ask Davis the DBA or Kris the Kafka Cluster Manger or Alex from accounting if we have <resource> our team can plug into and use. "Oh, yeah, El has one under their desk they kick occasionally, ask them to hook you up!"
If you solve this problem in a turnkey way Fortune 500 companies will write you very large checks to help them prevent such duplicate waste, and will in turn become the 15th system they need to integrate....
That XKCD joke about "how 14 standards becomes 15 standards" also applies to the class of "one system to integrate with and report from all other systems"
Not the same. Every corporation I've worked at (several dozen in my career across the F500) has had numerous stories about obscene waste in regards to building things in software.
Waste at all levels. I've worked at insurance companies that spent $100million on development where only 200 customers signed up (estimated to be 20,000 at start). I've worked at telecoms that spent $25 million developing internal tools that no one used. I've worked at big tech where entire teams sole purpose is to control a single widget on a UI page.
This isn't even on the procurement side. Recently left a company where a single org was paying $10,000 a month on licenses when only 12 devs existed. I've seen organizations waste tens of millions of salesforce licenses that no one uses.
I'm sorry but the waste is rampant. SMB's can afford to waste tens of millions of failures, but modern US corporations can because there is no real competition in US markets. Just monopolies abusing each other.
I'm sure scientists would love the chance to have stupid budgets and make stupid things.
It is true that businesses tend to have more money than scientists so the numbers are bigger, but scientists pursue failed experiments that are "waste" in just this same way.
"It only got 200 users" is the business version of the null hypothesis.
No, it's best to manage your software delivery organization to reduce the cost and time of experiments so that you can quickly and cheaply figure out what to build... and then build that.
But there will still necessarily be things that you build that don't ship, and that's inherent to the problem domain.
Are you sure those 8 months is not being spent on just “coding”? There’s design, product team input and iteration, etc. Where did you see that an A+ engineer goes into a cubicle and come X months after with an MVP in isolation?
AI is the new cloud. There's no market for people or companies who aren't committed to it. If you're a dev who refuses to use AI, no company will hire you; and should a company decide not to use AI they will have a hard time retaining devs (and they will need more devs). Their investors and big-ticket customers will also think twice before signing off on major commitments.
So yes, use AI. Don't nitpick the costs and benefits. The world is headed this way; if you want to develop software for a living and afford to eat, you need to be too.
> and should a company decide not to use AI they will have a hard time retaining devs (and they will need more devs)
Need more devs? Why? If a company was being profitable just fine prio AI era, they will still be profitable if they decide not to use AI. Shipping crap faster is not a formula for success. Shipping quality faster? I prefer shipping quality at a good pace
Will you though? I see this repeated, but I’ve almost never changed products because one has 10x more features than another.
I usually buy and use products that are simple and effective, and that get out of my way to do the thing that I want to do.
For email, I’m a happy customer of Fastmail and I’ve been paying them for years. I don’t care if they ever release a new feature and I’d never switch away from them to a competitor that’s less stable but does more. They release improvements slowly but they are very stable. But I would switch away from them if they start shoving AI into things or delivering subpar features that make my email worse.
For healthcare related websites, I can already see my test results, schedule appointments, and communicate with my doctor. What more could an AI-driven medical platform give me that makes my life better?
For maps — I unfortunately had to move away from Apple recently when they added Ads. So I’m mostly just using OpenStreetMaps. I could see AI improving the OSM functionality by updating the app (OrganicMaps) routing algorithms and such, so there is room for growth there, but it’s not that massive.
Can anyone offer features that Uber can’t now due to LLMs? There are a bunch of local Uber competitors but uber wins because it’s easy and there aren’t major features to differentiate there.
Do you have examples that prove that delivering a bunch of features really fast is going to steal customers from something?
your personal experience is clearly in the techie bubble
ai is more than delivering features fast (thats probably one of the lowest priorities for companies)
right now its a race to automate work, especially back office. companies already are seeing 10M+ in savings and revenue growth and we're barely starting. workflows in sales, outbound, gtm, marketing, eng, operations, compliance, kyc etc
consumer is a different beast, consumers want convenience which has already been hyperoptimized and the big consumer cos run on network effs instead of features
> right now its a race to automate work, especially back office. companies already are seeing 10M+ in savings and revenue growth
What? Where? Citations please. We're seeing big companies massively stall in all traditional sectors except AI which is a irrational market built off hype.
ai companies know how to use the tools internally, not surprising
there are no citations yet because this is going on behind closed doors, if you know you know. we'll start seeing it in the financials of companies soon. alternatively you can look at the revenue growth of applied ai companies
It's much more than that. There's plenty of market for people and companies who don't specialise in cloud software. The market for programmers who don't use AI is going to be more like the market for programmers who don't use compilers.
> So yes, use AI. Don't nitpick the costs and benefits. The world is headed this way; if you want to develop software for a living and afford to eat, you need to be too.
It's really saddening to see software engineers throw out all critical thinking and innovation out the window to behave like sheep and follow the trend line. The industry was trailblazed by people that refused to do just that and the same is going to be true in the future.
Yes but most people aren’t trailblazers, they’re horribly average and just want to get by. This includes me.
This industry is hostile. You need a self preservationist mindset if you want long term success. Or, at least, it feels that was for someone who isn’t absurdly talented, wealthy, or connected. So, for now, we put our head down and be good little cogs.
I think of it this way. In a company with a good culture, I will build a rapport with my management and give my honest opinions. In a company with a bad culture, I just nod along and say “uh huh yeah yes sir what a great idea!” Because I know that’s it’s gonna get pushed through no matter what I say, and my opinions will only serve to hurt me.
And, right now, tech, or even America, is like one big company with a rotten, rotten culture.
>The difference this time is pace: you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.
It is weird that the author seems to understand that the pro-AI claims made by AI companies about the product’s necessity are not falsifiable, but then backtracks with “woah woah woah but don’t think I’m anti-AI.”
How is the assertion above any more rigorous than the productivity claims the author is criticizing throughout the rest of the article? That you won’t “survive” if you don’t adopt AI within a few months?
It is not true when the AI CEO says it, and it is not true when the person calling BS on the AI CEO… for some reason also says it…
When the AI CEO says it, its because stock go brrr. I never believed that AI CEOs because they're making unverifiable claims that they never backed up, claiming you're firing people because of AI is so open for interpretation, and it shifts blame from you to the AI, reality is we should not blame AI for something a CEO did, you could have re-trained employees for AI, but you didn't why not? Maybe because it's not about AI is it?
Hey, author here. Fair criticism (and thanks for reading!). What I was reaching for with the "few months" claim wasn't about company-survival, rather individual practice. I didn't make that clear enough (I actually did write this, not "AI-slop it" as some elsewhere have suggested, so maybe I got "human-sloppy" by the end).
You're right that I don't back up the "woah woah woah" bit with any evidence, but I do stand by the sentiment that I think people should use AI; experiment, find the ways it can help you (I've found that there's a huge spectrum even among similar engineers, in terms of how they get value from it). Trying the tools properly costs you almost nothing, and "adopt deliberately, measure with the boring battle-tested stuff" is not the same position as "adopt or die".
> It is not true when the AI CEO says it, and it is not true when the person calling BS on the AI CEO… for some reason also says it…
People do take into account the motivations behind what someone says and to me the motivations here seem different enough to make some difference here. The AI CEO has an obvious motivation to lie, but the person calling BS doesn't have such a clear motive...
>When a company says “AI made everyone more productive, so we need fewer people”,
They are implicitly saying that as a company, they don't want to be more productive. They want the same productivity by paying fewer more productive people.
Why is there an imbalance between what an employer gets paid for a unit of production and what an employee gets paid for a unit of production?
> Why is there an imbalance between what an employer gets paid for a unit of production and what an employee gets paid for a unit of production?
Because labor gets exploited to make the owners richer. That's the basic fact, even though the owners (as a class) have financed a lot of propaganda to justify and obscure it.
> Let's rephrase: labor is used to ultimately provide owners more money than they put in.
I'd rephrase that: labor is used to provide the owners the maximum amount of money they can manage to extract from the people doing the labor.
A technology 10x's worker productivity? That means 9x more goes to the owners, and 0x (zero) more goes to the workers. Maybe the workers get even less, because now you can fire some.
> Who starts a company to lose money? Who starts a company solely for "creating jobs"?
A more equitable distribution of company profits does not imply the company loses money. It does not imply useless make-work jobs.
> A more equitable distribution of company profits does not imply the company loses money. It does not imply useless make-work jobs.
I fully agree, and remind you it's completely legal and simple for you to go and start a company that does equitable distribution of company profits. More people should do it instead of complaining that few people do.
Nobody does it because the incentives make it impossible. If you do this, then you just lose. Because everyone else will be doing it, so you’ll get pushed out.
Think of it this way: if slavery was legal, would anyone be running a fair labor farm? Maybe, for like a week, before they’re out of business.
Or, consider this: at any point in time, any of the tobacco company could have made nicotine-free cigarettes. But they never did. Why not? Because it’s a fundamentally impossible position to hold.
Now, this is very reductive, I admit. There is a niche for appealing to people’s conscience. But that niche is a luxury, and luxury goods don’t perform well in a tight economy. And, luxury goods will never have the breadth of the staples.
> I...remind you it's completely legal and simple for you to go and start a company that does equitable distribution of company profits. More people should do it instead of complaining that few people do.
No. Instead of doing that, the effort should go into making all companies act that way.
IMHO, what you just did is part-and-parcel of one angle of the "propaganda to justify and obscure it" that I referred to above (e.g. "Don't like it? Then I say your only response should be this ineffective and limited-scope action I specify that strictly adheres to the status-quo").
And it would be ineffective. Building a little oasis in the middle of the status quo would only help a few and is unlikely to resist the tendency of things to eventually revert to the mean. The mean needs to change, and the best path to that is probably through regulation, other kinds of social standards-setting, and increasing the power of the exploited groups (e.g. through unionization).
> They want the same productivity by paying fewer more productive people.
I believe you mean same output but fewer people? But by definition that would be higher company productivity, as the definition of productivity at the company and/or national level is the ratio of outputs to inputs. If you have fewer people but are getting the same output, then the productivity of the company (or nation) has improved.
If you had fewer people but the same productivity then there would be no benefit to the company as the outputs would correspondingly be reduced (and it may actually be worse for the company if the company has any fixed costs).
I don't see LOC as that different from number of hours in the office. They'd always say pre-pandemic "If they're not in the office, how will I know they're working?" Simple, use the output metrics that you use to evaluate all of your workers to see what they contribute to the business.
I largely think that we engineers are to blame for LoC being still perceived as an asset rather than a liability. We are proud of stuff we create, but it turns out that you can't describe how "big" something is without some metric, and so we fall back on the metric that is easiest to compute.
Suggestion: we should all shift our terminology, and in particular make heavy use of phrase "...and it cost N lines of code". And say what we spent those LoC on.
"I implemented new feature X, and it only cost 200 lines!"
"That bug was brutal to figure out, but in the end it only cost 6 lines of code."
"It was doing something in case X that it didn't do in case Y, and it turns out that the distinction wasn't even needed. So I fixed the problem and saved 20 lines of code at the same time!"
Lines of code are a price you pay. We don't go around bragging about how we spent $200 without any mention of what we purchased with that money. Why do we do that with LoC? "I had to pay an extra $200 because I signed up late" and "I only paid $200 for my hand-painted artisanal pottery lamp hanger. Factory-made ones cost upward of $1200 on Amazon!" are two very different statements, and map to exactly the same distinction in code.
Anecdotally, coworkers are writing a LOT more unit tests. By which I mean NOBODY is writing unit tests, but Claude is generating a ton of em. We’re talkin 300 lines of unit tests for 20 line changes that are already covered by other, better kinds of tests. Huge JSON objects of test data that we already have generators for, etc
> but Claude is generating a ton of em. We’re talkin 300 lines of unit tests
Of course - it is setting itself up for more token consumption later: when a small change is needed, it may have to parse/adjust 10,000s or 100,000s lines of test data / code...
A sensible senior developer would recognise the shackle that huge brittle tests suits can become and correct course. But this is against Anthropic's business strategy
> If you got a free headcount increase essentially overnight, why wouldn’t you use it to deliver more value to your customers, faster?
That shows that, in reality, it's short-sighted profit-taking. Boss just wants another lambo in the garage, and doesn't really plan to be around, when it's time to pay the piper.
More that LoC is a simple metric that has always been a problem.
Non-Functional requirements is a vestigial term from ‘function point analysis’ which is from the late 70s, and which also ended up being a proxy for LoC.
The entire industry is so focused on measuring now, and incentives are so skewed to short term that lagging indicators like maintainability are a non starter in many organizations that it will be challenging to fix this time.
This is already changing again now that CEOs have wised up to the fact that they're paying for code by the line but these lines don't translate to profit.
> I’ve watched this industry absorb higher-level languages, IDEs, autocomplete, agile and devops, and there were always crusty hold-outs reminiscing about the good old days before X came along and ruined everything.
But all of those things were consciously built, deterministic and transparent tools. LLMs/AI are something fundamentally different.
yes it does seem fundamentally different. Most claims about AI are unmeasured marketing and favoritism. Similar to how management wants you to use eclipse or codeblocks to a developer that uses Emacs skillfully because it is shiny and new and they don't understand the requirements of the developer.
I think a better metric these days is what percentage of code is not reviewed / understood by humans. That is the real bottleneck. Until we can stop looking at the code, AI barely matters - you are just trading quality for quantity.
Thats why it is so amazing for speed runs and prototypes. Here it is legitimately > 10X faster.
You need to retrain managers from seeing a prototype and thinking "yep, ship it" and over to "okay, how do we build this properly?" And I don't think that's gonna happen.
What happened was the audience changed. Before, the audience for things about writing code was mostly software developers. Now it's the employing class. The collective wisdom of engineers? It has little impact on the conversation because the audience doesn't care. In fact, it's more than indifference; many are eager to no longer be "burdened" by it.
Not only do they not want to pay our salaries, which is an expense, they're eager not to have to depend on our expertise or judgement as well. That judgement and expertise is a locus of control that resides outside their own hierarchy.
The paradigm used to be create good enough abstractions you can express what you need in a few dozen lines or whatever. Those lines will be clearer and more precise than English for describing what it does.
I wonder if we'll ever get back to that? If it's still relevant?
I think LLMs will make vertical slice architecture more common using less abstraction. If juniors are mostly relying on LLMs then they will accept the long files it generates and not have the opportunity to learn abstractions.
It is pretty funny how this whole industry in a very short amount of time, with tons of experience and knowledge to lean on, reverted back to dubious measurements of productivity. If you track LoC and tokens used as productivity measurements, developers are going to max their LoC and token usage! Its so predictable that we have a Law named after this phenomenon! The fallout was so predictable I feel like I should have been positioning myself for all of the potential consulting work that's about to be needed.
If developers burn through thousands in AI tokens a day, does it really matter, and is it a good spend? Are the outputs actually checked for sanity, fitness, qa/qc, security etc. How much rework is coming out because of lack of validation, or too much automation in the soup.
The more I read, the more I feel that 1 dev, 1 ai agent with the dev as a gatekeeper is probably the most appropriate workflow. Where you now treat the single dev + ai as a team in terms of planning and cost analysis and you get about 1.2-1.3x the throughput compared to a traditional team of 3-5 devs with partial PM and partial QA where the Dev now needs to take on those roles too.
The output should include more/better testing, examples, demos etc... since the bus factor is now 1, but AI is expected to be able to do the heavy lift.
A) a newly-receptive audience - engineers who have discovered that they very much enjoy and appreciate the tradeoff of proximity to the code for amplified velocity and impact, now that it's possible to achieve without being a manager of messy human teams.
B) an ecosystem in which it's grown nearly impossible to connect a functional description of something to how much bespoke construction and effort was involved, partially because of marketing and partially because of how much software already exists to be built on top of. It's impossible to tell from a few paragraphs of functional description whether something was built in a weekend or took a team 4 years to ship, so volume of code is the natural fallback for describing complexity.
By this argument, I guess we should write our code slower too. Maybe we should only use a single finger as we type. And add an extra day between email responses.
Because by the inverse of their argument, slower MUST be better, right?
This is silly. LLMs are a diesel powered keyboard. If I've got a backlog of features, why shouldn't I ship all of them? If they're bad ideas, I can also just remove them.
Nothing about SDLC best practices has changed EXCEPT the ability to increase volume.
When a company says “AI made everyone more productive, so we need fewer people”, I want to see the evidence - and I don’t believe it exists today.
I think these companies doing "AI layoffs" do actually see improvement though it is a placebo and not caused by the AI usage. Don't we know for a long time already that leaner software teams perform more efficiently?
don’t read any of this as anti-AI
I am not afraid to say I am anti-AI it surfaces a rot that in this industry marketing ideals and anecdotes have more impact then measured performance and that many people still find it very hard to estimate a developers performance, impact.
AI is shit, doesn't speed up my work. Only 10/20% of programming is typing and AI can do that fast, but the whole process no. If you disagree show me a proper study where actual improvement is measured.
Probably you could get a cheaper and more constant improvement if you make sure the developers are properly trained in the IDE's and environments they are already using. For example give everyone a Unix programming course and a course in their preferred IDE.
When I read recent news on HN, I feel it is a fable about Goodhart's Law. The law says: 'When a measure becomes a target, it ceases to be a good measure.' The dog should wag its tail. But the tail is wagging the dog.
LoC by itself is useless and so is AI LoC, it doesn't really show anything by itself.
But if you pair AI LoC in a range and also task completed in the same range and then compare that with historical data over a similar range without AI, then you have something tangible.
You also need to look at defect reports to understand the full picture of is AI being helpful.
So, we do need to measure AI LoC and AI PR counts, but we also need to make sure we are using other metrics to help paint the full picture.
Large enterprises class systems are notoriously difficult to work Ai. It’s the context window limitation. Assuming 10 tokens per LoC. The best models today cannot wrangle 100k distributed LOC across multiple repos. It’s great for building new and maintaining smallish codebases. All this code being written is fantastic, but maintaining them efficiently over the code lifecycle is tricky.
>The difference this time is pace: you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.
I don't think so. Take a good company A (with a good product and a good pace of good features) of today. Take the extreme case they decide not to use AI at all. Well, they will still be shipping good features at their current pace.
No amount of AI will make a bad company ship a better product than A's. If any, bad/mediocre companies will be pushing crap faster than they did before, but that's it.
AI can make good companies better, but cannot make bad companies good. Why does company A need to worry about shitty companies using AI? Sure, other good competitors could be using AI, but all in all, shipping "faster" is not the "mark" of good quality
Yeah, that closing message was a little weird to me. I understand framing the article as "not anti-AI", especially if the author uses and enjoys the tools. But the end sounds like a call to blindly adopt the tools and figure out the justification later.
Yeah I think it also really depends on what your business is. Many or most of us here (and likely also the author) work in the kinds of tech-forward businesses where competition is fierce and velocity is essentially. But there are many many businesses, and also tons of public sector organizations, where this is not the case. Leadership in those organizations should probably be going a lot more slowly, waiting and seeing, letting all the fast movers fight it out through all this churn, and adopting only whatever eventually rises to the top.
Hi, author here. You're absolutely right! (yes, Claude-pun, I'll see myself out...) - I mean, I agree that Company A will remain "good", and may not need to worry about Company B. If that came across in the post then it was unintentional.
A lot of the criticism I've seen here could probably be addressed by me clarifying that no, I don't think AI should be blindly adopted, and no I don't think it adds efficiency or productivity by just existing and being "used". It needs thoughtful implementation, and each developer I know or manage or have chatted to uses it subtly differently, hence why I encouraged experimentation and trial-and-error, because when it "clicks" for you, then in essentially every case I've experienced or seen first hand, its added something (whether rigor, speed, efficiency, capability, etc).
Reporting on percentage of AI generated lines of code is very different from total lines of code. Yes I know both of them are missing what's the value delivered, but the later assumes the value is the number of lines, while the former assumes value is at least the same but delivered faster.
I too made a post like this on here not that long ago. The point i was trying to make was to be AI knowledge first. The tools are here and someone has spent lots of money(foolishly yess!, But) creating this tools, so why not use them to your advantage. The one's that wait too long find themselves playing catch up on the next big thing that's comes of it. This is a phase that will blow over and in that process there is something cooking. Think of it as the stepping stone to the next era into the future. The future isn't created on its own, we must push for it. Hope doesn't do much in creating innovative advancements.
Before the smartpphones we have today there was touch pad LCD products all fighting for what now we call smartphones, that came with heavy innovative techniques to achieve a goal. The goal wasn't evident nor clear at the time.
This will lead to something else that is far more useful and could be harmful in many ways not just to employment.Economies are changing like never before transformational force are changing our lives as we speak. housing prices, Wages, Technology, Political Power, Warfare, ideologies, the list goes on. AI is the starting point in this new era. Choosing to use silly words like " This is not how we used to do things: no shit, we also used to ride horses and sacrifice virgins for it to rain. I don't know when people will ever get this ( The world is ever evolving) that is what humans do.
Having a say so and a control in what is harmful and what is helpful is just as equally important.
It's dying down now because unlike before, companies are paying out the ass for those tokens, where many companies now have token budgets enforced rather than the previous tokenmaxxing.
Nah, as long as you're good a sport about it, it's all good. In fact, it's refreshing to have someone make a mistake like that so confidently, and then own up to it immediately.
Author here. I think this was my favourite (and favorite) thread. I chuckled.
I'm also pretty sure I could find ways to weave "septic" into a post about AI.
> Call it AI-first, AI-proficient, whatever you like
Can we just call it AI assistant and since it is really what it is. Just call a spade a spade, call it a day.
Nvidia boss Jensen Huang refer to AI as teammate in his recent COMPUTEX presentation, but it's disingenuous to call that since it's a just tool, but a very potent tool nonetheless. He's obviously biased to a fault but he's literally banking his company on AI now, but for the rest of us AI assistant should do more than fine.
Calling it teammate, workmate or friend is also rather childish. It's like having an imaginary friend that can lead young people to do silly things and this risk probably can be extended to junior developers [1],[2].
I agree with the main point but this misses something crucial:
> why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue
Most roadmaps are full of garbage and would be better off being deleted. You get very few truly useful new features in a year.
To paraphrase ESR: the value to your customers is in them being able to know that can rely on your product still operating next year, not in those 20 new features.
Or to think about it another way, maybe block will be better off with fewer developers, but only if they produce sufficiently FEWER features so that they’re forced to prioritize.
> But! Hold my beer… in February 2026 METR effectively walked it back : their follow-up estimates flipped to a speedup (with error bars wide enough to ride a Moto Guzzi, with panniers, through!), and they abandoned the study design entirely - because developers now refuse to work without AI, and can’t reliably self-report time on agentic work. Their latest position: AI probably speeds developers up in 2026, and we can no longer cleanly measure by how much.
This may be true, but they followed in May with this [0]:
> Importantly, survey results are not necessarily grounded in reality. There are reasons to be skeptical of people’s responses to counterfactual questions such as about AI’s effect on productivity — for instance, our study in early 2025 found that people overestimated AI’s effect on their time spent on tasks by 40 percentage points on average.
Author here. Thanks, this is a useful addition I'd missed. The 40-point overestimate from their early-2025 work is exactly why I read METR's current position as "we can no longer cleanly measure this" rather than "AI definitely speeds you up now"; self-reports are doing a lot of load-bearing work in every direction, including in my own sense of my productivity.
It’s worth looking at sectors where LLM code generation hasn’t been very visible, such as certification-accredited flight-control, braking, train-control, medical, or nuclear-control source code involving real-time embedded operating systems. This sector relies on assurance: deterministic scheduling requirements, detailed commit traceability, tool qualification, configuration management, independent verification, etc.
Since this is an area where failure can lead not to Instagram accounts getting hacked, but planes falling out of the sky and nuclear reactors spewing radioactive elements, it’s worth a close look. Some of the most visible companies in this sector include: QNX, Wind River, SYSGO, Lynx, Green Hills, Siemens Embedded, etc. None of them seem to have much if any adoption of LLMs for source code generation based on public statements.
Research in this area agrees with this view:
“In this paper, I have conducted a comparative analysis of the C++ code generated by popular LLMs including: OpenAI ChatGPT, Google Gemini, DeepSeek, Meta AI, and Microsoft Copilot for compliance with MISRA C++. The study revealed that none of the evaluated LLMs generated MISRA-compliant code despite clear prompts, with DeepSeek showing the fewest violations and Meta AI the most.”
This study showed that people writing computer games had little interest in productivity tools (because they are producing something that is really used). But people who produce things that not really used are obsessed with productivity:
> the perennially unprofitable venture-backed startup, for which faux productivity is connected to the generally immaterial nature of its high valuations, versus the game studio that lives and dies by the profitability of its products.
> In a sector of the economy where "it's not about how much you earn, but about how much you're worth," the labors of the companies whose workflows are built on the kinds of productivity apps that today comprise nearly 40 percent of Product Hunt's output are not actually directed at the creation of a thing, but at the appearance of the creation of a thing.
Maybe this is why Silicon Valley seems to have become obsessed with productivity and AI whereas the people in the industries you mention don't seem as excited. It's because they are actually making real things so they don't have to 'look busy' in order to justify themselves.
Many mid size to large companies are hilariously inefficient and the executives have no idea how work actually gets done. This means you can (in theory) fire a decent percentage of your workforce without affecting your output. You can then claim they’ve been replaced by AI without anyone ever challenging that assertion. I’m not making a pro or anti AI claim here, just saying that you won’t know whether you were wrong about it until/unless things start to go really badly.
> But adoption is the starting line, not the scoreboard.
Yes yes, shout it from the rooftops! Over the next few years I think we're going to see that companies that get this point will keep doing meaningful things, and stand a chance of weathering this transition period.
I think we're going to see a bunch of companies that went all in on AI for AI's sake go under because they've lost their mission, lost their implementation, and won't have a way to get those back in a reasonable timeframe and at a reasonable cost.
Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.
So of course we don't see massive productivity gains. Because these parts of the SCLC were always bottlenecked but their capacity matched the throughout. We fired all the dedicated QAs years ago. Sr+ engineers that do all the code review are limited.
Teams have not re-organized to match the new code-input velocity.
Engineers don't want to do QA because it's "beneath them".. and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.
There is some truth to this, but in practice I'm finding that yes, removing the writing code bottleneck has improved throughput quite a bit.
My day (excluding the huge amounts of communication overhead) used to progress as a serial operation of: 1. Write some code for one thing, 2. Self review of that thing, 3. Review other peoples' work, 4. Respond to review comments, 5. Get things merged, 6. Back to 1.
Now I have more of a tendency to queue up work on a few things at once, and then the serial steps are the self reviews and reviews of other peoples' work, and some of the review commentary back and forth (though I can automate some of this in parallel as well).
The upshot is that I'm more working in batches now than in serial, which I really do find to be more efficient.
It's not that it has removed all the bottlenecks at all, but no longer being required to focus all my attention for periods of time on physically typing code has removed one important bottleneck, and has changed, and I would say, improved, my workflow significantly.
One thing the AI tools have taught me is that it hasn't been my personal bottleneck for at least a very long time. It's made that part faster for me, and that allows me to take bigger bites at the apple each iteration, but it's not meaningfully speeding me up in the way people claim.
I disagree that it's not meaningfully speeding me up. I'm definitely doing a lot more, and more quickly. But the benefit is definitely smaller at the team and organization level, because we still have all the same serialization points - review, validation, decision making - downstream of my work.
I realized after I posted that it didn't quite capture what I meant. For instance if I'm able to do a more complex piece of work all at once in about the same amount of time as it'd previously take me to do a simpler piece of work, than that is a speedup. And that's what I am able to realize.
But what's not as much the case is that if I did an A/B test on the same task that I'd be massively sped up because so much of my day to day work are the things you mentioned as being serialization points. The time I take to figure out what needs doing, what the best approach would be, making sure it was actually the right thing to have done in the first place once I'm done, all that stuff. I use AI assistance for those tasks too but it's not the same effect as when I just hand off the pure implementation phases. So it winds up being "faster" and you'll have to pry my AI assist tools out of my cold, dead fingers - but if I'm being honest with myself by *that* metric it's not a huge gain.
Code has never been the bottleneck, and it was always an illusion that it was. I mean, programmers on the whole are a group that jerks around probably 95% of their time (this isn't an attack as I've spent my career as a software developer, and this included countless hours on Reddit, HN, Slashdot, and so on).
> Engineers don't want to do QA because it's "beneath them"..
I’m fine with doing QA. But the fact is that it’s not how management measure my productivity. Spending hours doing QA looks like wasting time to them because it’s not an activity they track. They track my tickets so any hours not spent on them is literally harmful.
Also there’s the fact that you can’t QA your own output. It’s easy to overlook mistakes and defects.
> and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.
Just like QA, code review takes time. It’s easy to justify that time when the submitter has put in the effort to ensure that the contribution is worthwhile. Or can explain the design clearly. Not so much when it’s slop thrown over the wall.
> Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.
None of those are truly bottleneck. Deciding what to build is obvious: Something that solve a user problem. Reviewing code is easy when the intent of the code is clear (with additional prose if needs be). Testing code is equally easy and should already be automated.
The one slow activity has always been about designing the solution. And it has no relation to code. It’s mostly deep thinking and research. I do it on the sofa or in front of a whiteboard. If I’m typing, I already have a solution in mind.
'something that solves enough users problems it's worth it to implement it' rather, and I think it is often difficult to judge how much engineering time to spend on user issues.
I'm currently working in an internal team, so I value cost savings estimation, but even before prioritising was also a bottleneck (although a small one compared to architecture and design)
I don't know about anyone else, but for me, even though the AI writes a lot of code, the vast majority of that code tends to be... tests. Same with my coworkers.
This morning I reviewed a 1,200 LoC PR. Pretty large by pre-AI standards. But most of it was tests. Before AI, it would be a lot smaller, but only because the PR author wouldn't be nearly as diligent with test coverage as AI tends to be.
And to preempt some common rebuttals:
1. I always read the tests to make sure they are meaningful, and rules and subagent review routines in place to make sure stuff like "assert 1 == 1" or "Process.sleep(5000)" never make it in.
2. Tests do add a maintenance burden as well, but I find that it's pretty easy to refactor and condense tests.
> When a company says “AI made everyone more productive, so we need fewer people”, I want to see the evidence - and I don’t believe it exists today. Show me that x% of your workforce is genuinely idle (or even just underutilised) because the work can now be done by fewer people. Even then: I’ve never seen a product/SaaS company that didn’t have an endless roadmap. If you got a free headcount increase essentially overnight, why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue.
I see some people calling for calm instead of AI panic by invoking Jevons Paradox. But at least within these companies there's no good evidence of Jevons in action, is there? The roadmap is endless, but when employees are perceived to be idle they get fired instead of being assigned more (or more ambitious) tasks.
To be fair, one could claim Jevons applies to "the market" at large, but at least we can say the evidence from tech companies is not encouraging. So maybe it is, indeed, time to panic a bit?
> Choosing the layoff instead tells me the productivity claim is doing PR work for a decision that was already made for other reasons (over-hiring, investor pressure, take your pick).
Yup, I think we all suspect this. Though it's probably a mix of the two factors.
Anyone relying on a steady paycheck from an employer should panic a bit all the time, because nothing can save them from bad management. The reference to Jevons Paradox doesn't say anything about individual managers responding correctly. If 30% of managers screw up, that's a lot of collateral damage.
Now to respond to your actual point, I don't think software developers should panic. Even if pure software engineering gets hit hard, I'm having trouble imagining a scenario where years of software development skills plus knowledge in a specific domain isn't a good thing for current software developers. This is unlike what happened with international trade, where you had 60-year old textile workers losing their jobs, no alternative jobs, and no policy being offered to compensate them for the effects of trade.
Yes, it's the "market" argument that I find compelling. That is, not jevons within firms, but rather across them.
Is it true that the evidence in tech so far is not encouraging? I was pretty worried about the job market a year or so ago, but it seems pretty good for experienced people at the moment, no? (I do have big concerns about the entry level pipeline though!)
The kloc fallacy never actually disappeared. Project and engineering managers got wise to the fact that it was only loosely correlated with shipping features, and stopped emphasizing it. Most everyone else has carried on silently believing it without really thinking about it. And of course engineers themselves have always believed it. How many times have you heard some guy talk about how he wrote 10kloc over the weekend as a brag?
Please read the full paragraph for the answer instead of cherry picking a quote for a knee-jerk reaction:
> Be curious, try the new tools, test the latest models. To not do so is silly.
> [...]
> you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. The way we work has already changed, and it’s not changing back as far as I can tell.
> you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.
I really dislike these claims that act like they know the future of engineering, that they’ve been let in on some enlightenment that we haven’t been. What’s going to happen in a few months? Is Sam Altman going to nuke my house from orbit? Or is it because my CTO is going to fire me for not using AI? If it’s the latter, that’s not a curiosity problem, that’s a “there’s a gun to my head” problem.
It seems to be based on some idea that there's no way you can be productive enough without AI. But I've yet to see any companies really shipping meaningful software at some unprecedented speed that was not possible pre-AI. Instead, I see a lot of half baked features and buggy apps. I am not convinced that those that choose to either NOT use AI or use it more sparingly / judiciously (my preference), are somehow going to be "left in the dust".
Yeah, I’ll second that. I see folks moving _fast_, but boy oh boy are they breaking things (or delivering something that never worked) which if anything makes _me_ slower lol
Because I don't think that's the point of the article, which is just a commentary about how AI labs are marketing the effectiveness of their services by using terms like "8x more code per quarter" like that's an obvious good thing (which it isn't).
If you want a more in depth explanation, go look for interviews with devs who were already super-productive before LLMs and now came around to using them everyday.
Because it's fun. And why shouldn't we be into incremental automation?
I still write code manually to keep my trad-coding skills from withering away, but using AI without a doubt has allowed me to better test my existing apps. Create playwright automations I would've never had the time for. Allowed me to search through docs many times faster. And it just making programming more fun when I do use it for more challenging problems, and I actually get something working at the end of the day.
To play devil's advocate for a moment (although I hate it): LoC often actually means NIH... but NIH suddenly has a pretty big proponent in the form of resistance to supply-chain attacks.
Basically the choices are:
1. Roll your own
2. Lockfile your deps for too long
3. Chase the bleeding edge for every dependency
The first is security-through-obscurity because DIY libs will have bugs and vulns but they won't be well-known. The second means missing known vulnerabilities. The third means supply-chain risk.
The rash of attacks and the ease of LLM-powered roll-your-own has shifted the risk-reward calculus towards 1.
But I hate it. This is the further Peter Pan never-gonna-grow-up of our industry that we cannot develop solid best-practice tools and must churn endlessly.
I'm reminded of my first tech job about 25 years that had some not very technical manager who had a technical toady write up a script to check lines of code added as a productivity measure. I was in big trouble because it didn't account for lines removed or modified, only new lines added. The copy paste guy was praised of course for how productive he was for.
Funny how AI is continuing the same story of non/semi technical busy bodies with their dumb bullshit.
Another AI slop article urging me to use AI on the orange AI fanboy site which has guidelines against AI slop comments, but AI slop submissions, that's just fine I reckon... Screenshot since the share button demands I have some social media login.
Hey, author here. My AI overlord advised me not to engage with this comment, but I don't like being told what to do.
I don't know what the reference to "orange AI fanboy site" is, sorry, but I do find it interesting that what I assume is an AI-writing-detection-site pegged it as 100% AI written.
Obviously folks will believe what they believe, but just to satisfy myself I will state that I used AI (Claude Fable 5) to help with research by suggesting and then summarising articles, then interviewing me both as a supporter and detractor to really solidify my position (essentially arguing/debating with the AI), and then it suggested the post layout (funnily enough including that specific subheading "Why I actually care", which I will concede sounds AI-as-hell), but I then wrote everything else. I did paste in any quotes and specific numbers (which that section has quite a few of), and I did then do a final pass with AI (both Fable, and then ChatGPT) to pick up spelling, grammatical issues, formatting, etc. Anyway, have a good weekend and thanks for reading. :)
I show dead and see both fanboys and critics all the time. Look at my comment history, I feel like I'm constantly arguing from the other side with people who are more fanboy than me and then other people who are more critic than me.
"As someone who spends a lot of time writing x86_64 Assembly and optimizing pure-JAX code for TPU clusters, this recent obsession with LLM-generated 'Lines of Code' metrics feels like a massive step backwards.
In High-Performance Computing (and especially things like quantum simulation, which I work on), the entire goal is reducing complexity and overhead. The magic of frameworks like JAX/XLA isn't how many lines of code you write, but how elegantly a few purely functional lines can compile down to highly parallelized hardware instructions.
If an LLM writes 100,000 lines of boilerplate for a project, someone eventually has to maintain, debug, and pay for the compute to execute that bloat. The real value of AI in engineering shouldn't be churning out a million lines of CRUD per month; it should be helping us build better differentiable systems, grokking complex mathematical landscapes, or spotting inefficiencies in low-level execution.
We spent decades learning that Goodhart's Law applies heavily to software engineering (more code != better software). It’s strange seeing leadership forget that just because the code is now generated by an agent."
The thing LOC measures best is how much code someone now has to read, understand, and keep alive. That number going up is a cost, not an output.
I spend a lot of my time taking over codebases other people left behind, and the AI-heavy ones have a recognizable shape: lots of plausible-looking code, thin tests, and nobody who can tell you why a given abstraction exists. Writing was never the hard part. Deciding what not to build, and being able to delete it confidently later, is the part that does not get faster with a model.
What did get faster for me is reading and reverse-engineering unfamiliar code - which is a little ironic, since the same tools are now producing more of the unfamiliar code that needs reverse-engineering in the first place.
Bragging about an AI agent generating a million lines of code is exactly like bragging about an automated factory generating a million tons of airplane weight. It completely misses the point of engineering. The bottleneck in software development hasn't been "typing speed" for a very long time; it's domain understanding, system design, and long-term maintenance.
Every line of code an LLM instantly spits out is a line a human engineer will eventually have to read, understand, debug, and migrate when the underlying business logic changes. The "better publicist" might be successfully selling these generation metrics to executives, but it's the actual engineering teams who are going to be paying the maintenance tax on all this auto-generated sprawl for the next decade.
This weird trend reached an apex in a Feb 2026 OpenAI blog post [1], recently on the front page [2], which describes the process for building... something... written 100% by agents.
There is no description of what the thing is, no indication of what value it provides its users. The closest it gets is "the product has been used by hundreds of users internally, including daily internal power users".
But the fact that the thing has a million lines of code is repeated twice in the first few hundred words.
[1] https://openai.com/index/harness-engineering/
[2] https://news.ycombinator.com/item?id=48416264
> "the product has been used by hundreds of users internally, including daily internal power users".
My guess is it’s an email filter.
> million lines of code
> written 100% by agents
Yeah, probably an email filter. Or maybe a JS menu for a departmental wiki that basically recreates jquery using MS JScript and transpiles it into JS 5.
> My guess is it’s an email filter.
It may also be an email generator.
The email filter team is trying to match the pace of innovation of the email generation team. At stakes is the ability for the employees to process the billions of mission-critical generated emails each of them receives each day.
It’s true. They’re all go-getters destined for big things. Look at those token burn rates!
Your hilariously specific hypotheses remind me of how little I know about technology.
> how little I know about technology.
Probably because you smoked too much weed in school.
Remember, this is the tech industry! An abject lack of knowledge is no impediment for people with boundless confidence in their assumptions!
Ya gotta start smoking weed after you're done with school, that's the way to success
The best strategy is to figure out what you are going to do after smoking weed before you smoke weed. So, draft your prompt and send it before lighting up.
And trash your short-term memory? Nah, smoking weed is straight up bad for most people.
Plot twist: they weren’t even enrolled in that school.
The entire Linux kernel is about 40 million LoC, and only something like 16 million LoC after you remove drivers. I have a hard time imagining whatever OpenAI was talking about there having anywhere close to 6% as much utility as the Linux kernel, despite having 6% as many lines of code. And I have a hard time imagining it's anywhere close to maintainable, regardless of how powerful their LLMs might be.
To be fair, few things of any number of LOC have as much utility as the Linux kernel, and it's also a particularly dense example of code. There's plenty of other examples that have higher LOC / utility ratio without being vibe coded. For example, Google's monorepo famously has 2 billion LOC, which is a statistic I've heard long before LLM coding took over.
Clarification: Google claimed to have 2 billion lines of code in their repo ten years ago, and a commit rate of 50,000 changelists per day, both on exponential growth trends.
That's a monorepo with hundreds if not thousands of different applications. It's not even close to an apples to apples comparison.
That's certainly a way to look at it. And that repo contains a "third party" directory which itself contains Linux, LLVM, and much of the rest of the open source world. But I would suggest that the largest of those thousands of applications probably has a transitive closure of hundreds of millions of lines of code.
I'm aware. I worked on that specific project (assuming we are talking about the same one) back in the day. :-)
There are certainly very large applications in that repo in the hundreds of millions of lines of code. But comparing the entire repo to single applications is not an apt comparison.
Ok, then we can still compare one of those very large applications that have hundreds of millions of lines.
The Linux kernel is not in any way at top of big projects. A kernel, as the name suggests, deals with specific issues and tries to remain small.
The world’s biggest software is usually built over endless adapters of different data and a need to reconcile endless edge cases with laws, regulations and real world complexities.
When I was young, I remember a (joke) program from a book or magazine, called something like report writer or something. It was written in basic and you typed it in.
You would run it and it would say:
how many pages? _
You would type in a number, and it would generate that many pages of a complex-sounding report.
something like "the subsystem design interface is ..." blah blah
similar?
Chrome has 50 mil LoC
https://openhub.net/p/chrome/analyses/latest/languages_summa...
Chrome is basically reinventing each OS API and libraries. One day they’ll have their own tcp stack and packet filter.
It kinda makes sense given that one of their major products is a computer that runs an operating system literally called ChromeOS.
Chrome still has a way to go until Zawinski's Law is satisfied natively.
http://www.catb.org/jargon/html/Z/Zawinskis-Law.html
Arguably with QUIC it already does.
The reality distortion field is strong around anthropic. Anthropic posts tons of equally bullshit blog posts, written entirely by AI, saying absolutely nothing, to the front page and they consistently average many hundreds of upvotes.
I have to wonder if HN is astroturfed. Anthropic and OpenAI can post about a new model and it gets over to HN instantly and is full of glowing reviews of supposedly real people who supposedly have had prior access to it who supposedly think it's the best model yet.
Feels doubly so for Anthropic. There's just unbelievable level of glaze, and insane upvote velocity for "blog posts" that are essentially fluffed up feature documentation.
Somehow everything boris says has become the word of God. The dude is just an engineer, like you and me, who gets unlimited tokens for free.
Yeah, I sometimes catch these posts minutes after they were submitted and they're full of highly upvoted glowing reviews that maintain their momentum on the top of the page.
And this is hacker news. A place where famously the most upvoted comment is the one critical of the post.
Upvoter here. Nothing special -- I like Claude a lot. I found it more ergonomic to work with, and I think its models are state of the art. I believe I'm more productive especially in legacy crufty codebases.
I may not be representative of the universe or have a controlled, randomized study to back it up, but that's not what upvotes are for are they?
That's a fair point. To play devils advocate to myself, it's possible that the huge upvote share is due to a much bigger marketshare among our community.
Yeah, that was my guess too. Still a little disappointing to see fellow HNers reflexively fanboying a company that's the overwhelming dominate player in LLM coding.
I try to reserve my reflexive fanboy company/project votes for underdogs who need and deserve the help.
HN is astroturfed. Not just AI and also before AI took off. It's so easy and so valuable to astroturf HN
HN is probably astroturfed, but it is also one of those places where a lot of actual subject experts frequent. I don't find it unusual that a new model gets instantly posted here. It is also not unexpected that the most recently released model is the best model.
Heavily. There’s an amount of true believers who actually think RSI is going to happen any day now, but you can spot patterns amongst brand new booster accounts…
I real life I meet people who like AI and people who hate it, but nobody who’s on a personal mission to defend Anthropic from anyone that dares to question their hyperbolic marketing.
The tech field has always been full of naive technology boosters. HN might be heavily astroturfed for all I know but I am sure there are many real people in a state of constant excitement over the progress of AI.
Sorry, was it not this?
https://github.com/openai/symphony
That does not appear to have a million lines of code
Yeah it was very disappointing that so few details were provided. One of the reasons I think it's going to be an open source project or effort that is going to show, sooner or later, how effective these things actually are.
In their podcast interview, they mention that it's an Electron app that users download, and so they periodically create a new build. See section "Autonomous Merging Flow" here: https://www.latent.space/p/harness-eng
Oh god why did you make me read that.
>We intentionally chose this constraint so we would build what was necessary to increase engineering velocity by orders of magnitude
What kind of wanky bs is "engineering velocity". Maybe the post was written by AI?
It's a real term. It's a Agile metric for measuring how much a team is shipping over time.
Whether or not the whole concept is wanky bs depends on who you ask lol. It's useful if you measure it over time, not so much otherwise.
I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to, except apparently it was not satire at all, and indeed seemed to reflect the position of many CEOs etc when it comes to LLM code generation.
I do think that over the past few months, it feels like the hype around producing unmaintainable amounts of LoC has started dying down. More pragmatic and realistic takes are seemingly shared more openly, and are maybe even getting through to top leadership at some tech companies. Maybe not all is lost yet.
I once worked in a company where there was an 80% code coverage requirement. Some enterprising contractor had a script that generated a single file with its own covering test suite the size of which could be tuned to achieve 80% over the whole codebase. Mostly the code was untested.
And thanks to AI, we could generate extremely convincing reams of code whose only purpose is to be fake unit tested. Amazing. I sincerely hope I never need to use this nuclear weapon.
Or better yet: effectively fake unit tests. It is almost never the case that tests written by AI detect actual issues. At most they detect that has changed.
Yeah I’ve been thinking that LLM unit tests are basically snapshot tests. Just sorta ossify things in place. If they break, you just ¯\_(ツ)_/¯ and have the LLM fix them. It’s like they were never there!
So it’s just like the olden days of everybody ignoring tests, but we give anthropic a ton of cash
1000000/25/8/60 = 83+ lines of code per minute.
100000 LOC per month /25 days per month /8 hours per day / 60 minutes per hour
That seems...problematic for anyone doing code reviews.
This will greatly increase developer velocity (by making them run far away).
> That seems...problematic for anyone doing code reviews.
No, it's incentive to let LLMs do the reviews, supporting your tokenmaxxing efforts.
It has been incredibly hilarious to watch the C-suites sudden realization that tokens COST MONEY and immediately revise their guidelines for how employees should use AI.
Like maybe having every engineer generate 1 million lines of code per month every month…with no thought to how those lines of code would make the company money…or how many tokens would be burned to accomplish this at what cost…wasn’t fully thought through.
The word “slop” was a good choice to talk about the mass of code generated by AI. I think it resonates with non-tech people and it conveys disgust. It’s clear that we should avoid slop.
“Technical debt” never hooked management in the same way and we have found it hard to convince them that it needs to be addressed. Debt in general is something that can be a problem, but doesn’t need to be avoided or addressed until it is a problem so the can is kicked down the road.
Just fix technical debt over time as you work on other things and budget for it as you give estimates.
This approach has always worked for me. Non technical management will never understand technical debt and really shouldn’t need to.
To be fair, they are also different things, though there is certainly overlap...
To me, tech debt, captures the idea that we cut corners now to move faster, with the understanding that it will need to be "re-paid" and cleaned up later, otherwise we take on too much tech debt, and everyone knows too much debt is bad...
AI slop code means people feed their tasks to a model, trust it to drive the changes, they might do some cosmetic clean ups, then generate a 3 pager PR description they didn't even read themselves, then toss it over to the code reviewer, let that chump figure out what the hell I was doing while I ship 3-4 more PRs...
Technical debt is a indefinable quantity which makes it very prone to be abused to mean "I wish I could rewrite this in [insert some fashionable language, framework or coding style]".
AI slop is an easier concept to quantify. It's basically the code for which insufficient people in the organisation have a meaningful understanding of how it works or what it does.
> It's basically the code for which insufficient people in the organisation have a meaningful understanding of how it works or what it does.
Its connotation also includes being vastly larger than needed for the purpose it serves, _if_ there is even any purpose.
> I do think that over the past few months, it feels like the hype around producing unmaintainable amounts of LoC has started dying down.
I wonder if a small part of this is more and more business and product people actually trying to incorporate AI into their daily workflows. I have seen this in both small companies I work for. People were very excited about getting Claude Cowork a couple of months ago, and while they use it daily, I would say they are rather underwhelmed compared to the magic they were expecting. Complaints include the output being mediocre and verbose, it getting the most basic things wrong, hitting token limits all the time, and people going back to doing things themselves because it is faster.
Sure, there is some degree of holding it wrong in the beginning, but people are realizing that maybe, just maybe, there is still somewhat of a gap between what AI CEOs, LinkedIn grifters, and YouTube AI supplement peddlers claim and reality.
I suspect this is it. I'm 40, and the only tech person in my social circle. Many of my friends were all excited about using it for things like basic webdev and home networking. One shotting that type of stuff is very viable even if you don't know anything about the topic. Now that they are trying to use it for something they actually know about, suddenly it's unusable. It's a modification of Gell-Mann Amnesia.
> which basically read as satire to most engineers I talked to
Seemingly engineers get this wrong too. I'm reminded of when Cursor bragged about how many lines of code a group of agents could produce, with the underwhelming results of a barely working browser, when the same could be built with much less code.
But they highlighted the amount of code as they were proud over how much slop their constellation of agents had shit out, and these were supposedly engineers, really strange to see.
“Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.
And anyway, I’m pretty sure what people really mean by this “less is better” mantra is: the lowest amount of code that still accomplishes the goal and is still readable is preferred. Linux apparently has 40M lines of code, and I bet most of it is better than mine. Some things just take lots of code.
Which seems to leave room for these agent salesmen to pitch SLoC as a plus. We just have to believe those lines are all good ones. I that case, it would be impressive. I don’t believe it, but they are probably pitching to people who do.
> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right?
No, it's the perspective of a programmer who wants the project to not be bogged down too much in technical debt so every change gets slower and slower to implement, as everything gets more intermingled. A clean design helps you move faster for a long time, compared to a design that is fast to implement but makes it hard to move forward properly in the future, without resorting to shortcuts and/or hacks.
> Some things just take lots of code.
True. Rich Hickey does a good job differentiating between what's complicated because the domain is complicated, VS what's complicated because the implementation just ended up that way, even though with some more thought and design, could have been made a lot simpler.
> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.
I think it is (or should be) a goal & business-oriented concern as well, not just an engineer's who enjoys their craft.
More complex systems are worse than simpler systems (that accomplish the same), in cost, maintenance, fragility, ease of understanding, etc. Fewer moving parts usually result in higher reliability, fewer things that can break down or fail to interact properly, etc. That's a business concern too, not just engineering craftmanship or whatever. Business people should care about this too.
I don't think this is the same as bikeshedding over irrelevant details, something we software engineers are often prone to. Monstrous complexity does impact the business!
It's like we've all forgotten what technical debt means. We just say the phrase, but we have forgotten that it is analogous to actual debt. Every line of code produced should be treated as a liability to the company, like a bond they issued that they have to pay interest on in the future. You only take on the liability if it produces more business value than it costs to maintain. The goal is not to issue as many bonds as you possibly can.
Less is better is the position of the engineer who has seen some shit and whose career lived to tell about it.
I had an MoM at Stripe who pushed back on perf designations based on number of PRs.
I wish I were joking.
(The had never been an engineer.)
It's a signal. It's not a strong signal, and you certainly should not base your entire perf on it, but if the number is unusually high or low, it's a signal that could warrant further investigation.
(I once worked with an engineer that had two PRs, both fairly small bug fixes, in a given calendar year, and when I looked more carefully, they did not have any other obvious output or impact.)
Strongly agreed. It is a signal. I did an analysis once at the end of the year. Work group of about 45 engineers. The CM system had a lot of steps, and work could get bounced around, but there was a step where some one "resolved" a software activity. Bug fix or new requirements, it did not matter. This step was when someone actually completed work and put into into the dev stream.
A quick DB query and the variance was substantial. A couple of people had over a hundred. About 10 had 2. For the year. The ramp up was slow, average was 8 to 10 a year.
Dig a little deeper. Those at the top were 'group leads' not only did they do IC work, they also got stuck with all 'paperwork' on the problem work packages. They had 'power', so they could override various things. So, they were doing a lot of work, and taking care of things. Good signal, matches what one would expect.
Those at the bottom. One of them had effectively been a 'systems engineer'; all of their time was working on requirements with the customer, making powerpoint, etc. Important work, so that signal was inverse of what it originally showed.
A couple were in the middle that had great reputations for technical expertise. They were spending almost full time in training / mentoring / very hard problems mode. Highly valuable, but not shown by looking at these numbers.
All the rest? 80% of the work was being done by 20% of the people. We could have dropped about 12 heads and barely noticed.
The problem is, you could not take action on this measure. It gave you a place to start, but you needed to know more about what was going on day to day.
Let's measure "executive performance" by counting how many "answered phone calls" per hour they have. If they don't answer enough calls, that's a signal, that they aren't doing anything useful, and should be depreciated as a result.
Trying to parse your sentence, which is ambiguous...
You're saying that the manager-of-managers would argue that the number of PRs should affect perf ratings? Or the MoM would push back against the line managers who were giving ratings based on # of PRs?
They were reviewing perf designations, then pulling up PR count, then arguing against designation based on the number of PRs opened.
That still doesn't clarify: were they saying "many PRs→good" or "many PRs→bad" or "number of PRs is irrelevant" or...?
That PRs == impact.
I think the reliability struggles of Github may have helped with this
I can't help but wonder if the causation is backwards here and the millions of lines of slop had more to do with the Github struggles than the reverse
In reality yes, and probably a complex mixture of things. Dedicated time and resources being siphoned off for Llm work, etc
I also think starting to migrate to Azure just as their traffic/usage exploded from LLM use (plus I assume merging a bunch of poorly written early-gen LLM code as early adopter dog fooding) was poor planning by Github/Microsoft.
> I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to
Did those engineers not actually read the complete tweet? Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work". Which doesn't seem like satire at all..? It just means "develop mostly reliable AI-driven refactoring tools with good guard rails". Which seems quite sensible, actually?
> Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work".
Making a grand claim of a goal and not really having an explanation on how to achieve it isn't really much better. I could say "we want to scale food production so that one farmer could manage a million acres of corn a month", but that wouldn't really be sensible. A line of code is less work than an acre of corn of course, but I don't think it's at all apparent what upper bound for how much code is actually plausible for a single engineer to generate in a month and have any degree of confidence in. Given the absurd levels of hype around AI from non-engineering management in the past couple of years, it's not clear why the benefit of the doubt is earned here when there legitimate are managers and executives claiming pretty much exactly what you're claiming this guy wasn't.
I don't care - porting the current architecture - with all the known I wish I had done this differently's - doesn't gain much. See some developers I've worked with who love Rust for "safety", even though they just put everything in unsafe at the first sign of trouble instead of thinking about how this should work safely.
Porting to a new language is easy, but does nothing useful. What we need is to fix the mistakes of the past so we can get to the future. We need to make acceptable performance.
Minor correction: LinkedIn, not twitter. https://www.linkedin.com/posts/galenh_principal-software-eng...
> Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work"
These are one and the same. Whether it's ported code or not doesn't change that. The framing device also doesn't matter, because it's the exact "Oh it's our goal" shtick that executives use in the former's case.
"It's just a measure" doesn't cut it in a world where every single AI measure immediately gets turned into a target by executives greedy for efficiencies that don't exist.
EDIT:
Right, I forgot. This is HN where everyone is a galaxybrain and "Port a million lines of code per month" is a totally reasonable goal for a single individual.
I can easily game writing 1M LOC per month by having the LLM write code in more verbose ways, with useless indirections and abstractions thrown in for good measure. I could even ask claude to write code that does nothing but just takes up line.
In contrast, converting 1M LOC of code per month is a much more solid measure, as long as you measure LOC of the source, not the new code. Sure, in the short term you can pick the easy/verbose things to port, but it's hard to do sustainably. A 5M LOC code base would still be expected to be ported in 5 engineer months.
Granted, you can still rush the work, not test properly, neglect good planning and engineering. Ported lines of code should not be the only measure (just like with any other measure). But it's a much less problematic measure than coding 1M LOC
> Granted, you can still rush the work, not test properly, neglect good planning and engineering.
Which is the core point of my reply and not something to just be casually handwaved, thank you very much.
If everything in the initial code is 300% covered with excellently documented tests that should be minimally changed during transition (if transition don’t reveal any corner case tests were missing, maybe the transition is not such a bright move after all), that seems a possible thing to consider.
Otherwise it really sounds like a recipe for unnecessary huge risk with dubious expected positive outcome.
Not saying don’t have fun, but on the other side maybe not with the core product of you cash cow already?
> "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work". Which doesn't seem like satire at all..?
Because many programmers don't believe that'd work. See the reaction to Bun's porting to rust. (I bet Bun will work and prove those programmers wrong, but that's another story.)
It's not unmaintainable if you have 1000 agents maintain it.
It is unmaintainable even if you spend 100k per month on tokens to have LLMs pretend they are maintaining it, if they slow down and make little ACTUAL progress. Sadly real progress is impossible to measure, if all you have is an overexcited """engineer""", a credit card, and so much cash spent you could hire all the best engineers you know and still have money for a porsche.
Well, software presumably has a goal of accomplishing something for some end-user, so the progress should be trivial to measure: are features/changes being completed?
The marketing ploys of OpenAI/Anthropic where agents build something that nobody uses might be hard to track given that there are zero users. But what about everyone using agents for real software? It's trivial to prove that agents make progress.
Yes that is the entire point. Measure features deployed in production and their value in gaining and retaining customers or users, cost reductions, reduced incidents and outages, etc.
Lines of code is completely irrelevant as a metric.
It's not unmaintainable if most of it is tests. Just have it write tests until it becomes safe for AI.
I hate I can't tell if you're joking without checking posting history lol
…and then the CEO sees the token bill…
All else being equal, and assuming you are building the right thing, being able to deliver more correct lines of code is a good thing. The question is how to do it reliably, given that a human cannot possibly read all of it. The answer seems to me to involve spot checks with proofs of correctness and statistical quality control, the latter being things that can be automated. One issue I see is that the models are constantly changing and are therefore not well understood statistically.
If you are generating that many lines of code it’s also almost impossible to tell if you’re building the right thing. You need to deploy each functional change and measure if it’s giving you the expected outcome, before moving onto the next thing.
>All else being equal, and assuming you are building the right thing, being able to deliver more correct lines of code is a good thing.
Why? If you can deliver the same thing in fewer correct lines of code wouldn't that be preferable? At a bare minimum if you're still insisting on using AI to slop out your project, having it do things in fewer lines of code means you can fit more into your LLM's context window.
> If you can deliver the same thing in fewer correct lines of code
it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.
Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?
Without looking at the details, I expect that each network protocol has a checksum of some form, and there are likely a lot less than N different checksum algorithms. Similarly I expect several will have encryption - using one of a few standard algorithms (if any doesn't use a standard algorithm you have a strong case to say not supported). I also expect that there is a lot of protocol parsing - this can be done as custom hand coded for each, or using a parsing framework (and likely there are some places of generic code in between).
Parent said "I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N."
You're arguing the inverse: that at least some parts of the code are independent of N. Sure. But the topic is the part that isn't.
This is still not an argument for more lines of code. It demonstrates that lines of code are positively correlated with number of features, yes. But that's like saying the number of nails scales with the size of a house. More nails does not create more house.
Then you simply produce those fewer lines of code even faster. The question is, how fast are you delivering correct code?
Moreover, writing too terse code harms readability and maintainability. There is such a thing as irreducible complexity.
> When a company says “AI made everyone more productive, so we need fewer people”, I want to see the evidence - and I don’t believe it exists today.
Because they're bullshitting and using AI as an excuse to correct from their covid era over-hiring while simultaneously making themselves look good to investors by showing they're embracing the hip new technologies to become a more streamlined and cost-efficient operation than ever.
> while simultaneously making themselves look good to investors by showing they're embracing the hip new technologies to become a more streamlined and cost-efficient operation than ever.
This is not anything new... It just has a new name...
> covid era over-hiring
That's a generous excuse. To me it looks like they're just trying to depress wages across the board. Given that _several_ rounds of layoffs have occured since then, this 6 year old excuse rings particularly hollow.
> investors by showing they're embracing the hip new technologies
I thought investors cared about returns.
> to become a more streamlined and cost-efficient operation than ever.
And a completely uncompetetive one as well. "We're using the same whizz bang technology that any idiot in their bedroom can use!"
It is endlessly... amusing (?) to me, that we as a community spent decades trying to make it clear that our productivity is not easily measured because what we're doing is complicated and long running, only for AI to come along and suddenly LoC, Nx multipliers, tickets / week etc are held up as useful if not objective measurements.
The reasons we rejected LoC and other measurements have not changed (broadly: code output isn't important, quality output is). AI has all the same problems people do. But for whatever reason we are throwing what we've learnt away. It's kind of embarrassing.
The non-technical people are in charge and they're not tethered to reality in the same way that engineers are. Objective reality will win in the end, but that doesn't prevent damage being done in the short term.
IDK, I do think a lot of it is LLMs enable people who were not in our community to come into it (in an eternal september kind of way) and they are going through all this from first principals and ignoring their elders, but I've also seen technical people suddenly measuring themselves this way. The most optimistic read of this is that they _feel_ productive, and that feels nice, and they want to share how that feels, and so they are reaching for these garbage metrics because they have nothing else.
> The most optimistic read of this is that they _feel_ productive
In addition to "feel productive", two other feels I think are flying under the radar:
1. You get a parasocial relationship with a "friend" (or at least conversation partner) who seems to "understand" you.
2. You get some form of gambling entertainment when you pull the lever and the output keeps landing on different sides of the jackpot you want.
While #2 has some overlap with classic creative struggle, I think it can at least be seen as a kind of junk-food verson, where the frequency is different and the health-promoting parts aren't present.
>we as a community spent decades trying to make it clear that our productivity is not easily measured
Did we? All I saw the last decade was increasing worship of the Github activity grid, from both engineers and non-engineers. IMHO the bazaar had already lost its way before this.
I had seen, up until LLMs, posts in this theme: https://dannorth.net/blog/the-worst-programmer/ pretty regularly. This one was only a few years ago!
Maybe we run in different circles. Or did, anyway.
Maybe a particular group of software engineer cultivated the need for careful measures. But the programming field never escaped the idea of simple metrics.
That's because you would always have loosely involved but aggressive and demanding bosses (there is unfortunately an economic value to the boss whose primary task is forcing more effort out of the employee and who doesn't help coordination or anything else). So at best you had two intersecting clouds of approaches with actual accomplishment intersecting with LoC and related measurements.
The thing AI is that it provides all the tools to satisfy that loosely involved but demanding boss. So suddenly you are going to have a larger demographic of people who like LoC and feature-additions as metrics 'cause now they are easy.
All that to shill slop machines so the billionaire class can throw people out on the street.
If your A+ senior developer spends 8 months working on a feature that ultimately doesn’t get shipped or a MVP that gets killed, then you wasted that A+ senior developer and their productivity was the same as the other two B+ engineers that also worked on the project. This is actually a very common issue and usually ignored when it comes to things like hiring or assigning resources to a project. AI won’t change that in a meaningful way, your team may just finish their tasks a lot faster but the bureaucratic layer above will likely remain the same, which will make any AI coding gains negligible. Companies would have to be rebuilt from the top down for AI and that’s very unlikely to happen.
I think engineers tend to over index on this kind of thing being "waste". You didn't waste that investment, you paid for the option to ship that feature or MVP and the research into the question of whether it made sense to ship it.
That's cool but don't get heart broken when engineers leave after repeatedly being told the thing they worked on for months wont ship because someone at the top said so.
Not really? If those are people I'm close with, I try to express this perspective to them in 1:1s that things that don't end up shipping are not a waste for the reasons I expressed here. And most of those people (because they are simpatico with me, which is why we're close) tend to see it the same way I do, and not leave because of this. And if they do leave for this reason, I conclude, well, they just weren't really aligned with me on this particular perspective. And that's a bummer, but not everyone is gonna see things the way I do.
put simpler, you learned what not to build.
It's definitely that, which is very valuable, but it's also the optionality value additionally. You had the option to launch the thing, which you wouldn't have had if you had never worked on it at all. It's notoriously difficult to properly value optionality, but it definitely has value, and often a lot of value.
sorry, but this just sounds like a rationalisation for "we built the wrong thing".
we should just be straightforward, say "we built the wrong thing" and then ask how we built the right-er thing.
No, optionality very literally has value. If I buy an option to purchase some commodities at some price, and the market moves against me, I lose the price of the option. By your logic here, the thought should be "buying the option was wrong, because it didn't go my way and I lost the price of the option". But it's often the case that actually buying that option was a good move.
The kind of optionality I'm talking about in software projects is not so clean to account as the financial instrument, but it has real value in just the same way.
see my reply further down the thread https://news.ycombinator.com/item?id=48503075
> sorry, but this just sounds like a rationalisation for "we built the wrong thing".
If it were so easy to decide what the right thing is to build before you build it then business would be easy.
That's the whole reason options have value. Having 3 shippable products ready to go when you can only effectively ship 1 puts the whole team in a much better position than choosing 1, focusing everyone on it, and hoping you hit the lottery with product-market fit.
So yes, an engineer may work on something that doesn't ship. That doesn't retroactively make their effort worthless, and that's not even counting the experience gained by the endeavor which may well pay off on the next round of products to ship.
> If it were so easy to decide what the right thing is to build before you build it then business would be easy.
It's not easy. That's why it's important to be straightforward and just move on without all the navel gazing.
> ... hoping you hit the lottery with product-market fit.
There's this thing called "research" where you talk to real people, instead of guessing.
> That doesn't retroactively make their effort worthless
No-one said building the wrong thing was worthless. Life is one continuous mistake.
---
we are saying mostly the same thing i'm pretty sure, especially in your other comment reply (https://news.ycombinator.com/item?id=48498912). although i feel you're dressing it up a little too much for my liking. i prefer being a lot more plain and direct about it (and probably a bit arsey).
ruthlessness is an asset when it comes to we built the wrong thing. ruthlessness gets us moving on faster.
I don't understand why you interpret "we should recognize that it's worth paying for optionality and sometimes we decide not to exercise the option and that's normal and fine" as naval gazing. I think it's the opposite, that feeling butt hurt about the projects you work on not shipping is what is naval gazing.
To me all your "I prefer being plain and direct" just sounds like someone who hasn't thought much about why building the wrong thing is not worthless, and why those continuous mistakes in life are worthwhile, and isn't really interested in thinking about things at more than the surface level.
It does seem like you aren't really disagreeing with us here. But you're just saying "don't make me think about why we agree about this!"
> It does seem like you aren't really disagreeing with us here.
I'm not.
> But you're just saying "don't make me think about why we agree about this!"
My position is that you're overcomplicating it with business doublespeak.
----
edit
> someone who hasn't thought much about why building the wrong thing is not worthless, and why those continuous mistakes in life are worthwhile, and isn't really interested in thinking about things at more than the surface level.
I have just spent the last two years writing over a thousand pages of very heavy introspective stuff about a bunch of stuff i've done, and things that have happened to me, over the last thirty years.
"surface level" is most definitely not the person you're speaking to.
Yes I understand that. The tendency of engineers to willfully refuse to understand what's going on in their businesses and scoff at the things they are refusing to understand by dismissing them as "overcomplicated" and "business doublespeak" is what my comment that started this thread was about.
Did you see the part in my big story time comment where i convinced the ceo his business strategy was wrong? do you think i did that with a flippant and dismissive comment?
https://news.ycombinator.com/item?id=48497153
i get the sense that you think i'm "one of those engineers". I am not.
Shouldn't companies figure this out before wasting tens of millions in budget + working hours? All I'm reading is that corporations are not taxed enough if they are okay with such opulent waste.
Story time. small business. less than 30 people.
ceo had invested £1 million to build a data analytics platform. "democratising data analytics" in a very specific domain. essentially, competing with someone like databricks in a niche. although they had never heard of databricks before i showed up.
For that million pounds they got a job scheduler written in pure django with a halfway finished react frontend. the whole thing was constantly broken. there were multiple race conditions throughout the product. i joined well after the million pounds was all gone. three years after i joined i had fixed the worst of the problems by rewriting massive swathes of the thing.
i eventually convinced the ceo they'd been doing the wrong thing all this time -- they should focus on analytics + specific domain consultancy services instead of software products.
the major failure was no-one ever moved on from idea V1. they never moved to idea V2. which meant they never got to idea V3. instead, everyone spent a hell of a lot of time talking about how great V1 was going to be, and how they planned to build V1 and what V1 would look like, check out this status update about our progress on V1, check out this mock up on what V1 is going to look like etc. they had an agile consultant come in to tell them how to be more agile. a scrum-master to tell them how to scrum.
3 months after joining was the first time i mentioned apache airflow. they literally could have just stuck a nice frontend on top of it and written a backend data transfer library. job done. very cheap idea V1. unfortunately, the previous team of django developers could only see their trusty django hammer. edit -- and i should add their big £1 million budget too.
multiply the budget by 10x or more. exact same thing at some big corpo. bigger budget = room for more bullshit.
Yes, thanks for the story. This is what I was trying to say. The idea that it's completely okay for companies to misallocate billions of dollars across the industry while people are legitimately suffering do to myriad of reasons is just bonkers level of selfishness.
I worked at a company that had an $80,000 monthly AWS spend when the total users in question was less than 100,000. The most concurrent users was <500.
This obscene waste actually isn't health for society nor the economy.
Ah I see the point you're making now. Yes, sometimes (often) businesses make very bad decisions.
But that doesn't imply that every project that does not ship was a poor investment of time and resources.
Software engineering projects expand to fill the deadlines you set for them (usually going over). Same thing for budget. You'll waste a bunch of a million pound budget. People are forced to get creative and thrifty with a £20k budget.
constraints can be useful https://en.wikipedia.org/wiki/Oblique_Strategies
> The idea that it's completely okay for companies to misallocate billions of dollars across the industry while people are legitimately suffering do to myriad of reasons is just bonkers level of selfishness.
Yes. The metaverse bullshit comes to mind. Something no-one wanted or needed, and exorbitant amounts of money spent on it.
Knowing what to build (and that it hasn't already been built or bought elsewhere in the company) requires bits of information / person-to-person networking / visibility into the state of the company that not all managers or VPs have.
In fact, most people don't have that knowledge, because they're busy with existing or "local" problems , or because they didn't know to ask Davis the DBA or Kris the Kafka Cluster Manger or Alex from accounting if we have <resource> our team can plug into and use. "Oh, yeah, El has one under their desk they kick occasionally, ask them to hook you up!"
If you solve this problem in a turnkey way Fortune 500 companies will write you very large checks to help them prevent such duplicate waste, and will in turn become the 15th system they need to integrate....
That XKCD joke about "how 14 standards becomes 15 standards" also applies to the class of "one system to integrate with and report from all other systems"
No. This is like saying "shouldn't scientists figure this out before wasting tons of money running experiments?".
Not the same. Every corporation I've worked at (several dozen in my career across the F500) has had numerous stories about obscene waste in regards to building things in software.
Waste at all levels. I've worked at insurance companies that spent $100million on development where only 200 customers signed up (estimated to be 20,000 at start). I've worked at telecoms that spent $25 million developing internal tools that no one used. I've worked at big tech where entire teams sole purpose is to control a single widget on a UI page.
This isn't even on the procurement side. Recently left a company where a single org was paying $10,000 a month on licenses when only 12 devs existed. I've seen organizations waste tens of millions of salesforce licenses that no one uses.
I'm sorry but the waste is rampant. SMB's can afford to waste tens of millions of failures, but modern US corporations can because there is no real competition in US markets. Just monopolies abusing each other.
I'm sure scientists would love the chance to have stupid budgets and make stupid things.
So no not the same at all.
It is true that businesses tend to have more money than scientists so the numbers are bigger, but scientists pursue failed experiments that are "waste" in just this same way.
"It only got 200 users" is the business version of the null hypothesis.
> $10,000 a month on licenses when only 12 devs existed
Depend, depending on the licenses in question, this could be a fantastic deal
Thought I wrote it, but this was for Postman (yes the GUI curl software).
Nobody can perfectly predict the future.
So it's best to throw billions of dollars down the drain?
No, it's best to manage your software delivery organization to reduce the cost and time of experiments so that you can quickly and cheaply figure out what to build... and then build that.
But there will still necessarily be things that you build that don't ship, and that's inherent to the problem domain.
Best to shelve something and not ship it once you know it won’t work, than to continue to throw even more money down the whole after it.
> spends 8 months working on a feature
Are you sure those 8 months is not being spent on just “coding”? There’s design, product team input and iteration, etc. Where did you see that an A+ engineer goes into a cubicle and come X months after with an MVP in isolation?
Weird baseless push for AI on the end, with no reasoning, no goal, no claim of gain. "Just go and use AI, people, developers must adopt new things."
It's not the first article I've read recently that is an ad for AI after a short context pretending to criticize it, with nothing connecting them.
AI is the new cloud. There's no market for people or companies who aren't committed to it. If you're a dev who refuses to use AI, no company will hire you; and should a company decide not to use AI they will have a hard time retaining devs (and they will need more devs). Their investors and big-ticket customers will also think twice before signing off on major commitments.
So yes, use AI. Don't nitpick the costs and benefits. The world is headed this way; if you want to develop software for a living and afford to eat, you need to be too.
> and should a company decide not to use AI they will have a hard time retaining devs (and they will need more devs)
Need more devs? Why? If a company was being profitable just fine prio AI era, they will still be profitable if they decide not to use AI. Shipping crap faster is not a formula for success. Shipping quality faster? I prefer shipping quality at a good pace
youll be outcompeted by companies that do use it (caveat: effectively)
growth is much more important than profitability
Will you though? I see this repeated, but I’ve almost never changed products because one has 10x more features than another.
I usually buy and use products that are simple and effective, and that get out of my way to do the thing that I want to do.
For email, I’m a happy customer of Fastmail and I’ve been paying them for years. I don’t care if they ever release a new feature and I’d never switch away from them to a competitor that’s less stable but does more. They release improvements slowly but they are very stable. But I would switch away from them if they start shoving AI into things or delivering subpar features that make my email worse.
For healthcare related websites, I can already see my test results, schedule appointments, and communicate with my doctor. What more could an AI-driven medical platform give me that makes my life better?
For maps — I unfortunately had to move away from Apple recently when they added Ads. So I’m mostly just using OpenStreetMaps. I could see AI improving the OSM functionality by updating the app (OrganicMaps) routing algorithms and such, so there is room for growth there, but it’s not that massive.
Can anyone offer features that Uber can’t now due to LLMs? There are a bunch of local Uber competitors but uber wins because it’s easy and there aren’t major features to differentiate there.
Do you have examples that prove that delivering a bunch of features really fast is going to steal customers from something?
Well this is a different argument, that we really don’t need very much new software because so much of what was needed is already written.
I’m sympathetic to this argument. But it’s orthogonal to the AI question.
your personal experience is clearly in the techie bubble
ai is more than delivering features fast (thats probably one of the lowest priorities for companies)
right now its a race to automate work, especially back office. companies already are seeing 10M+ in savings and revenue growth and we're barely starting. workflows in sales, outbound, gtm, marketing, eng, operations, compliance, kyc etc
consumer is a different beast, consumers want convenience which has already been hyperoptimized and the big consumer cos run on network effs instead of features
> right now its a race to automate work, especially back office. companies already are seeing 10M+ in savings and revenue growth
What? Where? Citations please. We're seeing big companies massively stall in all traditional sectors except AI which is a irrational market built off hype.
ai companies know how to use the tools internally, not surprising
there are no citations yet because this is going on behind closed doors, if you know you know. we'll start seeing it in the financials of companies soon. alternatively you can look at the revenue growth of applied ai companies
“Trust me, bro”
applied ai company revenues are semi public
some are even profitable!
everything else is free alpha, do with that what you want
Enjoy getting your milkshake drunk by AI-first companies then.
It's much more than that. There's plenty of market for people and companies who don't specialise in cloud software. The market for programmers who don't use AI is going to be more like the market for programmers who don't use compilers.
> So yes, use AI. Don't nitpick the costs and benefits. The world is headed this way; if you want to develop software for a living and afford to eat, you need to be too.
It's really saddening to see software engineers throw out all critical thinking and innovation out the window to behave like sheep and follow the trend line. The industry was trailblazed by people that refused to do just that and the same is going to be true in the future.
Yes but most people aren’t trailblazers, they’re horribly average and just want to get by. This includes me.
This industry is hostile. You need a self preservationist mindset if you want long term success. Or, at least, it feels that was for someone who isn’t absurdly talented, wealthy, or connected. So, for now, we put our head down and be good little cogs.
I think of it this way. In a company with a good culture, I will build a rapport with my management and give my honest opinions. In a company with a bad culture, I just nod along and say “uh huh yeah yes sir what a great idea!” Because I know that’s it’s gonna get pushed through no matter what I say, and my opinions will only serve to hurt me.
And, right now, tech, or even America, is like one big company with a rotten, rotten culture.
Are you saying productivity is strictly greater for developers who don’t use AI?
AI makes people think they are being productive, but in reality is a drain on productivity.
That METR study was retracted, dude.
Or, don’t. Do what you want, don’t listen to random people on the internet telling you what to do.
Oh come on, the value of AI > 0. That’s not a controversial take.
Maybe. The value of leaning Linux and basic shell tools is > 0 but a lot of devs do fine without.
My take is that “$EDITOR fluency” >> AI.
>The difference this time is pace: you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.
It is weird that the author seems to understand that the pro-AI claims made by AI companies about the product’s necessity are not falsifiable, but then backtracks with “woah woah woah but don’t think I’m anti-AI.”
How is the assertion above any more rigorous than the productivity claims the author is criticizing throughout the rest of the article? That you won’t “survive” if you don’t adopt AI within a few months?
It is not true when the AI CEO says it, and it is not true when the person calling BS on the AI CEO… for some reason also says it…
When the AI CEO says it, its because stock go brrr. I never believed that AI CEOs because they're making unverifiable claims that they never backed up, claiming you're firing people because of AI is so open for interpretation, and it shifts blame from you to the AI, reality is we should not blame AI for something a CEO did, you could have re-trained employees for AI, but you didn't why not? Maybe because it's not about AI is it?
He is talking about the cultural considerations of being hire-able. Not about productivity.
Hey, author here. Fair criticism (and thanks for reading!). What I was reaching for with the "few months" claim wasn't about company-survival, rather individual practice. I didn't make that clear enough (I actually did write this, not "AI-slop it" as some elsewhere have suggested, so maybe I got "human-sloppy" by the end).
You're right that I don't back up the "woah woah woah" bit with any evidence, but I do stand by the sentiment that I think people should use AI; experiment, find the ways it can help you (I've found that there's a huge spectrum even among similar engineers, in terms of how they get value from it). Trying the tools properly costs you almost nothing, and "adopt deliberately, measure with the boring battle-tested stuff" is not the same position as "adopt or die".
> It is not true when the AI CEO says it, and it is not true when the person calling BS on the AI CEO… for some reason also says it…
People do take into account the motivations behind what someone says and to me the motivations here seem different enough to make some difference here. The AI CEO has an obvious motivation to lie, but the person calling BS doesn't have such a clear motive...
>When a company says “AI made everyone more productive, so we need fewer people”,
They are implicitly saying that as a company, they don't want to be more productive. They want the same productivity by paying fewer more productive people.
Why is there an imbalance between what an employer gets paid for a unit of production and what an employee gets paid for a unit of production?
> Why is there an imbalance between what an employer gets paid for a unit of production and what an employee gets paid for a unit of production?
Because labor gets exploited to make the owners richer. That's the basic fact, even though the owners (as a class) have financed a lot of propaganda to justify and obscure it.
> Because labor gets exploited to make the owners richer
Only a person who never tried to organize labor into a company could ever have such a couch-sitter opinion
Honestly expanding this point for the joy of debating.
Granted, grandparent comment used _charged_ words. Let's rephrase: labor is used to ultimately provide owners more money than they put in.
Is that not a fair assesment of the real world? Who starts a company to lose money? Who starts a company solely for "creating jobs"?
What exactly is the beef with grandparent comment? Is it just the negatively charged words? It's the rephrased version beef-inducing as well?
> Let's rephrase: labor is used to ultimately provide owners more money than they put in.
I'd rephrase that: labor is used to provide the owners the maximum amount of money they can manage to extract from the people doing the labor.
A technology 10x's worker productivity? That means 9x more goes to the owners, and 0x (zero) more goes to the workers. Maybe the workers get even less, because now you can fire some.
> Who starts a company to lose money? Who starts a company solely for "creating jobs"?
A more equitable distribution of company profits does not imply the company loses money. It does not imply useless make-work jobs.
> A more equitable distribution of company profits does not imply the company loses money. It does not imply useless make-work jobs.
I fully agree, and remind you it's completely legal and simple for you to go and start a company that does equitable distribution of company profits. More people should do it instead of complaining that few people do.
Nobody does it because the incentives make it impossible. If you do this, then you just lose. Because everyone else will be doing it, so you’ll get pushed out.
Think of it this way: if slavery was legal, would anyone be running a fair labor farm? Maybe, for like a week, before they’re out of business.
Or, consider this: at any point in time, any of the tobacco company could have made nicotine-free cigarettes. But they never did. Why not? Because it’s a fundamentally impossible position to hold.
Now, this is very reductive, I admit. There is a niche for appealing to people’s conscience. But that niche is a luxury, and luxury goods don’t perform well in a tight economy. And, luxury goods will never have the breadth of the staples.
> I...remind you it's completely legal and simple for you to go and start a company that does equitable distribution of company profits. More people should do it instead of complaining that few people do.
No. Instead of doing that, the effort should go into making all companies act that way.
IMHO, what you just did is part-and-parcel of one angle of the "propaganda to justify and obscure it" that I referred to above (e.g. "Don't like it? Then I say your only response should be this ineffective and limited-scope action I specify that strictly adheres to the status-quo").
And it would be ineffective. Building a little oasis in the middle of the status quo would only help a few and is unlikely to resist the tendency of things to eventually revert to the mean. The mean needs to change, and the best path to that is probably through regulation, other kinds of social standards-setting, and increasing the power of the exploited groups (e.g. through unionization).
> They want the same productivity by paying fewer more productive people.
I believe you mean same output but fewer people? But by definition that would be higher company productivity, as the definition of productivity at the company and/or national level is the ratio of outputs to inputs. If you have fewer people but are getting the same output, then the productivity of the company (or nation) has improved.
If you had fewer people but the same productivity then there would be no benefit to the company as the outputs would correspondingly be reduced (and it may actually be worse for the company if the company has any fixed costs).
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
I don't see LOC as that different from number of hours in the office. They'd always say pre-pandemic "If they're not in the office, how will I know they're working?" Simple, use the output metrics that you use to evaluate all of your workers to see what they contribute to the business.
I largely think that we engineers are to blame for LoC being still perceived as an asset rather than a liability. We are proud of stuff we create, but it turns out that you can't describe how "big" something is without some metric, and so we fall back on the metric that is easiest to compute.
Suggestion: we should all shift our terminology, and in particular make heavy use of phrase "...and it cost N lines of code". And say what we spent those LoC on.
"I implemented new feature X, and it only cost 200 lines!"
"That bug was brutal to figure out, but in the end it only cost 6 lines of code."
"It was doing something in case X that it didn't do in case Y, and it turns out that the distinction wasn't even needed. So I fixed the problem and saved 20 lines of code at the same time!"
Lines of code are a price you pay. We don't go around bragging about how we spent $200 without any mention of what we purchased with that money. Why do we do that with LoC? "I had to pay an extra $200 because I signed up late" and "I only paid $200 for my hand-painted artisanal pottery lamp hanger. Factory-made ones cost upward of $1200 on Amazon!" are two very different statements, and map to exactly the same distinction in code.
Anecdotally, coworkers are writing a LOT more unit tests. By which I mean NOBODY is writing unit tests, but Claude is generating a ton of em. We’re talkin 300 lines of unit tests for 20 line changes that are already covered by other, better kinds of tests. Huge JSON objects of test data that we already have generators for, etc
> but Claude is generating a ton of em. We’re talkin 300 lines of unit tests
Of course - it is setting itself up for more token consumption later: when a small change is needed, it may have to parse/adjust 10,000s or 100,000s lines of test data / code...
A sensible senior developer would recognise the shackle that huge brittle tests suits can become and correct course. But this is against Anthropic's business strategy
I kinda feel as if this was the money quote:
> If you got a free headcount increase essentially overnight, why wouldn’t you use it to deliver more value to your customers, faster?
That shows that, in reality, it's short-sighted profit-taking. Boss just wants another lambo in the garage, and doesn't really plan to be around, when it's time to pay the piper.
Also means they don’t have any ideas for how to grow revenue.
More that LoC is a simple metric that has always been a problem.
Non-Functional requirements is a vestigial term from ‘function point analysis’ which is from the late 70s, and which also ended up being a proxy for LoC.
The entire industry is so focused on measuring now, and incentives are so skewed to short term that lagging indicators like maintainability are a non starter in many organizations that it will be challenging to fix this time.
Which kind of sucks, when you emphasize and steer the agent(s) to more optimal solutions with less complexity and code.
This is already changing again now that CEOs have wised up to the fact that they're paying for code by the line but these lines don't translate to profit.
Yep, pendulum swung one way, now swinging back the other. No different than any other hype cycle.
Not enough people read The Goal.
Ugh. Just imagine the following on a normal curve:
Pre-AI: The goal is to make more money.
With-AI: The goal is to ship more code.
Post-AI: The goal is to make more money.
Can't wait to see how we get there...
It seems to naturally follow that a company that sells lines of code would want to measure success in lines of code.
> I’ve watched this industry absorb higher-level languages, IDEs, autocomplete, agile and devops, and there were always crusty hold-outs reminiscing about the good old days before X came along and ruined everything.
But all of those things were consciously built, deterministic and transparent tools. LLMs/AI are something fundamentally different.
yes it does seem fundamentally different. Most claims about AI are unmeasured marketing and favoritism. Similar to how management wants you to use eclipse or codeblocks to a developer that uses Emacs skillfully because it is shiny and new and they don't understand the requirements of the developer.
I think a better metric these days is what percentage of code is not reviewed / understood by humans. That is the real bottleneck. Until we can stop looking at the code, AI barely matters - you are just trading quality for quantity.
Thats why it is so amazing for speed runs and prototypes. Here it is legitimately > 10X faster.
You need to retrain managers from seeing a prototype and thinking "yep, ship it" and over to "okay, how do we build this properly?" And I don't think that's gonna happen.
We're still in the FA phase of FAFO when it comes to LLM code generation, aren't we?
What happened was the audience changed. Before, the audience for things about writing code was mostly software developers. Now it's the employing class. The collective wisdom of engineers? It has little impact on the conversation because the audience doesn't care. In fact, it's more than indifference; many are eager to no longer be "burdened" by it.
Not only do they not want to pay our salaries, which is an expense, they're eager not to have to depend on our expertise or judgement as well. That judgement and expertise is a locus of control that resides outside their own hierarchy.
The paradigm used to be create good enough abstractions you can express what you need in a few dozen lines or whatever. Those lines will be clearer and more precise than English for describing what it does.
I wonder if we'll ever get back to that? If it's still relevant?
I think LLMs will make vertical slice architecture more common using less abstraction. If juniors are mostly relying on LLMs then they will accept the long files it generates and not have the opportunity to learn abstractions.
It is pretty funny how this whole industry in a very short amount of time, with tons of experience and knowledge to lean on, reverted back to dubious measurements of productivity. If you track LoC and tokens used as productivity measurements, developers are going to max their LoC and token usage! Its so predictable that we have a Law named after this phenomenon! The fallout was so predictable I feel like I should have been positioning myself for all of the potential consulting work that's about to be needed.
This is the way. If the C-suite idiocy is inevitable, as I believe it is, the more moral thing to do is to take advantage of such idiocy.
> Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
https://www.goodreads.com/quotes/536587-measuring-programmin...
If developers burn through thousands in AI tokens a day, does it really matter, and is it a good spend? Are the outputs actually checked for sanity, fitness, qa/qc, security etc. How much rework is coming out because of lack of validation, or too much automation in the soup.
The more I read, the more I feel that 1 dev, 1 ai agent with the dev as a gatekeeper is probably the most appropriate workflow. Where you now treat the single dev + ai as a team in terms of planning and cost analysis and you get about 1.2-1.3x the throughput compared to a traditional team of 3-5 devs with partial PM and partial QA where the Dev now needs to take on those roles too.
The output should include more/better testing, examples, demos etc... since the bus factor is now 1, but AI is expected to be able to do the heavy lift.
Not a better publicist, but:
A) a newly-receptive audience - engineers who have discovered that they very much enjoy and appreciate the tradeoff of proximity to the code for amplified velocity and impact, now that it's possible to achieve without being a manager of messy human teams.
B) an ecosystem in which it's grown nearly impossible to connect a functional description of something to how much bespoke construction and effort was involved, partially because of marketing and partially because of how much software already exists to be built on top of. It's impossible to tell from a few paragraphs of functional description whether something was built in a weekend or took a team 4 years to ship, so volume of code is the natural fallback for describing complexity.
By this argument, I guess we should write our code slower too. Maybe we should only use a single finger as we type. And add an extra day between email responses.
Because by the inverse of their argument, slower MUST be better, right?
This is silly. LLMs are a diesel powered keyboard. If I've got a backlog of features, why shouldn't I ship all of them? If they're bad ideas, I can also just remove them.
Nothing about SDLC best practices has changed EXCEPT the ability to increase volume.
AI is shit, doesn't speed up my work. Only 10/20% of programming is typing and AI can do that fast, but the whole process no. If you disagree show me a proper study where actual improvement is measured.
Probably you could get a cheaper and more constant improvement if you make sure the developers are properly trained in the IDE's and environments they are already using. For example give everyone a Unix programming course and a course in their preferred IDE.
When I read recent news on HN, I feel it is a fable about Goodhart's Law. The law says: 'When a measure becomes a target, it ceases to be a good measure.' The dog should wag its tail. But the tail is wagging the dog.
LoC by itself is useless and so is AI LoC, it doesn't really show anything by itself.
But if you pair AI LoC in a range and also task completed in the same range and then compare that with historical data over a similar range without AI, then you have something tangible.
You also need to look at defect reports to understand the full picture of is AI being helpful.
So, we do need to measure AI LoC and AI PR counts, but we also need to make sure we are using other metrics to help paint the full picture.
Large enterprises class systems are notoriously difficult to work Ai. It’s the context window limitation. Assuming 10 tokens per LoC. The best models today cannot wrangle 100k distributed LOC across multiple repos. It’s great for building new and maintaining smallish codebases. All this code being written is fantastic, but maintaining them efficiently over the code lifecycle is tricky.
Converting the production database to Prolog to ship LOC.
My old CTO has a spiritual metric that always resonated with me: Revenue / Lines of Code. The higher the number the better.
>The difference this time is pace: you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.
I don't think so. Take a good company A (with a good product and a good pace of good features) of today. Take the extreme case they decide not to use AI at all. Well, they will still be shipping good features at their current pace.
No amount of AI will make a bad company ship a better product than A's. If any, bad/mediocre companies will be pushing crap faster than they did before, but that's it.
AI can make good companies better, but cannot make bad companies good. Why does company A need to worry about shitty companies using AI? Sure, other good competitors could be using AI, but all in all, shipping "faster" is not the "mark" of good quality
Yeah, that closing message was a little weird to me. I understand framing the article as "not anti-AI", especially if the author uses and enjoys the tools. But the end sounds like a call to blindly adopt the tools and figure out the justification later.
Yeah I think it also really depends on what your business is. Many or most of us here (and likely also the author) work in the kinds of tech-forward businesses where competition is fierce and velocity is essentially. But there are many many businesses, and also tons of public sector organizations, where this is not the case. Leadership in those organizations should probably be going a lot more slowly, waiting and seeing, letting all the fast movers fight it out through all this churn, and adopting only whatever eventually rises to the top.
Hi, author here. You're absolutely right! (yes, Claude-pun, I'll see myself out...) - I mean, I agree that Company A will remain "good", and may not need to worry about Company B. If that came across in the post then it was unintentional.
A lot of the criticism I've seen here could probably be addressed by me clarifying that no, I don't think AI should be blindly adopted, and no I don't think it adds efficiency or productivity by just existing and being "used". It needs thoughtful implementation, and each developer I know or manage or have chatted to uses it subtly differently, hence why I encouraged experimentation and trial-and-error, because when it "clicks" for you, then in essentially every case I've experienced or seen first hand, its added something (whether rigor, speed, efficiency, capability, etc).
Reporting on percentage of AI generated lines of code is very different from total lines of code. Yes I know both of them are missing what's the value delivered, but the later assumes the value is the number of lines, while the former assumes value is at least the same but delivered faster.
So what has actually shipped? I'm already using much many more AI-coded projects in my daily life than I was a few months ago.
I too made a post like this on here not that long ago. The point i was trying to make was to be AI knowledge first. The tools are here and someone has spent lots of money(foolishly yess!, But) creating this tools, so why not use them to your advantage. The one's that wait too long find themselves playing catch up on the next big thing that's comes of it. This is a phase that will blow over and in that process there is something cooking. Think of it as the stepping stone to the next era into the future. The future isn't created on its own, we must push for it. Hope doesn't do much in creating innovative advancements.
Before the smartpphones we have today there was touch pad LCD products all fighting for what now we call smartphones, that came with heavy innovative techniques to achieve a goal. The goal wasn't evident nor clear at the time.
This will lead to something else that is far more useful and could be harmful in many ways not just to employment.Economies are changing like never before transformational force are changing our lives as we speak. housing prices, Wages, Technology, Political Power, Warfare, ideologies, the list goes on. AI is the starting point in this new era. Choosing to use silly words like " This is not how we used to do things: no shit, we also used to ride horses and sacrifice virgins for it to rain. I don't know when people will ever get this ( The world is ever evolving) that is what humans do.
Having a say so and a control in what is harmful and what is helpful is just as equally important.
It's dying down now because unlike before, companies are paying out the ass for those tokens, where many companies now have token budgets enforced rather than the previous tokenmaxxing.
Confusing skeptic and sceptic will never not be funny to me (edit: I now live in shame)
Then I think you are the confused one, as they mean the same thing but one is US and one is UK+NZ+etc.: https://en.wiktionary.org/wiki/sceptic#English
I think you’re reading “sceptic” as “septic”. They are not the same word.
Damn it - well, I'll never live this one down, I'll learn to shut up next time
Nah, as long as you're good a sport about it, it's all good. In fact, it's refreshing to have someone make a mistake like that so confidently, and then own up to it immediately.
Author here. I think this was my favourite (and favorite) thread. I chuckled. I'm also pretty sure I could find ways to weave "septic" into a post about AI.
It shows good character to own your mistakes.
About as funny as “confusing” color and colour. Which is to say: not very.
Skeptic and sceptic are pronounced identically, because they are just different spelling of the same word.
Sure, live in shame, but don't let go of the humor in it all :)
I did get quite a laugh when the comments made me realize what an asshat I was
Sceptic is the UK spelling of skeptic.
Maybe you've confused it with septic?
How do you mean? Guy was born and raised in New Zealand and is using British spelling. There is nothing confused or confusing about this.
> Call it AI-first, AI-proficient, whatever you like
Can we just call it AI assistant and since it is really what it is. Just call a spade a spade, call it a day.
Nvidia boss Jensen Huang refer to AI as teammate in his recent COMPUTEX presentation, but it's disingenuous to call that since it's a just tool, but a very potent tool nonetheless. He's obviously biased to a fault but he's literally banking his company on AI now, but for the rest of us AI assistant should do more than fine.
Calling it teammate, workmate or friend is also rather childish. It's like having an imaginary friend that can lead young people to do silly things and this risk probably can be extended to junior developers [1],[2].
[1] Chatbots Can Be Dangerous For Kids:
https://www.psychiatrictimes.com/view/chatbots-can-be-danger...
[2] Why AI companions and young people can make for a dangerous mix:
https://med.stanford.edu/news/insights/2025/08/ai-chatbots-k...
i wish the shortcut from a-b will be faster then ever this 2026! thanks all
I agree with the main point but this misses something crucial:
> why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue
Most roadmaps are full of garbage and would be better off being deleted. You get very few truly useful new features in a year.
To paraphrase ESR: the value to your customers is in them being able to know that can rely on your product still operating next year, not in those 20 new features.
Or to think about it another way, maybe block will be better off with fewer developers, but only if they produce sufficiently FEWER features so that they’re forced to prioritize.
> But! Hold my beer… in February 2026 METR effectively walked it back : their follow-up estimates flipped to a speedup (with error bars wide enough to ride a Moto Guzzi, with panniers, through!), and they abandoned the study design entirely - because developers now refuse to work without AI, and can’t reliably self-report time on agentic work. Their latest position: AI probably speeds developers up in 2026, and we can no longer cleanly measure by how much.
This may be true, but they followed in May with this [0]:
> Importantly, survey results are not necessarily grounded in reality. There are reasons to be skeptical of people’s responses to counterfactual questions such as about AI’s effect on productivity — for instance, our study in early 2025 found that people overestimated AI’s effect on their time spent on tasks by 40 percentage points on average.
[0] https://metr.org/blog/2026-05-11-ai-usage-survey/#productivi...
Author here. Thanks, this is a useful addition I'd missed. The 40-point overestimate from their early-2025 work is exactly why I read METR's current position as "we can no longer cleanly measure this" rather than "AI definitely speeds you up now"; self-reports are doing a lot of load-bearing work in every direction, including in my own sense of my productivity.
When will performance or lacks of bugs become a metric again?
It’s worth looking at sectors where LLM code generation hasn’t been very visible, such as certification-accredited flight-control, braking, train-control, medical, or nuclear-control source code involving real-time embedded operating systems. This sector relies on assurance: deterministic scheduling requirements, detailed commit traceability, tool qualification, configuration management, independent verification, etc.
Since this is an area where failure can lead not to Instagram accounts getting hacked, but planes falling out of the sky and nuclear reactors spewing radioactive elements, it’s worth a close look. Some of the most visible companies in this sector include: QNX, Wind River, SYSGO, Lynx, Green Hills, Siemens Embedded, etc. None of them seem to have much if any adoption of LLMs for source code generation based on public statements.
Research in this area agrees with this view:
“In this paper, I have conducted a comparative analysis of the C++ code generated by popular LLMs including: OpenAI ChatGPT, Google Gemini, DeepSeek, Meta AI, and Microsoft Copilot for compliance with MISRA C++. The study revealed that none of the evaluated LLMs generated MISRA-compliant code despite clear prompts, with DeepSeek showing the fewest violations and Meta AI the most.”
https://arxiv.org/abs/2506.23535
This study showed that people writing computer games had little interest in productivity tools (because they are producing something that is really used). But people who produce things that not really used are obsessed with productivity:
> the perennially unprofitable venture-backed startup, for which faux productivity is connected to the generally immaterial nature of its high valuations, versus the game studio that lives and dies by the profitability of its products.
> In a sector of the economy where "it's not about how much you earn, but about how much you're worth," the labors of the companies whose workflows are built on the kinds of productivity apps that today comprise nearly 40 percent of Product Hunt's output are not actually directed at the creation of a thing, but at the appearance of the creation of a thing.
Maybe this is why Silicon Valley seems to have become obsessed with productivity and AI whereas the people in the industries you mention don't seem as excited. It's because they are actually making real things so they don't have to 'look busy' in order to justify themselves.
https://components.news/the-gamer-and-the-nihilist/
https://news.ycombinator.com/item?id=47235774
Many mid size to large companies are hilariously inefficient and the executives have no idea how work actually gets done. This means you can (in theory) fire a decent percentage of your workforce without affecting your output. You can then claim they’ve been replaced by AI without anyone ever challenging that assertion. I’m not making a pro or anti AI claim here, just saying that you won’t know whether you were wrong about it until/unless things start to go really badly.
I don't get how if productivity is barely moving, how a decrease in comprehension will improve anything.
beautifully put, AI is changing the way we make software but the way we measure productivity is still in our hands. L'chaim!
So, how the comapny will be evaluating the students on what basis?
How do you get to discuss without going to the article directly
Click the "n comments" link, like you must have done to post this comment?
> But adoption is the starting line, not the scoreboard.
Yes yes, shout it from the rooftops! Over the next few years I think we're going to see that companies that get this point will keep doing meaningful things, and stand a chance of weathering this transition period.
I think we're going to see a bunch of companies that went all in on AI for AI's sake go under because they've lost their mission, lost their implementation, and won't have a way to get those back in a reasonable timeframe and at a reasonable cost.
Writing. Code. Is. No. Longer. The. Bottleneck.
Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.
So of course we don't see massive productivity gains. Because these parts of the SCLC were always bottlenecked but their capacity matched the throughout. We fired all the dedicated QAs years ago. Sr+ engineers that do all the code review are limited.
Teams have not re-organized to match the new code-input velocity.
Engineers don't want to do QA because it's "beneath them".. and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.
Was writing code ever the bottleneck for anyone other than raw juniors and non-programmers?
There is some truth to this, but in practice I'm finding that yes, removing the writing code bottleneck has improved throughput quite a bit.
My day (excluding the huge amounts of communication overhead) used to progress as a serial operation of: 1. Write some code for one thing, 2. Self review of that thing, 3. Review other peoples' work, 4. Respond to review comments, 5. Get things merged, 6. Back to 1.
Now I have more of a tendency to queue up work on a few things at once, and then the serial steps are the self reviews and reviews of other peoples' work, and some of the review commentary back and forth (though I can automate some of this in parallel as well).
The upshot is that I'm more working in batches now than in serial, which I really do find to be more efficient.
It's not that it has removed all the bottlenecks at all, but no longer being required to focus all my attention for periods of time on physically typing code has removed one important bottleneck, and has changed, and I would say, improved, my workflow significantly.
One thing the AI tools have taught me is that it hasn't been my personal bottleneck for at least a very long time. It's made that part faster for me, and that allows me to take bigger bites at the apple each iteration, but it's not meaningfully speeding me up in the way people claim.
I disagree that it's not meaningfully speeding me up. I'm definitely doing a lot more, and more quickly. But the benefit is definitely smaller at the team and organization level, because we still have all the same serialization points - review, validation, decision making - downstream of my work.
I realized after I posted that it didn't quite capture what I meant. For instance if I'm able to do a more complex piece of work all at once in about the same amount of time as it'd previously take me to do a simpler piece of work, than that is a speedup. And that's what I am able to realize.
But what's not as much the case is that if I did an A/B test on the same task that I'd be massively sped up because so much of my day to day work are the things you mentioned as being serialization points. The time I take to figure out what needs doing, what the best approach would be, making sure it was actually the right thing to have done in the first place once I'm done, all that stuff. I use AI assistance for those tasks too but it's not the same effect as when I just hand off the pure implementation phases. So it winds up being "faster" and you'll have to pry my AI assist tools out of my cold, dead fingers - but if I'm being honest with myself by *that* metric it's not a huge gain.
Yep totally agreed.
Depends on your company. I'd say very rarely, and never for long.
This. Isn't. News.
People. Already. Know. This.
It hasn't been the bottleneck for decades for the majority of products.
I put a little too much weight on "the".. sorry..
Reality is that was A bottleneck. Code review has historically been faster than writing the code.
That is no longer true for me. I can complete two to three PRs per day in a span of time that would have historically taken one to three days.
I now sit around doing code reviews and asking for code reviews.
Code has never been the bottleneck, and it was always an illusion that it was. I mean, programmers on the whole are a group that jerks around probably 95% of their time (this isn't an attack as I've spent my career as a software developer, and this included countless hours on Reddit, HN, Slashdot, and so on).
> Engineers don't want to do QA because it's "beneath them"..
I’m fine with doing QA. But the fact is that it’s not how management measure my productivity. Spending hours doing QA looks like wasting time to them because it’s not an activity they track. They track my tickets so any hours not spent on them is literally harmful.
Also there’s the fact that you can’t QA your own output. It’s easy to overlook mistakes and defects.
> and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.
Just like QA, code review takes time. It’s easy to justify that time when the submitter has put in the effort to ensure that the contribution is worthwhile. Or can explain the design clearly. Not so much when it’s slop thrown over the wall.
> Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.
None of those are truly bottleneck. Deciding what to build is obvious: Something that solve a user problem. Reviewing code is easy when the intent of the code is clear (with additional prose if needs be). Testing code is equally easy and should already be automated.
The one slow activity has always been about designing the solution. And it has no relation to code. It’s mostly deep thinking and research. I do it on the sofa or in front of a whiteboard. If I’m typing, I already have a solution in mind.
'something that solves enough users problems it's worth it to implement it' rather, and I think it is often difficult to judge how much engineering time to spend on user issues.
I'm currently working in an internal team, so I value cost savings estimation, but even before prioritising was also a bottleneck (although a small one compared to architecture and design)
I don't know about anyone else, but for me, even though the AI writes a lot of code, the vast majority of that code tends to be... tests. Same with my coworkers.
This morning I reviewed a 1,200 LoC PR. Pretty large by pre-AI standards. But most of it was tests. Before AI, it would be a lot smaller, but only because the PR author wouldn't be nearly as diligent with test coverage as AI tends to be.
And to preempt some common rebuttals:
1. I always read the tests to make sure they are meaningful, and rules and subagent review routines in place to make sure stuff like "assert 1 == 1" or "Process.sleep(5000)" never make it in.
2. Tests do add a maintenance burden as well, but I find that it's pretty easy to refactor and condense tests.
I think this is important:
> When a company says “AI made everyone more productive, so we need fewer people”, I want to see the evidence - and I don’t believe it exists today. Show me that x% of your workforce is genuinely idle (or even just underutilised) because the work can now be done by fewer people. Even then: I’ve never seen a product/SaaS company that didn’t have an endless roadmap. If you got a free headcount increase essentially overnight, why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue.
I see some people calling for calm instead of AI panic by invoking Jevons Paradox. But at least within these companies there's no good evidence of Jevons in action, is there? The roadmap is endless, but when employees are perceived to be idle they get fired instead of being assigned more (or more ambitious) tasks.
To be fair, one could claim Jevons applies to "the market" at large, but at least we can say the evidence from tech companies is not encouraging. So maybe it is, indeed, time to panic a bit?
> Choosing the layoff instead tells me the productivity claim is doing PR work for a decision that was already made for other reasons (over-hiring, investor pressure, take your pick).
Yup, I think we all suspect this. Though it's probably a mix of the two factors.
> So maybe it is, indeed, time to panic a bit?
Anyone relying on a steady paycheck from an employer should panic a bit all the time, because nothing can save them from bad management. The reference to Jevons Paradox doesn't say anything about individual managers responding correctly. If 30% of managers screw up, that's a lot of collateral damage.
Now to respond to your actual point, I don't think software developers should panic. Even if pure software engineering gets hit hard, I'm having trouble imagining a scenario where years of software development skills plus knowledge in a specific domain isn't a good thing for current software developers. This is unlike what happened with international trade, where you had 60-year old textile workers losing their jobs, no alternative jobs, and no policy being offered to compensate them for the effects of trade.
Yes, it's the "market" argument that I find compelling. That is, not jevons within firms, but rather across them.
Is it true that the evidence in tech so far is not encouraging? I was pretty worried about the job market a year or so ago, but it seems pretty good for experienced people at the moment, no? (I do have big concerns about the entry level pipeline though!)
The kloc fallacy never actually disappeared. Project and engineering managers got wise to the fact that it was only loosely correlated with shipping features, and stopped emphasizing it. Most everyone else has carried on silently believing it without really thinking about it. And of course engineers themselves have always believed it. How many times have you heard some guy talk about how he wrote 10kloc over the weekend as a brag?
> "Augment surveyed 219 engineering leaders and asked them to define “AI-native engineering” . They got 219 different answers."
I mean, if you give 219 people a free text box and ask them to explain anything, you're extremely unlikely to get the exact same answer twice...
> I think every engineer should be using AI daily.
Why?
Please read the full paragraph for the answer instead of cherry picking a quote for a knee-jerk reaction:
> Be curious, try the new tools, test the latest models. To not do so is silly. > [...] > you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. The way we work has already changed, and it’s not changing back as far as I can tell.
> you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.
I really dislike these claims that act like they know the future of engineering, that they’ve been let in on some enlightenment that we haven’t been. What’s going to happen in a few months? Is Sam Altman going to nuke my house from orbit? Or is it because my CTO is going to fire me for not using AI? If it’s the latter, that’s not a curiosity problem, that’s a “there’s a gun to my head” problem.
It seems to be based on some idea that there's no way you can be productive enough without AI. But I've yet to see any companies really shipping meaningful software at some unprecedented speed that was not possible pre-AI. Instead, I see a lot of half baked features and buggy apps. I am not convinced that those that choose to either NOT use AI or use it more sparingly / judiciously (my preference), are somehow going to be "left in the dust".
Yeah, I’ll second that. I see folks moving _fast_, but boy oh boy are they breaking things (or delivering something that never worked) which if anything makes _me_ slower lol
And also delivering things nobody wants or will use, just because they can.
I read the entire paragraph, and the entire article. Nothing in there explained to me why every engineer should be using AI every day.
Because I don't think that's the point of the article, which is just a commentary about how AI labs are marketing the effectiveness of their services by using terms like "8x more code per quarter" like that's an obvious good thing (which it isn't).
If you want a more in depth explanation, go look for interviews with devs who were already super-productive before LLMs and now came around to using them everyday.
If you read the paragraph, then why did you just ask "why?" instead of expressing your opinion about the explanation given in that paragraph?
Because it's fun. And why shouldn't we be into incremental automation?
I still write code manually to keep my trad-coding skills from withering away, but using AI without a doubt has allowed me to better test my existing apps. Create playwright automations I would've never had the time for. Allowed me to search through docs many times faster. And it just making programming more fun when I do use it for more challenging problems, and I actually get something working at the end of the day.
Sounds like it's working for you, but none of that explains to me why every engineer should be doing that, and every day
We need a Slop Audit methodology.
That is why I have created one (Open Honest Slop Audit).
I guess nobody cares anymore that AI is built on one of the largest thefts in history.
To play devil's advocate for a moment (although I hate it): LoC often actually means NIH... but NIH suddenly has a pretty big proponent in the form of resistance to supply-chain attacks.
Basically the choices are:
1. Roll your own
2. Lockfile your deps for too long
3. Chase the bleeding edge for every dependency
The first is security-through-obscurity because DIY libs will have bugs and vulns but they won't be well-known. The second means missing known vulnerabilities. The third means supply-chain risk.
The rash of attacks and the ease of LLM-powered roll-your-own has shifted the risk-reward calculus towards 1.
But I hate it. This is the further Peter Pan never-gonna-grow-up of our industry that we cannot develop solid best-practice tools and must churn endlessly.
I'm reminded of my first tech job about 25 years that had some not very technical manager who had a technical toady write up a script to check lines of code added as a productivity measure. I was in big trouble because it didn't account for lines removed or modified, only new lines added. The copy paste guy was praised of course for how productive he was for.
Funny how AI is continuing the same story of non/semi technical busy bodies with their dumb bullshit.
Instead of building up a sane system for handling dependencies, just copy-paste them whole cloth into your code! Instant rockstar status!
Another writer, back in February[1], noted "Every major tech CEO is now competing on what percentage of their code is written by AI"
1 https://www.thepragmaticcto.com/p/lines-of-code-are-back-and...
Amateurs. Using LLMs merelly to generate code. pfft... so 2026....
A few of my workflows now are: Use an LLM to generate code that generates code.
"Second Order AI Software Engineering(TM)"
You should trademark Metaslop™!
This is also called Spec Driven Development.
Another AI slop article urging me to use AI on the orange AI fanboy site which has guidelines against AI slop comments, but AI slop submissions, that's just fine I reckon... Screenshot since the share button demands I have some social media login.
https://imgur.com/a/UW15xVE
Hey, author here. My AI overlord advised me not to engage with this comment, but I don't like being told what to do.
I don't know what the reference to "orange AI fanboy site" is, sorry, but I do find it interesting that what I assume is an AI-writing-detection-site pegged it as 100% AI written. Obviously folks will believe what they believe, but just to satisfy myself I will state that I used AI (Claude Fable 5) to help with research by suggesting and then summarising articles, then interviewing me both as a supporter and detractor to really solidify my position (essentially arguing/debating with the AI), and then it suggested the post layout (funnily enough including that specific subheading "Why I actually care", which I will concede sounds AI-as-hell), but I then wrote everything else. I did paste in any quotes and specific numbers (which that section has quite a few of), and I did then do a final pass with AI (both Fable, and then ChatGPT) to pick up spelling, grammatical issues, formatting, etc. Anyway, have a good weekend and thanks for reading. :)
Genuinely funny how often I see both "HN is an AI hate site" and "HN is an AI fanboy site".
As dang said in one of these threads recently, opinions are just spilt on this!
I show dead and never see a dead fanboy. Just the critics.
I show dead and see both fanboys and critics all the time. Look at my comment history, I feel like I'm constantly arguing from the other side with people who are more fanboy than me and then other people who are more critic than me.
"As someone who spends a lot of time writing x86_64 Assembly and optimizing pure-JAX code for TPU clusters, this recent obsession with LLM-generated 'Lines of Code' metrics feels like a massive step backwards. In High-Performance Computing (and especially things like quantum simulation, which I work on), the entire goal is reducing complexity and overhead. The magic of frameworks like JAX/XLA isn't how many lines of code you write, but how elegantly a few purely functional lines can compile down to highly parallelized hardware instructions. If an LLM writes 100,000 lines of boilerplate for a project, someone eventually has to maintain, debug, and pay for the compute to execute that bloat. The real value of AI in engineering shouldn't be churning out a million lines of CRUD per month; it should be helping us build better differentiable systems, grokking complex mathematical landscapes, or spotting inefficiencies in low-level execution. We spent decades learning that Goodhart's Law applies heavily to software engineering (more code != better software). It’s strange seeing leadership forget that just because the code is now generated by an agent."
The thing LOC measures best is how much code someone now has to read, understand, and keep alive. That number going up is a cost, not an output.
I spend a lot of my time taking over codebases other people left behind, and the AI-heavy ones have a recognizable shape: lots of plausible-looking code, thin tests, and nobody who can tell you why a given abstraction exists. Writing was never the hard part. Deciding what not to build, and being able to delete it confidently later, is the part that does not get faster with a model.
What did get faster for me is reading and reverse-engineering unfamiliar code - which is a little ironic, since the same tools are now producing more of the unfamiliar code that needs reverse-engineering in the first place.
Bragging about an AI agent generating a million lines of code is exactly like bragging about an automated factory generating a million tons of airplane weight. It completely misses the point of engineering. The bottleneck in software development hasn't been "typing speed" for a very long time; it's domain understanding, system design, and long-term maintenance.
Every line of code an LLM instantly spits out is a line a human engineer will eventually have to read, understand, debug, and migrate when the underlying business logic changes. The "better publicist" might be successfully selling these generation metrics to executives, but it's the actual engineering teams who are going to be paying the maintenance tax on all this auto-generated sprawl for the next decade.