Software architecture
View All Tags
I have been investigating which decisions in a coding agent deserve a generative call and which can use a smaller mechanism. Choosing a tool, checking a claim and escalating a task are different problems from writing the patch that solves it. My proposal is to distribute that work across code, classifiers, decision models and LLMs, then measure whether the separation improves the outcome.
I want to start automating things with agents and reuse them across projects. An agent that investigates incidents, another that examines repositories, another that prepares documentation. And I want them to collaborate when the work calls for it.
The supply of frameworks is growing so quickly that choosing one seems to have become the mandatory first step. My question starts earlier: how do you design an agent that others can find, assign work to and hold accountable for its results?
That leads me to services, contracts and distributed systems. The framework running each agent will be a decision within that architecture.
Some projects give a great first impression when you open them:
core, domain, infrastructure, services, helpers…UserService, OrderManager, PaymentHandler…And yet, when you try to follow how the system actually works, you find something very different: methods calling other methods calling other methods, layers that only delegate, business logic scattered across the repository… and you thinking:
“This looks architectural, but understanding it is painful.”
That’s what I like to call cardboard architecture: it looks solid on the outside but doesn’t really hold the weight of the business inside.
In recent years, I've seen two equally damaging extremes in many development teams: over-engineering and the eternal PoC culture. This post is about why both extremes are bad engineering practices and how to find a reasonable middle ground.