Hacker News Reader

Comment by kstenerud | Hacker News Reader

Hundreds of bots modifying thousands of microservices may sound good on the surface, but all those thousands of microservices make up an architecture and a product.

Agents aren't very good at carrying the entire model in their context, so when they reason about a small piece of code, they often come up with something that hurts other parts of the code (especially as the KLOCs pile up). The complexity hasn't been replaced, only moved. And guess what's going to happen when all of these microservices become even more of a moving target than they already are?

AI is capable of improving productivity, but this approach sounds more like a nightmare in the making.

View on HN

The agents are like ants, and ants build like crazy until the resources run out in winter. AI winter is going to be interesting, to say the least.

I don't say this to be mean, but you need to plan for a world where it's always summer. Maybe the valuations will collapse with OSS models but programming is never going back to normal.

> but programming is never going back to normal.

Are you telling it's shit now? I'm just curious.

You're not going to get your old job back. You're a prompt engineer or you're fired.

Programming will never go back to what it was before 2026.

You're living in a corporate bubble, drowning in the kool-aid, along with half this forum.

You are saying programming IS going to go back to what it was? If yes, great! But how exactly? Why would anyone do that and why would companies want that?

I think Op did not claime that "programming is going back to what it was" because even the point we should be going back to is not agreed where it should be. It's a profession always in flux.

On the other hand, "you're a prompt engineer or you're fired" just reeks of psychosis. Things will change, they will never be the same, perhaps the profession will contract. But there sure as hell will still be people thinking deeply about their code and crafting it.

The models got good at this seven months ago.

Your hypothesis that your job is secure because the models hit a ceiling is based on seven months of observational history.

We've been watching the models get progressively better for years now. It's not going to stop in place.

In some amount of time from now, these models will absolutely require less hand holding.

It's as though everyone with your perspective isn't looking at the overall trend line. You're laser focused on just these last few months.

And if it comes, it comes. I have no doubt a model can be as good or better than humans. I don't think humans are the peak of possibly. I just don't think the current crop of models will get there. And I do not think fast takeoff will happen. In the meantime, I keel hearing psychotic chants of "don't even read the code anymore, bro!" While the code these things output is severely lacking. At this point, it _is_ cool-aid.

> I keel hearing psychotic chants of "don't even read the code anymore, bro!"

In just these seven months since Claude got good, I'm at $5M annualized at 65% MoM growth with 30% margins and plenty of opportunity to take that to 70%+. As a dev team of essentially one.

You're in a new game. Stop thinking with preconceived notions and take full advantage of it.

There are going to be a lot of winners and losers with this disruption. Don't lock yourself into the old regime because you grew up on newspaper.

I'd like to consider myself somewhere towards the middle of the spectrum on AI outlook, but posts like yours in this thread depress me. It's difficult for me not to see it as spreading FOMO so that you can gain financially.

When's the last time you worked as an IC? Is there any reason to take your opinions on "my job" seriously when downward pressure on salaries is only beneficial to you and whatever AI companies you're attempting to start?

"The world will be better off as a whole". Why do you think this? How are you contributing to making the world better with AI? Is there any reason that's not related to making money?

I'm trying to help you by sharing and you're choosing to be dark and gloomy about it. I can only help so much.

What you did a few years ago will likely dry up as a source of supporting you and your family. There is all kinds of new value to create in the world. Find the calling that is meaningful to you. Go cure cancer instead of plumbing widgets and wizbobs at 100k QPS active-active five nines SLA.

Just don't stay as a gas station pump attendant, butter churner, or elevator button presser.

And it's also wild that you assume what I'm doing doesn't bring value to the world. There's a film being released theatrically in a few months that directly incorporates what I've worked on. I've been a filmmaker for decades outside of tech and that is deeply meaningful to me.

I didn’t assume, I asked. But you’re being particularly condescending, so I guess that’s where we’re at.

“Directly incorporates” is pretty vague and still seems like it’s financial, but good for you. I hope it’s something that assists artists and doesn’t replace them. Personally it’s hard for me to find meaning in something like that, given the thread’s context of “I don’t even look at the code”. What craft was done? In what way is the movie better now? It’s cheaper?

I won’t endorse glee about anyone losing their job, even if it means people with a lot of freedom can throw things at the wall and see what sticks. Same story as always, it’s just faster now.

I wasn't being condescending, that's just text's inability to encode delivery.

You don't look at the bytecode you produce. You don't know 99.99% of your stack. You are a master of abstraction and you always have been. This is just a different flavor of the same recipe.

You've got a tool that will let you execute at greater breadth than ever before. Like what it must've been like for the very first engineers who had access to the internet or the first libraries or package managers.

Job flux is demand finding new salients. Employment hasn't dipped as far as I can tell. There are more exciting opportunities now than ever before, you just have to step into it.

I'll admit, this is a heated topic, and heated topics rarely go well over text.

I apologize for misreading and pettily being condescending "in return".

I agree with the way you phrased it here.

If the job is now being a promoter, how can you not see that it’s a low skill, low pay job anyway? There are a billion capable promoters in LCOL countries that can prompt as good as someone in the Bay. Might not be worth stressing so hard to be a promptmaxxer. Could just become a bus driver or some other skilled profession if you want to keep earning a living.

I don’t think this is actually true, though. In fact, I believe the opposite.

My experience with LLM assisted coding is that I need a technical hand on the steering wheel to get something workable out it. Otherwise, what comes out is a brittle, non-functional mess that only in the most tenuous way resembles what I had in mind.

The job was never to type the code out. The job was always to take a problem in the real world, and shape it into a model which can be implemented in software. What LLMs do not do is to architect a system of suitable complexity to the scope of the problem. If you give a low skill worker the job of writing the prompts you will first get a prototype. Then a prototype with more features tacked on. Then a prototype with so many features tacked on that it breaks under its own weight.

Software engineers know system design, and can adapt the system design to the scope of the problem. Are we creating a single piece which will eventually expand into a big system, we need to design completely differently from if we are creating a robust stand-alone thing, which just needs to do one thing and do that one thing really well.

If anything, we will need stricter skill requirements for software engineers. Just because anyone can produce code which runs now, does not mean we should let anyone loose on creating the critical software infrastructure of our society.

> The job was never to type the code out. The job was always to take a problem in the real world, and shape it into a model which can be implemented in software.

"Typing" the code was never the whole job, and it can be the easiest part. But "the code" is very much the artifact that is used to generate values. It being correct and easy to maintain lower the associated costs and MAY raise its value. It being brittle and hard to maintain raise the associated costs and WILL lower its value.

So being good at system design is how you target the first case.

> Software engineers know system design

And the models won't ever learn distributed systems?

You're basing your assumptions on the current status quo. The models only started getting useful in December, and so we just assume that's where progress ends?

The models are coming for all aspects of software. Schema design, distributed systems, SRE, ... They're not going to stop getting better. Especially when so much value creation and cost cutting is possible.

You assume the contraction of software engineering has peaked. I'm saying it's only getting started.

The skills we have aren't special or particularly hard. They're just boring and mundane enough that they're only attractive to a certain subset of the population. Most people would die if they sat in front of a computer for as long as we do. The demand for our skills has outstripped the labor pool. That's why we've been highly compensated, not because what we do is difficult.

The march of progress will continue, and it's a good thing. It might hurt us to no longer have in demand skills, but the world will be better off as a whole.

The important thing will be knowing what to build and how to market it. That's a totally different skill.

Many programmers still just write programs, using tools where it is useful.

Of course programming never stands still. I don’t think anyone thinks it will rewind. But your second sentence is very odd.

Your extraordinary claim may reflect life in certain companies in SV in the grip of AI Psychosis, but most companies are evaluating these tools objectively - they are certainly not ready to perform as agents or replace humans, and it is debateable whether they are providing much efficiency boost in the case where you try to replace humans writing code entirely - there are definitely significant downsides - loc inflation, lack of context, incorrect code which appears correct, wasted time, burnout of supervising humans having to read the output etc etc.

All the thought leaders like this article jumping to the shining future of independent agents cooperating under light human supervision are vastly premature - LLMs are nowhere near intelligent or independent enough for that.

> plan for a world where it's always summer

The difficulty in adopting this belief lies in the fact we have multiple points of reference in the past, of visionaries claiming that "this time is different" and we reached the end of history... and well, the rest is history.

But the models are useful now and Inference is profitable. At most we must worry that the latest is not actually useful, or that they won’t get better.

> Inference is profitable

Let's wait for Anthropic's S-1 to see if this is actually true.

Fundamentally, if Anthropic ain't profitable with all the investment and usage they get, then it's possible that it may not be economical to train new models in the future (I agree that inference for already trained models makes money, but the real question is if this money will pay for the cost of training & employees).

I hear you, but this time is different and history doesn't tell us what happens next. They were wrong those times. They would be correct today.

I don't have any clever argument to justify this, you just have to look at the ways the world is changing today and decide for yourself whether there is a clean historical analog.

It's a pun on AI winter - if there's not going to be a winter, then it's always summer. But things won't be static.

It is in fact normal for new technologies to be adopted, and for there to be no cycle where the technology just disappears. There was no Internet winter or railroad winter, not in the same way there was an AI winter where AI just went away.

Those technologies had valuation bubbles but the technologies themselves stuck around and changed the world beyond recognition. If someone sees the rate of change and thinks it'll stop for...some reason, then they're the ones who believe things are different this time.

My counterpoint is that "the internet" is quite recent, and has had many iterations - we've basically abandoned gopher, mostly irc, etc. Even "the web" as we know it is arguably entering a winter we can't yet foresee the duration of.

I 100% agree that "AI" is not going anywhere as long as humans are here (I wouldn't be building a company in the space otherwise).

I'm challenging this specific absolute certainty that "a swarm of agents building code like ants" will be living in eternal summer. This paradigm might be completely different just 6 months from now, from all we know!

Yes that’s very sanguine. On the other hand there have been many times when tech made a permanent difference.

Smartphones, internet, PCs, computers, semiconductors, relativity, antibiotics, telegraph, printing, electricity, steam power, …

It has stayed comms and compute summer since the end of the twentieth century. It has stayed infection summer since the beginning of the twentieth century. You get the idea.

I don't see why we would weight those points of reference stronger than the ones where people claimed "this time is different", and it really was different.

In fact there's almost nothing similar between my day to day life and the day to day life even of my grandfather, to say nothing of the Irish peasantry I came from 500 years ago, say. The number of correct everything-is-differences per year seems to be going up, not down.

In tech 'this time it's different' happens about every 10 years, so yes? Mainframes, minicomputers, the PC revolution, the internet in the 90s, commodity cloud computing: even more internet, the smartphone and now AI. It's not the end of history, it's the continuation.

okay, ignoring the oxymoron with which you end you comment, what do you think folks plan for when they put on a life jacket to enter a recreational boat?

Continual gains that have not stopped and there is clearly much gain to be had even if model intelligence stopped scaling. I find it borderline nasty how so many people are positively hoping for a bubble to pop or an AI winter to come so that they can feel like they can cope with the evolving world...despite all evidence to the contrary that any of these things will happen very soon at all.

currently unfettered ai spending is reducing qol for more individuals than it is increasing. why should the avg joe be happy about reduced qol?

who is it reducing qol for?

I get that SWE get far higher benefit than maybe everyone else, but who is it actively reducing QoL for?

Massive price increases for any electronics that contains RAM, SSDs, etc. has hurt everyone. The GPU supply crunch has hurt a smaller swath but hardly zero.

As a software engineer I don't think my quality of life has been improved - I now get gigantic patches to review (and I know the people writing them haven't reviewed or tested their own patches so even worse) and my tester is now drowning in big garbage patches that are taking longer to test, so my work isn't progressing either.

Yikes. Sounds like your workflow needs a ton of work if your SWE QoL hasnt improved. that's pretty wild that youd not be optimizing

additional to the great examples already given, anyone in residential proximity to a compute centre is recieving noise + environment pollution. resultant destruction of sleep and air/water quality is massively detrimental to qol. the joes who net benefit from ai detriments seem to live far away from the consequences. I shall ask another way, how do the average joe's ai benefits outweigh his ai detriments?

Data center complaints existed long before AI. The stories you read about neighborhood issues are by and large for pre-existing data centers. This is not an AI issue

I specifically mentioned the other arguments because I didn't want to repeat them, I'm not going to repeat them

Speak to young folk. My numerous nieces and nephews use ChatGPT all the time and yet they still hate it.

They are contemplating a lifetime of devalued skills, because they can see that prompting a model is an unskilled task.

I'd suggest that they need better education then. Prompting isn't unskilled. Neither was googling before that. There is critical thinking involved, and the method in which you utilize the outputs that matters as well.

Yes skills are going to be devalued, but that isn't happening yet for the vast majority. So its not really apt for them to think this way.

> I'd suggest that they need better education then.

I'd suggest you need better education.

> Prompting isn't unskilled.

That's not what the AI firms are selling.

Ah good well thought out points im really learning something

There's at least skill needed to recognize the BS in the answers.

I've been prompting a bit on a hobby project that sort of boils down to MechE. It's far from my domain of expertise but I've recognized enough BS and been sent down some rabbit holes all too frequently to discover the BS at the end.

There will, at some point, be a capex winter. Companies are splurging on a huge buildout and aren't going to buy GPUs at this rate forever.

That does not mean we're all going back to artisanally hand-crafting software. That's never going to happen.

Not sure what they are doing with the GPUs anyway, nvidia is on track to produce more GPUs than can be physically used, because the DCs don't exist, and won't for another 18 months, and the power plants needed likewise don't exist.

It’s like De Beers: control supply to control the price.

On the other hand, AI is good at following invariants and adversarially policing the system to pay back debt. The latter is too expensive for humans as a project grows.

Right now you can open Claude Code in your project and prompt it "start a workflow that fans out subagents, each with a narrow scope, to look for {simplifications, correctness by construction opportunities, <insert your goal>} ranked by impact vs confidence, and then collate the findings into result.md". If you have the tokens, do more workflows that find more issues and/or vet and polish the findings already in the file.

I do that every time my weekly usage is about the reset to spend me last tokens.

Maintenance is becoming trivial, and anyone who thinks AI dooms you to an ever growing mudball apparently hasn't considered using AI for anything other than appending more code to the mudball.

Are they? Because my experience is they’re really, really bad at following them and as context grows they get worse at following them.

I think probably something like 90% of developers are web developers doing some kind of web app that uses some remote API provided by someone else.

This works great as long as you are not doing what the parent comment cautions you to not do: Let agents decide the architecture.

The moment you do that, why even bother producing a result.md? Just let the Bot execute on its findings, you realistically won't be able to judge them anyway.

I've built many things this year letting sota models design the architecture, and they've been well-reasoned about it.

I think what you describe is a lack of harness/infra/process around working with agents on a project. No effort to document ADRs. No effort to document invariants. No effort to design processes that ensure maintainable software even if it were five years ago and only humans were writing the code.

Just because you delegate important decisions to AI doesn't obsolete practices as trivial as maintaining a log of potential issues in your codebase that you'd want to work through, keep track of, and verify.

And they're really good at adding more code to reduce complexity. In particular Claude is absolutely bonkers at the moment. I am having trouble taking this seriously especially because you mentioned Claude. Have you looked at anything it's done?

I use Claude model=fable effort=high to write most of my initial plans, especially the hard things like re-architecture.

I recommend putting time into figuring out the "soft infrastructure" of your projects, usually things you've never been arsed to do in your life (like me until this year).

Start with a docs/*.md folder that you link to from AGENTS.md where you can document things that would be important for you, any human, and especially AI to know. Start with a super basic ADR system where you document invariants over time, maybe a single DESIGN.md file that just lists them. Have a references/ directory that shallow clone all of the important deps you use for local agent reference (and tell the agents about them in AGENTS.md). Keep your plan files to higher level things like invariants, decisions, accepted risks, rejected ideas, that way you review the hard stuff, and sota models these days write crazy-good code.

Look at using AI as a skill that you have to learn and develop, not like how we see CSS where it's the technology's fault if we suck at it for life while putting zero effort into developing the skillset.

Or maybe there's some load bearing "make impossible states unrepresentable" platitude in my AGENTS.md I'm overlooking that's responsible for why I have such a great experience with AI and nobody else on HN apparently is.

I have a good experience too.

I do the same as you. I actively want to succeed with it, and therefore put time into making it work, and I have a good experience. As do the other 80+ developers at my company (it is a fintech). Pretty much every commit is written by claude currently, but I have to steer it constantly, and keep tweaking my setup.

I think the difference is probably that some people just don't really like the idea, therefore put in the minimum of effort, see that results are sub-optimal (which they definitely can be), and declare it useless.

> Or maybe there's some load bearing "make impossible states unrepresentable" platitude in my AGENTS.md I'm overlooking that's responsible for why I have such a great experience with AI and nobody else on HN apparently is.

We can notice that you're describing the work, but not any result that have derived it from it. I can explain to someone how to learn vim and tmux, but the best argument is to explain the benefits of doing so. I can't just say, take two weeks of your time and wait for the results.

I've been on HN seeing all kinds of comments like yours that promote spending more for tools (time and money) but never expand on WHY I should even do that or what's the proven benefits of doing so.

The context here is using AI agents to automate high-quality software development, something that is slow and expensive to do by hand which committed us to suboptimal maximas like "that subsystem is too gnarly and fragile to improve, so we won't" and "we used React Native in the Windows start menu because it's what the developer knew best".

This is the part people often miss: durable context matters more than the prompt. We are maintaining https://github.com/VoltAgent/awesome-design-md, an open-source collection of `DESIGN.md` files for coding agents.

It applies the same idea specifically to visual design, making things like typography, spacing, colors, layouts, and component patterns explicit and reusable. You can use the existing examples as a starting point or contribute your own.

Great advice and PoV. One nit: I recommend against the filename "DESIGN.md" for architectural invariants, in light of the emerging use of that filename for UI / design system / CSS tokens (colors, fonts, typography, etc).

See https://designmd.ai/ for examples.

Good point. "decisions.md" is a good starting spot.

The point, of course, is that you need some way to document decisions and pivots and eurekas (including rejected ones) over the lifetime of the project. It's a key part of invariant discovery and then committing to them.

Seems to me the real question is "what scheme can we use to organize our code base such that an agent working on one part really can make changes and not break the other parts on accident".

My current theory I might test out is to treat generative AI as generative AI. This means instead of editing things like a microservice in place you version freeze them to bug fixes only and create new versions for new features. This way you can go and update all the places that use the old version to the new version one at a time. As you do you can check that the new version does not break anything while still having an old version to fall back to.

This would presuppose only a single new version being "in-flight". But a microservice change often bleeds into another microservice having to change. Multiply this by all the agents working on the product, and you get a very complicated release process for those microservices.

The ripple effects are basically the same as what you'd get in a monolithic codebase. In fact you can still think of a set of microservices as a single codebase, just not centrally maintained anymore. The complexity is moved rather than eliminated. And you'll still have agents (and people) stepping on each other if there's too little coordination.

More coordination is exactly what the commenter was proposing though so I dont really see the point in your response.

Right but if you coordinate those changes in a new version you would still have the old version to fall back to if any of those changes lead to problems.

Yes, but then there's a trap lurking nearby: As different versions of the same function proliferate, it muddies the waters, because you now have multiple parts of your system calling a similar-but-not-quite-the-same function. Your refactors are never complete, and you find yourself less able to properly reason about the system as a whole anymore. The payment and subscription systems call different versions of the same function, which works most of the time but they don't always agree.

With a lot of discipline and process control, one could make such a system work, but it's most definitely not a free lunch. The complexity has to go somewhere.

Yes, I agree half finished refactors are bad. But I think with AI the timing is a bit different now so the best plan changes. I.e. AI can finish various steps in generating the new version and transitioning to the new version much faster than people could in the past. So you are unlikely to end up with lots of half finished refactors because AI can finish them fast.

The bigger problem now is handling the AI mistakes and failures, not slogging through all the steps of a refactor. So having a full and complete ready to go fallback version with like Blue / Green deploys might be really helpful. But to do that you need discrete versions, not digging through diffs to find the problem and redeploy.

But this is all just a theory I haven't tested right now.

This has been one of the billion(s) dollar questions of 2026. There have been a few approaches emerging throughout the year (heuristics to hard-divide work, using better languages with dependable contracts, task management protocols, and organizational agent roles). None has won so far, though, but some appear (or claim) to be close.

How does this freezing version and new version and so on differ from having the code in a version controlled repo?

It would be more about the release cadence and strategy. I.e. instead of deploying to production as fast as possible after merging new code, have discrete releases. Like maybe daily, weekly or monthly. And keep the last couple releases around ready to roll back as fast as possible if there are issues with the new release

Imo there's zero difference between 'thousands of microservices' and 'one monolith with thousands of functions/classes/etc' in terms of effort required to make it correct - both are still tiny interconnected pieces making up a whole, and you can separately unit test a function just as easily as you can separately e2e test a single microservice.

They still make up some whole product that presumably does something as a whole that you actually care about, and the complexity inherent to that doesn't go away with either approach.

1 difference (out of many, many, differences), is that (most) compilers don't make guarantees across process boundaries.

Sure there is. For thousands of classes/functions, I can test the boundaries between them in nanoseconds each. Integration tests are the important part, because with the quality of AI coding these days, unit testing is a waste of time.

With micro services, that same function call is now a minimum of 200us. And now I have LOC for serialization/deserialization, retries, error handling, etc, bloating my code and making it harder to understand, plus now to do the same integration test I need to understand N different build systems for each component.

You can also make breaking changes to internal APIs without versioning or release coordination. Just update all the call sites.

Have you had to deal with a microservices environment? Because there's significantly more operational and architectural complexity with a distributed system compared to a monolith. Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. I would generally not recommend adding all this overhead unless absolutely necessary. Or at least that was the recommendation pre-AI, but I don't think I've changed my mind on it yet.

> Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things.

Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.

Then it sounds like you can only have a true microservice architecture if your application doesn't really need transactional guarantees, consistency or fault tolerance.

Then you must have heard the wrong thing. Oh well. You can't communicate with everyone.

Then please help me understand, it is entirely possible that I misunderstood you, but you are not clarifying your point.

You were happy with your interpretation before. Perhaps that's sufficient?

Microservices are just another "cache" level in the end. They can make sense in the right situations, but you need to make your architecture deliberate in order to reap its advantages. Idempotent services are an easy win, and also places where you have data locality (similar to cache locality, just a few levels lower).

At the end of the day, it comes down to:

- how far does the data have to travel, and at what cost?

- how much latency can your process tolerate?

- how much unreliability can your process tolerate?

- where and how do you isolate resources that are concurrency sensitive?

- what's the infrastructure going to cost?

In fact microservices are arguably more complex. It is the reason why microkernels have not succeeded compared to monolith till now.

The separation in micro services is hard to break though. You need to add an API on one side and a call on the other.

In a monolith it's significantly easier to do something that has an unexpected impact somewhere else. For example, changing a shared object a singleton to a clone will give you race conditions all over the place. You just don't have that footgun in micro services.

>Hundreds of bots modifying thousands of microservices

That is way too close to monkeys on typewriters for comfort.

It doesnt sound good at all!

10 people generating 800 commits a day is completely stupid.

I mean at this stage people don’t even know what they’re building anymore. They’ll burn through their backlog faster than the backlog can be filled.

Or maybe they spend 700 commits fixing the issues generated by the first 100?

This doesn’t make any sense to me

I used to say my job was „managing complexity“, not being a programmer. After AI, thats still true because they suck at it.

Why do you need to always modify the service? Once it is up and running and performs a function - don't touch it.

For the same reason you change or replace any function in a program: The situation has changed.

> Hundreds of bots modifying thousands of microservices may sound good on the surface

It really does not, honestly.

The point of dividing your software into independent services is to be able to give those services to different teams that can independently develop and release them.

What’s the point if you’re treating the whole system as a slop bucket?

Eventually we'll compress out unnecessary state and keep desired data states only; AI then won't be editing k8s yml, source code, etc.

It will just be computing new geometric states and syncing them to the screen.

Incidentally not having devs save endless copies of their dev tools and languages will save a bunch of electricity; storing and copying that stuff around uses a lot of electricity.

Software engineers who want to be taken as experts in their craft need to understand the chip makers are experts in theirs all the same. They’re not leaving your concerns about correctness, efficiency, and stability unconsidered.

Almost offensive for non-experts in hardware dev to continue to insinuate no one but SaaS devs have any idea how computers work.

Reply on news.ycombinator.com