[The External-Opinion Problem: Why Solo Founders Can't Validate What Their Agent Tells Them]

I shipped a payments integration last spring that I was really proud of. The agent and I had built it over four days. It handled the happy path; it had tests, the tests passed, and the demo worked. I pushed it. 

Three weeks later, a user's card got double-charged because my idempotency handling wasn't actually idempotent but keyed on a value that wasn't unique across retries. The agent had written exactly what I asked for. I just hadn't known to ask whether the retry key was safe, and there was nobody around to tell me I'd missed it.

That's the problem I want to talk about. Not "AI writes bad code" (it usually doesn't); the problem is narrower and harder to see: when you build alone with an agent, you have no one to tell you what you didn't think to check.

When you work with an agent, you're a hostage to the context you gave it at the start. You describe what you want, it builds toward that description, and the quality of the result is bounded by the quality of your framing. If your framing has a gap, the agent doesn't fill it; it builds confidently around it, and the gap ships with the feature.

On a team, this is survivable because you're not the only voice in the room. You open a PR, and someone who wasn't in your head looks at it. A colleague says, "Wait, what happens if this gets called twice?" and the gap closes before it reaches production. That review is the mechanism by which one person's blind spot gets caught by someone who doesn't share it.

Solo, there are no holes in the bubble. You, the agent, and your shared assumptions sit in a closed loop. You prompt from your competence, the agent builds on your prompt, and you evaluate the result with the same competence that wrote the prompt. If you didn't know idempotency keys had to survive retries, nothing in that loop knows it either. You don't get corrected, and you get a clean demo and a problem that shows up later, on its own schedule, usually at the worst time.

The uncomfortable part is that the loop feels productive the whole way through. You're shipping, and the tests pass. It's only when reality arrives (a user, an auditor, a security researcher, or a real load spike) that you find out the project drifted from a norm you didn't know existed.

Eighteen months ago, the hard part of building with AI was getting the agent to produce what you wanted. You learned to prompt: be specific, give examples, and break the task down. That skill mattered, and it still does, but it's no longer where projects fail.

The agents got good enough that "produce what I asked for" is mostly solved. What's left exposed is the other half: knowing whether what you asked for was right. The bottleneck shifted from "How do I describe this task?" to "How do I know the output is actually production-ready?" and that second question is much harder, because it requires knowing what "production-ready" means for code like yours, which is precisely the knowledge a less-experienced solo builder is missing.

This shift hits isolated builders hardest, and it does so unevenly. A senior engineer building solo still has the bottleneck; they just carry more of the verification standard in their own head, so they catch more of their own gaps. A first-time founder shipping a SaaS with an agent has the same bottleneck and almost none of the internal standards to meet it. The tool is equally capable of both. The gap between them is entirely in what each one knows to check.

A colleague of mine has a phrase for this that stuck with me. He calls it the "magic words" problem. The magic words aren't the prompt that gets the agent to build the feature but rather the criteria you'd use to check whether what it built is any good and, crucially, the criteria you'd hand the agent so it could check itself.

The catch is that there are thousands of them, and they're domain-specific. "Write tests" isn't a magic word; it's a wish. The actual criteria are: write unit tests for the logic and integration tests for the boundaries; make the integration tests cover the core business scenario, edge cases included; distribute coverage so the integration tests aren't just re-checking what the unit tests already cover; and don't write tests that assume the same mistake the code makes. That's one narrow corner of one discipline. Multiply it across security, data handling, error states, concurrency, accessibility, API contracts, and every other dimension a real product has to satisfy, and you start to see the size of the thing.

On a team, you don't need to hold all of those in your own head, because the team holds them collectively. The security-conscious engineer flags the auth gap; the person who got burned by a race condition last year catches the concurrency bug. Solo, you need either to know all the magic words yourself or to get them from somewhere outside the bubble. Most people can't know all of them. Which means the real question is, where do the magic words come from when you don't have them?

There are really only three sources of outside opinion, and it's worth being honest about what each one costs:

• A colleague. The highest-bandwidth option and the one solo builders don't have by definition. The closest substitutes are a freelance senior engineer for a paid review, a technical advisor, or a community: posting your approach in a domain-specific Discord or forum and asking what you missed. These work, but they're slow, intermittent, and only as good as whoever happens to answer. They don't scale to "every commit," and they tend to give you a verdict on the thing you already suspected was risky, not the thing you had no idea to ask about.
• A standard. Codified norms exist for a reason: OWASP for web security, the relevant compliance framework for your domain, language and framework style guides, and reference architectures. A standard is the cheapest external opinion you can get, because it's written down and waiting. Its limit is that you have to know a standard exists before you can check against it, and you have to be able to apply it correctly. A standard doesn't walk over and tell you it's relevant; you have to go find it, which puts you back in the bubble problem one level up.
• A service. This is the category that's grown fastest in the last year: tooling built specifically to be the outside opinion. Static analyzers and linters are the long-standing versions. The newer wave is continuous scanning systems aimed at AI-generated code specifically: tools that watch a codebase over time and check it against encoded criteria, leaked secrets, hallucinated dependencies, access-control logic that breaks across commits, and tests that look like tests but verify nothing. Some run as a CI check; some run as a persistent agent that opens its own PRs with fixes.

I'll be honest about the limits here rather than sell you one, because it's true: no service is a substitute for understanding your own product. A scanner catches the categories someone thought to encode. It will not catch a domain mistake nobody anticipated, a business logic error that's perfectly valid code doing exactly the wrong thing. What these tools do well is collapse the cost of the checks that can be codified, so your scarce human attention goes to the part that can't. Used that way, they're the closest a solo builder gets to a reviewer who shows up on every commit. Used as a guarantee, they become a new version of the same false confidence that got you into trouble.

For the record, this is the gap Enji Guard is built for: scanning of AI-written code against project-specific rules, with the security and dependency checks running on every change rather than once at merge. <br />I work adjacent to that product, so take the mention for what it is: one instance of the "service" category, not the answer to the whole problem.

You can't manufacture a colleague; what you can do is stop relying on the loop that has no holes in it. A few things that have changed how I ship solo:

1. Write the verification criteria before you build, not after. Before you ask the agent for a feature, write down (in plain language) what would have to be true for it to be safe to ship. Not how to build it; how you'd know it's right. This forces the magic words out of your head and onto the page, where you can see the gaps in them. When the list is thin, that's information: it means you don't know what good looks like here, and that's the part to go research before you write a line.
2. Make the agent argue against itself. After it builds something, ask it, in a fresh context, not the one that just wrote the code, to find the ways this implementation could fail in production. A clean context isn't your collaborator anymore; it's closer to an outside reviewer, and it'll often name the category you missed. It's not a real second opinion, but it's the cheapest approximation of one.
3. Pick one external standard per risky domain and actually read it. If you're handling payments, money movement has known failure modes that are written down. If you're storing user data, the compliance baseline exists. You don't need to become an expert. You need to know enough to recognize which of the thousand magic words apply to you.
4. Run a service for the codifiable checks, and be clear-eyed about what it doesn't cover. Let it own secret leaks, dependency updates, and the security invariants that can be automatically checked and maintained so your own attention goes to the business logic no tool understands.

None of this closes the bubble completely. Solo, you will still ship things you didn't know to check. The goal is to shrink it by getting as many outside opinions as you can from sources that don't share your blind spots. My double-charge bug would have been caught by any one of these: a written idempotency criterion I didn't have, a fresh-context review I didn't run, an OWASP-adjacent payments checklist I hadn't read, or a scanner watching for exactly that class of error.

I had none of them at the time because I thought the bottleneck was still getting the agent to build the thing. 

It wasn't. It was knowing what to check and having no one to ask.