What Real AI for Normal People Looks Like
If a chatbot is not an AI strategy, what is? Real AI for ordinary business users helps with messy daily work, not jus...
Children of the Magenta Line
9 min read
When the Code Looks Right and Still Kills the Company and Your Job
25.05.2026, By Stephan Schwab
Every few months a new executive announces that coding has been solved. The model writes the code. The team just supervises. The savings will be enormous. Aviation made the same mistake thirty years ago and gave it a name: children of the magenta line. Trained pilots learned to obey the autopilot's pink track on the navigation display instead of flying the aircraft. Some of them followed that line into a mountain. AI-assisted development is repeating the pattern at speed, and the people loudest about the gains are the least likely to notice when the line points the wrong way.
Where the Magenta Line Came From
"Automation does not remove judgment. It hides where judgment is still required."
In the mid-1990s, American Airlines training captain Warren Vanderburgh recorded a now-famous internal lecture titled “Children of the Magenta Line.” He had watched a generation of pilots grow up on glass cockpits and flight management computers. The autopilot drew a magenta course line on the navigation display. The crew’s job, increasingly, was to keep the aircraft on that line and to trust whatever the box said.
His warning was simple. The line is a tool. The aircraft is still being flown by humans. When the situation gets weird, the right move is often to drop down a level of automation, take manual control, and fly. Pilots who could not bring themselves to do that — who kept asking the computer why it was doing what it was doing while the runway slid past — were the ones in trouble.
The lecture was not anti-automation. It was anti-passivity. Vanderburgh’s point was that the cockpit had quietly shifted from flying the aircraft to managing a system that flies the aircraft, and that the training, the habits, and the instincts had not caught up.
Substitute “AI coding assistant” for “flight management computer” and the lecture writes itself.
The Colombian Mountainside
"The crew did not crash because the computer failed. They crashed because they trusted it past the point where they should have flown."
The clearest case study is also the most uncomfortable. On December 20, 1995, American Airlines Flight 965 flew a perfectly functioning Boeing 757 into a mountain near Cali, Colombia. The captain was experienced. The first officer was competent. The aircraft was healthy. The weather at altitude was fine. I wrote about the human side of that accident in Following the Plan Into the Mountain.
What killed those 159 people was not a broken machine. It was a one-letter waypoint entry into the flight management computer, accepted without verification, that bent the magenta line away from the airport and toward terrain. The crew kept reasoning about the system instead of about where the aircraft was actually going. By the time the ground proximity warning screamed, the geometry was already unforgiving.
That is what trusting the line past the point of judgment looks like. It is not laziness. It is a trained reflex to defer to the box because the box is usually right.
AI coding tools are usually right too. That is exactly the problem.
The GPS-100 and the Checkride
"New automation rewards the people who keep verifying. It punishes the people who stop."
A small personal memory. Years ago, when civilian GPS navigation was new, I flew with a panel-mounted unit that was essentially a Garmin GPS-100 generation receiver. Tiny screen. Limited database. A miracle compared to what came before.
On a checkride, the examiner watched me set up the route. Before each waypoint, I cross-checked the latitude and longitude the unit displayed against the published coordinates on the chart. Not because I expected the GPS to lie. Because the cost of a wrong entry was a real diversion in a real airplane, and the cost of the check was ten seconds.
He noticed. He told me later that most candidates by then were already in the habit of typing in the identifier and trusting whatever came back. The new toy was so good, so fast, so confident, that the verification step had quietly evaporated.
That is the moment to watch for. Not when the tool is bad. When the tool is good enough that the human stops checking.
Coding Has Not Been Solved
"A model that writes plausible code has solved typing. It has not solved software."
“Coding has been solved” is a phrase that survives only as long as you keep “coding” small. If coding means “produce a function that compiles and roughly does the thing,” then yes, the models are very good and getting better. They have solved a slice of the job that used to take a junior developer an afternoon.
If coding means the whole act of developing software — naming the problem, modeling the domain, designing the boundaries, choosing what not to build, writing tests that pin down behavior, integrating with systems that lie about their contracts, shipping safely, observing what happens, and changing the design when reality pushes back — it has not been solved. It has been made faster in the parts that were already mechanical and more dangerous in the parts that were never mechanical to begin with.
The magenta-line analogy is exact. The autopilot did not solve flying. It solved holding a heading and an altitude with less workload, which freed the crew to do harder things: weather, traffic, fuel, contingencies, decisions. The crews that thrived used the saved attention for those harder things. The crews that drifted used it to disengage.
An AI coding assistant does not solve software development. It removes a chunk of clerical work and hands you back attention. What you do with that attention decides whether your codebase ends up better or quietly worse.
How “Children of the Magenta Line” Shows Up in a Codebase
"The warning sign is not bad code. It is code nobody on the team can defend."
The cockpit failure mode has a developer equivalent. You can spot it without a stopwatch.
- Pull requests where the author cannot explain a non-trivial block they accepted.
- Tests that exist because the assistant suggested them, not because they pin down a behavior anyone reasoned about.
- “Refactors” that move code around without changing what the system actually does or guarantees.
- Bug reports that get patched in three different places because nobody traced the cause, just asked the model for a fix.
- Architectural decisions framed as “the AI recommended” instead of as a trade-off the team chose.
- A creeping inability to say why a function is shaped the way it is, only that it passes.
Each of those is the same pattern: the magenta line is drawn and followed. Nobody is flying.
Dropping Down a Level
"The cure is not to turn the automation off. The cure is to stay current at the level below it."
Vanderburgh’s prescription was not to ban the autopilot. It was to make sure pilots could, at any moment, drop a level: from full automation, to selecting modes by hand, to flying raw data, to flying the airplane by feel. Each level was a fallback. Currency at the lower levels was what made the higher ones safe.
The same discipline applies to AI-assisted development. The cure is not to refuse the tools. It is to stay sharp at the levels below them.
- Read the diff you are about to commit. All of it. Out loud if needed.
- Write the test before the implementation often enough that you remember how. Tests are the developer’s raw data. I cover the agentic version in Tests Beat Instructions for AI Coding Agents.
- Keep a small change small. If the assistant offers a sweeping rewrite, decline and ask for the smallest step.
- When something feels off, drop the assistant. Open the file. Reason in your own head. If you cannot, that is the signal that you have lost altitude on the problem, not that the model needs a better prompt.
- Question the code through the agentic tool. Ask where a rule lives, which files parse pricing, what assumptions the change introduced, and whether the same decision appears in multiple places.
That last move matters. An experienced developer can read an agent’s answer and smell trouble before the incident exists. “I am parsing pricing here, here, and here” is not a harmless summary. It is a future crisis politely announcing itself. The right response is not a committee meeting. It is a sharp instruction: keep it DRY, centralize the pricing rule, add the test that proves it. The human is not competing with the agent. The human is interrogating the system through the agent before the magenta line quietly bends.
None of this slows down a strong developer. It is what strong developers were already doing.
What Leaders Should Actually Ask
"Do not ask how much faster the team is. Ask whether they can still hand-fly the system they are shipping."
If you are a CEO, CTO, or board member listening to someone explain that coding is now a commodity, a few questions cost nothing and save a lot.
-
Can the team explain, without the assistant, the last non-trivial change they shipped?
If the answer is a vague gesture toward a prompt history, you are looking at children of the magenta line.
-
What happens when the assistant is wrong and confident?
There needs to be a real answer. Tests that fail loudly. Developers who question the agent's answers. Observability that catches drift. If the only safety net is "the next prompt will fix it," the floor is further down than the slide deck suggests.
-
Where is the team practising the level below the tool?
Pairing, deliberate test-first work, code reading sessions, small refactors done by hand. Aviation calls this currency. Without it, the apparent productivity gains are borrowed against a future incident.
-
Who owns the design when the assistant disagrees?
If the answer is "we go with whatever the model produces because it is faster," design has left the building. The magenta line is now drawing itself.
The Useful Frame
Coding has not been solved. A slice of it has been automated, and the slice that remains is the one that always mattered most: judgement, design, verification, and the willingness to overrule a confident system when the geometry is wrong.
The crews who survived the glass cockpit transition were not the ones who used the automation least. They were the ones who refused to become passengers in their own aircraft. The developers and teams who will come out of the AI transition stronger are the same kind of people.
The magenta line is a tool. Somebody still has to fly.
Contact
Let's talk about your real situation. Want to accelerate delivery, remove technical blockers, or validate whether an idea deserves more investment? I listen to your context and give 1-2 practical recommendations. No pitch, no obligation. Confidential and direct.
Need help? Practical advice, no pitch.
Let's Work Together🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
The Code Review That Isn't a Review
Stefan opens three weeks of pull request history and finds approvals that arrived faster than anyone could have read the code. Daniel defends his r...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Children of the Magenta Line (25.05.2026)
- The Invisible Nature of Software (22.05.2026)
- AI Won't Run Your Company by Itself (18.05.2026)
- Quality Was the Point of Agile Coaching (15.05.2026)
- What Real AI for Normal People Looks Like (11.05.2026)