So maybe the solution is to make all subproblems greenfield products?

By this I mean treat features as isolated plugins. I get that there are cross-cutting features that touch multiple pieces of functionality, and those probably need special treatment, but a large class of functionality can be developed in an isolated way with a common set of design tokens and APIs to tie them all together.

This might play better to coding agent strengths.

Full disclosure: this is very much an armchair view. I have all of 2 weeks of experience coding via agents (vs manually), but this thread is nerd sniping me into trying it myself.

▲

CuriouslyC 3 days ago | parent [-]

I do try to do this, from an architectural standpoint it starts with modular monoliths to avoid coupling, then I try to decompose problems in a way that is very sandboxed so the blast radius of an agent going of the rails is contained.

▲

ffsm8 3 days ago | parent [-]

So the things people hate Java for will make a big comeback then? Hexagonal architecture with domain driven design,a big fetish for inversion of control, so the LLM never needs to figure out how the system works, it just magically does. And errors have just the right amount of stack trace, this being 500++ lines

	▲	CuriouslyC 3 days ago \| parent [-]
		A lot of old school "java-ish" paradigms are going to come back with AI for the same reason people used them with Java back in the day - they put golden handcuffs on implementors, which is a bad tradeoff for competent, agile humans but a very good tradeoff for sometimes off the rails agents. This includes waterfall, spec driven development, front loaded planning, extensive automated testing suites, formal verification, etc.