At 10 on a Tuesday night, I asked Claude how we could structure the intents for a local, LLM-powered AIDE I’m building. I was creating this thing from scratch and hadn’t the faintest clue about best practices for AIDEs, and googling would take hours, and anyway Claude is faster. About three minutes later, Claude’s Fable 5 model had surfaced a few options, talked through the tradeoffs I requested, and asked if it could continue writing them into the codebase, which I pushed back on with a few points before approving. While reviewing the code, a few thoughts popped into my head: am I actually developing this code, can I take ownership of the output, what’s my job here apart from just thoughtful prompting, is this what development now looks like?
Then I realized I was the prince.
The king is dead
You, the clueless prince, have been promoted to the throne, wide-eyed and out of your depth after spending a lifetime mastering one part of the estate. You’re now expected to govern roadworks and forestry and agriculture and defence, none of which you understand, and also you start Monday. The one mercy is your council: wizened old advisors who know how everything works, who follow you into every meeting and surface decisions and lay out tradeoffs and carry out whatever you choose, spawning their own deputies the way a chancellor might dispatch surveyors. Claude, Codex, Kimi, DeepSeek: all very good counsel, very cheap, very available at 10 on a Tuesday night.
Old/new
The old kingdom hired farmers for specific crops. You wanted a Python backend engineer, so you tested for Python backend engineering, and the farmer you hired knew tomato farming to the roots but nothing about those weird React crops one field over, because tomatoes were their entire career. Depth paid; breadth often looked unfocused at promotion time. Most people optimised against that system for decades, and while plenty of good engineers became architects, integrators, teachers, product builders, and curious generalists, many others never had much reason to venture beyond the farm. They didn’t read much outside their domain, or attend conferences or build their own products or teach the work to anyone else. Passive osmosis was a rational career strategy. It no longer is.
New tools have arrived that can plant and harvest faster than any farmer and cover more ground. Value has moved up the chain to those who can orchestrate farming, who understand the land and market and competition and available tools, and who can deftly delegate the work to those tools. The new paradigm tests for statecraft, for whether you can pick up a new domain at speed, judge counsel you couldn’t have produced yourself, and build sensors to catch rot your advisors can’t see or surface.
True, many experienced engineers already functioned as architects and integrators. LLMs didn’t invent the need for systems thinking. They just widened the execution bottleneck so dramatically that steering is now almost the whole job.
Judgement
Statecraft is harder than planting tomatoes, and the new paradigm expects fast progress. The prince starts clueless, and cluelessness is forgivable for a season, but remaining so is abdication.
You still need to know enough to be dangerous, enough to read the code and know what good looks like, because “go build me an app” without inspecting the result is risky. You can no longer rely on generative knowledge alone (“I can produce code”) but now need evaluative knowledge (“I can tell good architecture from bad”). You need the palate of an editor who’s never written a novel, and every computer science curriculum we have today teaches the novel first and hopes for taste later. The order has inverted and we still haven’t caught up.
Which raises an awkward question: how do we mint new princes? Can you develop taste without prior generative knowledge? An editor who’s never written a novel may still learn taste from deep reading and analysis, but programming taste often comes from having built and debugged systems. The current orchestrator class learned to govern by farming. If we skip the tomato-farming phase entirely, do we end up with rulers who can’t tell when the council is feeding them beautiful, confident nonsense?
My hunch is we’ll do what aviation did. When the Wright brothers moved from bicycles to planes, we didn’t ask trainee pilots to prove they could pedal fast enough in the sky; we built flying schools that taught the new skill directly, with instruments and instructors and hundreds of supervised hours, and the pilot population grew. Early pilots learned to throttle and pitch and roll, which were new skills with no bicycle equivalent. We’re still building the flying schools for evaluation in development.
Failure modes
My council pushes back on me, usually gently, but sometimes they validate my poor instincts so fluently I only catch the problem ten runs later when something misbehaves. A human council features ambition and rivalry and vanity, advisors with their own interests who’ll fight you in the chamber. That friction makes counsel useful, but my AI council carries none of it. Its flattery behaves like a mirror, and a mirror can’t warn you about what’s coming.
Which brings me to the two ways kingdoms die. Invasion happens slowly and visibly, and you may still have time to put pikes in the fields and archers on the walls and cannons in the crenellations. Rot gives you no such notice. Consider how junior devs used to learn: with free, fast, and brutal feedback. Your code didn’t compile, the crop failed, the client fired you in month two. But fluent advisors combined with your own cluelessness suppress those older signals, so the danger is no longer bad code but a bad mental model, which is harder to spot and correct in time, leading to 18 months of slow decay as your codebase rots and racks up technical debt.
I nearly found out the hard way. Had I not built TraceAct, my observability package, it would have taken me longer to know one project was wasting 97% of its token use during web searches, each agent fetching full pages and discarding everything but a sliver per turn. My orange advisor and I corrected it with cheaper searches pooled across all agents, plus deterministic page extraction, which cut overall search token spend by 55%. I built instrumentation before I needed it because I knew I was running blind. If you govern entirely through advisors, you put yourself at risk.
Hiring
The market, meanwhile, is still hiring farmers. Live coding rounds, whiteboard soil analysis, instruments finely tuned to a newly cheap ability, with no good tests yet for statecraft. You walk them through a fully functional farm with a complete understanding of how the whole thing runs, and they want to know whether you personally planted the 34th tomato in the third patch, even though your advisors exist for that reason and are standing next to you. One of them is even usually on the call. It’d be amusing if it wasn’t so bewildering.
In five years it’ll seem odd to test for planting at all, the way it now seems odd to test mathematicians on long division when calculators are good and fast and cheap. I’d been watching The Man Who Knew Infinity, which has a scene where Ramanujan, taking no notes in a Cambridge lecture, walks up to the board, completes the proof, and admits he doesn’t know how he knew it; he just knew.
The professor gets mad, but the professor has a point. The film’s arc bends toward Hardy teaching Ramanujan rigor and provenance, grounding output in proof. AI makes everyone look like a magician, but can you show the trick in slow motion if asked? Most vibe coders can’t, and employers can tell, and they’re trying to distinguish recently promoted princes from royals who can plan, maintain, debug, and evolve systems they didn’t write, who’ve shipped working systems they can explain. Live coding is a cheap proxy for whether you can read code under pressure and reason about it out loud.
The better interview looks something like this: candidates get an AI-built system and have to find the hidden defects, challenge the architecture, improve observability (or cut logging noise), diagnose a failed run, outline security and cost risks, absorb a requirements change midway, and defend what they accepted and rejected from the model. Princes are never off the hook no matter how many advisors they keep.
The market will catch up eventually, the way it caught up to calculators and looms and cars, and the interviews will change shape. Until then, the council convenes at 10 on a Tuesday night, and it never keeps you waiting.