Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jacob.gold

Post reply on HN
Print view View original

111–120 of 183 posts

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

#111

Post by szp2005 »

jatora wrote: post #34
raincole wrote: post #25

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 Choose N over your prior. My recommendation is 1.

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.

[flagged]

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

#112

Post by misiek08 »

BLKNSLVR wrote: post #97
whatever1 wrote: post #62

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.

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 / us…

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.

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

#113

Post by stymaar »

> A small team today, running 20-100 agents in parallel, might generate 500 commits/200 pushes/100 PRs

Who the fuck is writing the requirements in that story?! Setting aside the problem of pushing AI-generated code that nobody has read straight to production, the reason why you're pushing code to production in the first place is to implement a product that is solving a problem for your users. And the problem I have with the hypothethical workflow described above is: How is any product owner supposed to come up with hundreds of feature or improvement requests a week?

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

#114

Post by onion2k »

p1necone wrote: post #36
kstenerud wrote: post #13

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 repl…

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…

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.

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

#115

Post by MrBuddyCasino »

kstenerud wrote: post #13

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 repl…

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

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

#116

Post by whatever1 »

tokioyoyo wrote: post #104
whatever1 wrote: post #62

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.

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.

Twitter is dead. After the layoffs it required multiple bailouts and pivots to its business. Not even sure what X is about today.

Layoffs pushed over the cliff the company. Both due to engineering (content is now trash), and product (lost most of the ad revenue)

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

#117

Post by lucfranken »

The reason micro services became fancy is because they could split up large groups of people. They could work on different parts more autonomously without all being dependent on each other.

It has an overhead but as scaling the amount of people was worth it there was an advantage.

Where did this work: where the interfaces between those groups of people were agreed upon.

A team could call: finance->billTrip(TripObject) via an API and the finance team became independent. The micro services had an API which was documented. They could move from Stripe to SAP to a custom solution internally without bothering the other teams.

Now we have AI.

Those interfaces are still needed. But is there still an advantage to hard separating those interfaces in real micro services, with separate databases for each team, over http or other protocols?

On some point it may. A service which needs to scale unlimited (like RenderThumbnails with hundreds of thousands of call per day) might have that. But if you send out 1000 invoices per day it might not be needed for that at all.

In Rails they have active job for it for example. Same codebase but a scalable worker for longer running jobs.

AI is capable of quickly keeping function calls consistent internally. So a hard coded API is way less useful now for those services which don’t need the scale. An interface could suffice just fine. No human would ever read the finance API anyway.

Keeping consistency in the monolith part is way easier. That is statically testable, quicker testable and there are plenty of tools. All disadvantages on micro services on those calls are just a waste.

One thing where I think hard boundaries are useful is on really blocking AI coding tools. With microservices you are able to physically prevent Claude or others to modify the other interfaces. That way it prevents hallucinations, quick fixes and other workarounds the tools like to do. Just because an AI wants to get sometime done it will sometimes skip corners.

I see that as a current state which will be fixed quite soon. The models and their harnesses will become increasingly better in preventing stupid corner cutting to get the fix out.

When that is done: why would you want more complexity with micro services instead of less?

Instead of we all implementing microservices and other structures we should get the harnesses right to respect interfaces and boundaries.

And in the micro services era we had meetings to sync the API’s between them. So maybe the AI’s should meet about the interfaces, with a good coffee.

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

#118

Post by hombre_fatal »

kstenerud wrote: post #13

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 repl…

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

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

#119

Post by 0123456789ABCDE »

bpodgursky wrote: post #16
gentooflux wrote: post #14

Earlier quoted context omitted.

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.

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?
Post reply on HN