The Agnostic Builder

The designer knows the API constraints. The engineer knows the customer. Agents let both act on more of what they already understand.

By Jason Waldrip November 4, 2026 14:00 6 min read

A designer sits through a product review and hears why a customer keeps getting stuck. She knows what needs to change. She also knows the route that idea will take: a conversation with product, a spec, a design, a ticket, and a wait for an engineer to pick it up.

She’s been in enough technical discussions to understand the constraints. She’s watched the team make tradeoffs between the interface and the API. She has an idea for both. The part she couldn’t do was make them work.

Now she can sit down with an agent and try.

What she gets back may be wrong. The agent might misunderstand a business rule, miss a security boundary, or produce a screen that looks right and falls apart when someone uses it. She’ll still need to direct it, exercise the result, and bring in other people when the work reaches beyond what she understands.

But she no longer has to wait for a handoff to find out whether her idea works.

the box on the org chart

We organized software teams around the difficulty of implementation. Writing production code took a set of skills. Designing an interface took another. Product management connected the customer’s problem to the work those people could do.

Each discipline developed expertise worth having. Each also became a box on an org chart, with a handoff at the edge.

I described the agnostic builder as someone who can see across those boxes and act on that understanding. AI has made that idea more practical than it was when I first wrote about it. An agent can read a codebase, make changes, run tests, open the application, and use a browser to exercise what it built. Give it access to the right tools and it can investigate a failure, change course, and try again.

OpenAI described one internal product team’s experience: its agents wrote application code, tests, documentation, and tooling. The engineers made the application, logs, and metrics accessible to those agents so they could inspect their own work. The team also made clear that its results depended on that environment. Giving an agent a task is not the same as giving it a way to know whether it succeeded.

That distinction matters to the designer in the product review. She can direct an agent across the interface, API, and tests. Whether the result deserves to ship depends on the context and feedback available to both of them.

you already know more than your title says

The designer has sat through the API discussions. The engineer has watched customers struggle with an interface. The product manager has spent years hearing why a technically plausible idea won’t work for the business.

None of them automatically knows everything about the other disciplines. But each has learned things outside the work their title says they own. For a long time, acting on that knowledge meant finding someone with the implementation skill and enough room in their queue.

The designer can now ask an agent to change the API and show her the result in a running product. The engineer can explore the interface with the same tools. The product manager can take a customer’s workflow, build a version, and discover where the original request left questions unanswered.

That changes the conversation between them. Instead of handing off a description and waiting, they can work on the same problem together, with something in front of them that can be exercised and changed.

The expertise still matters. A designer can see where a flow fights the person using it. An engineer can recognize a boundary the proposed change would break. A product manager can explain why the customer needs the exception that looks unnecessary in the spec. The builder has to know enough to use those perspectives, and enough to know when to ask for one.

the work is holding the whole picture

I wrote in Still the Painter that your capability didn’t go down when generation got cheap. It went up. The judgment you used to express through the work of your own hands can now reach further.

The same applies across a software team. Your expertise is still yours. You can use it to direct work that used to stop at the edge of your discipline.

The designer’s eye helps choose between working alternatives. The product manager’s understanding helps decide which problem deserves to be solved. The engineer’s experience helps shape a system that can keep working as it changes. An agent can help each of them explore the parts they couldn’t previously implement themselves.

That comes with a responsibility. Once you can make a change across the whole system, you have to care about more of the system. The interface, the data it exposes, the business rule behind it, and the path it takes to production are connected whether your title acknowledges them or not.

And agents are capable of getting the connections wrong. In SWE-Marathon, a research benchmark of 20 long-horizon tasks, the authors found failures involving weak self-verification and premature termination. That is a small, specific set of tasks, not a verdict on every agent. It is enough to make the point that a finished-looking result still needs evidence.

the organization has to move too

A person can adapt and still be stopped by the company around them.

Give a product manager an agent, then require every idea to pass through the same sequential design and engineering queues, and you’ve put the old walls back. Let a designer build a working version, then measure her solely on how many design artifacts she hands off, and you’ve told her where her job ends.

The way into this can be gradual. A team can use agents inside its existing disciplines while it learns what they can do and where they fail. But the opportunity opens up when people can work across those disciplines together, bringing their expertise to one continuous problem instead of passing artifacts from one queue to the next.

That also changes what you look for when you hire, develop, and promote people. Depth still has value. So does the ability to understand how a customer’s need, a design choice, and a technical constraint affect one another. A team needs room for both.

The question I keep coming back to is how much understanding is already sitting inside your company, waiting for permission to cross a line on the org chart.