Integrating Founder-Level Judgment with AI-Native Product Leadership
Give an agent a race condition, and it will often "fix" it by rewriting the surrounding code to alternate synchronous and asynchronous calls. It compiles. It passes the tests you gave it. Here's what that fix would miss: nothing was correlating errors across the threads writing to the same log file, and the real problem was never sync versus async; the system needed a queue sitting outside it entirely. Run that thought experiment and the failure isn't in execution. It's in judgment. The agent produced something plausible with no way to tell whether plausible and correct were the same thing here.
That gap between plausible and correct is where most of the risk in AI-assisted engineering now sits. Historically, adding execution capacity meant adding people, and people brought judgment with them because judgment was baked into hiring. You couldn't buy raw code output without also buying someone's opinion about whether the code should exist. Coding agents broke that bundle. You can generate ten times as much code today without adding a single person who has a view on whether it should ship. The execution side of the equation moved. The judgment side stayed exactly where it was: with you, or with whoever wrote the spec, or with whoever happened to be paying attention that day. That's fine when the problem is genuinely new and the limit is how fast someone can build and test something nobody has built before. It's not fine anywhere else.
I'm not arguing for locking everything down here, and I'm also not arguing for handing an agent, or a new hire, wide latitude and hoping their judgment lines up with yours. Both of those skip the actual question, which is where you draw the line ahead of time, so that what ships on an ordinary day is still something you'd sign off on if you were watching.
What the productivity studies actually measure
The productivity numbers behind this shift are real. A controlled study of GitHub Copilot found developers completed a well-scoped task 55.8% faster than a control group. A field study at Microsoft and Accenture found 12.9 to 21.8% more pull requests per week among Copilot users, and ANZ Bank's internal rollout reported similar gains in coder throughput. Look at where every one of those benchmarks starts: after somebody already decided the task was worth doing. None of them measures whether the model should have picked that task in the first place. That's not a flaw in the research. It's a boundary around what AI currently does well.
An agent with no boundary around it doesn't make you faster. It makes you louder: more code, more pull requests, all of it downstream of whatever assumption the model inherited, including the ones nobody thought to check.
What I ask before anyone builds anything
Before AI or a new team gets loose on a problem, I want six things answered:
- Who has the problem?
- How do we know they have it?
- What are we betting will change their behavior?
- What's the cheapest way to test that bet?
- What are we explicitly not building yet?
- What result would change our mind?
Answering these slows the first week down. Skip them and the cost doesn't disappear; it resurfaces months later, once a team has built quickly in a direction nobody actually agreed to and now has to unwind it. Picture a team with an agent-assisted stack that can ship features faster than it can agree on which one matters. Sales wants a dashboard, support wants an export button, a big prospect wants SSO. Each is reasonable alone, and the team has capacity to build all three, so it does. Three months later, nobody can say which of the three moved the number the company actually cares about, because nobody wrote the bet down before starting. The team wasn't moving slowly. It was moving fast in six directions. Question five would have forced somebody to say no to two of the three. Question six is the one people skip, and skipping it is how a bet turns into something a team defends forever instead of something it tests and lets go of.
The odd part is that the usual engineering metrics can look fine the whole time this is happening. Pull requests go up, cycle time goes down, more features ship. None of that tells you whether the team picked the right three things to build in the first place.
Where this meets engineering
I teach my engineers a version of this at the code level: define the database schema, the API interface, and the UI, state clearly what the rules are at the connections between those layers, then let AI fill in the blanks in between. Knowing which junctions in a pipeline are load-bearing matters more than knowing every line inside it. That's also why I still don't hand architecture-level decisions, queue placement, error correlation across concurrent processes, where a cache sits in the request path, to an agent unsupervised. It isn't that the agent can't produce something that runs. It's the exact failure the race-condition example illustrates: a plausible fix that never touches the actual problem. Those decisions are expensive to reverse and easy to get wrong in ways that don't surface until production, so in 2026 I keep them with a person accountable for understanding the tradeoff, not for approving the diff.
A workable arrangement inside that boundary: define the spec and API surface first, have one agent write code against it, and have a second agent write tests from the same spec independently, so neither is grading the other's assumptions. Closing the loop with a deterministic pipeline gives you an automated check, though a human still decides what happens when CI disagrees with the team. I lean toward mixing models across these roles, writer, tester, reviewer. I can't point to a study proving this helps; it's a preference I hold loosely, and I'd drop it if I saw a good test showing it doesn't matter.
Inside that boundary, whether the agent writes a for loop or a while loop shouldn't matter to anyone. It's easy to reverse and doesn't touch anything else. That's similar to delegating between engineers: the more judgment someone has already demonstrated in a domain, the more you can hand them the reason and the boundary rather than the implementation. The analogy only goes so far, though. Trusting an agent's track record in a domain says something about how much delegation is safe inside a known boundary. It says nothing about the agent's judgment being equivalent to a person's.
The rule has a limit worth admitting too. Sometimes a choice that looks purely internal and reversible, say, which caching layer a service uses, turns out to be load-bearing in a way nobody flagged, because three other services quietly came to depend on its specific eviction behavior. You don't learn that from the spec. You learn it when something downstream breaks. Drawing the boundary in advance is a bet on what's likely to matter. It doesn't guarantee you drew the line in the right place.
Where boundaries go wrong
The other failure mode is that boundaries stop getting revisited. A set of questions written once quietly turns into six boxes nobody questions again, carrying forward whatever blind spot existed the day they were written. If the market isn't understood yet, heavy specification can slow the learning you actually need. That's why cheap prototypes matter: AI now lets you build far more product than the team has validated, which means you can lock in edge cases nobody asked about before confirming the premise mattered at all. Build the sloppy version first to find out which assumptions were wrong, then specify harder on the parts that turned out to matter.
How much you specify should track how much you actually know. Early on, when you don't know the customer or the problem well, low specification and heavy exploration are the right posture, because the fastest way to learn is to build something small and watch it fail informatively. Once you understand the problem, specification should rise sharply at the interfaces that matter, the schema, the API surface, who reviews what, what stops the work, even while it stays loose on implementation details that don't touch those interfaces. Founders who specify hard on day one are usually encoding a guess as if it were a fact.
This isn't really about how much process to add or remove. Write down who the customer is, what evidence you have, what you're betting will change their behavior, what you're deliberately not building, and what result would make you change your mind. Do the same at the schema and API layer: name who reviews what, and let the boundary widen once you've actually learned something. Boundaries get drawn wrong in both directions: too tight where a team needed room to find the actual problem, too loose where a caching decision quietly became permanent. The boundary is still yours to draw. Getting it right the first time isn't the point. Noticing when it's wrong, and redrawing it, is.
