Building with AI, designing with judgment: The responsibility that can’t be delegated

When a team creates an agent, a skill, or any piece of AI, it is making the same kind of design decision it was making fifteen years ago when defining a class or a service.

The difference is that today, that decision gets made ten times faster. And that speed has a side effect that can easily go unnoticed: it has eliminated some of the steps that used to force us to think before writing code.

Writing a well-defined function used to take an hour or even more, and required deciding what went in and what didn’t. Creating an agent takes ten minutes with a prompt, if it even takes that long. And that same decision about what goes in and what can’t be skipped without anyone noticing because the agent “works” all the same.

What gets lost here is not speed. It’s judgment.

And judgment is, ultimately, the one thing a senior engineer brings to a team that the model cannot bring to itself.

The pattern is one we already know, it just changed its name

Anyone who has led a development team recognizes this problem because they’ve already lived through it twice.

The first time was with classes that did too much, like the classic God Object: an entity that ends up handling validation, persistence, notification, and business rules all together because, at the time, it seemed simpler to add one more method than to create a new class.

The second was between 2015 and 2018, when many teams broke monoliths into microservices without a real domain criterion and ended up with the worst possible combination: the operational complexity of a distributed system (networks, latency, partial failures) added to the logical coupling of a monolith because the services kept depending on one another in a chain.

An agent that reviews, suggests, validates, and notifies is that same mistake with a new name.

It doesn’t have a clear purpose, even though it seems to. It’s several design decisions that were never fully made, compressed into a single prompt. And the cost is real. It’s operational.

When something fails, it’s much harder to isolate which part of the flow failed because the boundary between “reviewing” and “validating” never existed as a design boundary. It existed as a sentence within a paragraph.

Three questions separate a designed agent from an improvised one:

• Does it have a single responsibility? Not in the sense of “technically does one thing,” but in the sense that, if it fails, there’s a single reason (or a small, related set of reasons) it could have failed. That’s the operational definition of the single responsibility principle, and it’s the same test we’ve applied for years to a class or a service.
• Does something similar already exist? When two or three skills do similar tasks under different names, it’s not a coincidence. It’s a sign that no one looked at the team’s inventory before adding a new piece of AI to the mix. It’s the same problem that caused service duplication in the early days of microservices, except now the cost of creating the duplicate is lower, so it happens more often.
• Did we design it, or did we let the model figure it out? A prompt that encodes a clear decision about how to approach the problem is a design artifact. A vague prompt that delegates the way of solving it to the model isn’t design: it’s outsourcing the thinking that belongs to whoever is leading technically.

None of these three questions are new. They’re the same ones a tech lead asks when faced with a poorly designed class or a service that does too much.

What changed is that, since creating a piece costs almost nothing, it also costs less to skip the question.

The other extreme: When orchestration is the problem, not the solution

There’s a mistake symmetrical to the previous one, and it’s just as common: convincing yourself that a system is solid because the architecture diagram looks big.

A flow with 15 agents, each with its own set of skills, connected to one another with neat arrows, conveys a sense of solidity that doesn’t always match reality.

And describing it in words is even more seductive: “multi-agent orchestration,” “distributed reasoning pipeline,” “architecture of specialized agents collaborating.”

It sounds like serious engineering. Sometimes it is.

Often, it’s the modern version of a problem we already knew under a different name: accidental complexity disguised as essential complexity.

The question that tells one from the other isn’t “Does it work?” It’s:

“Does each step in this chain exist because the problem or the workflow demands it, or because it was easier to add a new agent than to ask whether the previous one could do a bit more, or could be redesigned better?”

A pipeline of six agents where three of them do trivial format transformations, such as taking an output, reordering it, and passing it to the next one, isn’t a robust architecture.

It’s three additional points of failure, three places where context can get lost or corrupted, and three more elements that someone has to maintain, version, and understand when something breaks in the production environment.

Complexity isn’t free only when it “serves a purpose.” It’s a fixed cost from the moment it exists, whether it serves a purpose or not.

This pattern has the same precedent we already mentioned with microservices: when the unit of decomposition (the service in one case, the agent in the other) is so cheap to create, the temptation is to decompose by default instead of decomposing by necessity.

No one asks, “Does this need to be a separate agent?” because creating the separate agent doesn’t cost anything visible at the time.

The cost shows up later, distributed across debugging time, latency accumulated through each handoff, and the difficulty of explaining to someone else on the team why the flow has that shape and not a simpler one.

Two questions help distinguish necessary orchestration from over-engineering:

Could these steps be solved with fewer pieces without losing clarity of responsibility? Simplifying well, by grouping two steps that are really the same logical decision, is not the same as simplifying poorly, by going back to compressing several real responsibilities into one, the mistake already discussed.

The question isn’t “Is less better?” It’s whether the number of pieces reflects the actual number of distinct decisions the problem or workflow has, no more and no less.

Does the architecture survive the question “What is this actually for?” If, pointing at a specific agent in the diagram, no one on the team can explain in one sentence why it exists as a separate piece and not as part of another, that piece is probably there out of design inertia, not out of the problem’s necessity.

A big diagram isn’t necessarily evidence of good design. It’s evidence that many decisions were made, good or bad.

The same goes for the language used to describe it: the fact that an architecture can be described with elegant vocabulary says nothing about whether that architecture was the simplest or most effective way to solve the problem.

And “simpler” here isn’t an aesthetic preference. It means less surface area for failure, lower maintenance costs, and less incident-response time when something doesn’t work as expected.

What this means for the business, not just the team

This isn’t an aesthetic architecture problem. An agent without a clear responsibility, or a pipeline with more pieces than the problem requires, has a measurable cost.

When something fails in production, diagnosis time multiplies because no one can point to which part of the flow is responsible for what.

When someone new joins the team, understanding “what this system does” takes longer than understanding a well-named function because its scope was never made explicit, or because it’s spread across more pieces than necessary.

And when the business asks for a small change, such as “also have it send an email,” that small change ends up touching a piece that was already doing four other things, or crossing four agents that didn’t need to be separate, with the risk of breaking something no one predicted.

Conscientious design of an AI element doesn’t eliminate 100% of the uncertainty. A model remains probabilistic, and no level of decomposition, whether more or less, changes that.

But there’s a real difference between a system whose behavior we can’t explain because we never thought it through, and one that still doesn’t deliver 100% of the expected results after having been designed with the same rigor as any other piece of software.

The first is design negligence.

The second is technology’s real limit. And that limit needs to be accepted and, above all, understood in order to find the best solution that gets as close as possible to the expected results based on the techniques available.

Before creating the next agent or skill, pause for a moment, this isn’t an argument against building with AI.

In fact, I love working with AI.

It’s a reminder that building fast doesn’t excuse us from designing, in either direction: neither by compressing too many responsibilities into a single agent, nor by multiplying agents that are, at bottom, repeated the same decision.

Before creating the next AI element, the question isn’t whether it works. The model resolves that almost always.

The questions are whether it has a responsibility that can be named in one sentence, whether something similar already exists on the team, whether we decided that way of solving it or the model decided by default, and whether the number of elements we end up using reflects the actual number of decisions the problem needed and had.

If those questions can be answered calmly, the team is probably building something well thought out that can be explained and sustained.

And I say probably because sometimes, even after answering the questions, we might still be falling into some antipattern.

But if we struggle to answer them from the start, that difficulty is the sign that something isn’t quite right.

At INSPYR Global Solutions (IGS), this is how we approach and adopt AI: bringing our knowledge, experience, and professionalism to every stage of building and adopting AI, not only across the SDLC but also within our internal processes and day-to-day work, with human judgment always at the center of every decision.

That combination, human in the loop as a principle, not an exception, is what allows us to harness the speed AI gives us without giving up the quality that only our own expertise can guarantee.

If you’re interested in building with AI while developing the judgment and technical expertise that make technology truly valuable, explore career opportunities at IGS and discover what you could build with us.