Cases from the MBA and the Vanguard · MBA module — faster software, or developers who still understand it
Subtitle: Are we using AI to make software developers faster, or are we making them more efficient while reducing how much they understand and think for themselves?
A small software company develops a specialised platform used by customers around the world.
The company has a close technical team: eight developers work on new features and improve the software, while six engineers provide global support to customers.
Because the team is small, everyone depends on each other. Developers need to build quickly. Support engineers need to understand how the software behaves when something goes wrong. Customers expect problems to be solved quickly, regardless of where they are or when an issue happens.
The development team increasingly uses AI coding tools.
At first, AI is mainly an assistant. Developers use it to explain errors, write small functions, create tests and improve documentation. The benefits are obvious.
Development becomes faster. Developers spend less time on repetitive tasks. New features can be created more quickly, and a small team can deliver more without hiring additional people.
Over time, however, the way the team uses AI begins to change.
Instead of asking AI for help with one small task, developers start describing the result they want and allowing AI to create larger parts of the solution.
The process becomes simple. Describe the feature. Generate the code. Run the tests. If something fails, ask AI to fix it. The code works. Tests pass. Features are delivered. From a business perspective, this looks like progress. Customers get improvements faster. The development backlog becomes shorter. Developers can work on more ambitious features.
But something else starts to happen. Some developers know what the software is supposed to do, but understand less about exactly how the generated code does it. They can test the result and see that it works, but they cannot always explain every decision inside the code or predict what will happen in an unusual situation. The team starts debating whether this really matters. Modern developers already use frameworks, libraries and code written by other people. Nobody understands every layer of a modern software system. Perhaps AI is simply the next tool. Maybe a good developer no longer needs to write everything themselves. Their job could be to describe the problem correctly, guide the AI, review the result and make sure the software works.
Then a customer reports a serious problem.
The support engineer cannot find an obvious cause. The problem appears to involve a recently developed feature. The engineer contacts the developer who worked on it.
"What happens here?"
"What does this part depend on?"
"Why was it designed this way?"
"What should we check next?"
The developer knows the feature. They know what it is supposed to do. But much of the implementation was created with AI. Without asking AI to analyse the problem and suggest the next step, the developer is unsure where to begin.
The support engineer now has a customer waiting for an answer, while the person who built the feature cannot clearly explain how it works. Eventually, more experienced members of the team help solve the problem. But the incident creates an uncomfortable discussion. The issue is not whether AI produces useful code. It clearly does. The question is whether the company is becoming faster at producing software while slowly losing the human understanding needed to support it.
Universities face the same problem. Students increasingly learn programming with AI from the beginning. They can generate code, correct errors and build applications faster than previous generations.
But if AI always suggests the next step, how much experience do they gain in finding that next step themselves?
The company and the university now face the same dilemma.
Should they encourage AI as much as possible because it improves speed and productivity?
Or should they deliberately create situations where developers must work without it, even if doing so makes them slower?
Open with:
"If your development team lost access to AI tomorrow, what would they still be able to do confidently?"
Ask a developer first, then someone responsible for support or customers.
Then add one fact:
A customer has a critical problem, and the developer responsible for the feature cannot explain the code without AI assistance. - Does that change the answer?
Now AI does not only write code.
It can change the codebase, run tests, fix problems and deploy approved changes.
The developer is no longer just using AI. They are supervising an AI system that can act.
If developers understand less of the software themselves, can they still properly supervise what the AI is doing? And when AI makes a mistake, who inside the company understands the system well enough to recognise it?
If AI can build the software faster than we can understand it, who is ultimately responsible for knowing how it works?
A live case: every round can be improved, and the author's feedback is the next one.
The same two questions, answered twice: first without the mentor's corpus, then from it — the mentor's doctrine for intelligence officers, his HAI5 method, the task-to-agent protocol and his chapter 18.
Without the mentor's corpus
1. Yes, and aviation shows how. In 2013 the US Federal Aviation Administration issued a safety alert urging airlines to let pilots fly by hand when appropriate. Continuous use of the autopilot does not maintain the manual skills a pilot needs when it disconnects. Lisanne Bainbridge named the trap in 1983 as an irony of automation: the more a system automates, the more its operators are left with the rare, hard failures, and the less practice they get for them. This incident was one of those failures. So require it where the failure arrives, in debugging and support:
In universities, teach with AI and examine without it for what only the student can own: reading code, finding the fault, explaining the design. The productivity cost is a few hours a month. Ask yourself: when the autopilot disconnects, whose hands are on the controls?
2. Peter Naur answered this in 1985, in Programming as Theory Building. The real product of programming, he argued, is not the text but the theory in the programmers' heads: how the program maps onto the world, why each part is the way it is, and how it should change. When the people who hold the theory leave, the program is effectively dead, even if every line survives. AI now produces text without theory. So the developer must still own the theory, and the support engineer's four questions are its test: what happens here, what does it depend on, why was it designed this way, and what do we check next? A randomized experiment Anthropic published in January 2026 points the same way. Engineers learning a new library with AI help scored 50% on a comprehension quiz, against 67% for those who coded by hand, and the widest gap was in debugging. Those who asked the AI to explain did better than those who let it write. Ask yourself: could the author of this feature answer the support engineer's four questions without the AI?
Sources: FAA, SAFO 13002, Manual Flight Operations (2013); L. Bainbridge, "Ironies of Automation", Automatica 19(6), 1983; P. Naur, "Programming as Theory Building", 1985; J. H. Shen and A. Tamkin (Anthropic), "How AI assistance impacts the formation of coding skills", January 2026.
From the mentor's corpus
1. The mentor's doctrine for intelligence officers answers the first question with a drill. Officers who train only with perfect AI will over-trust it; officers trained with degraded AI develop calibrated trust and override discipline. Its exercise is a three-pass simulation: full AI support, then none, then AI with injected errors, with performance compared across the three. Apply it to this team once a month on a real past incident: solve it with the AI, then without it, then with an AI fed a subtle bug, and see who catches it. The mentor's own case in chapter 18 names the principle: learning by losing where losing is cheap. A drill is where losing is cheap; a customer waiting on the phone is where it is not. For universities, the mentor's training progression starts novices at the two lowest HAI5 levels. There the AI is a tool that sorts and flags, and no decision is delegated, so that independent capacity grows before the AI becomes a teammate. Ask yourself: where does my team lose: in a drill, or in front of a customer?
2. The mentor updated West Point's Thayer Method for the AI era, and it answers the second question. Thayer's cadets worked problems alone, wrote their solutions on the board and briefed them to the class. In the mentor's HAI5 version, students may solve the problem with AI, but they submit their AI conversation. In class they must explain why the solution is correct, and when and how they used the AI; they cannot just cite it. The first of the method's three pillars is domain expertise deep enough to validate and explain what the AI produced. That is the line for a developer: the AI may write the code, but the developer must be able to brief it. The mentor's task-to-agent protocol then sorts the work:
Ask yourself: if I had to brief this feature at the board tomorrow, without the AI, could I?
On the NEO Turn. When the AI changes the codebase, runs the tests and deploys, the question is the case's own: who can recognise its mistake? The mentor's answer runs through all his work: the agent acts only inside a fence, and every action leaves a record. In chapter 18 the firm's agent could read and propose, but it could not sign, could not write in her books and could not leave its fence. Every step left a receipt. For a coding agent, the fence is a declared HAI5 level for each kind of change. The receipt says what was changed, which tests it passed and who approved the deploy. The monthly drill keeps the approver able to read that receipt. An approver who cannot explain a change is not supervising it, only signing it.
Sources: the mentor's doctrine Vanguard Intelligence: A Doctrine for NEO Era Decision Superiority, chapter 5 (degraded-mode training, the three-pass simulation) and chapter 6 (the HAI5 training progression); the mentor's HAI5 case (the Thayer Method for the AI era); the Vanguard Task-to-Agent Mapping Protocol; chapter 18 of this book.
The mentor's first volume names this case's two failure modes before it offers a way between them. Over-reliance on AI means accepting its outputs without human judgment and missing the context it cannot see; the result, in his words, is effective execution of the wrong strategy. Under-utilisation means refusing AI for fear of losing control, and losing tempo. His line between them is short: AI for operations, humans for judgment. The incident shows where this team crossed it. Writing the code was operations. Its theory, the answer to "why was it designed this way?", was judgment, and it went to the machine with the code.
Toyota drew the same line in 2014. In its oldest plant, the world's largest carmaker gave a corner back to people: workers hammered glowing metal into crankshafts by hand instead of by the usual automated process. Mitsuru Kawai, a half-century veteran whom Akio Toyoda had asked to promote craftsmanship, explained why: when he was a novice, experienced masters were called gods, and they could make anything. About a hundred manual workspaces opened across Toyota's plants in Japan. What people learned there went back into the machines: the crankshaft line became 96 percent shorter than three years earlier, and about a tenth of the material waste went. Kawai's reason is this case's answer: "To be the master of the machine, you have to have the knowledge and the skills to teach the machine."
For a team of fourteen, one such corner is enough:
The price is a few days a quarter. What it buys is speed that survives the next incident.
For the university, the same corner: build with AI, and each semester build one thing by hand that the student then teaches back to the class.
Ask yourself: who in my team could still teach the machine?
Sources: Vanguard Leadership, vol. 1, the chapter on AI as a force multiplier (the two failure modes; AI for operations, humans for judgment) and the Shokunin chapter (mastery includes the obligation to teach); C. Trudell, Y. Hagiwara and J. Ma, "'Gods' Make Comeback at Toyota as Humans Steal Jobs From Robots", Bloomberg, 7 April 2014.
A question for the table, a disagreement, what you would have done. The case lead reads every comment; the ones the table takes up enter the chapter as questions from the room, with your name.