There's no such thing as a small software team anymore

mmooreslaw about 3 hours ago 73 commentsRead Article on jacob.gold

ES version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

59% Positive

Analyzed from 2975 words in the discussion.

Discussion (73 Comments)Read Original on HackerNews

kstenerud•about 2 hours ago

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.

gentooflux•about 2 hours ago

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.

tjwebbnorfolk•33 minutes ago

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.

bpodgursky•about 2 hours ago

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.

sebastiennight•32 minutes ago

> 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.

zx8080•about 2 hours ago

> but programming is never going back to normal.

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

jatora•about 1 hour ago

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.

thin_carapace•37 minutes ago

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

pianopatrick•about 2 hours ago

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.

honr•15 minutes ago

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.

kstenerud•about 2 hours ago

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.

pianopatrick•about 1 hour ago

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.

jatora•about 1 hour ago

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

p1necone•about 1 hour ago

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.

romanhn•about 1 hour ago

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.

win311fwg•about 1 hour ago

> 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.

alright2565•about 1 hour ago

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.

0x696C6961•1 minute ago

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

killthebuddha•about 1 hour ago

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

whateverboat•about 1 hour ago

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

john_minsk•about 2 hours ago

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

kstenerud•about 1 hour ago

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

wotamess•40 minutes ago

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.

naniel•3 minutes ago

i agree with this.. but also think it could stress a couple things more:

- satisfying the needs of parallel agentic development is wholly aligned with the optimal DevSecOps CI/CS/CD WhateverTerm models out there. And that's rad, bc a lot of orgs have a reference frame to map to.

- microservices, monoliths, monorepos, mammoths, whatever.. The code and services can be structured however, so long as the release capabilities are modular and governable/manageable/auditable/flexible/transparent/etc. A killer workflow allows for tight independent releases, but not chaotic, with proper add'l structure/scaffolding to satisfy that list above. Microservices and smaller repos can help with the context window bit initially, but you can rig up and kind of local llm-focused setup to allow for selective context and holistic context (across N repos or N projs within monorepo)

- strategy: use the robots to fix the problems in your PDLC/CICD/ABC so that the robots can help you out more, and keep iterating on that

davepeck•about 3 hours ago

A wise troll once said:

> best weapon against complexity spirit demon is magic word: "no"

In counterpoint, I believe small teams can remain small. Small teams can ship simple monoliths with high velocity, commit count, and quality. Service orientation didn’t suddenly become low-cost because of agents; the boundaries between multiple services that version and deploy independently are still tricky beasts to wrangle. And it’s not clear why “running more agents” is inherently desirable or impactful; my small team’s (admittedly anecdotal) experience is that the value quickly saturates.

alansaber•about 2 hours ago

Agent spam is definitely an excercise in diminishing returns

whatever1•22 minutes ago

Wait two years until we have sufficient churn of senior talent in the teams. Then all of the services will have outages daily.

Only the seniors who know their systems are keeping the lights on today by keeping bs commits out.

Once they burnout and quit, nobody will have a freaking clue what the LLMs have done and why services are down.

jaggederest•10 minutes ago

You can already see a practical example of this in microsoft's issues with Azure. Too many services, too little understanding, everyone left who knows what is going on. There was an interesting article here a little while ago by one of the architects something like "how azure set a trillion dollars on fire" or something like that.

fra•17 minutes ago

I would take the other side of that bet. In five years, there won’t be more outages than today.

franciscop•about 2 hours ago

I saw the `require('gulp')` and the memories def came back. That's def how we used to do code ~10 years ago. I still don't like the multi-threaded PER PROJECT too much, I prefer having 2 projects and switching context window, I find the current tools (at least the ones I know) are a bit underwhelming for multi-threading. But I'm also trying to upgrade my knowledge.

A good way I've found, since I do a lot of OSS and have my own libraries, when I find a bug in one of those libraries I can work on the same project on the main window while fixing the library on another window. I normally need to tell the main one "let's skip this for now, I'm fixing the library" meanwhile or similarly.

_345•about 1 hour ago

I'm really skeptical you can ship ~10 PRs a day per person unless these PRs are tiny pieces of one feature or all of them are tiny bugs that are each a 3 line fix that you could review instantly. Otherwise how can you confirm that the AI even did the right fix or feature correctly? That you even wanted that feature done that way?

somesortofthing•about 1 hour ago

Microservices can trample on each other just as easily as monolith internals can. If anything, the friction of reconciling changes in a monolith is useful signal that conflicting changes happened, and it takes slow and flaky e2e tests to replicate in microservices. It's not like you're resolving the merge conflicts by hand.

HWR_14•24 minutes ago

I don't understand why microservices would have fewer merge conflicts than monoliths.

abigdog•14 minutes ago

From experience it is more human nature to make spaghetti in monoliths but a well disciplined monolith would be as confict free as the equivalent microservices.

layoric•29 minutes ago

> If you have a large monolithic service where every change has to be coordinated carefully..

Microservices are WAY harder to coordinate for deployments. You end up with feature service dependencies, and you are back to the same coordination, but now harder to discover down stream dependencies..

abigdog•17 minutes ago

He misses the bit about Microservices where you need to integrate changes across services and avoid undocumented API spec from your changes blowing something up. Getting alignment and so on. There are probably agentic solutions but this article misses a lot of detail and doesn't even hand wave it.

ulrikrasmussen•10 minutes ago

Is this satire? Changing your easy to maintain monolith architecture to a microservice architecture to enable parallel agent development, really? That's got to be some of the worst advice I'd heard in a long time.

You will have conflicts during parallel work if people are changing features that are related. You will also get these conflicts with a microservice architecture and hundreds of independent repos, but now it is not a merge conflict because you touched the same syntax, it is a semantic conflict.

And didn't Uber also have a famously slow and convoluted CI pipeline where it took an enormous amount of time and resources to build anything?

samlinnfer•39 minutes ago

Thousands of microservices = thousands deployments that can fail, that needs to kept compatible, that needs to be able to find each other, that needs to be monitored. This is just pushing the pain downwards.

fhub•about 3 hours ago

> So Uber’s approach to modularity may have seemed extreme at the time, but it could become the new normal.

I doubt it. This seems to conflate code modularity with service modularity. Moving complexity from the codebase into operations is counterintuitive to at least the way I use LLMs.

ch4s3•about 1 hour ago

How would the LLMs even appropriately build and manage context in such a setting?

throw123fgbkjgf•about 2 hours ago

Pretty sure Uber ended up with thousands of microservices because they used to tie owning a service to perf and promo, and were trying to cut down the number for years. It's hilarious to see this interpreted as an intentional choice.

the_sleaze_•32 minutes ago

used to work for a company and this is exactly what happened, each team lead pushed for their own little secret garden and fight over who had to add new things. Managing the kafka instance(s) to keep order turned into 2 people's full time jobs. They sold at absolute fire sale price not long ago

marius_•about 1 hour ago

There is no "small team" pushing 100PRs/day, agents or not.

lofties•about 3 hours ago

My biggest issue with these type of posts is that they never answer the "why". Hell, they don't even ask the "why".

> The more modular your code, the more agents you can run

OK, but why would I want to run more agents? So I can be more productive? What does this productivity lead to? And are we actually being more productive? Take a look at Bun's repo on GitHub which seems to be fully automated. Well over 5000 PRs open.

What's the use? How can we justify these 5000 PRs? Over the past years, software has become considerably more shit. Are these 5000 PRs improving the quality of software?

Is the end-user reaping the rewards? Are they getting better software, cheaper?

The answer to all of those is going to be "no".

And let's take Uber for example. They have many teams, and many more times the services. Has ride hailing become cheaper? No. Has it become more efficient? No.

Nothing is getting better, but at least we're all off worse!

horsawlarway•about 3 hours ago

Yeah, I think engineering orgs mostly jumped the shark.

Metrics like pr count and commits have always been terrible gauges for success compared to business performance.

But they're easy to measure, and even easier to game now with AI.

So we're seeing an outrageous gain on these metrics, and they've become almost completely divorced from business results.

No one cares how fast you ship prs. They care that you offer a compelling product, that works when they need it work, for a price they're able and willing to pay.

It's like we've decided to measure how far we've traveled in gallons of gas burned, but completely forgotten about measuring miles per gallon.

skydhash•about 2 hours ago

> It's like we've decided to measure how far we've traveled in gallons of gas burned, but completely forgotten about measuring miles per gallon.

Or forgotten to look at the map to see if we're getting closer to our destination.

I've never seen a consumer bugs that complains about how small our codebase is or how little PRs we have produced this month. It's always about some features not working properly.

Previously the core metrics were reducing consumer complaints and implementing features for the sales team to attract new clients. Then they suddenly got replaced by amount of PRs and token usages.

mushroom_lasagn•about 2 hours ago

My organization has noticed that some people's output has gone way up since they started using AI, while some people's has not. I imagine output is measured by LOC and MRs, since we are bad at metrics. There's now an effort to figure out why the laggards aren't using their AI "well" enough. I've seen some of the increased output that was sprayed at my team without consent, it was work that superficially looked good but on closer investigation did not solve the problem it was intended to. All that work has to be redone. The rework is being done quietly, so as not to draw management ire for a lack of "productivity". It's all so tiresome.

wseqyrku•about 3 hours ago

> but why would I want to run more agents?

Notice how difficult it is to turn off photo bursts in iPhone? Because that free cloud space needs to be filled fast. So ask your question again and you will find the answer very rapidly. They even gave it a cool name, "tokenmaxxing" what even the fuck.

cyh555•about 1 hour ago

it's against the social rules to call them out

jcelerier•31 minutes ago

> OK, but why would I want to run more agents? So I can be more productive? What does this productivity lead to?

software used outside of nerd niches? photoshop, canva, clickup, after effects and unreal engine over feh, imagemagick, impressive, emacs org mode, ffmpeg CLI and pico-8?

coffeefirst•about 1 hour ago

Uh-huh. I have a little boy who just saw his first firetruck, and you can see the wheels turning in his head, because BIG RED TRUCK. He doesn't talk yet, but a seed has been planted.

Some people operate like little boys. They want the BIG RED TRUCK. They haven't considered that's it's really hard to park and gets 5MPG, or that their use cases don't involve fighting fires (for which they are not trained), but they want the big red truck so they can drive the big red truck.

Anyway, if you go the 5000 microservices route, you move all your problems from the application layer into networking and orchestration problems. Best of luck with that.

linkregister•about 2 hours ago

I find that ride hailing is both cheaper and more plentiful compared to taxis in 2010. Even in non-inflation-adjusted amounts. Ride hailing and food delivery companies provide dispatching and coordination at a very large scale effectively.

I agree that these companies' products were fully mature prior to usable coding agents in late 2025, so I don't understand why they would require a large volume of code changes beyond minor promotions and localization enhancements. I would expect their challenges to be in the ML, data, storage, capacity, and compute infrastructure areas.

serious_angel•about 3 hours ago

Thank you. I do not believe the author has any idea what he is talking about, too. It's worth to also mention some basics:

    1. Dependency on some outsourced LLM vendors (no Internet? No API response? Welp, you do you.);
    2. Undefined amount of payments/paid subscriptions at vendors;
    3. Undefined amount of tokens burnt on each prompt/iteration within undisclosed algorithms;
    4. Absolutely no responsibility/copyright for the LLM output;
    5. Privacy concerns on inside/company project source code uploaded;
    6. Incremental eventual atrophy of developer's own skills;
    7. Inhuman attitude for art, development, effort, purpose in general, since the models are built on stolen effort of other, now unknown, people...

i_love_retros•about 2 hours ago

My ex boss who was very very pro AI would constantly say that we need to be more productive. Which triggered in me the question of "why". Aren't we producing enough as a society at this point? We have enough for everyone, and the fact that it's not being shared fairly has nothing to do with productivity. We don't need "more", we need " better". And I don't think most uses of AI will lead to that. If we lived in a more just society I think we would concentrate all the AI resources on a few key areas where it could genuinely help make things better, like medical research. We don't need more and more crud apps.

shimman•about 1 hour ago

You would absolutely love the book Dawn of Everything.

Humans are way more creative at social cohesion when you remove oligarchs and authoritarians.

raincole•about 2 hours ago

You can use this as a canary.

The out-of-control factor = the number of parallel working agents : the number of human programmers.

1. If the factor > N, you're losing control and there will be no organizational wisdom passed down.

2. If your team can't function with the factor <= N, your architecture is way too complex.

Choose N over your prior. My recommendation is 1.

jatora•about 1 hour ago

Plan for your organizational wisdom to be passed down in the form of code, comments, and markdown documentation files... all for other agents with centaur orchestrators.

janalsncm•25 minutes ago

Call me old school but I feel like the solution to humans clogging up the slop cannon will be for AI generated code to look more human.

That is, the code should be correct but also idiomatic.

talon8635•about 1 hour ago

I am a team of one, and I don’t use agents

burnto•about 2 hours ago

Why not just bake an agent into every service and chat with it? Sounds more fun at least.

gulugawa•about 3 hours ago

I'm a 1 person dev team who wrote frontend code that outperforms React.

Is was successful because I didn't use any sort of LLM assistance.

ChrisMarshallNY•about 2 hours ago

I’m a 1 person dev team that’s in the final stages of shipping a complete rewrite of a pretty big app (native frontend, server backend).

It’s going to be very successful, because I used all sorts of LLM assistance (and because it’s adding onto a successful app that’s been shipping for two years).

There’s absolutely no way that I could have managed this scale, on my own.

There will be examples of both success and failure, with LLMs.

shimman•about 1 hour ago

That's pretty impressive. I always like bespoke web utilities tailored for specific dev purposes.

What approach are you taking? I'm about to start a mithril.js project, was always under the impression it was the most efficient approach. Are you doing something similar or different or are you referring to WASM?

aussieguy1234•about 2 hours ago

There's another way to get this kind of parallelism without the mess of microservices.

Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.