Hacker News Reader

Comment by efficax | Hacker News Reader

I was worried this time last year that by this time this year, companies would have slashed their engineering teams down to a handful and everything would be driven by mostly autonomous agents with human guidance. But it just hasn't happened. Do I write all my code with an agent now? Yes. Can you just give an agent a desired outcome and let it work, unsupervised? Absolutely not. I can produce more code than I used to, but if I want it to be good, to be stable, to do what the product manager and designers want, it's only about 2 to 3 times more code than before. And that productivity is impacted by the fact that I'm reviewing 2 to 3 times more code than before (and you have to review, even more so now than before, because if you just let opus or gpt 5 do its thing, you'll get some terrible results, and I've found a lot of engineers on my team are just letting it do it's thing without a lot of iteration).

View on HN

The thing is: I could produce 2-3 times as much code as before _without_ an LLM, if I didn't care about my colleagues' ability to review my output properly.

Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.

A huge part of the job of Software Engineering is producing the right amount of code at the right time.

> Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.

> A huge part of the job of Software Engineering is producing the right amount of code at the right time.

Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small.

120 kloc mostly from one single developer copy-pasting and keeping non-compilable code for an obsolete target "for reference" for a decade, becoming both a ball of mud and a whole pantheon of god classes? No unit tests, no code review? Won awards.

Properly engineered, mandatory code review, mandatory unit tests, dev meetings to knowledge-share? People with the money said too slow, closed it down.

(Sometimes people bring up how bad Musk's code was at PayPal. I never bothered investigating. Successful product though, wasn't it?)

Survivorship bias, you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise, or a product that is possible within constraints that otherwise could have been a success, but not realised by sloppy work and incompetence.

Furthermore the dependencies you choose to build your product are presumably filtered for engineering practices or world class engineers. So given the choice you yourself prefer top quality engineering, so do your customers. Much in the same way you are a customer of your projects dependencies. Difference being, as developers we get to see how the sausage is made, our customers only see second and third order effects.

> you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise

Trying to ignore the nuance is hard in your position or the following one I’ll give is difficult.. but is the opposite potentially true as well? We don’t know how many projects failed because of over optimizing, too much time spent on design and engineering decisions. It’s of getting out and MVP to market. I only say this because I have been apart of a few of these.

Well, that's the other side of incompetence: they know how to spin their tools, but they don't know when to stop, or how to stop the change requests, the balance between shippable, maintainable, and what the market wants at that time.

I understand and of course I am familiar with the hypothetical you are trying to set up here but I was specifically pointing out a logical fallacy I see banded round all the time by people who should know better or educate themselves.

I will say that if “good engineering practices” comes up in your root cause analysis for a failure to launch a product you are not thinking critically.

Over optimizing and spending too much time on engineering decisions is also something an incompetent development team would do.

> Survivorship bias

The statistical problem is small sample size, not survivorship bias, as I got to see things before failure. These two examples are merely illustrative of things I've seen.

I think both are at play here and I don’t know about Musk’s programming skills. But it seems that they had other very good programmers (including levchin). So maybe business success can buy good engineers to clean the messed up code. I’m not sure how it goes with AI now though.

Good point. In my experience even hobby free software projects are generally better engineered than most proprietary software sold by businesses

> Successful product though, wasn't it

If you can call being an “also ran” in a field they had a ten year march on their competitors in success, yeah.

Truth be told it was the shoddy code they were forced to use for the vanity of their paymaster might well have held them back, though manifestly that is not a bad thing. Probably the best outcome, really.

The first thing they buy of the success money though, is a struggling technical competitors, so that this team can clean up there mess. This would mean that AI is only a good contributor at startups and with prototypes.

Lines of code are a business liability. They are future cost.

There's a trade-off to be made, and it's not necessarily clear where the trade-off sits for any particular company, or even team within the company.

One product person described it as eating vs breathing. Availability is like breathing: if you stop being available (including, but not limited to, because your software is a big ball of mud) then you're going to die pretty quickly. Product is like eating: you might not die so quickly but if no-one's buying what you're selling then you're still not going to survive.

The team I'm part of is a platform team, so we're closer to being lungs than being stomach. We can (and I appreciate being able to) focus more on stability than feature development.

> Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small.

One of the most uncomfortable truths about our profession is that there is no floor to how bad software can be while still making people billions of dollars.

I'd argue PayPal was a successful business, not a successful piece of software.

That's kind of the point.

The software only had to be good enough to support the business. It doesn't have to win a Turing Award, and probably wouldn't help the business if it did.

> Lines of code are a liability, not an asset.

I have been saying this for years, I once had a heated argument about a small system of maybe 1000 lines of code that was technically superior and more scalable but was freaking 1000 lines of code to maintain compared to the quick and dirty 10 lines of code it was suppose to abstract and make generic (for future use of course).

That with also countless debates over insignificant features in frontend apps at the cost of extra code. Frontend code is very susceptible to this maintenance cost dilema.

Many developers are too focused on delivery value compared to maintenance cost. It is unfortunate that non-technical management can see value delivered, but not maintenance cost incurred. With LLM-assisted code this has become many times worse.

I don’t think this is a great argument for such a small amount of LoC. 1000 lines depending on the service it provides could be very small.

> more scalable but was freaking 100000 lines of code to maintain compared to the quick and dirty 1000 lines of code...

I wonder though if, as long as you have LLMs to maintain the extra code, it's worth it to gain the new feature. Less tech debt than your intuition expects.

Why would an LLM be any more capable of maintaining the extra code than I am?

Sure man, knock yourself out.

Because it can read and understand the code base far beyond your ability.

You can pretend that's not true, but it is. And it's only going to get better.

>Many developers are too focused on delivery value compared to maintenance cost.

The way this is worded feels like it leaves the blame on developers. Aren't these developers focused on exactly what they are being judged by? Shouldn't we say it is the management who is too focused on delivery value compared to maintenance cost? Is it the developer's job to guide management or the manager's job to request guidance, assuming such guidance is needed?

We need to make sure the responsibility to resolve this problem falls on those with the power to act on it, and in this, developers tend to be receiving far more responsibility to fix than power to fix.

I don't think so, my experience is that most often falls into two scenarios:

1) The devs pushing for more complex solutions, covering obscure edge case scenarios, feature-creep, "future-architecturing" because they are more interesting to implement. Classic over-engineering problems.

2) The features the managers actually want are usually boring or annoying to implement and the devs just work around any big architectural problems caused by the feature delivery.

1 is 100% on the devs, 2 it varies wildly, the willingness to address architectural problems are often under pressure by time-delivery estimates from managers. But many devs (especially in companies with low morale) will often just work around issues because addressing the underlying problems can be very difficult and/or time consuming.

Meaning either the dev wants to do the right thing but doesn't have the time, or the dev doesn't care enough and just pushes the tech debt down to the future (when hopefully they will be at another job).

LLMs makes both problems significantly worse, although they are also often very helpful with the big restructurings mentioned in 2. The dev can still be lazy and the deadline can still be too tight even with that extra LLM help.

How is covering obscure edge case scenarios overengineering?

"Lines of code are a liability, not an asset."

wrong framing imo

EXCESS lines of code are a liability.

Code of course is an asset.. what other real asset is producing cash-flows? lol come on.

It's apples and oranges. Lines of code is just a measurement. You can't look at a whole codebase and say "these X lines are essential, those Y lines are excess, delete those" -- the lines interact with each other to create the whole thing.

It would be like saying "Weight in kilograms of course is an asset for an airplane. That's what keeps it in the air. What other real asset is the airplane made of?"

This is the thing. You "spend" lines of code, you dont produce it. The produced part is the outcome - a functional feature, stability improvements, some business outcome. Measuring productivity with LoCs is like measuring output with cash burn.

> Measuring productivity with LoCs is like measuring output with cash burn.

companies are doing that as well lol (re: tokenmaxxing)

I think that coding reviews are no longer feasible as they used to.

The pace and expectations have increased and a human can barely cope with reviewing its own code, let alone colleagues'.

They are not going to disappear in critical aspects of a codebase, nor shouldn't, but the industry will eventually reward self sufficient individuals able to keep the pace, harness and run adversarial reviews against the design and implementation autonomously.

I'll also say the harsh truth. A well implemented adversarial flow will do either better than your peers or will deliver 95% of the value at a fraction of the cost.

The industry has never valued product, let alone code quality except in places they are core to the business.

Otherwise you would not have MIT-bred leetcode ninjas writing react/tailwind bugged monstrosities at half a million/year for billion dollar products.

How'd that go for the most recent Windows update?

This is one of the things I ran into early on. LLM needs to compute the determinant of a matrix? Sure, just spit out some huge hyper optimized implementation of it. Good luck maintaining that. Slapping "use industry standard open source libraries for common functions" has improved the quality of LLM output for me by such a large margin.

> A huge part of the job of Software Engineering is producing the right amount of code at the right time.

I'd go further and say that usually the goal is to use as little code as possible without sacrificing readability.

Brevity is compression, and compression surfaces the salient points of a problem.

Elegance often comes down to brevity.

So it's like jazz... it's the code you didn't commit that matters?

"A huge part of the job of Software Engineering is producing the right amount of code at the right time."

But the whole job of the owners is to lower the costs as much as possible to produce the product, especially in an environment with higher costs to borrow (higher interest rates at the fed)

>I was worried this time last year that by this time this year, companies would have slashed their engineering teams down to a handful and everything would be driven by mostly autonomous agents with human guidance. But it just hasn't happened.

I find this somewhat puzzling. I thought things were moving quickly, but at this time last year I couldn't even get Claude (using Cursor) to spin me up a service skeleton that would compile, let alone do anything meaningful.

I know it feels like a long time somehow, but it was only between November and February that things started to actually somewhat work without significant hand holding. Even now, it seems like we're still figuring out how to fully leverage the current models and tooling, even in organizations that have largely gotten on board.

> at this time last year I couldn't even get Claude (using Cursor) to spin me up a service skeleton that would compile, let alone do anything meaningful

I've been using it to do this for 2 years now. And many people with me. The change you mention is one of is primarily one of Overton windows, of vibes.

Which harness software were you using for this 2 years ago? VS Code Copilot? Cursor?

Aider for me

Very successful by just being careful and walking it forward.

Yes its about 2 years, August 2024 from git it looks like.

Exactly the same for me. Sonnet 3.5+Aider made it possible.

I got downvoted though, apparently you and me are liars, haha. Easier to believe that than admit that their take of "I adopted it exactly when it became viable, now it's good, and before that it was a waste of time" was wrong. They're the people who were loudly claiming here last summer it was useless, asking "show me anything useful that has been coded using LLMs". Come to think of it, it has now been a few months since I saw one of those. Used to be every other thread.

I've had success with Aider from October of 2025 (from my git logs). I have to differ from the general sentiment over here. The tools and models are good enough to make a change in the way work is done. Of course, Big Tech. will move fast and make mistakes but this is qualitatively different from other recent hypes (e.g. crypto/NFT). It has had genuine impact on people and their lives and a lot of simpler jobs with larger teams have been replaced by these models and one operator.

Exact same for me as WhatIsDukka.

Yeah, I strongly remember getting Sonnet 3.5 with Aider to boostrap an (albeit basic) project and getting it to work. Especially vivid because I told my roommate at the time about it and he also tried it out and was also shocked. I'd put maybe $20 in credits into the API haha. Feels so quaint, it's almost a foregone conclusion with the current models and harnesses.

>I've been using it to do this for 2 years now. And many people with me. The change you mention is one of is primarily one of Overton windows, of vibes.

I suspect this may have depended on the specific framework. I quite literally could not get Claude (in Cursor) to give me a basic Micronaut setup in a fresh workspace with essentially a "hello, world" API. I would guess that if you're using something like Python and FastAPI, it might have been an easier task or better represented in the data.

The difference that I observed in the Opus 4.5 era is that Claude could take a service framework it has never seen before (proprietary corp) and figure it out.

It's not all that surprising that people were worried and believed this. The AI companies and infrastructure companies partnering with them have spent a lot of money and time trying to convince people this is the case year after year. The critical clue people miss is that everyone claiming that has very clear financial incentives to convince people that's the case even when they know it isn't. Anyone who was actually building with LLMs and judging for themselves based on its performance knew fully well that wasn't the case year after year.

I've said this before: if anthropic (et al) thought they genuinely had a shot at replacing even 30% of white collar work, they would ABSOLUTELY NOT warn ANYONE. They would do what oil, leaded gas, and cigarette companies did. Swear under oath this is completely safe, commit GRIEVOUS societal harm that you explicitly promised wouldn't happen, and then end up in history books instead of jail for reasons beyond my ability to fathom.

No. The very fact they are trying to "warn" us means it's all marketing.

This has been corroborated for me on the engineering front that I can't find a single IC I respect who actually thought there was any evidence AI was going to live up to the hype. I saw a lot of people I always thought were idiots/sycophants/brown nosers go insane with AI. Never saw anyone id trust to help me cross a street blindfolded say more that "I may be wrong, but I'm not seeing any evidence yet".

Fwiw , you're conflating multiple things and consequently drawing premature conclusions.

It can be massively over hyped for it's current capacity and decimate the white collar work.

A lot of the difference of opinion is down to their point of view. At my dayjob, LLMs will not live up to anything because the enterprise is not structured to take advantage of it's strength. That's unlikely to change within the foreseeable future.

I strongly suspect you mostly talked with people coming from just such a background, because it's hard to go beyond our own bubbles

Sure, naturally. And yet parent commenter is remarking that simultaneously no AI-true-believer startups have supplanted the old money, and simultaneously despite much talk the bigcos have not slashed headcount to tiny AI-powered teams.

Depends on the bigco IMO. I'm not sure what kind of layoff numbers for Year Three of genAI would grab your attention, but I assure you, hundreds of thousands have mine.

The layoffs started years before LLMs became practical coding tools.

So you're saying companies correctly estimated the need to cut staff to remain competitive and did so -- or at least, some state of affairs empirically indistinguishable from this. Not much of an argument, sorry to say

Hmm, isn't that just down to the fact people always vastly underestimate the amount of work software takes?

It takes a lot of time to successfully deliver a product. Even at the more "extreme" end of expectation - like saying it's a X10 multiplier (I'd disagree on that, it's more like 0.5-3 - depending on the type of work you're working on) you'd still need multiple years to go from first line of code to displacing established players. Things just don't change that fast.

Yes, this... all the hype from the leading AI companies just pattern-matched so many past cases where things didn't pan out. really giving me the bad vibes..

>The critical clue people miss is that everyone claiming that has very clear financial incentives to convince people that's the case even when they know it isn't.

Social media is flooded with bots pushing this narrative - coding is dead, engineers are all cooked, the latest model is scarily good, "what am I for?", etc.

A good rule of thumb is that if it's a human being and not a bot, they'll use the word "slop" at some point.

coding harnesses improvements mattered more than llm improvements this past year. You could solve problems on claude sonnet on claude code that you couldn't solve a year prior.

Nope. If you use pi and its extremely minimal harness you can see a _lot_ of difference in models.

Do I write all my code with an agent now? Yes. Can you just give an agent a desired outcome and let it work, unsupervised? Absolutely not.

I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them.

Some devs just 'get it' and thrive, leading a team really well and building a great culture. But a lot of them don't, especially if they don't get the support necessary to understand what changes when you move from IC to manager. If the team (or agent swarm) isn't performing well it often isn't a problem with them. It's a problem with the new manager still trying to stay on top of everything and micromanaging all the things. Alternatively, the new manager is completely hands off and only appears at a check-in point (one-to-one, agent completes a task, etc) where they crap on the work and get cross.

I have no evidence for this, but I'd guess that putting developers through some sort of management training would make them much better at using agentic swarms.

> If the team (or agent swarm) isn't performing well it often isn't a problem with them. It's a problem with the new manager still trying to stay on top of everything and micromanaging all the things.

You see problems in the results? Simple, don’t check the results!

Let codex review Claude output and the contrary. Win for everyone involved, more code, more features, more token usage, promotions, code to be debug by juniors and the cycle of life can continue.

Absurd.

We are beset on all sides with companies declaring agentic coding a failure and here you are stating as a matter of fact some teams “thrive” with this probabilistic expensive approach to approximating working code?

All the while concluding with “I have no evidence for any of this”.

Agentic coding is absolutely not a failure. It's just not the 10x that CEOs really wanted it to be.

We learned that some tasks don't really benefit from AI while others do. My team went from 7 people to 2 (went to new teams, no layoffs), and we're doing the same amount if not more work than we used to.

Is it more draining and lacking of focused work? Yes. Is it more money for the business? Yes.

> while others do

Now we just need to find those tasks. I want to believe.

> and we're doing the same amount if not more work than we used to

Zero evidence for this. It's programmers self-reporting their own productivity. (Have we not learned this lesson after 50 years of programming practice?)

Friend, you are commenting on a thread where one of the most prominent figures in tech (rightly or wrongly) is saying something did not meet expectations. As far as we can tell this is a man with every incentive to exaggerate and boost these products.

In my world, when something is expensive and doesn’t meet expectations it called a failure. Especially when something has been as hyped, scrutinized, defended and attacked as vibe coding.

Honestly, if you are the director of robotics at a firm I think it’s time you took a cold shower.

Why would Zuckerberg want to boost their AI, they have none to speak of after Llama really? Zuckerberg actually has every expectation to downplay AI so as to save face that Llama failed compared to frontier models.

Why are you assuming Zuck's expectations for progress of _his_ product have anything to do with the impact of that category of product for its users?

I’m sorry, what’s the question? Genuinely not sure.

I’ll rephrase, Zuckerberg would certainly enjoy agentic coding to be a wild success because it means less staff and more products he could fail to create.

Again, Zuck's success criteria don't necessarily align with that of others. In fact, I'd expect his success criteria are substantially different to most.

Making money? Seems to be the common success criteria for all.

It can both be a wild success and not what he expected.

These two not mutually exclusive?

“Wild success” and “going slower than expected”?

Wake me up when words have a meaning again.

> These two not mutually exclusive?

Correct, they are not.

Consider: Someone who "expects" their bank account to have $100M in it before they turn 30 and "only" gets it to $10M.

From the point of view of a normal sane person, they are experiencing "wild success", and yet at the same time they are definitely "going slower than [they] expected".

Pretty sure Zuck was talking about agents in general, not specifically Meta agents.

More importantly, he's really probably talking about 'superintelligence', rather than just building genuinely useful and monetizable models.

On the other side of this you have two companies growing revenue literally the fastest ever in any market segment, just for said tech. Somebody is spending this money and thinks it's worth it. Let's check back in six months.

Sure thing, just like I’ve been checking back on people over the last 3 years. I’ll hit you up too.

Past performance is not indicative of future results.

We're riding an exponential here for Pete's sake.

We all know the future results of a lame horse.

Judging by his account he’s a big time booster suffering with psychosis

not sure what this means. should I be worried?

I dont care about your well being TBH

just pointing out the obvious.

you care enough to respond, shouldn't have bothered.

These all sound like nice sound bites.

Until you factor in many large firms are interested in cheap Chinese models.

Are you a frontier lab booster by any chance?

Being a "failure" means it fails to meet its success criteria.

If you claim 10x and deliver 3x, that is a failure. The 3x may still be impressive or a gamechanger or ..., but it still falls short of its promises.

So what? Who cares about such a binary claims?

People making decisions.

Pay me 8x to get 10x, great. Pay me 8x to get 3x, nope.

I have not seen reasonable claims that people are paying 8x the salary of a SWE to get those 2-3x results.

Directionally, that's why companies are getting rid of token leaderboards and imposing limits on LLM costs. There's a diminishing marginal return to tokens

That's true and it's also very easy to game.

There is increase in (not only perceived) value _somewhere_ - IMO depends on the organizational culture. At my work I found going over 100$ on OpenAI/Anthropic's API pricing does not produce any meaningful additional output. It might be much different in different companies.

10x is a marketing gimmick in development, AI and pretty much everywhere

> Is it more draining and lacking of focused work?

To be completely honest, I’m living life right now. I love programming with my bare hands, but man I’m living just building a gajillion things a mile a minute with LLMs. I then come home and spend hours building stuff for myself using local models. I’ve never been so excited about just building shit, that I sometimes want to pull all nighters because I’ve been in the zone (a for work and at home).

Draining? Sorry… inject that LLM serum right into my veins

> Agentic coding is absolutely not a failure. It's just not the 10x that CEOs really wanted it to be.

It’s absolutely 10x faster for coding. But coding is only 10% of my job. The other 90% is figuring out what to code.

From my experience with daily stand-ups, I think they can be a significant boost to that, too. Though you will absolutely have to wear a manager hat with their estimates and breakdowns, not just fire-and-forget, as they're often as not wildly over-optimistic about task complexity.

I am also leading a small team of myself and 2 others and we're getting a lot done. The short lines of communication of being a small group + the power of agents has been great for us.

Because this companies defined the goal to replace humans with AI what didn't happen. What happened is that the humans can work faster and have more coffee breaks while the AI iterates for the next review and iteration round by that human.

And the human will not bother to review that mass of code and will just approve so the real test will happen in production.

why would companies who build tools for developers say they'd want to replace humans with AI? it was never the goal, it was never stated like that. they said that by the end of 2026 most of the code being output would be generated by LLMs, and is pretty much true.

The bit I don't have evidence for is whether or not teaching ICs to be managers would improve how they use agentic AI. I have plenty of evidence for the efficacy and effectiveness of AI itself (although not qualitative or obviously causal unfortunately.)

> plenty of evidence … although not qualitative or obviously causal

Those two things are the opposite of each other (evidence, but only anecdotally; you cant be both).

Anyway.

More tangible to your argument; what is your argument that this will be more effective than just prompt engineering?

Ive long believed that prompt engineering is a losers game; if there is a trivial set of tricks that improve the output, they will simply be automatically applied.

We see this playing out with the system prompts in coding agents and image gen.

The value of learning “photo realistic studio lighting…” was non existent. The nano banana api is capable of taking a naive prompt and expanding it with these tricks.

People who devoted themselves to learning these “magical incantations” wasted their time and effort; and it was obvious, from the beginning this would be true.

Now.

With managing agents; if a trivial set of management tricks can drastically improve the results, why are you better off learning them now, rather than waiting for them to be baked into cursor/codex/claude in easy mode?

What makes you believe this is a valuable investment in time and effort?

Even if we accept that right now assigning personas to agents and managing them as a manager yields good results, the horizon for change right now is so short, it seems extraordinary to suggest mass management and leadership training for engineers.

We should just wait and see.

All in investments like this would just be tokenmaxing in a funny hat.

are we tho? i don't really see anyone going back to planning and coding by hand, that ship has sailed and it's not coming back. people ditching agentic workflows altogether would be failure, people figuring out it's not a miracle tool and has uses for which it's not as productive is correction.

I think you are confusing manager with ICs. Managers don't really read or review the codes. What you are describing is where agents are doing all the coding and reviewing without people in the loop. I don't think the op is working with the code as black box. He is more about describing the higher IC workflow.

Whether we still need people in the coding loop is not a trivial difference

Managers don't really read or review the codes.

Good ones do. Reading the code someone is contributing is a powerful signal about how well they're doing.

ICs who manage swarms of agents should operate the same way. They set them off to do something, and then look at the output to see if it's going well.

That's the point I'm making here: managing a team of ICs and managing a swarm of agents has a lot of overlap in the systems and processes you can use to see if it's working well. By teaching ICs to be better managers I think they'd get better at using agentic AI.

> Managers don't really read or review the codes.

There's such and such. In some companies, the leaf engineers report to a team lead, which might or might not be granted this 'manager' title. Those poor fellows essentially doing double-duty and are the most likely candidates for burn-out.

Nothing you said makes any sense.

LLMs are driven by the text you enter into them and they are never fully autonomous unlike an actual employee.

You cannot train an AI and then at some point just let it loose.

"I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them."

I doubt that. Management is mostly dealing with people, the actual "management"* part is not where developers moving into management roles typically fail, it's the people part. With agents you have the management part without the people part.

I disagree with your 2nd assertion. Even engineers who are less tech lead style engineers, can gain a significant boost in productivity by being able to quickly run through POCs and build an understanding of surrounding areas of their work, so they are able to contribute more.

For eg I am able to make React changes much faster and the changes are higher quality, given frontend dev has never been my job role. I’m able to spin up test harnesses, write throw away glue code, test against large datasets, etc

> I am able to make React changes much faster and the changes are higher quality, given frontend dev has never been my job role

Man, if I had a dollar for every time someone said "I'm not good at X, but LLMs are so impressive at it". Like do you think there might be some connection between those two points?!

> I’m able to spin up test harnesses, write throw away glue code, test against large datasets, eTc

It seems that I don’t like coding when I read these kinds of statements. If I’m doing an experimentation, it would be a few lines at most. Because that’s all I needed before I can write a solution.

Writing code is the last tool to design with. Thinking and a bit of sketching is what I do mostly. Then I verify small bits with code (mostly for checking a library when the documentation is lacking or a stub when I’m focusing on another part). Otherwise, it’s just enough code to get it working well and refactoring when the requirements changes.

I get why you think this but you are incorrect. Why? Because managing a team of people is very very different from managing outsourced contractors, and LLMs are much more like the latter than the former.

Yes, an agent does feel like a very eager and very knowledgeable but also very clueless junior developer sometimes. But no, working with agents is not like leading a team of developers. You don't have to make sure an agent stays motivated, give it the feeling that its work is valued (I can let an agent spend some time building a prototype and then decide not to use it, if I did the same thing with something a junior developer took a week to build, that probably wouldn't be a good idea) etc.

> I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them.

I disagree.

From ICs that I lead, I expect that they learn fast. On the other hand, LLMs are basically incapable of improving.

Another issue that I can see is that I don't particularly like eager new colleagues who come up with (hallucinate) wrong answers. At the beginning, if you are uncertain, learn, and if you have questions that learning does not answer by itself, ask questions. But strongly avoid hallucinating answers. New colleagues can be taught that, LLMs not so.

New colleagues can be taught that, LLMs not so.

LLMs can be 'taught' though. You can give them additional context or instructions. The difference is that they can't really teach themselves.

This is roughly what I'm saying - someone who's managing an IC can steer them on the right course, and someone who's managing an agent can also steer it on the right course, so teaching someone how to handle ICs well gives them skills that are also applicable to handling agents well.

It's not perfectly analogous obviously because ICs are people and need to be managed as people, but I really think the skills are quite transferable in one direction. I'll add that I don't think someone learning to manage agents would necessarily become a good people manager.

> LLMs can be 'taught' though. You can give them additional context or instructions.

That's not teaching. Giving someone new information in the moment does not amount to giving them new long-term capabilities.

> I don't particularly like eager new colleagues who come up with (hallucinate) wrong answers.

People are most likely to come up with suggestions and ideas earlier rather than later.

Often they’re not learning what is “correct” but just how to “fit in”. A fresh perspective can be good even if flawed. It can help others spark new ideas and think outside the box.

The problem often is that the new manager can teach their hires to write better code and train them to be new managers. Given that a team leader in such a scenario is often checking for correctness, I am not sure if current LLM based AI will ever be able to do it. We need new AI for it.

I agree there is a skill change but agents aren't people so managing them is very different. E.g. you can spin up 1000 agents. Get them inti tight loops and get them more context and so on. A manager doesn't do that with people.

Agents aren't people, but they anthropomorphise themselves real hard.

> E.g. you can spin up 1000 agents. Get them inti tight loops and get them more context and so on. A manager doesn't do that with people.

My dad had various work stories, one from when he interviewed applicants:

  "So, why did you leave your last job?"

  "After 6 months, the management discovered my entire floor and the one next to it had been hired to do the same task. One of the floors had to go, I got unlucky."

> make them much better at using agentic swarms.

Do you mostly use agentic swarms? If so, I’d be curious of your use cases. People talk about “managing agentic swarms” a decent bit, especially on LinkedIn. I just don’t see how they are the best solution for majority of development use cases. At best they seem like using only a hammer to make sculpture.. or a sandwich.

> Some devs just 'get it' and thrive, leading a team really well and building a great culture.

I don't think it's this because the outcome you get from AI isn't controllable. You can give it the best prompts and design suggestions and it'll still give you completely wrong or horribly written code.

If you were a manager and one of your reports kept producing completely wrong and horribly written code that other folks on the team keep bringing up as problematic in PR reviews or privately, that developer would eventually be fired for someone better.

But in the AI case, there is no replacement because all of the LLMs have severe problems.

>I don't think it's this because the outcome you get from AI isn't controllable. You can give it the best prompts and design suggestions and it'll still give you completely wrong or horribly written code.

sorry if it's not the case but i have the feeling you still think AI coding involves talking to a chatbox and copypasting the answers

> because the outcome you get from AI isn't controllable. You can give it the best prompts and design suggestions and it'll still give you completely wrong or horribly written code.

I don’t have a dog in this fight but it seems you’re not accounting for iteration and feedback. A horse will veer off of a road if not occasionally nudged to stay on it, but is useful transportation, nevertheless.

> I don’t have a dog in this fight but it seems you’re not accounting for iteration and feedback

You can provide AI official sources to look at and dozens of prompts. I've lost track of the number of times where it didn't arrive at the right answer with tons of opportunities to correct itself based on feedback.

Just an endless of sea of "you're absolutely right to have brought that up, I didn't think about that" and other phrases it constantly uses when it fails to provide a solution. Fast forward 20 minutes later and it starts providing the same nonsense it did at the beginning because it forgot what it already said.

The code solutions it provides are so consistently bad but it's not limited to code. I recently tried a YouTube feature where it can generate AI thumbnails from your video. The results were really lackluster. It completely ignored my feedback like "use a real webcam photo of me that you see in the video", to which the AI recreated a completely different looking human that wasn't me. It even swapped out my real glasses with a rendering of glasses I don't have and kept on making incorrect assumptions about everything. After about 10 prompts and 20 minutes of waiting for thumbnails I gave up, it was really poor.

None of that supports the claim that it "isn't controllable," though. A curious mind should probably find it interesting that it can be fallible in those ways yet still be useful for producing work, and ask how both can be true at the same time.

There's just no escaping from making decisions. Agents can't reliably make them as many rely on tacit knowledge which isn't written down.

This bottleneck will always have to exist unless companies just accept AI defaults, with predictable outcomes.

> Some devs just 'get it' and thrive, leading a team really well and building a great culture.

I think what makes a dev well suited for AI isn't the same as managing a team. What really helped me get productive is having to write a lot of user stories and acceptance criteria with the wisdom of being a dev tasked with implementing them. Also, being on the refinement calls, answering questions, and updating requirements/AC is good feedback for authoring better requirements. If you're good at authoring requirements, checking output, and communicating corrections concisely then you can get the LLMs to sing.

I find it interesting that when drawing this parallel you mention that some devs 'get it' and 'build a great culture'; I think this is exactly where the analogy breaks down. Good managers get great results from people (and for people! they are linked).

Good AI managers are just running optimization loops at more declarative levels. Yeah, you need to get comfortable with less personal review of code for both, but I think the differences outweigh the commonalities - it's much easier for someone with a more 'traditional' IC model to be successful with agents then they would be with management, and I think most (good) management training would be entirely irrelevant. Parallels are maybe tighter to higher IC progressions.

In my experience, it's the opposite. People who become dependent on AI agents are avoiding human contact, and people who become managers are seeking it out (for better or worse).

Completely agree.

The job isn't to write code. The job isn't to architect. Those are means to an end.

Anecdotally: it seems like the most principled developers are having the most trouble adapting to agentic workflows.

> Can you just give an agent a desired outcome and let it work, unsupervised? Absolutely not.

Ignoring instructions - whether in AGENTS.md or my prompt - is the worst of it, and it routinely happens. It just waives things that I explicitly told it to do as part of the design.

Vibe coders (in the true sense, zero oversight) claim that you just need to prompt it carefully. That's completely untrue when faced with your careful prompt being ignored.

I even have "don't overrule me without asking" in my global AGENTS.md, and it simply doesn't do that.

Also noticed this. Their intelligence is very jagged. I’ve had them produce some highly optimized code yet fail to follow basic code guidelines.

I’m convinced the magic bullet is deterministic checks. Linters, static analyzers, etc. Whatever you can do to create deterministic gates that the LLM simply must overcome to reach a “done” state, do it. Has been making a huge difference for my team, but sister teams are so invested in writing the perfect Make No Mistakes prompt that they just can’t see it.

Basically I treat it like a junior dev. We don’t get junior devs to write code correctly by cajoling them just right, we add CI gates. It still works.

Why aren't the teams using shared checks? Are the codes in different repos?

They’re very, very different projects.

Wouldn't have helped, sibling comment: https://news.ycombinator.com/item?id=48797883

Architectural decisions are not lintable.

You can have a separate LLM as a brutal enforcer of an architecture decision. Works pretty well in the right harness.

Wider architectural guidelines, yes. "How a senior developer in this company would do it" — not so much.

That’s what code review is still for.

> Architectural decisions are not lintable.

I made a tool called ProjectLint to lint architectural decisions and anything that ESLint and ArchUnit and others like that wouldn't be a good fit for. It's not public yet, but is fairly rudimentary and based on Go + goja: https://github.com/dop251/goja

You write rules in ESLint, it makes sure that they're followed. If it's a file in your repo, it can obviously be checked. Now whether you can describe your architecture well enough to lint it (at least the stuff you care about enforcing), that's a different question.

In my case it's more like: "Oh, the AI messed up this pattern, but it will need to be followed N more times in the future, better write another projectlint rule." After a while, you can even copy them over between projects, as long as they're following the same conventions.

In the same spirit of https://www.archunit.org/

> Whatever you can do to create deterministic gates that the LLM simply must overcome to reach a “done” state, do it.

First thing Gemini did when I tried that was turn off all the rules in eslint.config.mjs claiming they were "overly stylistic"

Yes, it got better once I explicitly told it not to disable any rules, so I accept I was holding it wrong but I do worry just how many footguns it puts into other things because I didn't know the right guardrails to give it.

Why does your harness allow the LLM to generate output that can disable rules & checks?

I have no idea because Google Antigravity is closed source.

Although I don't use it, Antigravity should be configurable to prevent reads / writes to certain files. You should definitely do that and ideally configure a hook to automatically run the linter after the LLM completes, then feed it back to the LLM if it's red. Don't prompt your agent to do stuff, build your loop in a deterministic manner.

Add hooks to block it from being able to edit the files you don’t want changed.

It will burn up the tokens to get through the deterministic gates, more so when n order dependencies are involved in the mix. Enough typewritters and monkeys could get it done too.

I found I used fewer tokens by having many short prompts than long ones — because it spent many fewer tokens thinking and narrating.

These are word generators, not agents, I’m really not sure why people think they could be capable agents (ie independent) when they consistently ignore instructions, generate the wrong things and then double down when questioned, etc etc.

You’ve been sold something that simply doesn’t work for the purported use case (intelligence) and instead is like a stupid database of all world knowledge with the appearance of intelligence.

Useful tools at times (if you bear in mind their limitations), but not close to intelligent, independent agents.

> instead is like a stupid database of all world knowledge with the appearance of intelligence.

A "stupid" database would be better, based on what I get when I ask whether all of Oregon state is North of New York City. Indian English has a word for it: oversmart.

Your context isn’t to give it orders, they just don’t work like that. Your context (AGENTS.me, skills, per-request context we are sending in for each request to bots) is to give it the info it needs in the language category it’s trained for the answers you want; you have to give it a clear instruction each prompt. Basically, when you have a long session, you can see this by saying, ok, now moving onto another thing, blah blah blah (implicitly ignoring all previous instructions). It can even back fire - nagging too much about don’t skip tests in the context can make it slip into the linguistic space where there is some emergency and faking the results might be justified (I imagine there is a certain amount of training out there “just making the tests pass for now, will fix later, I promise.” If you rarely mention tests except “this one is failing, please investigate what is going on” (an informational outcome not a test outcome), it doesn’t really “cheat” (tho it can leap to conclusions as always). The tests need to be some deterministic step in the process anyways, tests don’t need fuzzy word directed search capabilities. But the models just don’t have the structure to allow feeding in a ten page set of rules and follow them. You can add a step to say, please check this git commit for compliance with the 23 rules in this standards file, and it will work better to catch the gaps.

> Basically, when you have a long session, you can see this by saying, ok, now moving onto another thing, blah blah blah

I try to avoid > 200k contexts, as the 1M context is where I first saw the massive decrease in reliability.

And my AGENTS is really short, and I said it was ignoring decisions in the prompt.

Whenever I work on a challenging question I worry about this, because Opus will easily think for 200k tokens on the first prompt. I fear any follow up discussion is lobotomised!

Yeah totally feel you on this one! To avoid it or at least limit that I usually ask it to create external memories, clearing the context window and leaving just a trace to recall the memory created for that run. I hope it might help!

> I even have "don't overrule me without asking" in my global AGENTS.md, and it simply doesn't do that.

You really need to look into hooks based on your coding agent. This is very much a solved problem as I demonstrate with

https://github.com/gitsense/pi-brains

I have a test repo

https://github.com/gitsense/gsc-rules-demos

that shows how you can block and warn and do other things.

You obviously can't have a "Don't make a mistake" rule though.

So would that solve (most recent example):

The agreed architecture is to use signing between two micros, so that a third can orchestrate between them in zero trust way (and to prevent a distributed monolith). It just decides that we can trust the third and skips the signing.

In my limited testing Fable is far better at obeying CLAUDE.MD than Opus is.

From what I can tell, the "established wisdom" is to get Fable to plan and Opus to implement (for cost purposes). The problem there is that Opus could ignore whatever it likes from Fable's plan.

Honestly this is where I would have fable generate a checklist and you just monitor opus to ensure it is going through the checklist. I think ignore is often the result of a context that is not focused enough.

i've yet to see a case where opus "ignores whatever it likes".

opus will definitely ignore instructions if you give it contradictory instructions, or a plan that has steps that obviously don't work with each other. but if you give it a coherent plan, it will follow it.

Doesn’t that kill your token caching changing models midstream?

The Claude harness effectively summarizes the discovery into a plan document, clears, and starts with just that summary - so you'd be clearing context regardless.

Opus is famous for doing what it wants in the face of instructions.

> that I explicitly told it

Try writing it in first person instead of second person or neutral.

A while ago someone had a similar complaint on here and shared some example lines, and that popped out at me immediately. However much structure we've wrapped these in, they're still text generators trained on all sorts of things, and if you think about a narrative where first and second person speech would be used, try to imagine context: In first person, it's most likely a description of something as it happens or someone planning what they will do. But in second person, especially command form, you open up to the possibility of commands being ignored, misunderstood, or actively rebelled against.

Whoever that was back then did some quick tests and found the pattern held, first person got it to follow far more reliably.

Do you have a link to the previous comment?

Had to go digging, wasn't sure exactly when it was: https://news.ycombinator.com/item?id=46820663

The short leash method is the way to avoid this.

It can't follow orders because it isn't thinking - even in a best case scenario, all you're doing with AGENTS.md is altering the probability distribution of outcomes away from things you don't want towards things you do want.

However that still means there's always some probability it will do things you told it not to, it's just reduced

People will need to realize that these behavior are actually truly human in nature.

People thought they'd get their own persona through AI, they get a sum of the best and worse of everyone.

Companies are putting a ton of effort into getting to that point of having agents do the work unsupervised. Whoever gets there first is going to be the winner.

I personally don't think it's possible and I haven't written a line of code since Sept 2025.

There's an AI psychosis going on right now, especially among the execs or management class, and we all gotta nod our heads in agreement and burn through tokens.

If you have runway, it’s a good time to start your own thing or join someone who is. Personally, I cannot force myself to wade through slop PRs from careless coworkers. If that’s the job now, I’d rather run a hotdog stand or something.

Luckily, I don’t think things are that dire. I think the companies issuing AI mandates are manufacturing sawdust, and even if it works, it would just enable them to burn through customer goodwill in record time as they make user-hostile decisions free from engineer pushback.

These are going to be a few tough years, but I think the opportunities to start something new are everywhere.

Pretty sure it's going to be a tough couple of decades, not just years.

Of course I don't know either way. However, I feel like it's going to be different, but maybe not apocalyptic. The market I am building for is photographers, and from what I can gather (and know first hand as a customer) is that there's real discontent with the toolmakers in our ecosystem.

It seems like in the quest for every tech company to become a multi-billion dollar empire, they've lost the plot on making hammers for their customers and have instead turned into some kind of strip mining operation. A totally AI agent-driven company is a MBA wet dream, and I think a fever dream. If Adobe, for example, were to achieve it, I don't think they'd use it to fix the backlog of bugs overnight. I believe they'd just become an even more incoherent zombie, trying to extract rents from creative cloud subscriptions.

In the meantime, photographers still need tools. If you wanna run a software company as a regular small-to-medium-sized business, you may find some customers that are happy to buy a quality hammer. The unicorn startup days might be behind us, but I'd be okay with that.

Now, if AI obviates creatives altogether I don't really know what to say. I'd morn the loss of a world that became so tasteless that AI-generated decorations are good enough, for starters.

But even the market for "photographers" is arguably in secular decline. Smartphones and AI have turned everyone into a photographer. The world is awash in visual content.

It's true. Magazines sales are dead. Product photography is probably toast (I'm seeing companies test what they can get away with using AI generated images of their food/products right now). Sports? I don't even follow it but I suspect it's all video content now. Funny enough wedding photography seems to be doing fine as far as a commercial segment goes.

But there are segments of the market that were always small, and AI doesn't threaten. Namely, fine-art and long-term documentary. The kind of work that gets shown as exhibition and sold as prints or photobooks. I can't imagine this stuff be supplanted by generative AI, because it has never been about economic efficiency. It's a labor of love for a photographer to work on a project for years at a time because the subject is important to them. And the customers of these works are not likely to accept lower-cost substitutes produced by a AI. The whole thing is too much about taste and thoroughly infused with humanist ethics. When I buy a photobook, I want to know that the artist lived and produced what I'm seeing, not just that it's pretty ink dots on paper.

From a market analysis perspective it's foolish to cater to these tiny and commercially nonviable artists. However, they have enormous esteem and influence within the community, and make part of their living as educators. I believe making tools that they need, and without blood-sucking cloud subscriptions, you are indirectly marketing to all the creatives (usually tending toward commercial) who attend workshops and see what tools they are running the workshop with.

Agents already run unsupervised, and they can code unsupervised too. The real question is what worthwhile work we should point these capabilities at. Nobody has really cracked that yet.

The same worthwhile things we were working on before agents. I’m personally using them to autonomously build open-source Shopify for every vertical. I set out building it before AI, but AI actually makes the dream feel achievable.

Have you got booked revenue for any of those verticals, using your system?

Yes we have provided custom storefronts for people running the SaaS on-prem and we have a handful of people using our cloud hosting. This is all without any marketing efforts and word of mouth. Albeit, we launched the Shopify alternative in Dec 2025 and the Toast alternative in May 2026. The gym and grocery ones in the works.

My main goal is to first get all of these open-source alternatives to start building themselves autonomously using loops and a Hermes-like scheduler before I focused on marketing. This is almost complete.

For marketing, we are building a GTM engine using an open-source CRM (Twenty). We have LLMs use the Twenty CRM API to bring in leads from X, LinkedIn, and the Web.

The cloud hosting is not the only monetization. We’re going to use these open-source SaaS to build a decentralized, interoperable marketplace where the people actually bring value, the sellers, can sell without those rent-seeking entities like Amazon taking a piece of every sale. LLMs are already going to start jumping across these marketplace moats.

The other monetization is going to be letting agents actually run these SaaS and see if they run a business autonomously. Like VendBench but an actual online business. I’m thinking of starting a designer brand, connecting to a POD (print on demand) and then let the agent create seasonal lines, handle customer service, and make sure orders are going to the POD and being processed. Doing this with restaurants and other verticals will probably need some human supervision.

Interesting. Where is this product located? If I'm looking at your profile correctly, this appears to be Openship[1], which is just a collection of starter templates from something from Nextjs and something called Keystone for each vertical. Is this what it is you are talking about?

I'm very curious how much revenue this is generating.

[1] https://github.com/openshiporg

Yes, it’s built on the shoulders of giants, Next.js[0] and lesser-known Keystone.js[1].

Next is a full stack framework and Keystone is a CMS built on top of Prisma and GraphQL. Keystone was created by this Australian company called Thinkmill. They have used it to help businesses build custom backend systems for more than a decade. But it needed to be deployed separately from Next and they were using emotion css for their dashboard and I wanted to use Tailwind/Shadcn. So first, I had to make the Next Keystone Starter that brought in Keystone into Next so each SaaS is just 1 Next app with a built-in storefront, GraphQL API, and dashboard.

Once that was built (and it took a while tbh), I started to build the Shopify and Toast alternative. But the itch to get these built quickly and autonomously had me working on the harness in the past months and now that is nearly complete.

Here is the e-commerce[2] and restaurant[3] repos. They have a link to deployed demos you can check out as well.

As far as revenue, I don’t feel comfortable relaying that right now. We have other revenue streams like fractional CTO where companies give us equity to manage all their tech and that is quite hard to quantify. Before Openfronts being built, I built Openship, and e-commerce OMS and that has exceeded 5M orders processed since its inception in 2019. That’s not counting orders by businesses running it on-prem.

I actually posted about this vision on HN[4] when I launched Openship and the response is what kept me building.

0. https://nextjs.org

1. https://keystonejs.com

2. https://github.com/openshiporg/openfront

3. https://github.com/openshiporg/openfront-restaurant

4. https://news.ycombinator.com/item?id=32690410

First I know what next is. Its standard enough.

Second, take this for what it is: your product may not be compelling in its current form. Building it to many different markets will not make it compelling. If you had a stronger revenue, please share it. This sounds incredibly thin.

Third, dont mistake building the same thing 20 times for different verticals for bonifide software skills. When a SWE builds the thing they have built before its usually to learn a language which is the easiest part of software. There is a reason a common adage in software is "9 women cant make a baby in a month". Breath is no replacement for depth.

Don’t take my word for it then, ask any terminal agent to dig in and get an idea of how good these apps are.

In the end, I built Openship and Openfront for my e-commerce business and then turned them into SaaS. All the revenue for these are just a cherry on top of our existing e-commerce businesses.

And I worked with Next and Keystone long before AI came along. Check my GitHub commits if you need some back story.

And I’m not building these 20 SaaS to prove I have bonafide SWE skills. I’m building them because I plan to have my own gyms, hotels, grocery stores down the line powered by these SaaS. SWE to me a means to an end and that’s to have many different businesses.

> Don’t take my word for it then, ask any terminal agent to dig in and get an idea of how good these apps are.

Okay but, you know this isn't a quality metric right? These models are incredibly biased towards positive confirmation of the prompt. I could give them nearly any repo and they would sing the praises of the best parts, if I asked.

This sounds a bit like psychosis.

I never told you what prompt to even feed your AI my guy. As far as I know, you can be like rip this repo to shreds and tell me what’s wrong with it and you’ll get your answer.

Crazy how you guys blindly trust proprietary apps where you can’t even read the code but asking you to read open-source code is psychosis?

> Crazy how you guys blindly trust proprietary apps where you can’t even read the code

Wow okay, I'm a huge open source advocate, I run hardly anything closed source. No one here was talking about that, this is your own weird segue.

> but asking you to read open-source code is psychosis

But you didn't ask that. You told me to get an agent to read it (actually, not even read it, make its own quality assessment for me).

That's a massive difference, and if you consider them to be the same thing, then yes, my statement stands.

You say you only use open-source and I’m the same way but I’ve asked agents to evaluate open-source alternatives. How is that psychosis? If it’s typescript or JavaScript, I can read the code but if it’s Rust/Go/etc, yeah I get AI to read it and tell me if it can solve my problem or if it has the features I need.

It’s actually the whole premise of my open source alternative directory called Opensource Builders[0].

0. https://opensource.builders

very much seems like a product built by an someone with no product research. The UX makes no sense for e-commerce.

That’s the neat part, you can use it headlessly. The built in dashboard and storefront are using the GraphQL API but you can deploy your own external dashboard and storefront using the same API.

We’re also very bullish that the chat interface is the universal UX now. Instead of sifting through the dashboard to change a product price or sell in a new region, you can use the built-in agent and just tell it to do that. Every Openfront comes with an MCP server that interfaces with the API so the agent can literally do anything you can do using the dashboard and API. This is where an agent running the business autonomously comes in.

And even then if you’re not satisfied with the backend API for each vertical, these Next apps can be forked and adapted to tightly fit your business instead of you messing with configs, you can make the app your own.

I don't think it's possible either. DHH pointed out in the most recent episode of Rework that AI removes a lot of the barriers to shipping code, therefore making it possible to build in lots of different directions in ways that was prohibitive to many organizations in the past. But this isn't necessarily a good thing, companies still need to understand what to build in order to ship a cohesive product. AI is great for prototyping and refining use cases in ways that are far superior to static figma designs, etc., but it is not a replacement for taste and execution.

But a slop machine that haphazardly shoots features against the wall to see what sticks still isn't a winning product strategy in 2026. And the problem I see increasingly is that so much energy is being focused on how to deliver with AI internally and externally that is not being expended to advance a company's product. I believe more and more in the idea that for many startups and companies, the actual "customers" are the investors and the product-market fit that companies seek is the product of the company itself, because this is all being driven from the top down, not by customers and users in the market asking for AI features.

> I believe more and more in the idea that for many startups and companies, the actual "customers" are the investors and the product-market fit that companies seek is the product of the company itself

In many respects this reflects the growing K-shaped nature of our economy. Average consumers don't matter because you really just need a small cohort of wealthy individuals to be hyper-invested in your product, 'regular' consumption is therefore just a way to keep things relatively on rails rather than the actual economic driver.

All of these AI-first companies don't actually have any market fit, so what they're doing is selling an imaginary product so that they can get investments and loans. As you said the company is the product.

But that's the nature of the beast isnt it? A probabilistic token predictor will all always have some errors from a human perspective, more and more energy, money and resources will always be needed to control and direct towards desired outcomes.

The bottleneck wasn't the coding, but previously it had the second order effect of slowing product development decisions enough to improve product cohesion.

It also created a cargo cult though.

"What can we get rid of for MVP" as a design strategy vs a way to iterate fast, for instance. Cutting things isn't a way to product cohesion, especially if you never go back to do the full-featured version.

Sometimes I wonder how many features or products flopped because the MVP dropped the things that would've actually taken off, and the business "smartly" pivoted away.

There's still a limit to how many new features you could shove in front of your users per month. But what if they were all much more baked out of the gate?

(See also: "data driven" product management as an excuse to not have your own vision for the product. If three competitors build a lot more in the span of six months, but have to depend more on their own skills and instincts vs A/Bing every little detail, maybe more of them will ship more bold and interesting new things.)

the opposite can also be true, feature bloat can destroy products by making it unclear for users what they should expect.

I'm really struggling to get an agent to write code I'm happy with. It's mostly pretty awful.

I've a fairly simple c# coding style. But simple is proving a bit more difficult to convey than I thought.

I get it to produce code. I then have to spend along time convincing myself it's correct. If I don't I end up embarrassing myself when a coworker reviews it, questions it and it's obvious I don't properly understand it.

This is really starting to screw with me mentally. It's like everyone in the world is saying they can fly by flapping their arms (dark factories). When I try I just stay in the same spot burning a lot of energy.

I don't think everyone in the world is saying they can fly by flapping their arms. It's a small number of very vocal, very online, AI enthusiasts, many who have a financial stake in AI winning.

work from tests to implementation. Validate the tests, and work with the agent to ensure there are not more cases that need testing. Then you can let the agent implement the code and you can refine it until it's simple enough but covers the test cases. TDD is the only way to use agents effectively, imo

Thanks. I have been doing this tdd abd it's a big improvement but the code is still pretty awful. Two skills I rely on are Matt pococks grill-me and his tdd. These massively helped, and technically the code generated is correct but it's still hard to follow and bloated.

https://github.com/mattpocock/skills/blob/main/skills/produc...

Measuring software performance by lines of code is like measuring aircraft performance by weight.

I have no idea why everyone seems to have forgotten this simple fact over the last four years.

Measuring aircraft production per weight doesnt sound like that bad of a proxy. If I hear that Boeing produced 300 kilotons worth of aircrafts more this year, I'd be right to suspect they've ramped up production.

Every day we stray further into depravity and barbarism.

I think you're overlooking the lesson of Goodhart's law: you can use a metric, but if you make it a target, it stops being a good metric. Neither "tons of aircraft" nor "lines of code" should be the measuring stick -- and if they're not, then they can still be used as metrics.

To be fair, the hazard with AI agents is that they generate fluent output that is often facile, so it's easy to do a lot of things while having a lot of defects. That's a sign that quality control is not prioritized enough. A change in quality will also reduce the utility of SLOC as a metric, but the mechanism is different than what Charles Good hart pointed out.

"companies would have slashed their engineering teams down to a handful and everything would be driven by mostly autonomous agents with human guidance. But it just hasn't happened. "

It never was going to happen.

Always the same story: https://en.wikipedia.org/wiki/Gartner_hype_cycle#/media/File...

> I was worried this time last year that by this time this year, companies would have slashed their engineering teams down to a handful and everything would be driven by mostly autonomous agents with human guidance. But it just hasn't happened.

Amara’s law: We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.

This continues to be applied to AI where people think is going to be next 12 to 18 months. Changes are coming but certainly not at the rate Zuckerberg and most people are thinking.

I believe this in general but the issue with AI specifically is historically in every cycle we've overestimated the potential of AI in both the short and the long run - people in the 60s were genuinely quite convinced we were close to AGI for a few years, as ridiculous as that now sounds.

This is why you get "AI winters" but we've never had a "steam engine winter" or a "railway winter" or a "petrochemicals winter"

It's interesting to score our predictions of various technologies. I've been waiting for hoverboards for 40 years. Our predictions of nuclear power being in every consumer appliance were way off. We just couldn't make it safe and cheap enough. This is a common theme for "physical" technologies. On the other hand, we greatly underestimated the advent and potential of the internet. Most science fiction of the 20th century envisioned very large computers with limited interconnected capabilities. We made computers far smarter and more ubiquitous than most could ever have conceived. I see AI as a function of the kinds of technologies we consistently underestimate.

Yes, that's a fair counterpoint. I guess my counter-counterpoint would be that LLMs actually seem to have characteristics closer to the first group than the second, in that they (currently at least) need enormous quantities of physical things and energy in order to work.

So the nuclear power problem of "it works fine and it's actually very good in a lot of ways, it's just too expensive" could be quite relevant

Back in the day there was a mantra: best amount od code is 0. Now we have agents spitting lines after lines.

I am not afraid of my future. Even if one person can do work of 5, the amount of generated code will grow exponentially. And not everything can he vibecoded with 0 knowledge. There is a complexity that need understanding to change and optimize. For now :)

> Back in the day there was a mantra: best amount od code is 0.

It was true for that time, because producing and maintaining the code was done by humans with limited speed of comprehension.

Today, we might challenge this assumption (not saying its wrong or right), because migrations can be done in 1-2 weeks with hundreds of agents.

I think it doesn't prove much that it hasn't happened yet. Companies might just be moving slower than you think, and are still planning on doing it. And, in many corners, "don't manually write code" is being joined by "don't manually read code" as an attractive principle.

The Yale economist Pascual Restrepo, who is well regarded researcher in automation, doesn't think it will happen for most jobs.

https://fortune.com/2026/04/04/ai-jobs-future-not-important-...

you might have to think the way through though and these companies are already being caught up with the huge token costs at the same time.

There was an interesting comment during the cloudflare layoffs (partially driven by the fact that the company was bleeding money also because of its token costs from one estimate being 5* million$ per month (I feel so silly that I accidentally had written/meant 500 and had kentonv do the stats on that part :-( Sorry kentonv!), don't quote me on that though)

The part was that there is only an enough marketshare in the first place. Cloudflare was doing some crazy experiments like operating matrix on cf workers and wordpress alternative and fediverse and so much stuff.

So they basically spent 10x the amount of token (and the token costs) and I imagine as such the reading code of that part was getting sidelined as the attractive principle you are talking about.

Yet the market can't bring an actual demand 10x times though. These are things which nudge a user slightly but the actual impact on user growth isn't 10x or even justifiable within some cases given the costs.

Yet at the same time driving up the people who actually know their stuff and firing them because of the token costs. The people who have actually mitigated some of the largest DDOS attacks and are the backbone behind cf cash-cow (enterprise payments) is the fact that they have had the experience and entreprise knowledge about these things, yet they are literally removing that by firing workers and oh replacing them with interns. (They got 1111 interns and fired 1100 employees or something iirc)

It's weird and I have talked to some people about it but there is a disconnect between what management is hearing about AI and the ground reality of things. Reviewing code is becoming the bottleneck but if you don't review code and are shipping things to production, then you can get fired as I have talked about in some of my other comments sharing a story about how a guy shipped code to prod and the response was "but claude generated it" and got fired because the company basically said, look we basically don't care if it was generated by claude but the responsibility was on you to check it (review) and because the commit was done by you, you are gonna be treated responsible and he got fired from his job.

Yet this was the same company which was asking its employee to play around with claude at their free time, the manager of the employee I talked to being the most automatable person, the company employees working till 1 AM because they were saying to management that things were fine but they were being burried under the technical debt,that employee that I talked to got honest with the management and told reality and the management treated them as a person who didn't know AI or were the odd one out.

Sooo I don't know actually to be honest.

TLDR: reviewing code is being treated as the bottleneck but it is also the only thing stopping your company from imploding under technical debt, actual debt because of token costs etc. I remain skeptical if we should treat it as a bottleneck or as a safeguard mechanism. After all, if nobody's in the loop then whose responsible?

Reviewing code isn't a bottleneck so much so its a safeguard mechanism in my opinion. Also things differ in corporate land and hobby land and I would prefer corporate to not be using the practices that I do with how I do things for fun in my hobby time.

Side note: Even more so, I think I am a LiteLLM security working group maintainer and I have seen first hand on how much damage it can do in supply chain even when things were done right from LiteLLM side and the fault was within the side of ironically a security product that they used called Trivy.

There are things which you can do to be better prone to supply chain attacks in general but there is no full bullet proof way of doing so and in such.

Caution (should) be taken when dealing with corporate systems and as such I sweat a little when anyone suggests code review to be completely eliminated. Things (are/can be) different in hobby/prototyping world though.

> (partially driven by the fact that the company was bleeding money also because of its token costs from one estimate being 500 million$ per month, don't quote me on that though)

Cloudflare had 5000 employees (pre-layoff), so you are suggesting that every single one of them (eng, HR, legal, finance, receptionists) was using $100k tokens per month (that's $1.2M annualized, per employee), for a total of 3x gross revenue going to AI spend.

Let's imagine that this isn't absurd on its face. If true, then you'd expect Cloudflare's Q1 earnings to show a massive, massive net loss. In fact Cloudflare was cash flow positive in Q1.

The rest of your post is more qualitative, so harder to disprove, but from what I can tell, it seems equally made up.

(I work at Cloudflare.)

Sorry kentonv! , I apologize :-(

I had mistakenly written 500 million when it was around 5 million dollars so I messed up its 5 million per month[See Source], not 500 million. I wish to have a genuine discussion while you are here though because i can be wrong, I usually am and I would love to have a good faith discussion, thanks in advance!

I will try to back up a lot of it with hackernews comments from the thread when cloudflare layoffs were suggested so that I don't accidentally mis-represent anything and My suggestion wasn't a critique of cloudflare and please don't take it as such. The question was simply of the AI token costs associated.

and this was the comment that I was referencing to[0] which states the following:

> There was an recent article on X with an interesting take - it could be that companies are doing layoffs not because AI is making them more productive but because it hasn't. Their costs have gone up paying for expensive AI but haven't seen any revenue benefits to offset it.

An child comment of it talks about the coinbase layoffs which had happened around the same time[1]:

> (..) In 2023, their "Technology and Development" line item shows $1.32bn going out, and by 2025 it'd ballooned to $1.67bn. This is despite headcount actually contracting by almost a thousand people between those two statements.

Regarding this: > Let's imagine that this isn't absurd on its face. If true, then you'd expect Cloudflare's Q1 earnings to show a massive, massive net loss. In fact Cloudflare was cash flow positive in Q1.

We might be forgetting that (from my understanding, Cloudflare has never had profits) (positive annual net income) with an astronomically large P/E ratio.

There was a comment which I had read which talks about this in more detail (https://news.ycombinator.com/item?id=48060393):

> > The fact so many orgs opt for immediate greed over long-term growth really is its own canary that leadership and governance both has failed the marshmallow test.

> Why do you think it's greed? The company's stock is down and they just missed expectations on their last earnings report (unheard of in big tech in the last 2 years).

> It seems more like a traditional layoff scenario

Another comment [from the Layoff thread][2] which might summarize some things:

"Their AI costs have increased 600% but this hasn't translated into actual revenue. Also they are probably projecting AI costs to keep growing. They've done the math and at some point it is going to affect their bottom line. Reducing or limiting AI usage would be inconceivable given Cloudflare itself has invested on AI and is selling AI services. Instead they've opted for reducing about 20% of their head count."

I genuinely wish if we can have a good faith discussion about it. I appreciate cloudflare as a product myself and actively use cf tunnels, which is why I care about it as well and I wish to have a good faith discussion about it hopefully as well :-D

> The rest of your post is more qualitative, so harder to disprove, but from what I can tell, it seems equally made up.

I can be wrong, I usually am and if I am wrong, I wish to learn from it and I wish to improve as a person too!

I have learnt from this discussion (up until now) that I should mostly try to provide sources whenever talking on a public place/ on the internet so that I can be more accurate and I sincerely wish to have a good faith discussion once again, thanks and have a good day @kentonv :-D

[0]: https://news.ycombinator.com/item?id=48055149

[1]: https://news.ycombinator.com/item?id=48055413

[2]:https://news.ycombinator.com/item?id=48056124

[Source]: https://lowendtalk.com/post/quote/217055/Comment_4789235

Sure but there's also little reason to think we'll be able to replace xyz role entirely with software next month, or year, or decade. It's easy to disprove claims about the future; it's quite difficult to make believable ones.

> in many corners, "don't manually write code" is being joined by "don't manually read code" as an attractive principle.

I'm pretty sure I know where the failure case on that one is. The reason we're still manually reading code is to catch the failures and edge cases that the LLM fails to; not reading the code doesn't magically make the code good.

I have experienced and feel very much the same, and it is refreshing to see a realistic post about the success of agentic coding instead of the usual hype or doom.

I would add that a lot of that extra code is often in test/demo paths... I tend to think of working with an Agent as a "team" of 1 + agent... where the developer is now wearing a QA and PM hat in addition to lead/sr dev. That the work getting done is now roughly the offset of what a team would have produced and that coordination needs to step back and treat each individual with an agent as roughly a dev team. Coordination overhead and mythical man month still apply, just at a layer up.

I can similarly output 2-3x more code but everything stalls down to me having to review and integrate in a meaningful way the moment I am the one that has to maintain that code.

It's eerie to observe collaborators output code they don't understand, spend days chatting with Claude instead of reading (like really reading) compiler's output or 3 pages of manual, and how lost and oblivious they look when the AI fixates on solving a different problem than the one they have been tasked.

As crazy as it may sound, my workflow today does not look too different from a year ago - where I was already heavy into claude code.

Im not certain things will look too different a year from now either. We still have serious bottlenecks in terms of focus/attention you have for both delegating agent work and being able to review it. Even if we solve the "trust what ai does" problem, these cognitive deficit issues still exist - for teams coordinating work, even users adopting new shit, etc.

As an industry we are leaning heavy into accepting "slop" as the status quo - we care more about efficiency of output right now. Slop will get better & we can become more adaptive to living with the paradox of amazing yet delicate systems generated by AI. But I feel big shifts coming in this regard and if/when it does we may find ourselves in the dystopia of broader unemployment with worse net outcomes.

I do think the teams that ship quality with AI will do so by learning to slow down

https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing...

As a hobbyist coder, I wonder how much more new code, fundamentally, there needs to be? New devices need new firmware, new cars etc, but how much of that is bespoke? Sure, a new movie or a book is new entertainment, but I've already seen that movie and read that book, they just had different jackets. What do these "engineers" actually do that is novel and how much of the pizza is the novel slice is?

I feel like the increased reviewing time is consistently understated. I’m just an IC, but it seems obvious to me that you cannot cut staff and achieve increased output. There literally aren’t enough eyeballs to go around reviewing code when everyone is 2-3xing their output. I spend so much more time reviewing code; reviews that are sorely needed because I regularly catch batshit insane “fixes” that work but would quickly turn the codebase into a mess (the most recent one being a multi-hundred line diff that I went and fixed in 2 lines in 15 min). Maybe I’m underthinking it but it seems obvious that you either maintain the same output with fewer staff or you gain increased output with the same staff. All the companies that are attempting to cut staff and gain increased output are chasing an impossibility and throwing away their opportunity to accelerate.

Could be lack of imagination on my part but I truly can't imaging shipping 1000's of lines of code that I can't understand (beyond low-stakes prototypes). That means there's a ceiling on productivity gains.

I kinda love that you made this post feel negative enough that a bunch of AI skeptics are enthusiastically agreeing with a post suggesting that the realistic, pragmatic bear case for AI is, uh, 2-3x productivity improvements.

Make sure to have an agent audit your codebase for redundant code and dead code

When you come back to the codebase in two weeks or a few months, the agent just redoes stuff

If you end up with 2 to 3 times more code. That is HORRIBLE, because it means about 50-66% of the code is otherwise unnecessary. Those are eventually going to become unmaintainable garbage.

However, if you get 2 to 3 times the code in the interim, that's probably less than what's needed. I find myself cycle through almost 10x-20x amount of code implementations to get what I want which is actually less code, simple solution and desired behavior.

Given a specific behavior, there are usually just 1 simplest implementation, whether done by human or AI. However, there are 100 ways to do it with more complexity and either handwritten or AI slop, it will mean pain down the line. We used to have a lot of handwritten complexity because of certain design pattern culture, but they used to be contained because the ability to generate them is costly. Now it's much more risky and therefore more important to have simplicity as the guiding principle in ALL projects.

“How many Kloc did you submit today? I did 12.”

"How much on user account support?"

"..........."

Do you mean that to implement the same features, the agents write 2-3 times as much code as a human would write before?

My experience is that AI agents write 20-33% more code than I would for a given feature set, mostly because they are worse at remembering what utility functions already exist and less likely to merge similar functions into more generic ones. They generate that code 2-10 times faster than I could. Defect density is harder to compare: I probably generate more "dumb" defects due to oversight or missing unit tests, but fewer defects that violate domain rules or architectural objectives.

Frankly: if you want it to be good and stable, you can't really go any faster than before. The time it takes you to review all the code is no less than it would've to just write it in the first place, because the actual typing things out was never the part which took up time.

Im not worried about anything within 1 or 2 years. The upheaval if it happens will likely be within 10.

so 3 times more code to maintain in long term too. With no human that actually understands it on staff

I feel like even those benefits gonna melt pretty quickly. It's great as code review buddy tho

Have you honestly not noticed how dried up the tech job market is? This take is bizzare to me.

Ick. Stop.

Reply on news.ycombinator.com