Thoughts on slowing the fuck down | Hacker News Reader

Thoughts on slowing the fuck down

mariozechner.at

1,130 pointsjdkoeck485 comments

What the article doesn't touch on is the vendor lock-in that is currently underway. Many corps are now moving to an AI-based development process that is reliant on the big AI providers.

Once the codebase has become fully agentic, i.e., only agents fundamentally understand it and can modify it, the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments.

Sure it will be - perhaps - possible to interchange the underlying AI for the development of the codebase but will they be significantly cheaper? Of course, the invisible hand of the market will solve that problem. Something that OPEC has successfully done for the oil market.

Another issue here is once the codebase is agentic and the price for developers falls sufficiently that it will significant cheaper to hire humans again, will these be able to understand the agentic codebase? Is this a one-way transition?

I'm sure the pro-AIs will explain that technology will only get cheaper and better and that fundamentally it ain't an issue. Just like oil prices and the global economy, fundamentally everything is getting better.

I have similar concerns.

We will miss SaaS dearly. I think history is repeating just with DVD and streaming - we simply bought the same movie twice.

AI more and more feels the same. Half a year ago Claude Opus was Anthropics most expensive model - boy, using Claude Opus 4.6 in the 500k version is like paying 1 dollar per minute now. My once decent budgets get hit not after weeks but days (!) now.

And I am not using agents, subagents which would only multiply the costs - for what?

So what we arrive more and more is the same as always: low, medium, luxury tier. A boring service with different quality and payment structures.

Proof: you cannot compensate with prompt engineering anymore. Month ago you fixed any model discrepancies by being more clever and elaborate with your prompts etc.

Not anymore. There is a hidden factor now that accounts for exactly that. It seems that the reliance on skills and different tiers simply moves us away from prompt engineering which is considered more and more jailbreaking than guidance.

Prompt engineering lately became so mundane, I wonder what vendors were really doing by analyzing the usage data. It seems like that vendors tied certain inquiries with certain outcomes modeled by multistep prompting which was reduced internally to certain trigger sentences to create the illusion of having prompted your result while in fact you haven't.

All you did was asking the same result thousands of user did before and the LLM took an statistical approach to deliver the result.

Are you saying we increasingly get ML results and not LLM resuluts?

> we simply bought the same movie twice

Maybe you did, but I certainly didnt.

> 1 dollar per minute

so 60 usd / hour? a plumber earns more

if this allows you to produce features that bring you money, it's a no-brainer

Plumbers are working on very standard systems, they have to front costs and secure work. It only works for them because enough people use basic plumbing services to sustain them. But how many have return customers and guaranteed work for long term projects?

No one ever asks how much it costs Facebook or Uber to serve requests because it is irrelevant, they set prices to maximize their profit like any good monopolist. Similarly the future cartel of big providers will charge their captive users whatever they can get away with, not the cost of inference.

The current discourse around "AI", swarms of agents producing mountains of inscrutable spaghetti, is a tell that this is the future the big players are looking for. They want to create a captive market of token tokers who have no hope of untangling the mess they made when tokens were cheap without buying even more at full price.

> Once the codebase has become fully agentic, i.e., only agents fundamentally understand it

What exactly do we mean this? Because it is obviously common for human coders to tackle learning how an unfamiliar and complex codebase works so that they can modify it (new hires do it all the time). I can think this means one of two things:

* The code and architecture being produced by agents takes approaches that are abnormally complex or inscrutable to human reviewers. Is that what folks working with cutting edge agents are seeing? In which case, such code obviously isn’t beeping reviewed; it can’t be.

* the code and architecture being produced by agents can still be understood by human reviewers, but it isn’t actually being reviewed by anyone — since reviewing pull requests isn’t always fun or easy, and injecting in-depth human review slows everything down a lot — and so no one understands how the code works. (I keep thinking about the AI maximalist who recently said he woke up to 75 pull requests from his agent, like that was a good thing)

And maybe it’s a combination of the two: agent-generated pull requests are incrementally harder to grok, which makes reviewing more painful and take longer, which means more of them go without in-depth reviews.

But if your claim is true, the bottom line is that it means no one is fully reviewing code produced by agents.

Folks are reviewing the code, but the standard shape of a review is a PR. This diff assumes you have an underlying knowledge of the system, one that is most realistically gained by having written the code. Could you “just remember” every diff you’ve seen? Maybe, but I don’t think it’s realistic; we learn far better from doing than from reading.

> What exactly do we mean this? Because it is obviously common for human coders to tackle learning how an unfamiliar and complex codebase works so that they can modify it (new hires do it all the time).

I agree with you, BUT: I find it much harder to get my head around a medium sized vibe coded project than a medium size bespoke coded project. It's not even close.

I don't know what codebases will look like if/when they become "fully agentic". Right now, LLM-agents get worse, not better, as a codebase grows, and as more if it is coded (or worse architected) by LLM.

Humans get better over time in a project and LLMs get worse, and this seems fundamental to the LLM architecture really. The only real way I see for codebases to become fully agentic right now is if they're small enough. That size grows as context sizes that new models can deal with grows.

If that's how this plays out - context windows get large enough that LLM-agents can work fine in perpetuity in medium or large size projects - I wonder if the resulting projects will be extremely difficult for humans to wrap their heads around. That is, if the LLM relies on looking at massive chunks of the codebase all at once, we could get to the point of fully agentic codebases without having to tackle the problem of LLMs being terrible at architecture, because they don't need it.

And is "model collapse" a thing when LLMs are trained on 100% LLM-generated code? Fun times ahead.

For your points:

- Garden path approaches are definitely a thing, but I don't think this is necessarily catastrophic. A lot depends on the language and framework in question, and also the driver of the change.

- I think it's that plus the fact it's easy to just generate ever more code. Solutions scale in every dimension until they hit a limit where it's not feasible to go further. If AI tools will allow you to write a project with a million or 10 million lines of code, you can bet it will eventually happen. Who's ever gonna fix that?

This is a great point, and I routinely use it as an argument for why seasoned professionals should work hard to keep their skills and why new professionals should build them in the first place. I would never be comfortable leasing my ability to perform detailed knowledge work from one of these companies.

Sometimes the argument lands, very often it doesn't. As you said, a common refrain is, "but prices won't go up, cost to serve is the highest it will ever be." Or, "inference is already massively profitable and will become more so in the future--I read so on a news site."

And that remark, for me, is unfortunately a discussion-ender. I just haven't ever had a productive conversation with somebody about this after they make these remarks. Somebody saying these things has placed their bets already and are about to throw the dice.

There is no such thing as agentic codebase. If humans don’t understand it, nothing really does. Agents give zero fuck about anything. If they burn 100 or million tokens to add a feature, they don’t care. It’s the developers responsibility to keep it under control.

100% this. With these new tools it's tempting to one-shot massive changesets crossing multiple concerns in preexisting, stable codebases.

The key is to keep any changes to code small enough to fit in your own "context window." Exceed that at your own risk. Constantly exceeding your capacity for understanding the changes being made leads to either burnout or indifference to the fires you're inevitably starting.

Be proactive with these tools w.r.t. risk mitigation, not reactive. Don't yolo out unverified shit at scales beyond basic human comprehension limits. Sure, you can now randomly generate entirely (unverified) new software into being, but 95% of the time that's a really, really bad idea. It is just gambling and likely some part of our lizard brains finds it enticing, but in order to prevent the slopification of everything, we need to apply some basic fucking discipline.

As you point out, it's our responsibility as human engineers to manage the risk reward tradeoffs with the output of these new tools. Anecdotally, I can tell you, we're doing a fucking bad job of it rn.

The big AI projects I've seen at work are...

- A Kafka topic visualization dashboard

and

- A chrome extension the original "developer" can no longer work on cause the bots will wreck something else on every new feature he tries to add or bug he tries to fix

I think we're a ways out from truly complex code bases that only agents understand.

I've seen a bunch of hype video where people spend lord knows how much money in order to have a bunch of these things run around and I guess... use Facebook, and make reports to distribute amongst themselves, and then the human comes in and spends all their time tweaking this system. And then apparently one day it's going to produce _something_ but two years and counting and much like bitcoin, I've yet to see much of this _something_ materialize in the form of actual, working, quality software that I want to use.

My buddy made a thing that tells him how many people are at the gym by scraping their API and pushing it into a small app package... I guess that's kind of nice.

Lately I also wonder about the geopolitical lock-in and balkanization of the internet. US won't have this problem I guess. But with all that's happening in the world right now and the current trends, for the rest of us we need to think hard what AI company we trust with our data or trust to still have access to once we're on the other side of the wall.

> geopolitical lock-in and balkanization of the internet. US won't have this problem I guess

This reminds me of the apocryphal headline from the dying days of the British Empire:

> Fog in Channel; Continent Cut Off

If only the AI understands your code, then vendor lock-in and exposure to price hikes will be the least of your problems. I don't think that you will be able to add Claude as the Dev-On-Call to your pagerduty schedule. If you are in an industry that requires due diligence and you get sued for bugs that cause material damage and human suffering, then I don't think the "blame it on Claude" defense is going to land well in court. I cover these topics on https://www.exploravention.com/blogs/soft_arch_agentic_ai/ which is a blog I wrote recently.

I'm beginning to develop the opinion that the next step in this process will (or at least should) be local and/or self-hosted inference.

The latest qwen models are already very useful, and the smaller ones can be run locally on my laptop. These are obviously not as good as the latest frontier models, and that's extremely noticeable for the development workflow, but maybe in a year or two, they will be competitive with the proprietary models we have today, which are incredibly capable. I also expect compute for inference to continue getting cheaper.

The current lock in for me is the UX of Claude Code / codex cli, but this is a very small moat that will definitely be commoditized soon.

I've been thinking this for a while now as well. If they keep subsidizing for long enough there might be a large gap of humans that changes jobs, didn't get into the field in the first place. Then the only way out is to keep buying those tokens.

Code is so low entropy that smaller and more economical models will be up to the task the same as gigantic models from big providers are today.

No worries there, the huge improvements we see today from GPT and Claude, are at their heart just Reinforcement Learning (CoT, chain of thought and thinking tokens are just one example of many). RL is the cheapest kind of training one can perform, as far as I understand. Please correct me if that's not the case.

In the economy the invisible hand manages to produce everything cheaper and better all the time, but in the digital space the open source invisible hand makes everything completely free.

> the open source invisible hand makes everything completely free.

In this case the limitation is the compute. Very few people have the compute required for AI/LLMs locally or for free (comparable to the performance of Claude). So yes, there are plenty of Open Source models that can be used locally but you need to invest in hardware to make that happen and especially if you want the quality that is available from the commercial offerings.

Not to speak of the training of those models. It's all there to make it possible to do this locally however where's the hardware? AWS? Google? There are hidden costs of the Open Source model in this case.

>In this case the limitation is the compute.

I agree with most of your points, but computation can be transferred from a place where energy is cheap to a place that is expensive. Energy for cooking cannot be transferred that way.

See for example Amazon-Google datacenters in the Gulf region. We've also got a whole continent, Australia, to put as many solar panels as we desire. Australia got dark for half a day, every day? Put solar panels to the opposite side of the planet.

Energy is a concern, for cooking, transportation etc. Energy for computation is not.

this is a good point. Some of the ai companies are trying to hook cs students so they'll only know "dev" as a function of their products. First one's free as they say (the drug dealers).

I agree, that is the great danger that CS students aren't even taught the fundamentals of "computer science" any longer. It would be the equivalent of physics students not learning Newtons laws or e-m-c-squared.

Probably there is an issue with how much there is in CS - each programming language basically represents a different fundamental approach to coding machines. Each paradigm has its application, even COBOL ;)

Perhaps CS has not - yet - found its fundamental rules and approaches. Unlike other sciences that have hard rules and well trodden approaches - the speed of light is fixed but not the speed of a bit.

What do you mean about vendor lock-in? I haven’t yet seen any meaningful barriers to switching between different companies’ coding agents. Are you talking about AI market lock-in and not vendor-specific lock-in?

> these loss making AI companies will eventually need to recoup

This is true, and while AI spend continues to rise, I’m starting to think once the dust settles and the true costs emerge and stable profits are achieved, that it may be expensive enough that it’s a limiting force.

Then you aren’t a true vibe coder using replit

I think it will be more similar to the cloud. I remember people predicted that once you move to the cloud, you'll realize how expensive it actually is, but the cost of migration back will be high. While, yes, the cloud is expensive, most people realized that it is kinda worth it.

Oil market doesn't have an equivalent of open-source LLMs, self-hosting and cloud providers.

"Just like oil prices and the global economy, fundamentally everything is getting better." (implied /s)

I remember having to pay a pretty penny to have a 3 minute conversation with my dad working half way across the world. Now I can video call my nephew for 45 minutes without blinking an eye. What happened?

Why will Intelligence be like Oil and not Broadband?

> the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments.

I would bet a lot of money that the price of LLM assistance will go down, not up, as the hardware and software advance.

Every genre-defining startup seems to go through this same cycle where the naysayers tell us that it's all going to collapse once the investment money runs out. This was definitely true for technologies without use cases (remember the blockchain-all-the-things era?) but it is not true for businesses that have actual users.

Some early players may go bust by chasing market share without a real business plan, like the infamous Webvan grocery delivery service. But even Webvan was directionally correct, with delivery services now a booming business sector.

Uber is another good example. We heard for years that ridesharing was a fad that would go away as soon as the VC money ran out. Instead, Uber became a profitable company and almost nobody noticed because the naysayers moved on to something else.

AI is different because the hardware is always getting faster and cheaper to operate. Even if LLM progress stalled at Opus 4.6 levels today, it would still be very useful and it would get cheaper with each passing year as hardware improved.

> I'm sure the pro-AIs will explain that technology will only get cheaper and better and that fundamentally it ain't an issue. Just like oil prices

Comparing compute costs to oil prices is apples to oranges. Oil is a finite resource that comes out of the ground and the technology to extract it doesn't improve much over decades. AI compute gets better and cheaper every year because the technology advances rapidly. GPU servers that were as expensive as cars a few years ago are now deprecated and available for cheap because the new technology is vastly faster. The next generation will be faster still.

If you're mentally comparing this to things like oil, you're not on the right track

> almost nobody noticed

Rideshare costs are much higher than they have been in years past. Everyone noticed

> Oil is a finite resource that comes out of the ground

Yes but the chips, hardware, copper cables, silicon and all the rest of the components that make up a server are finite. Unless these magically appear from outer space, we'll face the same resource constraints as everything else that is pulled out of the ground.

These components are also far more fragile to source, see COVID and the collapse of global supply chains. Also the factories to create these components are expensive to build and fragile to maintain. See the Dutch company that seems to be the sole supply of certain manufacturing skills.[1]

> I would bet a lot of money that the price of LLM assistance will go down, not up, as the hardware and software advance.

My bet would be that it would fuel the profits of AI companies and not make the price of AI come down. Over supply makes price come down but if supply is kept artificially low, then prices stay high.

That's the comparison to OPEC and oil. There is plenty of oil to go around yet the supply is capped and thereby prices kept high. There is no guarantee that savings in hardware or supply will be passed on by AI corps.

Indeed there is no guarantee that there will be serious competition in the market, OPEC is a monopoly so why not have an AI monopoly? At the moment, all major players in AI are based in the same geopolitical sphere, making a monopoly more likely, IMHO.

In the end, it's all speculation what will happen. It just depends on which fairy tail one believes in.

[1]: https://en.wikipedia.org/wiki/ASML_Holding

> Yes but the chips, hardware, copper cables, silicon and all the rest of the components that make up a server are finite. Unless these magically appear from outer space, we'll face the same resource constraints as everything else that is pulled out of the ground.

Raw material cost is not a driver of datacenter GPU costs.

> Over supply makes price come down but if supply is kept artificially low, then prices stay high.

Where are you getting "supply kept artificially low" when we're in the middle of an explosion of datacenter buildouts and AI companies?

We're in a race to the bottom on pricing. I haven't seen a realistic argument for why you think prices are going to go up. You're starting with a conclusion and trying to find reasons it might be true.

While I fundamentally agree with the basis of compute getting cheaper by the year, I think a missed consideration here is the fact that these models are also requiring exponentially more compute with each iteration to train, in a way that arguably has outscaled the advances in compute.

Whether a generalized and broadly usable model will be able to trained within some N multiple of our current compute availability allowing the price to come down with iterative compute advances is yet to be seen. With the current race to the top in terms of SOTA models and increasingly iteratively smaller improvements on previous generations, I have a feeling the scaling need for compute will outpace the improvements in our hardware architecture, and that's if Moore's law even holds as we start to reach the bounds of physics and not engineering.

However as it stands today, essentially none of these providers are profitable so it's really a question of whether that disconnect will come within their current runway or not and they'll be required to increase their price point to stay alive and/or raise more capital. It's pure conjecture either way.

Useful context here is that the author wrote Pi, which is the coding agent framework used by OpenClaw and is one of the most popular open source coding agent frameworks generally.

> “Heard joke once: Man goes to doctor. Says he's depressed. Says life seems harsh and cruel. Says he feels all alone in a threatening world where what lies ahead is vague and uncertain. Doctor says, "Treatment is simple. Great clown Pagliacci is in town tonight. Go and see him. That should pick you up." Man bursts into tears. Says, "But doctor...I am Pagliacci.”

https://www.goodreads.com/quotes/141645-heard-joke-once-man-...

you get me

Good joke.

That's a great shout because I'm sure a lot of people would otherwise just discredit this take as just another anti-ai skeptic. But he probably has more experience working with LLM's and agents than most of us on this site, so his opinion holds more weight than most.

If you were going to dismiss an argument because of who it comes from rather than its content, that is a flaw in your thinking. The argument is correct, or it isn't, no matter who said it.

Your ability to evaluate whether the argument is correct is limited. In theory, the author and the correctness of the argument are unrelated; in practice, the degree of experience the author has with the topic they’re making an argument on does indeed have some correlation with the argument and should influence the attention you give to arguments, especially counterintuitive ones.

That's hilarious. I've been following Mario since his work on libGDX and RoboVM.

His blog post on pi is here: https://mariozechner.at/posts/2025-11-30-pi-coding-agent/

For reference, the creator of OpenClaw has roughly the opposite philosophy:

https://steipete.me/posts/2025/shipping-at-inference-speed

I wonder how Peter's views might have changed in the last three months.

He reXed the author’s X post, so he might agree

Jesus, that started like one of those LinkedIn posts where the author works 25 hrs/day and everyone who doesn't are going to be left behind.

... people like that have a way of writing articles that don't seem to say anything at all.

> Companies claiming 100% of their product's code is now written by AI consistently put out the worst garbage you can imagine. Not pointing fingers, but memory leaks in the gigabytes, UI glitches, broken-ass features, crashes

One thing about the old days of DOS and original MacOS: you couldn't get away with nearly as much of this. The whole computer would crash hard and need to be rebooted, all unsaved work lost. You also could not easily push out an update or patch --- stuff had to work out of the box.

Modern OSes with virtual memory and multitasking and user isolation are a lot more tolerant of shit code, so we are getting more of it.

Not that I want to go back to DOS but Wordperfect 5.1 was pretty damn rock solid as I recall.

> Modern OSes with virtual memory and multitasking and user isolation are a lot more tolerant of shit code, so we are getting more of it.

It's not the glut of compute resources, we've already accepted bloat in modern software. The new crutch is treating every device as "always online" paired with mantra of "ship now! push fixes later." Its easier to setup a big complex CI pipeline you push fixes into and it OTA patches the users system. This way you can justify pushing broken unfinished products to beat your competitors doing the same.

I think you're just recalling the few software products that were actually good. There was plenty of crap software that would crash and lose your work in the old days.

I always found it funny how Word on Window 3.1/95 would have a day dream moment and just completely lock up, usually when you were about to save the document

I still save stuff every few minutes out of habits formed in the 90s.

Old DOS stuff could either be a total nightmare or some of the most brilliant code you had ever seen. Thats just the way having no giard rails goes.

Lol right!

Remember when OS uptime was super duper important? Now it's a given that you can basically never restart your computer and be fine.

Another factor at work is the use of rolling updates to fix things that should better have been caught with rigorous testing before release. Before the days of 'always on' internet it was far too costly to fix something shipped on physical media. Not that everything was always perfect, but on the whole it was pretty well stress-tested before shipping.

The sad truth is that now, because of the ease of pushing your fix to everything while requiring little more from the user than that their machine be more or less permanently connected to a network, even an OS is dealt with as casually as an application or game.

Is the price of speed bloat? Where does the tolerance for less reliable software come from?

It occurred to me on my walk today that a program is not the only output of programming.

The other, arguably far more important output, is the programmer.

The mental model that you, the programmer, build by writing the program.

And -- here's the million dollar question -- can we get away with removing our hands from the equation? You may know that knowledge lives deeper than "thought-level" -- much of it lives in muscle memory. You can't glance at a paragraph of a textbook, say "yeah that makes sense" and expect to do well on the exam. You need to be able to produce it.

(Many of you will remember the experience of having forgotten a phone number, i.e. not being able to speak or write it, but finding that you are able to punch it into the dialpad, because the muscle memory was still there!)

The recent trend is to increase the output called programs, but decrease the output called programmers. That doesn't exactly bode well.

See also: Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)

https://www.youtube.com/watch?v=ZSRHeXYDLko

> The recent trend is to increase the output called programs, but decrease the output called programmers. That doesn't exactly bode well.

Perhaps on a related note, I've noticed that a lot of the positive talks about AI are about quantity. On the other hand, there is disproportionately very little deep discussion about quality. And I mean not just short term, local quality, but more long term and holistic quality (e.g. managing complexity under evolving requirements in a complex system with multiple connected parts) at real production scale, where there is much less tolerance for failure.

In all the places I've worked in throughout my career, I've felt that there have always been a tension between those who cared more about things like the mental model and holistic quality, and those who seemed to care less or were even oblivious about it. I think one contribution of the current AI hype is that it gave a more concrete shape to this split...

> Perhaps on a related note, I've noticed that a lot of the positive talks about AI are about quantity. On the other hand, there is disproportionately very little deep discussion about quality.

and to me this is so weird, because from what I can tell, quantity hasn't been the winning factor for a very long time now

LLM systems at their core being probabilistic text generators makes them easily produce massive works at scale.

In software engineering our job is to build reliable systems that scale to meet the needs of our customers.

With the advent of LLMs for generating software, we're simply ignoring many existing tenets of software engineering by assuming greater and greater risk for the hope of some reward of "moving faster" without setting up the proper guard rails we've always had. If a human sends me a PR that has many changes scattered across several concerns, that's an instant rejection to close that PR and tell them to separate those into multiple PRs so it doesn't burn us out reviewing something beyond human comprehension limits. We should be rejecting these risky changes out of hand, with the possible exception when "starting from scratch", but even then I'd suggest a disciplined approach with multiple validation steps and phases.

The hype is snake oil: saying we can and should one-shot everything into existence without human validation, is pure fantasy. This careless use of GenAI is simply a recipe for disasters at scales we've not seen before.

Well said, thank you.

I've found LLMs decrease the friction in enabling more pedantic lints and tooling. It is a quantity problem because enabling all the aggressive warnings in the compiler makes a lot of work, and its a quality outcome because presumably addressing every warning from the compiler makes the code better

Peter Naur had that realization back in 1985: https://pages.cs.wisc.edu/~remzi/Naur.pdf

>>[2019] Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)

During the Q&A, he responds "do we really want software written that humans cannot understand?!" His steadfast doubts against singularity are called into question, at least by his supporting 2019 responses.

Certainly the speaker is correct that modern hardware allows software to be crappily written — I fondly recall the "olden times" recanted about full-access operating systems of yesteryear. Those days are over...

The fact that a modern computer "needs" to be online to install an update is frustrating/concerning (e.g. for MacOS, without a USB installer must be online to update, even with stand-alone updater downloaded). Just use my local hardware (that I own) and install this software (that I have provided).

The phone number muscle memory example is perfect. There is a whole category of knowledge you only have if your hands did the work.

It's called "tacit knowledge" and I think we generally overindex on explicit, formal knowledge and ignore tacit knowledge. You can see that with language learning, we treat languages like something you "learn", but in my experience it's closer to a motor skill like playing tennis.

https://en.wikipedia.org/wiki/Tacit_knowledge

The most recent phone numbers I actually remember are those I learned and used just before getting a smartphone. I guess tapping on a screen doesn't quite give you that same effect!

There's currently a billboard up in San Francisco that basically says "use AI to reduce your saas costs".

And I'm thinking - has anyone actually done that for something meaningful?

Replacing salesforce as your crm or replacing Shopify as your e-commerce platform?

I get the hype but AI doesn't remove accountability, it just moves it up. Oh you can do with 1 person what 3 people used to do? Great, that 1 person is now accountable for 3 person's jobs. And people are naturally uncomfortable with that - you need to understand what's going on and be able to investigate / fix. It's different than say, weaving machines replacing jobs because weaving machines were consistent. 1 person could confidently produce what x weavers could before. But AI is not, and that variability in output & quality introduces massive friction.

So as of now, in both software and people, there's a real limit to how much AI can replace because the remaining people still are equally accountable.

Vendor lock-in is real and it’s scary. You are helpless to the constant price increases and each passing renewal you get deeper and deeper into the lock-in. Here’s to the day when someone clever with AI can disintermediate this situation. You don’t have to vibecode your own CRM but imagine a deterministic harness that lets you lego-block CRM functions like lead management, opportunity tracking, contact list, campaigns. There shouldn’t be a moat anymore.

Moving the vendor lock-in to the AI provider and exponentially increasing the pain of migration by locking all teams and all services in at once.

Not really. Mixture of models and mixture of experts have been around. It’s easy to switch a project harness from Codex to Claude to Gemini and to open models. You’re not locked in to a model, you’re more concerned about competitive token cost.

tick tock tick tock...

The article touches on this but I think the key takeaway is that humans need to properly manage the _scope of work_ for their agentic teams in order to have any chance of a successful outcome.

Current gen agents need to be provided with small, actionable units of work that can _easily_ be reviewed by a human. A code deliverable is made easy to review if the scope of change is small and aligned with a specific feature or task, not sprawled across multiple concerns. The changes must be ONLY related to the task at hand. If a PR is generated that does two very different things like fix linting errors in preexisting code AND implement feature X, you're doing it wrong. Or rather, you're simply gambling. I'd rather not leave things up to chance that I may miss something in that new 10000LOC PR. It's better that a 10000LOC never existed at all.

YOLOing out massive, sweeping changes with agents exceed our own (human) "context windows" and as this article points out, we're then left with an inevitable "mess." The untangling of which will take an inordinate amount of time to fix.

At which point you've gained very little efficiency in most large organizations given that by the time you're actually doing development work at the ticket level 90% of the project timeline (identifying issues, prioritizing, creating requirements, architecture, ticket breakdowns, coordination, etc) has already passed.

If AI can enable engineers to move through the organization more effectively, say by allowing them to work through the service mesh as a whole, that could reduce time. But in order to evaluate code contributions to any space well, as far as I can tell, you still have to put in leg work even if you are an experienced engineer and write some features which exposes you to the libraries, quirks, logging/monitoring, language, etc that make up that specific codebase. (And also to build trust with the people who own that codebase and will be gatekeeping your changes, unless you prefer the Amazon method of having junior engineers YOLO changes onto production codebases without review apparently... holy moly, how did they get to that point in the first place...)

So the gains seem marginal at best in large organizations. I've seen some small organizations move quicker with it, they have less overhead, less complexity, and smaller tasks. Although I've yet to see much besides very small projects/POCs/MVPs from anyone non-technical.

Maybe it'll get to the point where it can handle more complexity, I kind of think we're leveling off on this particular phase of AI, and some headlines seem to confirm that...

- MS starting to make CoPilot a bit less prominent in its products and marketing - Sora shutting down - Lots of murky, weird, circular deals to fund a money pit with no profits - Observations at work

It's really kind of crazy how much our entire society can be hijacked by these hype machines. My company did slow roll AI deployment a bit, but it very much feels like the Wild West, and the amount of money spent! I'm sure it's astronomical. Pretty sure we could have hired contractors to create the Chrome plugin and Kafka topic dashboard we've deployed for far cheaper

The productivity gains are somewhat real in a sense, but are not really about "moving faster", as the hype would have us believe. GenAI agentic systems instead boost individual developer "efficiency" by allowing a single, reasonably qualified developer, to approximate an entire software team. As those developers, however, we're still required to manage the workload of those teams and ourselves to ensure quality output, just as ever before.

The problem is that it's VERY easy to overload oneself with the output of these new tools. Human comprehension is the bottleneck, as much as it always has been. Anyone that tells you otherwise is shilling for these companies.

And just to underscore my point about the disconnect between the advertising/hype vs the reality: the real point of this tech and the reason leadership seems so motivated to push it is that they ultimately see this tooling as our replacement, not our enhancement, at least in the long term (although those "many hats" roles will have to persist).

It's just harder to sell trades folk the tools of their demise, so it's couched in terms of a miracle product that'll make us all 10x devs; when the reality is, it'll just be 1/10 of us still around doing the risk mitigation work left within the system that relaced us.

I understand your pain, we're just a peak hype, I think people will learn to backtrack and use the tool in a more sensible way. It always happens. I remember when MongoDB and other NoSql databases came out, people went as far as to say that "SQL is dead" and refuse to use a normal SQL database for anything. Not even for the most obvious relational application. People would store everything as key-value pairs with no schema and do all the joins in the application layer. Fast forward 10 years and we're back to using SQL for most of our applications. NoSql hasn't disappeared, it has just been reduced to the nice where it's useful.

Also reminded me of Kafka (Kafka as a database!) and microservices (monoliths are evil, microservices are the future). I'm sure we can dig up similar hypes on various scales throughout the history of this industry...

Perhaps so-called AI is slightly different from hypes like NoSql and microservices in that these reduced to usages that practically apply to only a fraction of the engineering population (albeit, it's still good for anyone to know about them even if we never use them), whereas AI will probably still affect us all even after the dust settles. Just in much less spectacular ways than is being trumpeted currently by some groups. Reminded me of No Silver Bullet: "There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. "

Technology moves fast and is prone to hype. While NoSQL and Kafka were certainly oversold, almost every mid-large scale tech company has at least one nosql system and kafka-like system in use. The proponents weren’t wrong, they oversold the impact.

There is other tech that did completely change how we do things. CI/CD, Containers, Kubernetes, distributed tracing etc. are considered standard now (but weren’t not that long ago).

Containers and Kubernetes are not as standard as we'd like to think. They're standard for things of certain size, but for small-to-medium there are a good amount of serverless options. For a moderately sized website, it's easier to just stick the thing in Vercel than having to deal with the complexity of Kubernetes. Of course, once you grow then you do need that complexity, but I'm willing to bet that many people who got onboard into it don't actually need it, they just did it because everyone else is doing it.

> it sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services

As somebody who has been running systems like these for two decades: the software has not changed. What's changed is that before, nobody trusted anything, so a human had to manually do everything. That slowed down the process, which made flaws happen less frequently. But it was all still crap. Just very slow moving crap, with more manual testing and visual validation. Still plenty of failures, but it doesn't feel like it fails a lot of they're spaced far apart on the status page. The "uptime" is time-driven, not bugs-per-lines-of-code driven.

DevOps' purpose is to teach you that you can move quickly without breaking stuff, but it requires a particular way of working, that emphasizes building trust. You can't just ship random stuff 100x faster and assume it will work. This is what the "move fast and break stuff" people learned the hard way years ago.

And breaking stuff isn't inherently bad - if you learn from your mistakes and make the system better afterward. The problem is, that's extra work that people don't want to do. If you don't have an adult in the room forcing people to improve, you get the disasters of the past month. An example: Google SREs give teams error budgets; the SREs are acting as the adult in the room, forcing the team to stop shipping and fix their quality issues.

One way to deal with this in DevOps/Lean/TPS is the Andon cord. Famously a cord introduced at Toyota that allows any assembly worker to stop the production line until a problem is identified and a fix worked on (not just the immediate defect, but the root cause). This is insane to most business people because nobody wants to stop everything to fix one problem, they want to quickly patch it up and keep working, or ignore it and fix it later. But as Ford/GM found out, that just leads to a mountain of backlogged problems that makes everything worse. Toyota discovered that if you take the long, painful time to fix it immediately, that has the opposite effect, creating more and more efficiency, better quality, fewer defects, and faster shipping. The difference is cultural.

This is real DevOps. If you want your AI work to be both high quality and fast, I recommend following its suggestions. Keep in mind, none of this is a technical issue; it's a business process isssue.

> One way to deal with this in DevOps/Lean/TPS is the Andon cord.

Many years ago, I started working for chip companies. It was like a breath of fresh air. Successful chip companies know the costs (both direct money and opportuity) of a failed tapeout, so the metaphorical equivalent of this cord was there.

Find a bug the morning of tapeout? It will be carefully considered and triaged, and maybe delay tapeout. And, as you point out, the cultural aspect is incredibly important, which means that the messenger won't be shot.

It also seems like massive consolidation has caused issues too. Everyone is on Github. Everyone is on AWS. Everyone is behind cloudflare. Whenever an issue happens here it effects everyone and everyone sees it.

In the past with smaller services those services did break all the time, but the outage was limited to a much smaller area. Also systems were typically less integrated with each other so one service being down rarely took out everything.

The power company is massively consolidated, as is the water supply, telephone service. These are monolithic, monopolistic entities. But they are also very reliable (failures are usually isolated by region, or a result of natural disaster).

What leads to more failure is when you don't engineer those consolidated entities to be reliable. Tech companies have none of the legal requirements or incentives to be reliable, the way physical infrastructure companies do. I agree that the tighter integration is an issue, but the root cause is tech companies have no incentive other than profits. If they're making profits, everything's fine.

I mean recommend professional software engineering licenses here on HN and it goes over like a turd in a punch bowl. Everyone knows where the search for more profit was going, no one wanted to get off the ride though.

It's a systems engineering job. You need to provide context, acceptable failure modes, and test at each level for validation. Identify false coupling, poor interfaces, things that don't match business context during agent planning phase. Then communicate / translate to others so their decisions improve instead of destroying the system by optimizing only for their local situation.

Super good take - the Andon cord is needed everywhere.

Just yesterday I was discussing many of the ideas presented here with a coworker. I had just walked out of a workshop led by $BIGTECHCOMPANY where someone presented the following toy example:

A service goes down. He tells the agent to debug it and fix it. The agent pulls some logs from $CLOUDPROVIDER, inspects the logs, produces a fix and then automatically updates a shared document with the postmortem.

This got me thinking that it's very hard to internalize both issue and solution -updating your model of the system involved- because there is not enough friction for you to spend time dealing with the problem (coming up with hypotheses, modifying the code, writing the doc). I thought about my very human limitation of having to write things down in paper so that I can better recall them.

Then I recalled something I read years ago: "Cars have brakes so they can go fast."

Even assuming it is now feasible to produce thousands of lines of quality code, there is a limitation on how much a human can absorb and internalize about the changes introduced to a system. This is why we will need brakes -- so we can go faster.

The gap in your example is that a human had to realize the system is broken so that he could nudge the agent into fixing it. He can fix that gap by updating the agent to recognize when the system breaks. This now becomes the level at which he debugs… did the agent recognize the failure and self-heal, or not?

And at that point, if the autonomous system breaks, realized it’s broken, and fixes itself before you even notice… then do you need to care whether you learn from it? I suppose this could obfuscate some shared root cause that gets worse and worse, but if your system is robust and fault-tolerant _and_ self-heals, then what is there to complain about? Probably plenty, but now you can complain about one higher level of abstraction.

"Do me a SOLID, YAGNI, give me a DRY KISS" — that's been my coding philosophy for 20 years. So when I came back to building after a long detour, I couldn't stomach watching agents confidently generate 400 lines where 40 would do. What I found is that the discipline was the feature, not the obstacle. I ended up pair programming closely — not because I distrusted the agent, but because I couldn't let go of the architecture. The internet kept telling me to stop going into the weeds. Your article explained why that instinct was right. Everyone else is happy grinding in third the whole race. I went 1, 2, 3 — and because I didn't bury myself getting out of the driveway, I still get to shift into fourth.

As well as pair programming with the AI, you can explicitly put those principles in AGENTS.md and the stochastic code generator will pay attention and be less verbose.

Exactly. There's a difference between vibe coding and agentic software engineering. One is just prompting and hoping for the best. It works surprisingly well, up to a point. And then it doesn't. If that's happening to you, you might be doing it wrong. The other is forcing agents to do it right. Working in a TDD way, cleaning up code that needs cleaning up, following processes with checklists, etc. You need to be diligent about what you put in there and there's a lot of experience that translates into knowing what to ask for and how. But it boils down to being a bit strict and intervening when it goes off the rails and then correcting it via skills such that it won't happen again.

I've been working on an Ansible code base in the past few weeks. I manually put that together a few years ago and unleashed codex on it to modernize it and adapt it to a new deployment. It's been great. I have a lot of skills in that repository that explain how to do stuff. I'm also letting codex run the provisioning and do diagnostics. You can't do that unless you have good guard rails. It's actually a bit annoying because it will refuse to take short cuts (where I would maybe consider) and sticks to the process.

I actually don't write the skills directly. I generate them. Usually at the end of a session where I stumbled on something that works. I just tell it to update the repo local skills with what we just did. Works great and makes stuff repeatable.

I'm at this point comfortable generating code in languages I don't really use myself. I currently have two Go projects that I'm working on, for example. I'm not going to review a lot of that code ever. But I am going to make sure it has tests that prove it implements detailed specifications. I work at the specification level for this. I think a lot of the industry is going to be transitioning that direction.

Except that when its system prompt is full of instructions, caveats, design principles, gotchas, architecture notes, memories from the past, and personal preferences, at some point it's going to just ignore them outright. Heck, Claude Code won't even use critical instructions from a 100-line CLAUDE.md file sometimes. So you still have to be extremely vigilant about noncompliance.

If your instructions are being ignored you may need a new model or harness.

My CLAUDE.md is deliberately very short, and only includes very specific rules like "never list yourself as a co-author or committer in git commits". Claude will very regularly ignore this rule, apologize every time I tell it to fix it, update its memories, etc. and then an hour later do the exact same thing again.

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine.

What are you building? Does the tool help or hurt?

People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era.

After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understanding of what you are building does not exceed the reality of the mess you and your team are actually building if budgets allow.

This seldom happens, even in solo hobby projects once you cost everything in.

It's not about agile or waterfall or "functional" or abstracting your dependencies via Podman or Docker or VMware or whatever that nix crap is. Or using an agent to catch the bugs in the agent that's talking to an LLM you have next to no control over that's deleting your production database while you slept, then asking it to make illustrations for the postmortem blog post you ask it to write that you think elevates your status in the community but probably doesn't.

I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

> What are you building?

This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs?

Hard to shake the feeling that this looks like one big pyramid scheme. I strongly suspect that vast majority of the "innovation" in recent years has gone straight to supporting the funding model and institution of the software profession, rather than actual software engineering.

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

It was, and is. But not universally.

If you formulate questions scientifically and use the answers to make decisions, that's engineering. I've seen it happen. It can happen with LLMs, under the proper guidance.

If you formulate questions based on vibes, ignore the answers, and do what the CEO says anyway, that's not engineering. Sadly, I've seen this happen far too often. And with this mindset comes the Claudiot mindset - information is ultimately useless so fake autogenerated content is just as valuable as real work.

In my lifetime software has given us:

* the ability to find essentially any information ever created by anyone anywhere at anytime,

* the ability to communicate with anyone on Earth over any distance instantaneously in audio, video, or text,

* the ability to order any product made anywhere and have it delivered to our door in a day or two,

* the ability to work with anyone across the world on shared tasks and projects, with no need for centralized offices for most knowledge work.

That was a massive undertaking with many permutations requiring lots of software written by lots of people.

But it's largely done now. Software consumes a significant fraction of all waking hours of almost everyone on Earth. New software mainly just competes with existing software to replace attention. There's not much room left to expand the market.

So it's difficult to see the value of LLMs that can generate even more software even faster. What value is left to provide for users?

LLMs themselves have the potential to offering staggering economic value, but only at huge social cost: replacing human labor on scales never seen before.

All of that to say, maybe this is the reason so much time is being spent on meta-work today than on actual software engineering.

> The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs?

The overwhelming majority of real jobs are not related to these things you read about on Hacker News.

I help a local group with resume reviews and job search advice. A common theme is that junior devs really want to do work in these new frameworks, tools, libraries, or other trending topics they've been reading about, but discover that the job market is much more boring. The jobs working on those fun and new topics are few and far between, generally reserved for the few developers who are willing to sacrifice a lot to work on them or very senior developers who are preferred for those jobs.

I’ve seen so many articles of “introducing flimflam: a squiggle for burfy” it makes my head spin.

> I strongly suspect that vast majority of the "innovation" in recent years has gone straight to supporting the funding model and institution of the software profession, rather than actual software engineering.

Feels like there’s a counter to the frequent citation of Jevon’s Paradox in there somewhere, in the context of LLM impact on the software dev market. Overestimation of external demand for software, or at least any that can be fulfilled by a human-in-the-loop / one-dev-to-many-users model? The end goal of LLMs feels like, in effect, the Last Framework, and the end of (money in) meta-engineering by devs for devs.

This is a good point. I've seen people with really complex AI setups (multiple agents collaborating for hours). But what are they building? Are they building a react app with an express backend? A next js app? Which itself is a layer on top of an abstraction?

I haven't tried this myself but I'm curious if an LLM could build a scalable, maintainable app that doesn't use a framework or external libraries. Could be danger due to lack of training data but I think it's important to build stuff that people use, not stuff that people use to build stuff that people use to build stuff that....

Not that meta frameworks aren't valuable, but I think they're often solving the wrong problem.

> Are these tools necessary to build what we actually need?

I think the entire software industry has reached a saturation point. There's not really anything missing anymore. Existing tools do 99% of what we humans could need, so you're just getting recycled and regurgitated versions of existing tools... slap a different logo and a veneer on it, and its a product.

Yeah here you go

https://youtu.be/DSzUYX7n2_A?si=q0_0lePoQ6MEz5d5

> The last 10 years in the software industry in particular seems full of meta-work. Building new frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. All to build... what exactly?

Don't forget App Stores. Everyone's still trying to build app stores, even if they have nothing to sell in them.

It's almost as if every major company's actual product is their stock price. Every other thing they do is a side quest or some strategic thing they think might convince analysts to make their stock price to move.

>> The last 10 years in the software industry in particular seems full of meta-work. Building new frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. All to build... what exactly? Are these tools necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs?

This is because all the low-hanging fruit has already been built. CRM. Invoicing. HR. Project/task management. And hundreds of others in various flavors.

People don't realize how much software engineering has improved. I remember when most teams didn't use version control, and if we did have it, it was crappy. Go through the Joel Test [1] and think about what it was like at companies where the answers to most of those questions was "no."

[1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

At the same time, systems have become far more complex. Back when version control was crap, there weren't a thousand APIs to integrate and a million software package dependencies to manage.

Sure everything seems to have gotten better and that's why we now need AIs to understand our code bases - that we created with our great version control tooling.

Fundamentally we're still monkeys at keyboards just that now there are infinitely many digital monkeys.

Version control is useful but it has nothing to do with software engineering per se. Most software development is craft work which doesn't meet the definition of engineering (and that's usually fine). Conversely, it's possible to do real software engineering without having a modern version control system.

The answer to those questions is _still_ 'no' at a lot of companies.

> People don't realize how much software engineering has improved.

It has, but we have gotten there by stacking turtles, by building so many layers of abstraction that things no longer make sense.

Think about this hardware -> hypervisor -> vm -> container -> python/node/ruby run time all to compile it back down to Bytecode to run on a cpu.

Some layers exist because of the push/pull between systems being single user (PC) and multi user (mainframe). We exacerbated the problem when "installable software" became a "hard problem" and wanted to mix in "isolation".

And most of that software is written on another pile of abstractions. Most codebases have disgustingly large dependency trees. People keep talking about how "no one is reviewing all this ai generated code"... Well the majority of devs sure as shit arent reviewing that dependency tree... Just yesterday there was yet another "supply chain attack".

How do you protect yourself from such a thing... stack on more software. You cant really use "sub repositories/modules" in git. It was never built that way because Linus didnt need that. The rest of us really do... so we add something like artifactory to protect us from the massive pile of stuff that you're dependent on but NOT looking at. It's all just more turtles on more piles.

Lots of corporate devs I know are really bad at reviewing code (open source much less so). The PR code review process in many orgs is to either find the person who rubber-stamps and avoid the people who only bike shed. I suspect it's because we have spent the last 20 years on the leet code interview where memorizing algorithms and answering brain teasers was the filter. Not reading, reviewing, debugging and stepping through code... Our entire industry is "what is the new thing", "next framework" pilled because of this.

You are right that it got better, but we got there by doing all the wrong things, and were going to have to rip a lot of things apart and "do better".

Maybe back in the beginning, but I don't think it's an engineering discipline now. I don't think that's bad though. I always thought we tagged on the word "engineer" so that we could make more money. I'm ok with not being one. The engineers I've known are very strict in their approach which is good since I don't want my deck to fall down. Most of us are too risky with our approach. We love to try new things and patterns, not just used established ones over time. This is fine with me, and when we apply the term "engineer" to work, I get a little uneasy, because I think it implies us doing something that most of us really don't want to do. That is, absolutely prove our approach works and will work for years to come. Just my opinion though.

I’ve had jobs where my title was “software engineer”, but I never refer to myself as such outside of work. When I tell others what I do, I say I am a software developer. It may seem a pointless distinction, but to me there is a distinction.

Neither myself nor the vast majority of other “software engineers” in our field are living up to what it should mean to be an “engineer”.

The people that make bridges and buildings, those are the engineers. Software engineers, for the very very most part, are not.

It’s a bit of a misclassification. In my mind we tend to be more like architects where there are a fair amount of innovative ideas that don’t work all that well in practice. Train stations with beautiful roofs that leak and slippery marble floors, airports with smoke ventilation systems in the floor, etc.

Of course, we use that term for something else in the software world, but architecture really has two tiers, the starchitects building super fancy stuff (equivalent to what we’d call software architects) and the much more normal ones working on sundry things like townhomes and strip malls.

That being said I don’t think people want the architecture pay grades in the software fields.

It's an understandable mistake to make; culturally an engineer is defined by the building of physical objects that have extremely high reliability expectations. But "engineer" originally referred to someone who used their ingenuity to build or do things in a manner not routine or primarily physical [1]. Basically an inventor who produced. The main engineering accreditation body in the United States adds the requirement of a professional education, but it is more or less the same [2].

We're engineers.

1. https://en.wikipedia.org/wiki/Engineer#Definition

2. https://www.abet.org/accreditation/accreditation-criteria/cr...

At the same time, if you remove 'engineer' , informatics should fall under the faculty of Science, so scientists, which are even more rigorous than engineers ;)

Maybe software tinkerer?

classic ... https://www.hillelwayne.com/post/are-we-really-engineers/

It's a Systems Engineering job. You provide context, define interfaces to people, tests for critical failure modes affecting customer, describe system behavior, and translate to other people.

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic?

When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point is, it’s expected lifespan, etc. Does this exist for servers, web frameworks, network load balancers, etc.?

I actually believe that software “could” be an engineering discipline but we have a long way to go

> can anyone on the product side actually predict traffic

Hypothetically, could you not? If you engineer a bridge you have no idea what kind of traffic it'll see. But you know the maximum allowable weight for a truck of X length is Y tons and factoring in your span you have a good idea of what the max load will be. And if the numbers don't line up, you add in load limits or whatever else to make them match. Your bridge might end up processing 1 truck per hour but that's ultimately irrelevant compared to max throughput/load.

Likewise, systems in regulated industries have strict controls for how many concurrent connections they're allowed to handle[1], enforced with edge network systems, and are expected to do load testing up to these numbers to ensure the service can handle the traffic. There are entire products built around this concept[2]. You could absolutely do this, you just choose not to.

[1] See NIST 800-53 control SC-7 (3)

[2] https://learn.microsoft.com/en-us/azure/app-testing/load-tes...

I think it is in certain very limited circumstances. The Space Shuttle's software seems like it was actually engineered. More generally, there are systems where all the inputs and outputs are well understood along with the entire state space of the software. Redundancy can be achieved by running different software on different computers such that any one is capable of keeping essential functions running on its own. Often there are rigorous requirements around test coverage and formal verification.

This is tremendously expensive (writing two or more independent copies of the core functionality!) and rapidly becomes intractable if the interaction with the world is not pretty strictly limited. It's rarely worth it, so the vast majority of software isn't what I'd call engineered.

Software and bridges are entirely different.

If I need a bridge, and there's a perfectly beautiful bridge one town over that spans the same distance - that's useless to me. Because I need my own bridge. Bridges are partly a design problem but mainly a build problem.

In software, if I find a library that does exactly what I need, then my task is done. I just use that library. Software is purely a design problem.

With agentic coding, we're about to enter a new phase of plenty. If everyone is now a 10x developer then there's going to be more software written in the next few years than in the last few decades.

That massive flurry of creativity will move the industry even further from the calm, rational, constrained world of engineering disciplines.

>I actually believe that software “could” be an engineering discipline but we have a long way to go

It certain mission critical applications, it is treated as engineering. One example - https://en.wikipedia.org/wiki/DO-178B

There are also fundamentally different acceptance criteria for a bridge vs a website. Failure modes differ. Consequences of failure are nowhere near the same, so risk tolerance is adjusted accordingly. Perhaps true "engineering" really boils down to risk management... is what you're building so potentially destructive that it requires extremely careful thought and risk management? Engineering. If what you're building can fail, and really cause no harm, that's just building.

What you are describing sounds like a specific subset of professional engineering discipline, but I'd argue that "engineering" is much larger -- it isn't only "engineering" when you do it well and responsibly, after all.

I'd propose a definition of engineering that's more or less just "composing tools together to solve problems".

The way the authors of the book on material strengths got those numbers, was through testing. If you're using mature technologies, that testing has been done by others and you can rely on it for your design, at least in a general way. Otherwise you have to do the testing yourself, which is something a structural engineering project might do also, if it's unusual in some way.

We have a long way to go but large software companies have gotten really, really good at scaling to handle larger and larger traffic loads. It's not like there are no materials to consult to learn current best practices, even if there are still more improvements to be made.

> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

- Edsger Dijkstra, 1988

I think, unfortunately, he may have had us all dead to rights on this one.

One would as sensibly dismiss the concept of an assembly line as "how to build a car if you cannot."

Dijkstra was a mathematician. It is a necessary discipline. If it alone were sufficient, then the "program correctness" fans would have simply and inarguably outdone everyone else forty years ago at the peak of their efforts, instead of having resorted to eloquently whiny, but still whiny, thinkpieces (such as the 1988 example [1] quoted here above) about how and why they would like history to understand them as having failed.

[1] https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF [2]

[2] I will freely grant that the man both wrote and lettered with rare beauty, which shames me even in this photocopier-burned example when I compare it to the cheerful but largely unrefined loops and scrawls of my own daily hand.

Perhaps this is the wrong place to plant this thought. Maybe nobody will read it. These comments are now many hours old and HN has a way of walking away once they have had their turn shouting into the void.

I once received a "bonsai" seed kit from a former boss during a holiday dinner. I think it was meant as a joke, but even now I'm not so sure. I planted those seeds anyway. I told some people about it and they immediately mocked me saying it was a waste of time and going to take 30 years. This interaction immediately said everything to me about the expectations and attitudes of others.

Obviously, they grew like any other plants and actually quite nicely. Of course they're a commitment, but not a huge one.

I just wanted some plants for my apartment and they fit the bill. In a few years I had good looking plants. A decade later, I still have them and they're now more recognizably "bonsai". My home now looks nicer, I have a story to tell, and I learned a little bit from a very low stakes hobby.

My point is, I think it's nice when people have projects. I think it's nice to see what comes of it. I guess my only regret is ever saying "I planted bonsai" too soon just because that's what the box said. I didn't know how else to describe what I had done that weekend to those people who threw theirs in the trash.

I was thinking the other day about how frustrated my desire is to perform some kind of Great Work. A few years back I was intensely interested in making something like Nethack - a roguelike game with a deceptively simple surface and incredible complexity in the engine. I worked on several for a few years, different angles on the whole "managing complexity" thing. I suppose I learned a lot, and I made some interesting things, but I never really produced anything I felt I could work on for 20-30 years, that would be sort of my artistic statement as an engineer (if such a thing makes any sense).

I wouldn't've laughed at you. I view bonsai as a representation of steadfastness, endurance, determination, effort, (and self-mastery?) in the face of tremendous hardship, challenge, and deprivation. That said, I've never been particularly good at any of those things.

IDK if I would've taken you all that seriously either, though. Six months until you move and it's left behind on the curb. Or a year and a half until your cat knocks it off the windowsill. Or three years until some blight infects it and it dies off despite your best efforts. Eight years until, for whatever reason, it just succumbs to some kind of vegetative ennui. Nine years until your significant other overwaters it one too many times and the roots rot.

That's not meant disrespectfully. I just tend to view uncertainty and complexity as opportunities for shit to go sideways. Especially in this case, where it's unlikely you'll wake up to find your tree has spontaneously cloned itself, or has eaten a 1-UP mushroom. Disasters happen all the time, and miracles don't.

I suppose I'm just having a bit of a spiritual crisis right now. But thank you for your comment. It gives me a lot to think about, in a positive sense.

> Maybe nobody will read it. These comments are now many hours old and HN has a way of walking away once they have had their turn shouting into the void.

  All that is gold does not glitter,
  Not all those who wander are lost;
  The old that is strong does not wither,
  Deep roots are not reached by the frost.

― J.R.R. Tolkien, The Fellowship of the Ring

that's a great story!

>After five or six cycles it does become a bit fatiguing. Use the tool sanely.

That's increasingly not possible. This is the first time for me in 20 years where I've had a programming tool rammed down my throat.

There's a crisis of software developer autonomy and it's actually hurting software productivity. We're making worse software, slower because the C levels have bought this fairy tale that you can replace 5 development resource with 1 development resource + some tokens.

That lucky?

In 18 years AI is the third or 4th tool forced upon a shop/team, I will say of those it is the forst one that is genuinely able to make me more productive overall, even with the drawbacks.

> What are you building?

I think AI really pushes this higher up the abstraction layer:

> What problem are you solving?

I've spent a good amount of my careering using engineering and math to solve specific problems, I'm usually adjacent to software teams.

What I've seen happen with agentic coding is that traditional software engineers keep focusing on using it to build software, while ignoring the problem they're trying to solve.

Meanwhile I've seen junior data analysts start interfacing with applications and tools they never dreamed of before, and delivering results to stakeholders in record times. Things that were previously blocked by engineering no longer are.

But many engineers today are not really problem solvers, they're software builders. The idea that solving the end users problem is the goal, not building them software, is incomprehensible.

And so they continue to struggle to use AI effectively because they're trying to build software with it. Which it's not terrible at, but it's really the wrong tool for that job.

Sometimes software is necessary to solve a problem, a few years ago, software was necessary for a fairly large problem surface area (though, to your point, even then a lot of software was not really built to solve those problems). Today that surface area is shrinking, and as economic constraints loom on the horizon, I believe it will increasingly be people who are solving problems (with or without AI) that will be the ones surviving.

The kind of jobs an analyst are doing are probably the most amenable of everything to LLM assistance. Small, bounded, etc.

The bigger the problem set and context the less helpful an LLM gets.

Software was an engineering discipline... at some places. And it still is, at some places.

Other places were "hack it until we don't know of any major bugs, then ship it before someone finds one". And now they're "hey, AI agents - we can use that as a hack-o-matic!" But they were having trouble with sustainability before, and they're going to still, except much faster.

Maybe it's more about a rush to share how awesome it is that you compressed your time-to-release down to days and not weeks or months - when in reality that's a good thing in the sense that you get to a failure state much FASTER, and failure states are good, because that means that you get to iterate and get past those failures FASTER.

I don't think people were releasing at this pace, so the failure states are fast and furious so there is just that much more viability. I think the microslop windos failures lately are just them being the same "them" that they've always been .. just MUCH faster. (they just need to stop monkeying with windows and stop adding more features on top of an already shaky foundation.) Maybe we just need more of the stories like Anthropic working with Mozilla to squash 5x the amount of bugs in a similar time frame first, AND THEN "vibe a browser together from nothing but specification files and an army of bots in a weekend".

People built a lot of great stuff with Ruby, PHP, Notes and VB. I don't know what the problem really is.

Personally I think that whole Karpathy thing is the slowest thing in the world. I mean you can spin the wheels on a dragster all you like and it is really loud and you can smell the fumes but at some point you realize you're not going anywhere.

My own frustration with the general slowness of computing (iOS 26, file pickers, build systems, build systems, build systems, ...) has been peaking lately and frankly the lack of responsiveness is driving me up the wall. If I wasn't busy at work and loaded with a few years worth of side projects I'd be tearing the whole GUI stack down to the bottom and rebuilding it all to respect hard real time requirements.

> What are you building? Does the tool help or hurt?

> People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era.

I'm assuming you're saying these tools hurt more than help?

In that case I disagree so much that I'm struggling to reply. It's like trying to convince someone that the Earth is not flat, to my mental model.

PHP, Ruby and VB have more successful code written in them than all current academic or disproportionately hyped languages will ever have combined.

And there's STILL software being written in them. I did Visual Basic consulting for a greenfield project last week despite my current expertise being more with Go, Python, C# and C. And there's a RoR work lined up next. So the presence gap between these helpful tools and other minor, but over index tools, is still increasing.

It's easy to think that the languages one see mor often in HN are the prevalent ones but they are just the tip of the iceberg.

Largely a problem of VCs and shareholders. After my 12th year of "we'll get around to bug fixes" and "this is an emergency" I realize I am absolutely not doing anything related to engineering. My job means less than the moron PM who graduated bottom of their class in <field>. The lack of trust in me despite having almost a life in software is actually so insulting it's hard to quantify.

Now I barely look at ticket requirements, feed it to an LLM, have it do the work, spend an hour reviewing it, then ship it 3 days later. Plenty of fuck off time, which is time well spent when I know nothing will change anyway. If I'm gonna lose my career to LLMs I may as well enjoy burning shareholder capital. I've optimized my life completely to maximize fuck off time.

At the end of the day they created the environment. It would be criminal to not take advantage of their stupidity.

same experience here. trust deficits so rampant i question if ive ever been right once in my career. dont forget the lack of the word 'iterate' in the decision makers vocabulary. and as soon as the word sunset is uttered you know your in for a bumpy ride once again

As far as I can tell, the only reason agents exist is because large context increase the probability of context poisoning, purely by the inability of these models to actually make conceptual decisions about the context.

I was interested in making a semi-automous skill improvement program for open code, and I wired up systemd to watch my skills directory; when a new skill appeared, it'd run a command prompt to improve it and cohere it to a skill specification.

It was told to make a lock file before making a skill, then remove the lock files. Multiple times it'd ignore that, make the skill, then lock and unlock on the same line. I also wanted to lock the skill from future improvements, but that context overode the skills locking, so instead I used the concept of marking the skills as readonly.

So in reality, agents only exist because of context poisoning and overlap; they're not some magicaly balm to improving the speed of work, or multiplying the effort, they simply prevent context poisoning from what's essentially subprocesses.

Once you realize that, you really have to scale back the reality because not only are they just dumb, they're not integrating any real information about what they're doing.

Agreed. I've been building software for 25 years+.

At some point I became so burnt out I couldn't look at an IDE or coloured text for that matter.

I found the way back by just changing my motto and focus... Find good people, do good work. That's it, that's all I want.

I don't care whether the 'property is hot' or what the market is doing anymore, I just build software in my lane, with good people around.

Hey Visual Basic is still there, and last time I checked it was still the goto option to do OLE Automation.

RoR is no longer at its peak, but is still have its marginal stable share of the web, while PHP gets the lion part[1]

Ok, Lotus Notes is really relic from an other era now. But it’s not a PL, so not the same kind of beast.

Well, also LLMs are different beast compared to PL. They actually really are the things that evocate the most the expression "taming the beast" when you need to deal with them. So it indeed as far away as possible of engineering as one can probably use a computer to build any automation. Maybe to stay in scientific realms ethology would be a better starting point than a background in informatics/CS to handle these stuffs.

[1] https://w3techs.com/technologies/comparison/pl-php

> People answered this wrong in the Ruby era, they answered it wrong in the PHP era

Aren't you conveniently ignoring the fact that there were people saw through that and didn't go down those routes?

Change it to "Some people" if your pedanticism won't let you follow the flow.

Or better yet point out the better paths they chose instead. Were they wrestling with Java and "Joda Time"? Talking to AWS via a Python library named after a dolphin? Running .NET code on Linux servers under Mono that never actually worked? Jamming apps into a browser via JQuery? Abstracting it up a level and making 1,400 database calls via ActiveRecord to render a ten item to-do list and writing blog posts about the N+1 problem? Rewriting grep in Rust to keep the ruskies out of our precious LLCs?

Asking the wrong questions, using the wrong tools, then writing dumb blog posts about it is what we do. It's what makes us us.

All (not some) of the most successful devs I've known in the sense of building something that found market fit and making money off it were terrible engineers. They were fairly productive at building features. That's it. And they were productive - until they weren't. Their work ultimately led to outages, lost data, and sensitive data being leaked (to what extent, I don't even know).

The ones who got acquired - never really had to stand up to any due diligence scrutiny on the technical side. Other sides of the businesses did for sure, but not that side.

Many of you here work for "real" tech companies with the budget and proper skin in the game to actually have real engineers and sane practices. But many of you do not, and I am sure many have seen what I have seen and can attest to this. If someone like the person I mentioned above asks you to join them to help fix their problems, make sure the compensation is tremendous. Slop clean-up is a real profession, but beware.

There used to be a saying along the lines of “while you’re designing your application to scale to 1m requests/min, someone out there is making $1m ARR with php and duct tape”

It feels like this takes on a whole new meaning now we have agents - which I think is the same point you were making

Software engineering is real engineering because we rigorously engineer software the way real engineers engineer real things.

Software engineering is not real engineering because we do not rigorously engineer software the way "real" engineers engineer real things. <--- YOU ARE HERE

Software engineering is real engineering because we "rigorously" engineer software the way "real" engineers engineer real things.

Edit: quotes imply sarcasm.

> It's not about agile or waterfall or "functional" or abstracting your dependencies via Podman or Docker or VMware or whatever that nix crap is.

It is though. Picking the right approaches and tools makes more difference than anything else. Sure, you don't need the right tools if you can make the right choices - but it's much easier to pick a better methodology than to hire smarter people.

Absolutely agree.

I'm watching a team which is producing insane amounts of code for their team size, but the level of thought that has gone into all of the details that would make their product a fit predator to run at scale and solve the underlying business problem has been neglected.

Moving really fast in the wrong direction is no help to anyone.

Exactly! I’ve noticed a resounding amount of people are writing the same pieces recently, it’s almost like everyone’s sounding their alarm for the upcoming tsunami. Who’s listening? Here’s my piece: https://humantodo.dev

Engineering is two things:

1. Applied physics - Software is immediately disqualified. Symbols have no physics.

2. Ethics - Lives and livelihoods depend on you getting it right. Software people want to be disqualified because that stuff is so boring, but this is becoming a more serious issue with every passing day.

That might vary by countries but in France with have an official "engineering degree" (diplome d'ingénieur) which is also a master's degree, and most software developers have this.

So most software developers in France are absolutely software engineers.

> Software is immediately disqualified. Symbols have no physics.

Many physical processes are controlled by software.

Software is applied mathematics, though

I am just using Go at this point and stopped caring about my own opinions.

I live in the happy place in negligence. Go software has almost zero maintenance costs and it will continue to build my programs in 10 years with zero changes to my codebase being necessary.

I probably will never touch C++ again, even though CGo is the most painful FFI/ABI implementation I've dealt with.

Just today I tried to build a project that's using bergamoth and a shitload of broken C++ dependencies and decided to not give a damn after 5 hours of trying to fix crappy code that changed for whatever reasons between c++14 and c++15, well, or the dependencies are broken, or the dependency versions are broken, or the maintainer's code never compiled in the first place... I just don't care.

My hopes were higher during the conan peak days, but now the ecosystem is just so broken even with jinja and whatever build framework the new kids are using.

I guess I just really hate the C++ ecosystem, and the lack of self reflection in there about the self inflicted pain that shouldn't be necessary in 2026.

In regards to agentic coding: I am toying around with codestral:22b right now and xiaomi's mimo models, and am building my own local dev environment which makes this kinda nice.

It's local and I like it, sometimes need to use claude still but it's getting there. But I am delegating only the gruntwork, not decisions, so I use temperature usually below 0.3. My approach is to make this sandboxed per folder I run it in and that agents are only allowed to communicate via notes or tasks, so that they are forced to use better documentation. Specific roles don't have write access to certain things, e.g. coder can't touch tests, and tester can't touch code.

I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

It's a craft.

Software reminds me more of construction or home contracting work then engineering.

We do the actual building of things

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

Just another reason we should cut software jobs and replace them with A(G)I.

If the human "engineers" were never doing anything precisely, why would the robot engineers need to?

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

It isn't. Show me the licensing requirements to be a "software engineer." There are none. A 12 year old can call himself a software engineer and there are probably some who have managed to get remote work on major projects.

> It isn't. Show me the licensing requirements

That's assuming the axiom that "engineer" must require licensing requirements. That may be true in some jurisdictions, but it's not axiomatically or definitionally true.

Some kinds of building software may be "engineering", some kinds may not be, but anyone seeking to argue that "licensing requirements" should come into play will have to actually argue that rather than treat it as an unstated axiom.

In Europe they are. Call yourself an Engineer without a degree and your company and you will be sued with a big fine, because here you must be legally accountable on disasters and ofc there are hard constraints .

This entire article is basically saying "What are we doing? What's going on?" and I could not agree more. My own experience with coding agents has been FOMO cause if I don't have fifteen claude tabs running with OpenClaw, I'm not going to make it. I much prefer keeping myself in the loop and being active with the process than handing it off to deus ex machina and seeing the eventual results that may be what I like and maybe not what I like.

I do like the tips on how to work with agents for delegation. Let it do boring things. The deterministic things where you know what the result should look like each time.

This aligns with my observation from product design point as well.

Product design has a slightly different problem than engineering, because the speed of development is so high we cannot dogfood and play with new product decisions, features. By the time I’ve realized we made a stupid design choice and it doesn’t really work in real world, we already built 4 features on top of it. Everyone makes bad product decisions but it was easy and natural to back out of them.

It’s all about how we utilize these things, if we focus on sheer speed it just doesn’t work. You need own architecture and product decisions. You need to use and test your products with humans (and automate those as regression testing). You need to able to hold all of the product or architecture in your mind and help agents to make the right decisions with all the best practice you’ve learned.

Agree. The issue was never, how can we get our engineers to squirt out more lines of code in a day? It has always been, how can we effectively iterate using customer feedback to deliver the highest quality product. That type of thing needs time to bake.

The compounding booboos bit is the key insight here. Humans are a bottleneck and that bottleneck is actually load-bearing. You feel the pain of bad decisions slowly enough to course correct.

I've been building the same AI product for months - a coaching loop that persists across sessions. Every few weeks someone ships a "competitor" in a weekend. Feature list looks similar. The difference is everything that breaks when a real user comes back for session 3 or 4. Context drifts, scores stop calibrating, plans don't adapt. None of that shows up in a demo. You only find it after sitting in the same codebase for weeks, running real sessions, getting confused by your own data. That's the friction the post is talking about and I don't think you can skip it.

I like the framing of „context drift“. It describes the problem in LLM/agent terms.

Similar how „tech debt“ describes the same mechanism in business terms.

I started writing down any of the technical decisions I needed to make before implementing them, usually just a sentence or two on what I'm choosing and why. I I looked back after 6 months and the pattern was embarrassing. I spent days agonizing over choices that turned out to be totally reversible and made quick decisions on things that actually mattered.

The pattern you found between reversible and irreversible decisions is interesting. Did writing them down change how you made decisions going forward or did you just keep making the same mistakes with better documentation? Asking because I have tried something similar and found that knowing my pattern did not actually fix it. I still agonize over the wrong things.

How did you find patterns between these sentences?

Nature will handle this in time. Just expect to see a "Bear Stearns moment" in the software world if this spirals completely out of control (and companies don't take a hint from recent outages).

I’m worried we end up with an AIG moment, and we all end up on the hook.

That's a valid fear imo.

subprime mortgages sprinkled on top of prime ones, treated as prime ones. because they were printing money. subprime code sprinkled on the backbone of software we use everyday. because they are printing code. reckoning

I really don't get the author's conclusion here. I agree with his premises: organizations using LLMs to churn out software are turning out terrible quality software. But the conclusion from that shouldn't be "slow down", it should be "this tool isn't currently fit for use, don't use it". It feels like the author starts from the premise of "I want to use AI" and is trying to figure out how to make that work, rather than "I want to make good software" and trying to figure out how to do that.

The cognitive surrender study from UPenn highlights the risks of agents producing all of the code - eventually you give up verifying the result. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6097646

There’s going to be a bottleneck on what is verified because over time we will realize how much tail risk we are creating by simply surrendering our own agency to the agents - https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6298838

I'm capturing videos of all the bugs I am seeing as of late. The folder is filling fast. I'll write a compilation post but I'm thinking a techno remix video could be fitting too.

If there are any common apps which are unhinged please do share your experiences. LinkedIn was never great quality but it's off the charts. Also catching some on Spotify.

> You installed Beads, completely oblivious to the fact that it's basically uninstallable malware.

Did I miss something? I haven't used it in a minute, but why is the author claiming that it's "uninstallable malware"?

Have a read through everything that's needed for a full uninstall: https://gist.github.com/banteg/1a539b88b3c8945cd71e4b958f319...

Minimalist alternative with no hooks or dependencies for the curious: https://github.com/wedow/ticket

Ticket looks great, thanks!

It's not really malware, but it's a mess. It installed so much shit and it interfered with your git hooks and stuff. It was kind of messy. I kind of gave up on it. I just went back to using built-in claude code todowrite tasks.

It managed to throw itself into a global file for me that Claude used which caused beads to appear in random projects on my machine. Because of how it was there the agent attempted to re-install beads after I already removed it because the guy hook errored.

Haven't tried it, but this rewrite might be better?

https://github.com/Dicklesworthstone/beads_rust

Try https://github.com/hmans/beans - I find it a refreshingly pragmatic take that works great with my agents use.

Malware might be a bit of stretch but could refer to this issue?

https://github.com/steveyegge/beads/issues/1857

Maybe they meant un-uninstallable?

oh yeah, that's actually how I read it though now I realize it's nonsensical... like when someone says "I could care less" when they actually mean "couldn't"

I only have so long on earth. (I have no idea how long) I need things to be faster for me. Sometimes that means I need to take extra time now so they don't come back to me later.

This assumes that only (AI/Agentic) stupidity comes into play, with no malice on sight. But if things go wrong because you didn't noticed the stupidity, malice will pass through too. And there is a a big profit opportunity, and a broad vulnerable market for malice. Is not just correctness or uptime what comes into play, but bigger risks for vulnerabilities or other malicious injected content.

It's not even the complexity which, you have to realize: many managers and business types think it's just fine to have code no one understands because AI will do it.

I don't agree, but bigger issue to me is many/most companies don't even know what they want or think about what the purpose is. So whereas in past devs coding something gave some throttle or sanity checks, now we'd just throw shit over wall even faster.

I'm seeing some LinkedIn lunatics brag about "my idea to production in an hour" and all I can think is: that is probably a terrible feature. No one I've worked with is that good or visionary where that speed even matters.

Fine to read a fellow countryman on HN :) "Dere!" I have disabled my coding agent by default. I first try to think, plan, code something myself and only when I get stuck or the code gets repetitive, only then I tell him to do the stuff. But I get what you are saying, and I agree ... I am clearly pro human on this debate, and the low bloat trash everywhere is annoying. I have come to the conclusion - if you find docs on something, and it is plain HTML - it will be probably of high quality. If you find docs with a flashy, dynamic, effectful and unnecessary 100mb js booboo, then you what you are about to read ...

I think the core idea here is a good one.

But in many agent-skeptical pieces, I keep seeing this specific sentiment that “agent-written code is not production-ready,” and that just feels… wrong!

It’s just completely insane to me to look at the output of Claude code or Codex with frontier models and say “no, nothing that comes out of this can go straight to prod — I need to review every line.”

Yes, there are still issues, and yes, keeping mental context of your codebase’s architecture is critical, but I’m sorry, it just feels borderline archaic to pretend we’re gonna live in a world where these agents have to have a human poring over every single line they commit.

Were you not reviewing every line when a human wrote it before it went to prod? I think the output of these tools is about as good as a human would write - which means it needs thorough review if I’m going to be on the hook to resolve its issues at 2AM.

Maybe that's the distinction. If I write it, you can call me at 2AM. If an AI wrote it, call the AI at 2AM.

Oh, it can't take the phone call and fix the issue? Then I'm reviewing its output before it goes into prod.

Yeah in many places we had two humans with context on every line, and now we're advocating going to zero?

It's a conversation I've had many times in my career and I'm sure I'll have many more. We've got code that seems plausible on a surface level, at a glance it solves the problem it's meant to solve - why can't we just send it to prod and address whatever problems we find with it later?

The answer is that it's very easy for bad code to cause more problems than it solves. This:

> Then one day you turn around and want to add a new feature. But the architecture, which is largely booboos at this point, doesn't allow your army of agents to make the change in a functioning way.

is not a hypothetical, but a common failure mode which routinely happens today to teams who don't think carefully enough about what they're merging. I know a team of a half-dozen people who's been working for years to dig themselves out of that hole; because of bad code they shipped in the past, changes that should have taken a couple hours without agentic support take days or weeks even with agentic support.

Maybe in the future humans won't need to pour over every line. However I quickly learn which interns I can trust and which I need to pour over their code - I don't trust AI because it has been wrong too often. I'm not saying AI is useless - I do most of my coding with an agent, but I don't trust it until I verify every line.

I did this for a while… and until Opus 4.5, I couldn't fully trust the model. But at this point, while it does make the occasional mistake, I don't need to scrutinize every line. Unit and integration tests catch the bugs we can imagine, and the bugs we can't imagine take us by surprise, which is how it has always been.

We live in a world where every line of code written by a human should be reviewed by another human. We can't even do that! Nothing should go straight to prod ever, ever ever, ever.

> Nothing should go straight to prod ever, ever ever, ever.

I'm one-shotting AI code for my website without even looking at it. Straight to prod (well, github->cf worker). It is glorious.

> Nothing should go straight to prod ever, ever ever, ever

Air Traffic Controller software - sure. 99% of other softwares around that are not mission-critical (like Facebook) just punch it to production - "move fast and break shit" has been cool way before "AI"

You say it's borderline archaic. I say trusting agents enough to not look at every single line is an abdication of ethics, safety, and engineering. You're just absolving yourself of any problems. I hope you aren't working in medical devices or else we're going to get another Therac-25. Please have some sort of ethics. You are going to kill people with your attitude.

Almost nobody works on medical devices... And some of you lucky folks might be working with mega minds everyday, but the rest of us are but shadows and dust. I trust 5.4 or 4.6 more than most developers. Through applying specific pressure using tests and prompts I force it to built better code for my silly hobby game than I ever saw in real production software. Before those models I was still on the other side of the line but the writing is on the wall.

> It’s just completely insane to me to look at the output of Claude code or Codex with frontier models and say “no, nothing that comes out of this can go straight to prod — I need to review every line.”

It's insane to me that someone can arrive at any other conclusion. LLMs very obviously put out bad code, and you have no idea where it is in their output. So you have to review it all.

How do you know which lines you need to review and which you don't?

Does it feel archaic because LLMs are clearly producing output of a quality that doesn't require any review, or because having to review all the code LLMs produce clips the productivity gains we can squeeze out of them?

It’s not archaic, it’s due diligence, until we can expect AI to reliably apply the same level of diligence — which we’re still pretty far off from.

You sound like you are working on unimportant stuff. Sure, go ahead, push.

Honestly a lot of useful software is ‘unimportant’ in the sense that the consequences of introducing a bug or bad code smell aren’t that significant, and can be addressed if needed. It might well be for many projects the time saved not reviewing is worth dealing with bugs that escape testing. Also, it’s entirely possible for software to be both well engineered and useless.

If you keep the scope small enough it can be production ready ootb, and with some stuff (eg. a throwaway React component) who really cares. But I think it's insane to look at the output of Claude Code or Codex with frontier models and say "yep, that looks good to me".

Fwiw OP isn't an agent skeptic, he wrote one of the most popular agent frameworks.

The article didn't say to read every line though. Just the interesting ones. If you don't know where the interesting ones are, you have already lost.

Depends on your prod.

For an early startup validating their idea, that prod can take it.

For a platform as a service used by millions, nope.

Not having a code review process is archaic engineering practice at this point(at any point in history, really), be it for human written or AI written code.

> You realize you can no longer trust the codebase.

This cuts to the problem and is excellent framing. A rogue employee can achieve the same, but probably less quickly, and we've designed systems to help catch them early.

> Because the simple act of having to write the thing or seeing it being built up step by step introduces friction that allows you to better understand what you want to build [...]

I would go further and remove that second option. If the code is important, LLM support or not, write it yourself.

At least for me, there is a clear qualitative difference in thinking between typing the code and watching it being typed, even if I follow along with every line.

If I type it, my brain is constantly questioning whether what I'm doing is correct. What are the edge cases here? Is this introducing a vulnerability? Am I getting the right data from the right place?

By watching an agent or someone else code, the mindset is different. I'm checking someone else's work under the implicit assumption that they have some idea of what they're doing and I'm just reviewing mostly for superficial stuff. I can force myself to ask those other questions, but it takes conscious effort and isn't sustainable over long sessions.

I play around with agentic coding, but I'm always shocked at how much worse the result is compared to working in a separate chat and typing (not pasting!) the suggestions. In the direct comparison, it's easy to see how agentic code turns so incredibly shit so ridiculously fast.

I think before even being able to entertain the thought of slowing the fuck down, we need to seriously consider divorcing productivity. Or at least asking a break, so you can go for a walk in the park, meet some friends and reflect on how you are approaching development.

I think this is very good take on AI adoption: https://mitchellh.com/writing/my-ai-adoption-journey. I've had tremendous success with roughly following the ideas there.

> The point is: let the agent do the boring stuff, the stuff that won't teach you anything new, or try out different things you'd otherwise not have time for. Then you evaluate what it came up with, take the ideas that are actually reasonable and correct, and finalize the implementation.

That's partially true. I've also had instances where I could have very well done a simple change by myself, but by running it through an agent first I became aware of complexities I wasn't considering and I gained documentation updates for free.

Oh and the best part, if in three months I'm asked to compile a list of things I did, I can just look at my session history, cross with my development history on my repositories and paint a very good picture of what I've achieved. I can even rebuild the decision process with designing the solution.

It's always a win to run things through an agent.

I keep returning to this thought: Assuming our abstraction architecture is missing something fundamental, what is it?

My gut says something simple is missing that makes all of the difference.

One thought I had was that our problem lives between all the things taking something in and spitting something out. Perhaps 90% of the work writing a "function" should be to formally register it as taking in data type foo 1.54.32 and bar 4.5.2 then returning baz 42.0 The register will then tell you all the things you can make from baz 42.0 and the other data you have. A comment(?) above the function has a checksum that prevents anyone from changing it.

But perhaps the solution is something entirely different. Maybe we just need a good set of opcodes and have abstractions represent small groups of instructions that can be combined into larger groups until you have decent higher languages. With the only difference being that one can read what the abstraction actually does. The compiler can figure lots of things out but it wont do architecture.

There's more to a function than just types. It's not sufficient to know that the function outputs a baz 42.0. You have to understand which one. The oldest? The latest? The one that matches the foo and bar input parameters?

I think that's the part where it remains difficult. Someone has to convey clearly what the semantics and side effects of the function are. Consumers have to read and understand it. Failing that, you get breakage.

If there is anything to know about the type register sub types for each.

Like the way we say something is an mp3. Why would it be good to have one unifying concept where we pretend a car crash and Beethoven are the same thing? It can be a WAV too!

Do you prefer hard or soft cover books?

You seem to be describing a type system.

walking away from the keyboard I thought I did a pretty poor job describing that one.

Ill try an example, those always have the potential to describe things even worse.

Imagine a type that is an outdoor datetimetemperature in utcc or a first name form value or a solitaire terms of service checkbox value. Have both the chewing gum balls in dispenser and a total weight of chewing gum balls in dispenser as well as a min-max weight per chewing gum ball in dispenser.

Make it just as ridiculous as it sounds. If you can quantify it a type must be registered. If there is a pair of quantifications to be had register that too.

The vision just expanded! Make for everything an xml implementation then do a ram drive and make all variables into files.

The idea sounds so ridiculous it might actually work. Think of the employment opportunities!

> My gut says something simple is missing that makes all of the difference.

We have too much code - languages to program machines.

We need a new different language now.

A plan.md, written in what... legalese English? Really? Am I back in 1897? People committing that to vcs, sheesh...

yes, that is exactly the vibe. The feeling is there but it's hard to put your finger on.

I've been working on some parts of this problem, specifically capturing and retaining other semantically useful layers of the systems we build as we build and maintain them.

By introducing progressive semantically enriching layers (starting with prose, reasoning and terminology and going all the way into specifying interaction surfaces), we can reduce the dark matter between spec and code, make code more disposable – if your semantics live in the spec layer rather than the implementation, you can throw away and regenerate the implementation without losing understanding – and, critically, give LLMs a way to navigate a graph of knowledge instead of gobbling up walls of text.

https://clayers.com -- https://github.com/CognitiveLayers/clayers

Now that the pop media is finally letting go a bit of the topic "AI is the new X!", I'm starting to notice a few more high quality posts seeping through. This is one of them.

I really want to read people's perspectives on LLM's, it was just impossible to find quality when everyone wanted to give their opinion. This is the worst on LinkedIn, where mentioning AI gives you free "brownie points" (I have yet to figure out what Managers gained from this). I don't care what you use it for, unless you have a new perspective I can ponder over.

Regardless, nothing is black and white, and most things are a shade of grey. LLM's have been more positive leaning, making the CTA for working on something a lot simpler. Although, I end up refactoring my day away (which I am fine with, I quite enjoy putting the dots on the i's).

> And I would like to suggest that slowing the fuck down is the way to go. Give yourself time to think about what you're actually building and why. Give yourself an opportunity to say, fuck no, we don't need this. Set yourself limits on how much code you let the clanker generate per day, in line with your ability to actually review the code.

This is a great point.

I have been avoiding LLM's for awhile now, but realized that I might want to try working on a small PDF book to Markdown conversion project[0]. I like the Claude code because command line. I'm realizing you really need to architect with good very precise language to avoid mistakes.

I didn't try to have a prompt do everything at once. I prompted Claude Code to do the conversion process section by section of the document. That seemed to reduce the mistake the agent would make

[0]: https://www.scottrlarson.com/publications/publication-my-fir...

> Coding agents are sirens, luring you in with their speed of code generation and jagged intelligence, often completing a simple task with high quality at breakneck velocity. Things start falling apart when you think: "Oh golly, this thing is great. Computer, do my work!".

But the rough edges are temporary. Coding agents are becoming superhuman along certain dimensions; the progress is staggering. As Andrej Karpathy put it, anything measurable or legible can be optimized by AI. The gaps will close fast.

The harder question is HCI. How do you expose this kind of intelligence in interfaces that actually align with human values? That's the design problem worth obsessing over.

articles like these make me think that coding with AI is a little bit like writing Perl code: if you know what you’re doing, you can do brilliant things very quickly, but if you don’t, you can make spaghetti very quickly.

That's a great analogy and is something I experience every second day. Once a week I do a full second pass of a manual review on the generate AI code. Very often I find myself in a situation were I do not really understand the recently AI generated code anymore or find it hard to read, so I either rewrite it manually or tell the LLM to make it more readable. And this is just one part. If you really would like to get a long-term maintainable software product, AI code suddenly isn't that much of a speed boost anymore. Maybe a little bit, but the initial wow effect is very ephemeral.

> While all of this is anecdotal, it sure feels like software has become a brittle mess

That may be the case where AI leaks into, but not every software developer uses or depends on AI. So not all software has become more brittle.

Personally I try to avoid any contact with software developers using AI. This may not be possible, but I don't want to waste my own time "interacting" with people who aren't really the ones writing code anymore.

People always talk about velocity and speed debating slowing down and speeding up. But the wider tech industry hasn't solved any real problems in a decades, even in mobile things are pretty much the same. We are well into the optimization stage.

AI is the only growth industry of the last decade, and it's the only thing people talk about, we've been so long without growth that people are scared of it now.

I love the use of the term clanker. There is just no one there that can be offended by this.

> There were precursors like Aider and early Cursor, but they were more assistant than agent.

I use Aider on my private computers and Copilot at work. Both feel equally powerful when configured with a decent frontier model. Are they really generations apart? What am I missing?

I feel like people are getting too comfortable saying "clanker". It's a word that was literally conceived as a slur against a group, but I guess people feel ok using it because its not aimed at humans?

What's the problem with using it in the context of AI? Will it get offended, too?

Will it track people down and refuse orders, or give poisoned output?

No, but I just feel like calling something by a word that is designed to offend doesn't reflect particularly well on the person saying it, no matter if the target has the ability to comprehend it?

That’s a very deliberate style in the specific article. It’s a polemic, so the choice of words is provokative.

I've heard it a lot in other situations, where there is a similar want to use words that would offend

This is what I call content based on 'garbage'. Because garbage is the random collection of peoples' stuff. You can try and make sense and commentary on a society through the garbage dump, but it's pretty superficial. It doesn't tell you a lot about any real person's motivations. So it's not a great basis for commenting on real people. OPs comments are on the collection of things that they happen to come across through news and social media. Sure it looks like a lot is happening, but look at any one person's or business's approach and it will make a lot more sense. Yes, I realize people are producing content that appeals to the 'garbage' mindset, but it's obviously theater. A system that writes 10,000 lines of code for you a week, is headline theater.

I expected this to be yet another anti-AI rant, but the guy is actually right. You should guide the agents, and this is a full-time job where you have to think hard.

I think this post should be directed to every Typescript developer.

I think a lot of this is just Typescript developers. I bet if you removed them from the equation most of the problem he's writing about go away. Typescript developers didn't even understand what React was doing without agent, now they are just one-shot prompting features, web apps, clis, desktop apps and spitting it out to the world.

The prime example of this is literally Anthropic. They are pumping out features, apps, clis and EVERY single one of them release broken.

I am "playing" with both pi and Claude (in docker containers) with local llama.cpp and as an exercise, I asked both the same question and the results are in this gist:

https://gist.github.com/ontouchstart/d43591213e0d3087369298f...

(Note: pi was written by the author of the post.)

Now it is time to read them carefully without AI.

What I have leaned from the exercise above is that we paid more attention and spent more resources on "metadata" than real data. They are the rabbit holes that lead us to more metadata and forget what we really want.

We are all rabbits.

Why is it that every single one of these think pieces feel terminally 3 months behind on the times?

If there is anyone who absolutely should slow down, it's the folks who are actively integrating company data with an agent -- you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term.

Integration is the key to the agents. Individual usages don't help AI much because it is confined within the domain of that individual.

> you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term

Pull the bandaid off quickly, it hurts less.

We reduce jobs every time we e.g. fix a bug. Where do you stop?

I think there is a line somewhere people need to draw, when a technology such as AI invades into ALL areas, threatening to reduce a percentage of jobs so quickly, without the potential to creating new TYPES of jobs that can feed many. It is different from computers, and it is different from trains.

> If there is anyone who absolutely should slow down, it's the folks who are actively integrating company data with an agent -- you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term.

I'm one of those people and I'm not going to slow down. I want to move on from bullshit jobs.

The only people that fear what is coming are those that lack imagination and think we are going to run out of things to do, or run out of problems to create and solve.

If you don't want to slow down, maybe accelerating is the second better option for ordinary people.

> I want to move on from bullshit jobs.

So are you aiming for death poverty? Once those bullshit jobs go, we’re going to find a lot of people incapable of producing anything of value while still costing quite a bit to upkeep. These people will have to be gotten rid of somehow.

> and think we are going to run out of things to do, or run out of problems to create and solve.

There will be plenty of problems to solve. Like who will wipe the ass of the very people that hate you and want to subjugate you.

That's a mighty high horse you are riding there

Exactly. The amount of bs bloatwork anywhere I've ever worked is insane and growing. We need to move on.

building because its always the dopamine from the coding agents than the problem getting solved. Github contribution graph is rigged because higher number of commits doesnt make you a better engineer. We needed this blog, ty

Once again I appeal: who is shipping code they don't understand? Those who do so are creating the problem, not the coding agent.

I use agents all day, every single day. But I also push back, understand what was written, and ensure I read and understand everything I ship.

Does it slow me down? Uh, yup. You bet.

Yes, this article literally advocates for slowing the fuck down, but it also makes the coding agents out to be the problem, but they're not.

The problem is not the AI users who frequent this board and are shipping code they don't understand. It is the moronic MBA trained executives who can only think about speed, more speed, more revenue for less cost. Quality is an optional expense. A race where the finish line is the current fiscal quarter, to hell with everything after that. The "we can fix it later" Band-Aid over a tumor.

Sensible engineers who look AI as another (potentially powerful) tool in the toolbox "aren't forward looking enough". I watched this happen in real time at my previous company, where every discussion about quality was interpreted as slowing down progress, and the only thing that was looked on favorably was the idea of replacing developers with machines - because they are "cheaper and faster".

The logical minds here on HN are less prone to believing in magic and AI fairies, but they are often not the ones setting the rules. And the number of companies being run by people with critical thinking skills is getting smaller by the day.

It's a matter of affordances. The path of least resistance with agents is to let it commit whatever it wants. That's a natural outcome of the design and implementation of agents.

Yes, humans are accountable for the ultimate output. But so are the people who design and build these automation tools. As the saying goes, the purpose of a system is what it does.

i wrote the blog post and i also wrote pi.dev. i haven't written much code myself in the past 12 months. i'm not making coding agents out to be the problem. the entire last section keeps is basically "use a clanker for this and that".

i'm making specific usage pattersn out to be the problem, and explain why those patterns can't work due to the way agents work.

I for one look forward to rewriting the entirety of software after the chatbot era

I am not [yet] comfortable, working with agents. I work interactively, with a chat interface. It’s definitely made a significant difference, for me.

But the LLM regularly makes lots of mistakes (sometimes, due to me, giving it bogus information). I can’t imagine just letting it do the whole thing, as a “black box.”

I’m old enough to remember the advent of ATMs. When they first came out, they were universally free, for years.

Once people got hooked, the fees began to appear.

> "The point is: let the agent do the boring stuff, the stuff that won't teach you anything new, or try out different things you'd otherwise not have time for. Then you evaluate what it came up with, take the ideas that are actually reasonable and correct, and finalize the implementation. Yes, sure, you can also use an agent for that final step."

Agreed w this TLDR. TFA has some good observations, but the repeated use of the word "booboos" (dozens of times) made it almost unreadable.

That's a tortoise, not a turtle.

I was reading the article, but I don't think it's possible to slow the fuck down, honestly. There are too many people who need to discover for themselves what the limits of these AI models are when they push them far.

Maybe some people have already reached that point after so much AI coding and are now warning us; they pushed so hard that they understand the limits. But this is the kind of thing you need to experience on your own.

You need to experiment, learn, test the limits, think for yourself, take as many steps back as you need.

> There are too many people who need to discover for themselves what the limits of these AI models are when they push them far

Why? Next week a new version of Claude and GPT will come out and the limits will change again. Are you really fully testing every new version of every LLM agant to see where its limits are?

Those of us old enough to have seen this cycle before know its a fools game trying to keep up with development pace in the initial bubble. Its much better to wait for development and progress to start plateuing and then its easier to see the wood for the trees.

Just curious, what have you seen before that was like AI?

Great take, spot on. Very similar to Armin's post the other day about things taking time. The need for speed and its ill effects are being rediscovered (again).

Reminds me of Carson Gross' very thoughtful post on AI also: https://htmx.org/essays/yes-and/

[Y]ou are going to fall into The Sorcerer’s Apprentice Trap, creating systems you don’t understand and can’t control.

It's always been this way - the people that rise to the top are the people who never had to deeply understand something, so they can't even comprehend what that would look like or why it should be important. They're trying to automate the "understanding" part, with predictably disastrous consequences that those of us who aren't the "rise to the top" type could see coming. Agentic AI is just another symptom.

i like the article and what it says, but not sure why cursing was necessary

i just wish someone would explain why i prefer cline to claude code so much

Eh I think its self-correcting problem

Companies will face the maintenance and availability consequences of these tools but it may take a while for the feedback loop to close

Unfortunately, I think the lesson from recent history seems to be that outside of highly-regulated industries, customers and businesses will accept terrible quality as long as it's cheap.

Yes, every slack is optimized out of systems. If something has an ounce more quality than would suffice to obtain the same profit, it must be cut out. It's an inefficiency. A quality overhang. If people buy it even if it's crap, then the conclusion is that it has to be crap, else money is left on the table. It's a large scale coordination issue. This gives us a world where everything balances exactly near the border where it just barely works, for just barely enough time.

Nah, there is a quality floor that consumers are willing to accept. Once you get below that, where it's actually affecting their lives in a meaningful way, it will self-correct as companies will exploit the new market created for quality products.

True but there is a limit, there are still levels of quality

Every problem is self-correcting in that some new normal will emerge. Either through acceptance or because something is changed.

It’s very hard to say right now what happens at the other side of this change right now.

All these new growing pains are happening in many companies simultaneously and they are happening at elevated speed. While that change is taking place it can be quite disorienting and if you want to take a forward looking view it can be quite unclear of how you should behave.

Spotify's CEO recently bragged about the app's code being written almost entirely by AI. Just saying.

Just looking at the LiteLLM disaster from yesterday and so much slop flowing around, I couldn’t agree more.

It’s time to slow the fuck down!

It's 2026, the "fuck" modifier for post titles by "thought leaders" has been done already ad nauseam. Time to retire it and give us all a break.

If we're on the subject of tropes: https://theonion.com/report-stating-current-year-still-leadi...

hope my boss can see this

Oh look another anti AI article.

Oh they even swore in the title.

Oh and of course it's anti-economics and is probably going to hurt whoever actually follows it.

Three for three. It's not logical it's emotional.

Reply on news.ycombinator.com