For a brief moment, vibe coding was the perfect description of what was happening. You opened an AI coding assistant, described roughly what you wanted, accepted a few suggestions, ran the application and hoped for the best. When something broke, you pasted the error back into the chat. When the design felt wrong, you asked the AI to make it cleaner. When the implementation became complicated, you started a new conversation and tried again.
It felt fast. It felt creative. It felt almost magical. And it was genuinely useful. Vibe coding helped people understand that software creation was no longer limited by how quickly they could physically type code. It lowered the barrier between an idea and a working prototype, and it gave founders, product managers, designers and experienced engineers a new way to explore.
But vibe coding is not the future of serious software development. The next phase is instructor-led coding. The AI is not the orchestrator. You are.
The problem was never that AI wrote the code
There is nothing inherently wrong with AI generating a large percentage of an implementation. The question is not who typed the code. The question is who understood the problem, established the constraints, made the architectural decisions, recognized the risks and remained accountable for the result.
Vibe coding often treats the AI as if it were the owner of the problem: here is a rough idea, figure it out. Instructor-led coding changes the relationship. Here is the problem we are solving. Here is why it matters. Here is the environment the solution must operate in. Here are the decisions we have already made. Here are the things you must not break. Now help me implement the next step.
That difference looks subtle, but it changes everything. The AI moves from being an unpredictable generator to a highly capable member of a team. It can implement, test, research, refactor, document and challenge assumptions. But it still needs leadership.
Context is the new source code
The most important skill in AI-assisted development is no longer writing the cleverest prompt. It is establishing the right context. That includes the obvious technical context:
- The architecture, language and framework
- Existing patterns in the codebase and the data models
- Security boundaries and performance expectations
- Deployment environments and testing requirements
But it also includes the context engineers often leave out because it does not look like code: why the product exists, who the user is, which problem is actually being solved, what tradeoffs are acceptable, which previous attempts failed, what the organization can realistically maintain, which parts of the system are likely to change, and what done actually means.
An AI can produce a technically valid answer that is completely wrong for your product. It can build an elegant abstraction where a simple implementation would have been better. It can introduce a dependency that conflicts with your operating model. It can optimize for scale you will never need while ignoring the migration path you need next month. The answer may compile. That does not make it a good decision.
Your job is to create the environment in which the AI can make good decisions.
Rambling is actually useful
We spent years learning to make computer input concise. Search queries were short. Commands were precise. Tickets were reduced to acceptance criteria. Prompt engineering initially followed the same logic: find the shortest sequence of words that produces the correct response. That is often the wrong instinct when working with modern AI systems.
Sometimes you should ramble. Explain how you arrived at the problem. Explain the failed solution. Explain why one stakeholder is worried about delivery speed and another is worried about long-term maintenance. Explain the strange constraint that only exists because of a decision made three years ago. Talk through your assumptions. Correct yourself halfway through.
I initially thought we should create another service, but I am now concerned that this introduces an unnecessary operational boundary. The team already owns three deployment pipelines, and this capability probably changes together with the existing domain. Let us first evaluate whether it belongs inside the current service.
That rambling contains valuable information. It tells the AI not only what you are considering, but how you evaluate a decision. It reveals priorities, constraints and uncertainty. It gives the system a model of your thinking. The goal is not to fill the context window with noise — it is to externalize the knowledge that would otherwise stay trapped in your head. A five-line prompt describes the task. A five-minute explanation describes the world the task exists in. That world is where the correct solution lives.
Voice changes the economics of context
Typing all of that context is exhausting. Speaking it is not. This is why voice has become my primary input method for AI-assisted development. When I type, I naturally compress my thinking. I remove details, shorten sentences and skip context because writing it feels slow. When I speak, I explain.
I can describe the architecture, the user journey, the concern I have about a particular approach and the outcome I expect. I can walk through a pull request while looking at the code. I can explain why the first implementation is directionally correct but violates a boundary the AI did not understand. Voice lets the instruction happen at the speed of thought rather than the speed of typing.
That changes the role of the developer. Instead of spending most of the session manually producing syntax, I spend more time framing the problem, reviewing decisions, identifying missing context, challenging the implementation, redirecting the AI and validating the result. The work becomes less like operating a code-completion tool and more like leading a highly responsive engineering team.
My foot-pedal workflow
The single most useful hardware addition to this setup is the Elgato Stream Deck Pedal. It has three customizable pedals and runs through Elgato's Stream Deck software. Each pedal can trigger actions such as keyboard shortcuts, and profiles can be configured per application — which means it integrates with practically any IDE or AI coding environment that exposes commands through hotkeys.
Left pedal: push to talk
The left pedal activates my voice-input tool or toggles the microphone. Press the pedal, describe the problem, release when finished. This keeps the microphone from staying open and makes voice input feel intentional rather than intrusive. Depending on your voice tool, map it to a push-to-talk shortcut, start/stop dictation, a microphone capture toggle, or the start of a transcription session.
Center pedal: focus the AI assistant
The center pedal fires the keyboard shortcut that opens or focuses the IDE's AI chat, agent or command interface. Instead of reaching for the mouse, changing focus and clicking into the correct panel, you press the pedal and start instructing. The exact shortcut depends on the IDE. The principle does not.
Right pedal: submit or accept
The right pedal submits the instruction, accepts a proposed change, or triggers another frequently used command. It can just as easily be mapped to:
- Stop the current AI operation
- Open a diff
- Accept a completion
- Run tests or start a build
- Trigger a custom multi-action sequence
Inside the Stream Deck application you assign a System → Hotkey action to a pedal and record the same keyboard shortcut your IDE expects. Elgato profiles keep different pedal assignments for different tools, so the workflow changes automatically when you switch applications: the pedals can control AI interaction while the IDE is active, meeting controls while Zoom is active, and media or microphone controls everywhere else.
It sounds like a small ergonomic improvement. It is not. Removing the friction between seeing a problem and explaining it makes you much more likely to provide the full context. And context is the entire game.
You are the orchestrator
Instructor-led coding does not mean issuing one enormous prompt and disappearing. It is a loop:
- Establish the objective
- Provide the relevant context
- Ask the AI to propose an approach
- Inspect the reasoning and implementation
- Correct misunderstandings and add missing constraints
- Validate the result and decide what happens next
The AI may be operating multiple tools. One agent investigates the existing codebase. Another generates tests. Another evaluates security concerns. Another updates documentation. But the existence of multiple agents does not eliminate the need for an orchestrator — it makes orchestration more important.
Someone must understand how the pieces fit together. Someone must recognize when two locally reasonable decisions create a globally incoherent system. Someone must determine whether the proposed architecture solves the real business problem or merely produces an impressive diagram. That someone is still you. AI can increase the size and speed of your virtual team. It does not automatically provide that team with judgment.
Your 10,000 hours still matter
There is a dangerous interpretation of AI-assisted development that says experience no longer matters. I believe the opposite is happening. Your accumulated experience matters more, because AI gives your decisions significantly more leverage.
The 10,000 hours are not a literal stopwatch. They represent years of pattern recognition: the systems you have seen fail, the launches that looked good in a presentation and collapsed under real traffic, the abstractions that saved time and later slowed everyone down, the incidents that taught you why observability, deployment safety and ownership boundaries matter, and the products that succeeded because the team understood the customer rather than simply implementing the requirements.
AI has access to an enormous amount of information, but it does not automatically know which information matters most in your situation. Expertise lets you recognize when an answer is plausible but wrong. It lets you ask the follow-up question that changes the entire implementation. It lets you say: this will work technically, but it creates the wrong ownership model. Or: the implementation is correct, but the user experience will make the feature irrelevant. Or: this abstraction makes sense in isolation, but it contradicts where the rest of the platform is heading.
A beginner can use AI to generate more code. An expert can use AI to make better systems.
AI multiplies judgment
Think of AI as a multiplier. If the direction is weak, AI helps you move in the wrong direction faster. If the architecture is incoherent, AI produces more incoherent code in less time. If the requirements are poorly understood, AI rapidly builds the wrong product.
But when the direction is strong, the same multiplier becomes extraordinary. A senior engineer can explore several implementation paths before committing to one. An architect can validate assumptions against the actual codebase. A product-minded leader can move from customer problem to working experiment without waiting for every intermediate handoff. A team can produce tests and documentation as part of implementation rather than treating them as work that might happen later. The leverage comes from combining machine speed with human judgment. Neither is sufficient alone.
The new definition of hands-on
Some leaders worry that using AI makes them less hands-on. I see it differently. Being hands-on was never supposed to mean personally typing every line of code. It means staying close enough to the work to understand what is happening and influence the outcome.
With instructor-led coding you can be deeply involved in architecture, product behavior, data design, API boundaries, implementation quality, operational readiness, testing strategy and documentation. You may not manually write every function, but you are still making the decisions that determine whether those functions belong in the system.
This is especially powerful for people who operate across product, engineering and architecture. You no longer need to choose between staying strategic and getting close to the implementation. Describe the business objective. Inspect the generated data model. Question the API boundary. Run the implementation. Review the user experience. Return to the architecture. That is not less hands-on. It is hands-on at a higher level of leverage.
The goal is not lower quality
The goal of instructor-led coding is not to ship disposable software faster. It is to ship the same quality — or better quality — in less time. AI should not become an excuse to remove engineering discipline. It should make that discipline cheaper to apply.
Tests can be generated alongside the implementation. Documentation can be updated while the decisions are still fresh. Alternative approaches can be evaluated before the team commits. Security and performance questions can be raised before code reaches production. Repetitive implementation work happens quickly, leaving more human attention for the decisions that actually require it.
The standard should not change. The system must still be understandable. The code must still be reviewable. The product must still solve a real problem. The architecture must still be operable. The team must still own the outcome. The difference is how quickly we can get there.
Time to market becomes a creative advantage
Reducing time to market is usually described as a business advantage. It is more than that — it is a creative advantage. When the cost of turning an idea into a working system decreases, you can explore ideas that previously would not have survived prioritization.
You can test a product assumption before spending months debating it. You can build internal tools that were always valuable but never valuable enough to justify a dedicated team. You can create highly specialized experiences for smaller groups of users. You can replace presentations about what might work with software people can actually use.
Instructor-led coding does not simply help us recreate today's products faster. It allows experienced builders to shape new products, workflows and services that would previously have been too expensive or slow to attempt. The same engineering quality. The same architectural responsibility. The same product judgment. But dramatically less distance between an idea and reality.
Vibe coding was the prototype
Vibe coding showed us what was possible. It showed us that software could emerge from a conversation. It made building feel playful again. It encouraged experimentation and brought many more people into the process. But serious systems cannot be built on vibes alone. They require context. They require judgment. They require someone who understands where the system came from, where it needs to go and which tradeoffs are acceptable along the way.
The next generation of software will not be built by humans manually writing every line. It will not be built by autonomous AI systems operating without meaningful supervision either. It will be built by experienced people who know how to lead machines: people who can provide rich context, who can explain rather than merely prompt, who can use voice to turn years of accumulated knowledge into immediate direction, and who can orchestrate many forms of intelligence toward one coherent outcome.
AI still writes the code. But you set the direction. Welcome to instructor-led coding.