No serious developer still expects AI to magically do their work for them. We’ve settled into a more pragmatic, albeit still slightly uncomfortable, consensus: AI makes a great intern, not a replacement for a senior developer. And yet, if this is true, the corollary is also true: If AI is the intern, that makes you the manager.

Unfortunately, most developers aren’t great managers.

We see this every day in how developers interact with tools like GitHub Copilot, Cursor, or ChatGPT. We toss around vague, half-baked instructions like “make the button blue” or “fix the database connection” and then act surprised when the AI hallucinates a library that has not existed since 2019 or refactors a critical authentication flow into an open security vulnerability. We blame the model. We say it is not smart enough yet.

But the problem usually is not the model’s intelligence. The problem is our lack of clarity. To get value out of these tools, we do not need better prompt engineering tricks. We need better specifications. We need to treat AI interaction less like a magic spell and more like a formal delegation process.

We need to be better managers, in other words.

The missing skill: Specification

Google Engineering Manager Addy Osmani recently published a masterclass on this exact topic, titled simply “How to write a good spec for AI agents.” It is one of the most practical blueprints I have seen for doing the job of AI manager well, and it’s a great extension on some core principles I laid out recently.

Osmani is not trying to sell you on the sci-fi future of autonomous coding. He is trying to keep your agent from wandering, forgetting, or drowning in context. His core point is simple but profound: Throwing a massive, monolithic spec at an agent often fails because context windows and the model’s attention budget get in the way.

The solution is what he calls “smart specs.” These are written to be useful to the agent, durable across sessions, and structured so the model can follow what matters most.

This is the missing skill in most “AI will 10x developers” discourse. The leverage does not come from the model. The leverage comes from the human who can translate intent into constraints and then translate output into working software. Generative AI raises the premium on being a senior engineer. It does not lower it.

From prompts to product management

If you have ever mentored a junior developer, you already know how this works. You do not simply say “Build authentication.” You lay out all the specifics: “Use OAuth, support Google and GitHub, keep session state server-side, do not touch payments, write integration tests, and document the endpoints.” You provide examples. You call out landmines. You insist on a small pull request so you can check their work.

Osmani is translating that same management discipline into an agent workflow. He suggests starting with a high-level vision, letting the model expand it into a fuller spec, and then editing that spec until it becomes the shared source of truth.

This “spec-first” approach is quickly becoming mainstream, moving from blog posts to tools. GitHub’s AI team has been advocating spec-driven development and released Spec Kit to gate agent work behind a spec, a plan, and tasks. JetBrains makes the same argument, suggesting that you need review checkpoints before the agent starts making code changes.

Even Thoughtworks’ Birgitta Böckeler has weighed in, asking an uncomfortable question that many teams are quietly dodging. She notes that spec-driven demos tend to assume the developer will do a bunch of requirements analysis work, even when the problem is unclear or large enough that product and stakeholder processes normally dominate.

Translation: If your organization already struggles to communicate requirements to humans, agents will not save you. They will amplify the confusion, just at a higher token rate.

A spec template that actually works

A good AI spec is not a request for comments (RFC). It is a tool that makes drift expensive and correctness cheap. Osmani’s recommendation is to start with a concise product brief, let the agent draft a more detailed spec, and then correct it into a living reference you can reuse across sessions. This is great, but the real value stems from the specific components you include. Based on Osmani’s work and my own observations of successful teams, a functional AI spec needs to include a few non-negotiable elements.

First, you need objectives and non-goals. It is not enough to write a paragraph for the goal. You must list what is explicitly out of scope. Non-goals prevent accidental rewrites and “helpful” scope creep where the AI decides to refactor your entire CSS framework while fixing a typo.

Second, you need context the model won’t infer. This includes architecture constraints, domain rules, security requirements, and integration points. If it matters to the business logic, you have to say it. The AI cannot guess your compliance boundaries.

Third, and perhaps most importantly, you need boundaries. You need explicit “do not touch” lists. These are the guardrails that keep the intern from deleting the production database config, committing secrets, or modifying legacy vendor directories that hold the system together.

Finally, you need acceptance criteria. What does “done” mean? This should be expressed in checks: tests, invariants, and a couple of edge cases that tend to get missed. If you are thinking that this sounds like good engineering (or even good management), you’re right. It is. We are rediscovering the discipline we had been letting slide, dressed up in new tools.

Context is a product, not a prompt

One reason developers get frustrated with agents is that we treat prompting like a one-shot activity, and it is not. It is closer to setting up a work environment. Osmani points out that large prompts often fail not only due to raw context limits but because models perform worse when you pile on too many instructions at once. Anthropic describes this same discipline as “context engineering.” You must structure background, instructions, constraints, tools, and required output so the model can reliably follow what matters most.

This shifts the developer’s job description to something like “context architects.” A developer’s value is not in knowing the syntax for a specific API call (the AI knows that better than we do), but rather in knowing which API call is relevant to the business problem and ensuring the AI knows it, too.

It is worth noting that Ethan Mollick’s post “On-boarding your AI intern” puts this in plain language. He says you have to learn where the intern is useful, where it is annoying, and where you should not delegate because the error rate is too costly. That is a fancy way of saying you need judgment. Which is another way of saying you need expertise.

The code ownership trap

There is a danger here, of course. If we offload the implementation to the AI and only focus on the spec, we risk losing touch with the reality of the software. Charity Majors, CTO of Honeycomb, has been sounding the alarm on this specific risk. She distinguishes between “code authorship” and “code ownership.” AI makes authorship cheap—near zero. But ownership (the ability to debug, maintain, and understand that code in production) is becoming expensive.

Majors argues that “when you overly rely on AI tools, when you supervise rather than doing, your own expertise decays rather rapidly.” This creates a paradox for the “developer as manager” model. To write a good spec, as Osmani advises, you need deep technical understanding. If you spend all your time writing specs and letting the AI write the code, you might slowly lose that deep technical understanding. The solution is likely a hybrid approach.

Developer Sankalp Shubham callsthis “driving in lower gears.” Shubham uses the analogy of a manual transmission car. For simple, boilerplate tasks, you can shift into a high gear and let the AI drive fast (high automation, low control). But for complex, novel problems, you need to downshift. You might write the pseudocode yourself. You might write the difficult algorithm by hand and ask the AI only to write the test cases.

You remain the driver. The AI is the engine, not the chauffeur.

The future is spec-driven

The irony in all this is that many developers chose their career specifically to avoid being managers. They like code because it is deterministic. Computers do what they are told (mostly). Humans (and by extension, interns) are messy, ambiguous, and require guidance.

Now, developers’ primary tool has become messy and ambiguous.

To succeed in this new environment, developers need to develop soft skills that are actually quite hard. You need to learn how to articulate a vision clearly. You need to learn how to break complex problems into isolated, modular tasks that an AI can handle without losing context. The developers who thrive in this era won’t necessarily be the ones who can type the fastest or memorize the most standard libraries. They will be the ones who can translate business requirements into technical constraints so clearly that even a stochastic parrot cannot mess it up.