Last updated: September 28, 2026
1 human, 11 AI employees (of the company’s 13).
89 capabilities shipped across 8 feature cycles, at ~$85 per capability.
I chose engineering as the second loop because it is the hardest problem I know. Building commercial software. Tested, deployed, used by real people in production. The kind of work I have spent 30 years doing with human teams.
The question was not whether AI can write code. That debate is settled. The question was how far AI can go without a human in the co-pilot seat. Not augmenting a developer. Not pair programming with a machine. Removing the human from knowledge and execution work entirely, and seeing what breaks.
The breakthrough was a simple shift in perspective: stop asking how to make machines work like human engineers, and start asking what machines actually need to be productive on their own.
I have been building commercial software for over 30 years using various methodologies including Waterfall, Agile, and even my own co-invented Lean Drops. When I started the engineering loop, I evaluated the emerging wave of AI-aware development methodologies. They are real and they are thoughtful. But they all still require a skilled human engineer in the knowledge and execution loop. Most are co-pilot models.
My question was different: how do I design an engineering team that does not need me in the room?
That question produced Taper, a machine-native SDLC. It follows the structural logic that any SDLC follows: requirements flow to design, design to planning, planning to execution, execution to delivery. What differs is that no human inside the loop does knowledge or execution work. Humans provide judgment and accountability. Everything else is machine-executed within governed boundaries.
Taper has been in use since the first day of the engineering loop. Process governance is built into the loop itself, so every execution hardens the system that governs the next one.
The SDLC came first. The architecture came second.
Once I had machines running a governed engineering process, I asked a different question: how would you write code if you did not have to be restricted by anything? No assumptions about who reads it. No conventions inherited from decades of software engineering. What does a codebase look like when it is designed for machine consumption from first principles?
The first clarity was mechanical. Object-oriented design, polymorphism, inheritance, dynamic dispatch: these constructs introduce ambiguity that is resolved at runtime, not compile time. Machines work more efficiently and consistently when behavior is explicit and statically traceable. Getting back to basics, pure functions with explicit inputs and outputs, removed an entire category of ambiguity from the codebase.
The second clarity came from reflection. Most of the patterns the industry treats as fundamental were introduced to make humans more efficient at expressing code that ultimately compiles down to the same zeros and ones. They are human productivity tools, not computational necessities, making them unneeded when the engineers are machines. I pushed the question to its logical end: if machines are the engineers, why write code at all? Why not compile directly to binary? The AI pulled me back. It still wanted code in a format I could read if I needed to. Even in a machine-native architecture, human oversight requires human-readable code. That is the floor.
What emerged from weeks of experimentation and iteration is a complete machine-native code architecture. Fully documented, with its own coding standards, security model, dependency governance, and intellectual property protections. At its foundation are four architectural properties derived from first principles: Findability, Comprehensibility in Isolation, Safe Mutability, and Verifiability. Any structure that achieves all four is correct. Any structure that fails one or more is wrong, regardless of how conventional it appears.
Like Taper, the architecture is a living system. Every execution of the loop tests it and refines it.
The SDLC addressed process. The architecture addressed code. The third question was harder: how do you prove quality?
I ran the engineering loop and paid attention to where the AI employees struggled. The failures were rarely in the code. They were in the gaps between phases: ambiguous handoffs, missing context, decisions that should have been explicit but were left implicit. I evaluated formal approaches to AI quality assurance, including evals frameworks and automated benchmarking. They measure model capability in isolation. They do not measure organizational quality: whether the right input reached the right engineer at the right time with the right context, and whether the output met the standard the business actually requires. Those are governance problems, not evaluation problems.
The key unlock was a concept I call burden flip. In traditional software development, the default state of work is assumed to be acceptable. A reviewer inspects it, and the burden is on the reviewer to find what is wrong. If the reviewer misses something, the defect moves forward. I reversed the default. In Taper, everything starts in an unproven state. Every capability starts unmatched. Every risk starts high. Every review is active. Every test scope includes everything. The burden is on the producing engineer to prove, with traceable evidence, that each condition is met before work moves forward. Not to assert readiness. To demonstrate it.
That single principle reshaped the entire SDLC. It works in both directions. The producing engineer must demonstrate that the work meets every condition before submitting it. The reviewing engineer assumes deficiency and must independently verify compliance before clearing it. Neither side coasts. Governance was woven directly into the process from direct observation of where AI employees struggled, not added as an inspection layer after the fact.
Governance is a spine, not a crutch. A crutch compensates for weakness and becomes unnecessary when the weakness goes away. A spine provides structure. Better models produce better output inside the same structure. The governance becomes more valuable as the models improve, not less.
What fell out of this was something I did not design for: robust compliance as a byproduct of the process itself. Every feature produces a complete set of structured artifacts. Every phase transition is documented. Every conversation between every employee, human to AI and AI to AI, is preserved across dedicated threads. I can hand an auditor a single archive for any feature and prove exactly how the software was built, who made which decisions, and how those decisions trace back to the governing standards. In 30 years of building software, I have never seen the incentives align this way. The process the machines need to do their best work is the same process that produces full auditability.
The governance is structural. But two types of human judgment and accountability sit above it.
The Product Designer owns business judgment. What to build, who to build it for, whether the finished product matches the original intent. The Product Designer touches every feature at the beginning and the end of the cycle. Business judgment requires market sense, taste, and experience. That does not automate.
The Product Architect owns technical judgment. When an engineering decision has no documented precedent, it escalates to the Product Architect. The decision is made, encoded in the governing architecture, and the same question never comes back. This role is designed to taper as the architecture matures. Early on, most technical decisions escalate. As the documented patterns grow, the engineers resolve more decisions on their own.
Both roles are currently held by one person.
The eleven engineers are not interchangeable AI agents invoked per task. They are AI employees. Each carries a persistent identity and a name, a role definition that governs their scope and accountability, alignment to company culture and quality standards, and an individual learning corpus that grows with every cycle. The distinction matters. An agent is stateless. An employee carries institutional knowledge, not in its own memory, but in the system it works inside. An agent executes a task and forgets. An employee learns from it and brings that learning to the next one.
Every feature runs through five phases. Each phase produces the structured artifacts that govern the next. The final phase encodes what was learned back into the system. The next feature starts stronger.
Business need is uncovered through persistent discovery, not accepted at face value. The root problem is identified, translated into structured product capabilities, and visualized as a prototype. The Product Designer approves the feature before any engineering begins.
The existing architecture and codebase are investigated for pattern evidence. Each capability is mapped to documented patterns. Where no pattern exists, the gap escalates to the Product Architect. Solutions are assembled from what already works, not invented from scratch.
The solution is translated into self-contained execution specifications, one per task, each containing everything an engineer needs to execute without doing any discovery. Risk is assessed at every task. No code is written until the plan clears review.
Test-driven development, local instance testing, end-to-end verification against the running application. Quality review against governing standards. Integration testing at system boundaries. Feature testing from the user perspective. Deployment to staging.
The Product Designer verifies against the original business intent. The Product Architect merges the PR. Dean, my DevOps engineer, deploys to production. Then the loop closes: new patterns are encoded in the governing artifacts, the codebase becomes reference for future work, and each engineer's learning corpus grows. The system is stronger than when the cycle started.
Human overrides are built into the governance, not worked around it. A gate can be trimmed or waived by a recorded ruling, so every override is a designed decision with a paper trail, never a quiet shortcut.
I now have a stable engineering team that is removing me from the knowledge and execution of commercial software development. I still hold judgment and accountability. But I don't write the requirements. I don't build the clickable prototypes. I don't write design docs. I don't write the code. I don't run the test suites as part of the pipeline. I don't review the diffs. I don't plan how things get built. I use the finished product, judge it against what I intended, and approve the release. Quinn, my feature analyst, interviews me. I collaborate with Norm, my design engineer, on look and feel, approve the PR, and use the finished product before customers do.
It is a strange feeling to know that I will never again write code on my own, without AI. Everything moving forward is machines writing zeros and ones, through the human-readable layer they insisted on keeping.
I spent seven months teaching my AI employees how to replace me, and along the way compressed over 30 years of building software into more than 160,000 words of governance.