Live data from Hacker News

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

jacob.gold

131–140 of 183 posts

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

#131

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

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?

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

#132
post #63

Earlier quoted context omitted.

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.

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.

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

#133

Earlier quoted context omitted.

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

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.

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

#134
> Fire up a coding agent for each one, tell it to “improve performance”, and there’s a good chance you ship significant improvements across all of them.

But I can do this like what, once or twice? Maybe once every release? Then my agents finish "improving performance" and it's Monday 10am. What the fuck I'm supposed to do the rest of the week?

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

#135
post #5

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

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

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

#136

Earlier quoted context omitted.

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

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.

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

#137
One of my predictions for software in the AI age is that we will end up with nano-services. The thinking is this:

1. LLMs perform best with tight, focused context.

2. Encapsulating specific well-defined functionality into a single service, tool or API inherently limits the amount of code it requires, and hence the context an LLM requires to reason about it. The smaller the codebase, the better an LLM will do with it.

3. Code is already increasingly written by swarms of agents that tend to step on each others' toes, and hence a way of isolating them would be great.

4. Combining the 3 points and taking them to the logical conclusion, we end up with nano-services.

It's basically the Unix philosophy, just scaled up to distributed systems. For all its other issues, the core philosophy worked pretty well for Unix tools, so it should work well for nano-services too.

Currently the "pipes" between these services are network calls, but they need not be. One could imagine an architecture where these components are composed either as direct function calls or remote network calls depending on access patterns and resource requirements for a given instance. Never worked with Elixir but I think that might fit the bill?

Maybe every sufficiently complicated distributed system will end up re-inventing an ad hoc, informally-specified, bug-ridden, slow implementation of half of Elixir.

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

#139

Earlier quoted context omitted.

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, an…

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.

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

#140

Earlier quoted context omitted.

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

Post reply on HN