Managers Have Always Been Vibe Coders.
We Just Didn’t Have the Words for It.
There’s a phrase that’s taken over the AI world lately Vibe Coding. You describe what you want, you feel your way through the problem, and the machine does the actual typing.
But here’s the thing no one is saying out loud:
Managers have been doing this for decades.
The Manager Was Always the Prompter
Think about how a typical engineering manager operated at a software company. They didn’t write the code. They described the code. They sat across from a whiteboard and said things like: “We need a system that handles concurrent checkout flows without overselling inventory.” Then they walked away and trusted someone else to figure out the semaphores.
That is prompting. Just slower, and with a salary attached.
The best managers I’ve seen were not the ones who could still write the fastest code… they were the ones who could articulate a problem with just enough context that a skilled engineer could run with it. They knew when to say more and when to say less. They knew the difference between specifying the what and micromanaging the how.
Sound familiar?
Your Team Was Always a Model Lineup
Here’s where it gets interesting… and a little uncomfortable.
If you’ve managed engineers for any stretch of time, you’ve had this experience: you onboard two engineers with similar resumes, and within three months, the gap is enormous. One of them seems to think with you. They anticipate edge cases. They flag problems you hadn’t seen yet. They ship and you barely need to review.
The other one? Smart, technically capable, but you’re rewriting their PRs more than you’d like. Not because they’re bad… they’re just running on a slightly older model of how the world works.
Imagine Priya, a senior engineering manager at a fintech startup in Bengaluru. She manages eight engineers. She mentally categorizes them… not unkindly… into tiers. Two of them she sends the hairy, ambiguous problems to: “Figure out why our reconciliation is off by 0.03% on high-volume days.” Three others she gives well-scoped tickets to, but she knows to check their work on anything involving async flows. The remaining three are solid for UI and documentation.
Priya was running a heterogeneous model lineup long before anyone coined the term “multi-agent orchestration.”
What changed? Today, she could run that same lineup with AI agents… and she wouldn’t have to wait three months to figure out who’s who. The capability profile is in the model card.
The Onboarding Doc Was Always the System Prompt
Every engineering team has one. The sprawling Confluence page nobody fully reads. The CONTRIBUTING.md nobody updates. The Slack message your tech lead sends on Day 1: “We use tabs, not spaces… I don’t care what the internet says. Error messages go to our internal logger, never console.log. And if you touch the payments module without telling Arjun first, there will be consequences.”
That, friends, is a system prompt. That is a skills.md file written in Courier New and anxiety.
The good managers did something more deliberate. They maintained living documents… not just of coding standards, but of thinking standards. How do we approach a problem we’ve never seen before? What do we do when requirements are ambiguous? When do we escalate versus figure it out ourselves?
These were the engineers’ priors. Their RAG corpus. Their injected context.
Today, when you write an agents.md or a claude.md or drop a 3,000-token context block before your first message to a coding agent, you are doing the exact thing the best managers have always done: giving your collaborator just enough of the world-model you’re operating from so they don’t go off and solve the wrong problem brilliantly.
The Sprint Was Always Parallel Execution
Here’s a scenario. Rahul is a VP of Engineering at a Series B company. His team is preparing for a major platform migration. He breaks it down in his head… database layer, API contracts, frontend adaptor, CI pipeline changes, documentation. Five workstreams, loosely coupled, could mostly proceed in parallel if he staffed it right.
He pairs engineers, sets checkpoints, defines interfaces between the workstreams, and says: “Don’t wait for each other. Build to the contract. We’ll integrate on Thursday.”
Thursday comes. Some threads are done. One is stuck. One did something unexpected but better than what he asked for. He stitches it together, finds the seams, files some quick glue tickets, and by Friday they’re staging.
Rahul just ran a multi-agent pipeline. He was the orchestrator. He defined the task graph, managed dependencies, handled the merge conflicts of human output, and shipped.
The only difference now is that his Thursday standup might be with AI agents instead of humans. The cognitive work, the decomposition, the interface definition, the integration logic, the judgment call on “is this good enough to ship?” - that work doesn’t go away. That work is the job.
The GTM Was Always the Eval
Managers who’ve shipped software know this gut-sinking feeling: you’ve launched, the feature is live, and now you’re watching dashboards with a kind of fervent prayer that the metrics don’t surface something terrible.
You’re running an eval. You just called it “monitoring.”
When engineers talk about “evaluating” an LLM’s output in production, they mean: does the thing do what we want, does it break in ways we didn’t expect, and does it hold up under real-world load? That’s a post-launch review. That’s the war room call at 2 AM. That’s the P0 retrospective.
The difference is that in the agentic world, the feedback loop is faster. You can run evals in minutes, not sprints. You can catch a regression before the customer does, not after the NPS drops. But the instinct… observe it in the wild, trust but verify, never fully trust the happy path… that instinct was always the manager’s instinct.
The Only Thing That Was Gated Was Access
Here’s the part that should make you pause.
For most of software’s history, becoming a “manager of people” required time. You had to earn seniority. You had to prove you could mentor. You had to survive a few performance review cycles and a handful of organizational reorgs. Management was not a state you entered… it was a level you unlocked, and many talented engineers never wanted to unlock it.
Which meant that for years, the leverage of coordination of breaking a problem into parts, assigning them to the right people, integrating their output was reserved for a relatively small group of people.
That gate is gone.
Today, a sharp product manager with no engineering background can spin up a trio of AI coding agents, give them a spec, define their interfaces, and ship a functional MVP in a weekend. A solo developer can run an “org” of five specialized agents - one for backend, one for tests, one for documentation, one for security review and operate at a throughput that would have required a small team three years ago.
A 22-year-old fresh out of college, who has never managed a single human, is now a manager. They have an org. It listens to them. It ships for them. And if they’re good at articulating problems, defining scope, and reviewing output? They’ll outship teams that are ten times bigger.
The Old Joke Isn’t a Joke Anymore
There’s a thing managers have always said to their engineers, usually at the start of a sprint, often with a completely straight face: “Just make no mistakes.”
Engineers would laugh. Because it’s a ridiculous thing to say. Of course we want no mistakes. That’s not instruction, that’s a wish.
But then Andrej Karpathy dropped “vibe coding” into the discourse. And then came Claude’s system prompts. And then came Cursor rules files. And now there are engineers - real, senior, thoughtful engineers - literally typing into their agent context blocks:
“Do not make mistakes. Think step by step. If you are unsure, stop and ask.”
The circle is complete.
Managers have been vibe-prompting for decades. The output was just human, so we called it “leadership.” Now the output is code, so we call it “AI engineering.”
We Are All Managers Now
The mental model shift I’m proposing isn’t about technology. It’s about identity.
If you’re someone who can think clearly about a problem, break it into components, define what “done” looks like, and evaluate the output you can run an org now. The org just happens to be made of agents.
The skills that made great engineering managers great… clarity of thought, ruthless decomposition, the ability to write a brief that leaves no room for misinterpretation, the taste to know when something is good enough versus when it needs another pass… those skills are now the most valuable skills in the world.
Not because AI makes management obsolete.
Because AI made management accessible.
Welcome to your first day as a manager.
Your team is waiting.
What’s your experience been like, running your own “agent org”? I’d love to hear how you’ve been thinking about this shift… drop it in the comments.
