> 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 and commit count. 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.
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.
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?
Same as op, I rewrote my Dropbox alternative (https://github.com/mickael-kerjean/filestash) in vanilla js a couple years back around the idea that components are plain exported functions like this:
Completely seriously, and I don’t think this is particularly controversial: outperforming React is not impressive. React was never particularly good at performance—VDOM is fundamentally overhead, and there are a variety of faster and lighter techniques employed by various competitors, and even among VDOM libraries it’s not as fast as it could be. React sold itself as fast initially, but what it was faster than (rebuilding the entire DOM on any update) was a strawman.
It’s not hard to be faster than React while exposing broadly similar functionality. If you’re making something for your own usage only, it’s even easier to beat it.
I don't disagree, I'm always curious if there are new techniques out there to adopt. It's just hard to find out about them because as you said, sometimes they are bespoke single use tools that aren't easily shared/discussed about.
This site has excellent articles on learning to use native web technologies with minimal dependencies. I've found them to be useful resources when learning how to create web components.
I use web components with a render function to generate HTML and templates to provide fine-grained reactivity. Targeted re-rendering of items with relevant state changes makes performance significantly faster and also makes forms easier to write.
Here is an example of a template used to render a list of events.
Do you prefer frameworks like lit to generate your web components? I always felt like the base APIs were okay-ish but I haven't really investigated web components much. Like honestly once maybe 4 years ago and it was for a POC at work.
> 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.
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!
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 give it a cool name, "tokenmaxxing" what even the fuck.
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.
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.
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.
This is a bad idea - you’re actively contributing to the problem by hiding the negative effects.
Don’t even think about starting that work until you’ve created bug tickets for as much of it as you can, and bright then to management’s attention. Management then needs to figure out priorities for doing that work and whether a change in approach is needed.
> 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.
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.
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.
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.
> 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?
While I’m sure there’s a sliver of usage outside, I’d wager most emacs org mode usage is firmly inside what the average human would consider a nerd niche.
well yes, that's what i'm saying. most people that interact with a computer use notion, a small percentage obsidian, and a fraction of that emacs org mode or other similar tools. I use zim-wiki but I don't expect most people to do the same, just like I don't expect most musicians to learn lilypond
Ah. I misread your list. I missed the "over" as a contrasting conjunction, in part because there are plenty of non-nerd [albeit perhaps scripted-by-one] usages of imagemagick and ffmpeg, so I didn't readily detect it was a list A and a list B.
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.
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.
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.
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?
- where and how do you isolate resources that are concurrency sensitive?
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.
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 to continue to insinuate no one but SaaS devs have any idea how computers work.
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?
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". Maintenance is becoming trivial.
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?
Honestly, this far into the game, it's like saying you can't take me seriously when I claim to have ridden a bicycle for a mile because when you try, it keeps falling over.
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).
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.
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".
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).
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.
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.
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
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.
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.
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?
I really don't think they can. I feel like if I rush a PR using AI, I can only just kinda hope the AI is good enough that my trust isn't misplaced. It becomes slightly less likely to be bad if you add a thorough AI review on top but it's just rolling the dice.
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.
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.
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.
> 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..
I think microservices are supposed to be easier to deploy independently, that's the whole point. And if they are not, it means you're just doing it wrong.
But in truth, all the projects with microservices I have seen in real life had deployment coordination problems, and looked to me like distributed monoliths. So maybe it's a 'no true scotsman' thing. Maybe they are always, or at least most of the time, harder.
People do microservices (read: an API spread across multiple processes), but then make all of the mistakes that logically couple the service deployments together. They use shared databases instead of one per service, make breaking changes to API schema instead of non-breaking or versioning, use a shared library of schema definitions instead of having each service define their own data objects for API calls, and have startup logic that depends on another service being up.
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.
The answer to all the questions, though, is more AI/LLM usage. Nobody got a freaking clue what the LLMs have done and why services are down? Diagnose it with LLM, and get the lights back on ASAP!
I have a similar concern, though. To do my job, I need to understand "the thing". I could outsource the understanding process to AI, but then if I'm asked a question by a developer or tester then I'm essentially stumped / useless because I didn't spend the time to understand the thing, I handballed it.
So I then ask the LLM the question I was asked, and pass the answer back (they could have done this themselves though, so where does that leave me? I'm either an AI wrangler, or replaced by someone else who wrangles AI replacing mutliple people in my role). Does my personally understanding the thing actually add value - do the seniors who know their systems add value - in the age of AI/LLM?
Does "LLMs all the way down" solve the problems?
With the existence of hallucinations I lean towards 'no', but again is that solved by adding layer(s) of LLMs to check for hallucinations?
So you are already sometimes being the „meat proxy”. It only shows one much worse thing - the people asking you are first to blame/for, because they didn’t ask LLM. Maybe it’s temporary and it will change.
One added value I see in senior knowing how things work is simple - in case of outage or business incidents (caused by incorrect logic produced by LLMs from even worse prompts or incomplete spec) senior can act faster and answer difficult questions live. Now we are going to have bunch of kids looking at „Hallucinating…” and „Crashing the prod…” status bar in CC CLI.
Maybe this is what’s gonna be acceptable and it’s just new world.
This argument comes up during every big layoff season. A good chunk of people pronounced Twitter dead when it got bought out. But software nowadays is pretty stable, despite its perceived jankiness.
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.
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?
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
Agentic coding puts a lot of pressure on team communication. Individuals produce more output. So there now is a lot more to discuss and synchronize on. This favors smaller teams that typically are responsible for more things. That doesn't necessarily mean fewer people. But I do think it favors having more smaller companies over fewer larger ones that are each able to specialize more. It also means that companies that currently outsource all their development or buy SAAS products now should consider in housing some things again. A lot of people worry about work disappearing. I think the opposite is going to happen: more work popping up in a lot of new places. Because doing that work is now feasible and doable.
Staying on top of work done across many teams is going to be a huge challenge for larger companies and it's going to cause them to organize and hire very differently. Getting this wrong means teams diverge much quicker than they used to and everything gets misaligned much quicker. Some team might launch a product before some other team that was considering to do a similar thing is even aware that is happening. As most engineers might appreciate, the easiest way to tackle complexity is to just work on cohesiveness and coupling. Small teams with few dependencies working on a coherent thing will be much more effective than large orgs with a lot of inter team coupling and no coherent plan.
I'm in my fifties so, I've been around for a while. I currently work in a very small company (3 people) so I'm used to doing things by myself. I also used to work in traditional teams inside large multinationals. Very different game. You spend non trivial amounts of time communicating with people in big organizations. And you basically only get responsibility for a tiny amount of functionality. I had to learn a lot after I left the safety of a big organization. When everything is your problem, you need to skill up in a hurry to deal with all the challenges effectively.
In my current role, I do basically everything vaguely technical. And non technical as well. And it is more than ever since AI coding entered the mix last year. I stopped referring to myself as a backend person. Because I also do UI, devops, websites, IT infrastructure, etc. And a bit of sales, marketing, etc. I'd add management but we're such a small team that I suffer a little from impostor syndrome on that front. But I can do the job if I need to.
I had a whole hiring plan that I developed three years ago that we never executed on. It had all the traditional dev team roles spelled out. That plan is obsolete. These roles will probably never be filled. I need different people though. I need more people like me that can do everything I do when I'm not around and people with complementary skills that are strong where I'm weak. But I have much less need for specialists. I mainly need generalists with attention to detail that can deliver complete working products and systems. I might want a product focused person but not a dedicated product manager. If you can specify it in an issue tracker, you can learn to prompt an AI as well. But I still need a good product plan and roadmap. In the same way, I expect designers to shape UI work directly and not via a separate UI team. I expect them to own the front end experience and drive it. I still need people that are strong in these roles. But not exclusively. Good small teams have less people than all the traditional roles you find in larger traditional teams. That calls for people with overlapping skills that can put on different hats as needed that complement each other.
Funny take. Monoliths are actually better then microservices because of the context they carry. At the end developers are supposed to run a product, not to keep mindlessly running agents just because they can
116 comments
[ 0.23 ms ] story [ 36.4 ms ] thread> 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 and commit count. 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.
Is was successful because I didn't use any sort of LLM assistance.
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.
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?
It’s not hard to be faster than React while exposing broadly similar functionality. If you’re making something for your own usage only, it’s even easier to beat it.
https://gomakethings.com/guides/?filter=html
Here is an example of a template used to render a list of events.
const EventItem = () => {
This is how the template is used in a component.I plan to publish an updated version soon.
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.
> 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!
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 give it a cool name, "tokenmaxxing" what even the fuck.
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.
This is a bad idea - you’re actively contributing to the problem by hiding the negative effects.
Don’t even think about starting that work until you’ve created bug tickets for as much of it as you can, and bright then to management’s attention. Management then needs to figure out priorities for doing that work and whether a change in approach is needed.
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.
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.
Humans are way more creative at social cohesion when you remove oligarchs and authoritarians.
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.
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?
There was enough there; I missed it.
Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.
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.
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.
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.
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?
- where and how do you isolate resources that are concurrency sensitive?
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.
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 to continue to insinuate no one but SaaS devs have any idea how computers work.
It really does not, honestly.
That is way too close to monkeys on typewriters for comfort.
What’s the point if you’re treating the whole system as a slop bucket?
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
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". Maintenance is becoming trivial.
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 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.
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).
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.
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.
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.
See https://designmd.ai/ for examples.
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.
The 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.
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.
Have you tried t3 code? It creates a separate worktree per agent, which makes running multiple agents at once much easier.
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..
But in truth, all the projects with microservices I have seen in real life had deployment coordination problems, and looked to me like distributed monoliths. So maybe it's a 'no true scotsman' thing. Maybe they are always, or at least most of the time, harder.
Makes it harder to justify using them.
That is, the code should be correct but also idiomatic.
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.
I have a similar concern, though. To do my job, I need to understand "the thing". I could outsource the understanding process to AI, but then if I'm asked a question by a developer or tester then I'm essentially stumped / useless because I didn't spend the time to understand the thing, I handballed it.
So I then ask the LLM the question I was asked, and pass the answer back (they could have done this themselves though, so where does that leave me? I'm either an AI wrangler, or replaced by someone else who wrangles AI replacing mutliple people in my role). Does my personally understanding the thing actually add value - do the seniors who know their systems add value - in the age of AI/LLM?
Does "LLMs all the way down" solve the problems?
With the existence of hallucinations I lean towards 'no', but again is that solved by adding layer(s) of LLMs to check for hallucinations?
One added value I see in senior knowing how things work is simple - in case of outage or business incidents (caused by incorrect logic produced by LLMs from even worse prompts or incomplete spec) senior can act faster and answer difficult questions live. Now we are going to have bunch of kids looking at „Hallucinating…” and „Crashing the prod…” status bar in CC CLI.
Maybe this is what’s gonna be acceptable and it’s just new world.
Layoffs pushed over the cliff the company. Both due to engineering (content is now trash), and product (lost most of the ad revenue)
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?
- 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
Staying on top of work done across many teams is going to be a huge challenge for larger companies and it's going to cause them to organize and hire very differently. Getting this wrong means teams diverge much quicker than they used to and everything gets misaligned much quicker. Some team might launch a product before some other team that was considering to do a similar thing is even aware that is happening. As most engineers might appreciate, the easiest way to tackle complexity is to just work on cohesiveness and coupling. Small teams with few dependencies working on a coherent thing will be much more effective than large orgs with a lot of inter team coupling and no coherent plan.
I'm in my fifties so, I've been around for a while. I currently work in a very small company (3 people) so I'm used to doing things by myself. I also used to work in traditional teams inside large multinationals. Very different game. You spend non trivial amounts of time communicating with people in big organizations. And you basically only get responsibility for a tiny amount of functionality. I had to learn a lot after I left the safety of a big organization. When everything is your problem, you need to skill up in a hurry to deal with all the challenges effectively.
In my current role, I do basically everything vaguely technical. And non technical as well. And it is more than ever since AI coding entered the mix last year. I stopped referring to myself as a backend person. Because I also do UI, devops, websites, IT infrastructure, etc. And a bit of sales, marketing, etc. I'd add management but we're such a small team that I suffer a little from impostor syndrome on that front. But I can do the job if I need to.
I had a whole hiring plan that I developed three years ago that we never executed on. It had all the traditional dev team roles spelled out. That plan is obsolete. These roles will probably never be filled. I need different people though. I need more people like me that can do everything I do when I'm not around and people with complementary skills that are strong where I'm weak. But I have much less need for specialists. I mainly need generalists with attention to detail that can deliver complete working products and systems. I might want a product focused person but not a dedicated product manager. If you can specify it in an issue tracker, you can learn to prompt an AI as well. But I still need a good product plan and roadmap. In the same way, I expect designers to shape UI work directly and not via a separate UI team. I expect them to own the front end experience and drive it. I still need people that are strong in these roles. But not exclusively. Good small teams have less people than all the traditional roles you find in larger traditional teams. That calls for people with overlapping skills that can put on different hats as needed that complement each other.