3-part series | Estimated reading time: 10 minutes
One day, I fed a 685-page book to an AI and asked it to "make it usable."
Software Engineering at Google: Lessons Learned from Programming Over Time. It's a landmark book distilling the hard-won knowledge of tens of thousands of Google engineers who have maintained over two billion lines of code across several decades.
Extracting the book's essence and building a leverage memo and action matrix — that part was squarely in the AI's wheelhouse. But the really interesting stuff came after that. By keep throwing questions at the AI, a unique framework emerged that went well beyond the book itself.
This article traces that process — how the framework evolved through a back-and-forth "sparring session" with AI.
The Starting Point: The "Trap" in a Great Book
Software Engineering at Google is a wonderful book. But it comes with some built-in assumptions.
Tens of thousands of engineers. Over two billion lines of code. Systems designed to run for decades. In other words, the scale this book has in mind is extreme.
If a startup or small team tries to apply this book's rules wholesale, they'll be crushed under the weight of excessive process. But dismissing it with "we're not Google, so it doesn't apply to us" would mean throwing away an enormous amount of genuinely valuable insight.
On top of that, as of 2026, the world looks very different from when the book was published in 2020. The big new assumption is the rise of AI-driven development. Code review, test generation, refactoring — many of the practices covered in Parts III and IV of the book are being fundamentally reshaped by AI.
So I threw the first question at the AI.
"As AI-driven development becomes mainstream, won't a lot of what this book covers — especially Parts III and IV — need to change significantly?"
The First Turn: The Idea of "Profiles"
The AI's response did what you'd expect: it sorted things into "what will change" and "what won't." AI will handle first-pass code review, AI is great at generating tests, documentation will be auto-generated — but architectural decisions, ethical considerations, and cross-team negotiations are still too hard for AI, it said.
Not a bad analysis. But it was still thinking inside the book's frame. So I pushed further.
"This book assumes tens of thousands of engineers, but if we also assume AI-driven development, couldn't a small organization do 'ship something working, fast' development using a monorepo and trunk-based development?"
The AI said yes, and went on to explain why a monorepo + trunk-based development approach is viable even for small teams. But that's when I noticed something: it was trying to apply the same rules to every system. Demanding the same test coverage from an MVP prototype and a payment system makes no sense.
"Instead of one single execution plan, what if we had separate ones — one for everything across the board, one for security-critical systems, one for large-scale systems, one for small-scale systems — and built a talent development environment that covers the areas where AI falls short? Wouldn't that solve most of the pitfalls?"
That question gave birth to a three-layer structure.
The Three-Layer Structure: The Framework's Skeleton
Layer 1: Common Foundation (Universal, Non-Negotiable)
Few rules, but absolutely mandatory.
The technical and cultural foundations that apply regardless of system type — monorepo, trunk-based development, AI-driven CI/CD, and so on. The rules here aren't things you "decide whether to follow"; they're baked in from the start.
Layer 2: Profiles (Operations Tailored to System Characteristics)
Institutionalizing the idea that "there is no universal solution."
| Profile | Top Priority | AI Dependency | Test Coverage |
|---|---|---|---|
| A: Small-Scale / High-Speed | Speed | Maximum | 60% |
| B: Large-Scale System | Consistency | Medium | 80% |
| C: Security-Critical | Safety | Restricted | 80% + Penetration Testing |
| D: Mission-Critical | Maintainability | Minimum | 80% + Multi-Person Review |
A team building an MVP moves fast under Profile A; a team handling a payment system requires a dedicated security reviewer under Profile C. The design allows different profiles to coexist within the same organization.
Layer 3: Talent Development Environment
A system for humans to continuously sharpen their skills in the five areas where AI struggles — architectural judgment, discovering unknown threats, value trade-off decisions, cross-team negotiation, and real-time incident response.
This third layer, however, would end up evolving the most dramatically through the sparring sessions.
The Second Turn: Rediscovering "Sparring"
While discussing the Layer 3 talent development environment, the AI presented "five domains that only humans handle." The classification itself was correct. But I noticed an implicit assumption lurking underneath.
It had become a binary: "AI is bad at it = humans handle it alone."
"Even in areas where AI struggles, isn't it effective for humans to spar with AI to expand their thinking, rather than doing everything on their own?"
That question changed the direction of the entire framework.
What is sparring, exactly? It's not getting AI to write code, or asking it for answers. It's using AI as a dialogue partner to structure your own thinking, generate counterarguments, and surface perspectives you've been missing.
For example, when you're torn on an architectural design decision, you ask: "Build the three strongest arguments against choosing this option." When doing threat modeling, you spar: "Come up with three variants that evolve my attack vector X." In a pre-mortem for incident response, you have it list: "The five most likely scenarios in which this system breaks at 3 a.m."
Don't ask AI for answers — ask AI to expand your questions.
Once this idea was incorporated, Layer 3 shifted from "a place where humans train on their own" to "a place where humans expand their thinking through sparring with AI."
The Third Turn: Sparring Logs as an "Asset"
If sparring is valuable, then the logs of those sessions should be analyzable. I pushed further.
"If we make submitting sparring logs mandatory and give feedback on them, shouldn't mentors include AI, not just humans? And what if AI analyzed the logs for personality traits, aptitudes, and compatibility — and used that to improve talent development plans and optimize team composition?"
The AI answered carefully. It's effective, but ethical guardrails are necessary. Personality analysis could lead to discrimination. There are privacy risks. If sparring starts to feel like it's being "monitored," psychological safety will collapse.
All fair points. But I pushed one step further.
"You've established a principle of not using this directly for evaluation — but shouldn't the quality of sparring questions be the single most important evaluation criterion in the talent development environment?"
It was a question that flipped the AI's assumption on its head. Turning the safety measure of "don't use sparring logs for evaluation" into "the quality of sparring questions is the most important thing to evaluate."
"Not measuring the most important thing isn't a failure of measurement technique — it's a failure of measurement courage."
The Fourth Turn: Protecting Privacy Through "Structure"
Use the quality of sparring questions for evaluation. But also protect psychological safety. How do you satisfy these seemingly contradictory requirements at the same time?
"For sparring logs, what if only AI could see anything beyond what a mentor gives feedback on — so that no human, not even the top of the org, can see the raw logs, only the AI analysis report? Couldn't that create a structure where the organization is genuinely able to keep honoring that ethical boundary?"
That question gave birth to a privacy architecture with three data layers.
| Layer | Access Rights | Contents |
|---|---|---|
| Layer 1: Raw Logs | The individual and AI only | The full sparring record. Not even the CEO/CTO can see it. |
| Layer 2: Mentoring Target | Only the mentor the individual has chosen | Time-limited. Auto-expires after 2 weeks. |
| Layer 3: AI Analysis Report | Individual → Mentor → Manager | Scores and trends only. No specific question content included. |
The critical point is that this is a "mechanism," not a "policy." Not a rule that says "the CEO won't look at raw logs," but a structure where "even if the CEO tried to look, the data is encrypted and the access rights simply don't exist."
Protected not by trust, but by architecture.
The Chain of Questions So Far
Let's trace the flow from the first question to here.
"Won't AI-driven development change Parts III and IV of this book?"
↓ In response to the AI's answer:
"Can't small organizations do monorepo + trunk-based development too?"
↓ Overturning the AI's assumptions:
"Instead of one-size-fits-all, couldn't profiles solve the pitfalls?"
↓ Challenging the AI's binary of "humans handle it alone":
"Even in areas AI struggles with, can't sparring expand human thinking?"
↓ If we're going to systematize sparring:
"What if we included AI as a mentor and used the logs for development?"
↓ Overturning the AI's "no evaluation" assumption:
"Shouldn't question quality be the single most important evaluation criterion?"
↓ To reconcile that with psychological safety:
"If we protect raw logs through structure, can't the organization keep honoring the ethical boundary?"
Each question precisely targets an "assumption" in the AI's previous answer and steers toward a better structure. This chain of questions is itself a live example of sparring.
Coming Up Next
In Part 1, we traced the process from analyzing the book to the emergence of the framework's skeleton — the three-layer structure and privacy architecture.
But this framework still had two serious flaws.
In Part 2, we'll unpack Working Backwards and space for exploration — two "structural blind spots" discovered through sparring with AI — and the final integrated framework (v2) that resulted.
"Relentless rationality kills what rationality alone cannot create."
What that means will become clear in Part 2.
Continues in Part 2: "Development Without a Goal Is Just a Game — Working Backwards and Space for Exploration" →