Summary: I didn't use AI agents to skip product discipline. I used them to compress it. The result was a one-person software factory with the same stages I expect in a serious v1.

I am starting a series of posts from my learnings, so others can learn and I want to learn from your comments and feedback. I will be posted on LinkedIn, connect with me.

Most people hear "solo builder with AI" and picture vibe coding. That wasn't my approach. My view: AI-native software development works best when it increases one person's reach without dropping the controls that make a v1 credible.

Over the last few months, I released a set of open source AI and agentic projects across evaluation, observability, runtime governance, MCP tools, control planes, and agent security. Repos such as AgentEval Forge, ToolTrust, HivePlane, and MCP Fabric show the code. The structure behind the work is the part nobody sees, so that's what this series covers. I wasn't trying to produce clever demos. I was trying to build near-commercial v1s as one builder, with AI agents as leverage. That meant keeping the old bones of good product development and changing the speed and surface area with AI.

Because this work was public, the proof is public too: GitHub repos, PRDs, field-test reports, and Dev.to articles that document what worked and what didn't. The AgentEval Forge PRD, the ToolTrust field test report, the HivePlane field test report, and the matching Dev.to writeups are all public.

This was more than faster coding

The weak version of this story is: AI helped me code faster. The better description is that I used AI to increase throughput across the whole product lifecycle. I started each build by writing the project file and the first problem statement. Then came a PRFAQ or one-pager to make the product concrete, plus research into adjacent OSS and commercial tools. I built a feature map before locking scope, then drafted and refined the PRD. The PRD became a work breakdown with milestones and tickets, and I wrote code with agent help under review constraints. Last came verification with tests, field runs, and release gates.

The code was only one stage. When people accelerate code generation and leave planning, control, and verification thin, the output looks productive right until it has to survive comparison, scrutiny, or production reality. Much AI-assisted software work still breaks exactly there.

The operating model I used

The work followed a repeatable pipeline.

AI changed the throughput inside each stage. It didn't change my expectation that each stage should exist.

Project files came first

Every serious build started as a product note before any code session. I wanted the initial artifact to answer basic questions early: what problem is this solving, who is it for, and what has to exist for v1 to matter. I also wrote down what would make it better than the other options and what shouldn't be in v1 at all.

This sounds boring until you compare it with how many AI-assisted projects start. The common pattern is to open the editor, ask the model for a scaffold, then discover the product while writing files. That's fine for prototypes. It's weak for anything you want to release, compare, explain to users, or defend in front of a hiring manager or leadership team. Starting with a project file gave me a stable product center before build noise arrived.

Those project files weren't lightweight notes. They held the full product skeleton: why this should exist, the target user, their problems, the final state, workflows, scope, non-goals, architecture direction, MVP boundaries, milestones, and interview talking points. You can see that structure in public artifacts such as the AgentEval Forge PRD and the ToolTrust PRD.

The private project files themselves aren't public, but the working format was close to this: the why-exist section and the user definition, the problem statements and final state, core workflows, product scope, non-goals, architecture direction, a local-first OSS stack, data and tool integrations, PRFAQ or release framing, the MVP definition, milestones and work breakdown, success metrics, risks and hard parts, and finally résumé lines and interview talking points.

One artifact carrying all of that was deliberate. It could support product thinking, build planning, technical work, writing, and career packaging without anything getting lost between tools.

The market map was part of the build

This is one of the least visible parts of the work, and one of the most important. Before pushing hard on a repo, I mapped the surrounding market. I looked at what adjacent OSS already existed and what commercial tools covered the space, then checked where the feature overlap was real and where the gaps were still open.

That changed two parts of the work. First, it improved scope. If a mature tool already solved 80 percent of the problem, I either changed the angle or got more specific. Second, it improved the writing. It let me describe a repo by capability and positioning, not only by code. That's part of why public reflections such as I Built an Agent Eval Harness. Real Agents Broke the Clean Version of the Story. and I Stopped Trusting AI Agents With Tools. So I Built a Gatekeeper. go beyond code detail.

That's part of leadership too. It means understanding the category you are entering and why your version deserves to exist. The method was narrow: list adjacent OSS and commercial products first. Compare by capability rather than marketing language. Then find where the market is strong and where both OSS and commercial are weak, and define the v1 around one of those weak spots.

The raw research notes sat in my private system, but the public products and PRDs reflect the result of that method. I wasn't building from vibes. I was building after locating the whitespace.

AI agents were workers, not the product owner

I used AI heavily during the build. The working model wasn't "let the agent drive." It was closer to managed delivery. I used agents for draft generation, exploration, scaffolding, and repetitive transforms. I kept product intent, acceptance criteria, and sequencing human-owned, forced written structure before long build phases, and treated review and verification as more important when generation gets cheaper.

That last point is often underestimated. When code becomes cheaper to produce, review quality matters more, not less. The bottleneck moves. The question stops being "can we generate enough code?" and becomes "can we prove the generated system deserves trust?"

The important difference between demo-ready and v1-ready

AI makes it easier to produce something that looks impressive fast. It doesn't automatically make it easier to produce something coherent, tested, packaged, documented, compared against the market, and honest about its edges. The one-person software factory exists to close that gap. Its job is carrying one product through the full lifecycle with enough discipline that the result is legible as a real v1, even at modest output volume.

For me, that meant field testing, release readiness, and public documentation weren't optional polish. They were part of the product. That meant publishing evidence such as the AgentEval Forge field test report, the ToolTrust field test report, and the HivePlane security audit, then writing about what those artifacts taught me.

Public receipts

If I say this was a disciplined AI-native lifecycle, there should be public evidence. The code, product artifacts, and retrospective writeups are all visible in four examples:

The repo proves the build happened. The PRD and field-test files show product and validation discipline. The Dev.to articles show what worked and what didn't, plus what I would change next time. You can see that in posts such as I Trusted My Agent Demos for Years. Then I Built a Gate That Says No. and I Connected 3 MCP Servers to One Agent. It Got Scary Fast..

Where this fails

This model isn't universal. It works best when the builder already has product judgment, enough engineering depth to review generated work, and enough experience to spot when a repo creates false confidence through green tests or polished demos.

It also doesn't mean one person should always do the whole lifecycle. In a company, the better outcome is usually not "make everyone solo." The better outcome is to use AI-native workflows to raise the throughput and clarity of cross-functional teams.

A real limit remains: AI compresses execution, but it doesn't remove the need for judgment. If the judgment layer is weak, the factory produces more output, not necessarily better products.

Recap

• I used AI to compress the full product lifecycle, not just to generate code faster.
• The work held to project framing, market mapping, PRD, work breakdown, verification, and release readiness.
• The repeatable capability isn't "solo coding." It's AI-native product development with public receipts and controls intact.

If you are using AI heavily in software delivery, where's your process compressing best: coding, planning, review, or release readiness?

References

1. AgentEval Forge repository
2. AgentEval Forge PRD
3. AgentEval Forge field test report
4. AgentEval Forge dev.to article
5. ToolTrust repository
6. ToolTrust PRD
7. ToolTrust field test report
8. ToolTrust dev.to article
9. HivePlane repository
10. HivePlane field test report
11. HivePlane dev.to article
12. MCP Fabric repository
13. MCP Fabric PRD
14. MCP Fabric dev.to article

AIEngineering #PlatformEngineering #EnterpriseAI #LLMOps