Addy Osmani, a long-time Chrome team engineer and author of Beyond Vibe Coding, argues that vibe coding and AI-assisted engineering are fundamentally different disciplines, and conflating them risks devaluing the rigor required to build production-ready software.
Vibe coding means fully surrendering to creative flow with an AI: high-level prompting, accepting suggestions without deep review, and prioritizing speed and exploration over correctness and maintainability. It’s useful for prototypes, MVPs, and learning, but not for production systems.
AI-assisted engineering treats AI as a powerful collaborator across the full software development lifecycle—boilerplate, debugging, deployment—but the human engineer remains in control, responsible for architecture, code review, and ensuring security, scalability, and maintainability.
The key distinction: in AI-assisted engineering, the human is on the hook for quality; in vibe coding, they are not.
How Addy personally uses AI tools
He focuses on spec-driven development: writing clear requirements and expectations before prompting, which gives the LLM much better direction than open-ended vibing.
He uses tests as a de-risking mechanism—keeping the project green makes it clearer when the LLM goes off rails and what broke.
He leverages Chrome DevTools MCP to give LLMs “eyes” on the browser, improving feedback loops by letting the model see rendering issues, console errors, and warnings rather than relying on blind text prompts.
He still vibe codes for personal tools and throwaway prototypes, and finds it powerful for sharing ideas interactively (e.g., showing a working prototype in a PR instead of a static mock).
He emphasizes that proficiency with these tools takes time and intentional experimentation, and encourages teams to share learnings to build a culture of psychological safety during this period of rapid change.
The 70% Problem
LLMs can produce roughly 70% of a working application quickly, but struggle with the last 30%—the “last mile” that includes edge cases, security, maintainability, and correctness.
Common failure patterns in that last 30% include:
Two steps back pattern: one prompt causes the LLM to completely rewrite or derail what was already built.
Hidden maintainability costs: vague prompts delegate architectural decisions to the LLM, producing convoluted or fragile code.
Security vulnerabilities: XSS, leaked API keys, and other issues arise when engineers don’t think holistically about the problem.
Experienced engineers can close the last 30% gap effectively; juniors and new grads often get stuck in re-prompting loops without the debugging skills or system understanding to recover.
A vibe-coded prototype should be rewritten with production quality in mind before entering a shared codebase.
Tactics for effective LLM usage
Break tasks into small, verifiable chunks rather than throwing all requirements at once—similar to sprint planning or writing pseudocode. This reduces context loss and compounding errors.
Understand model constraints: finite context windows, training data limitations (often lowest-common-denominator patterns from GitHub), and non-deterministic outputs. Set expectations accordingly.
Read through the model’s thinking log before approving changes—Addy makes this a habit to understand what decisions the LLM made and why, so he can maintain and debug the code later.
Be intentional about not using AI for everything: Addy deliberately reserves 20–30% of tasks for solving without AI to preserve critical thinking skills.
New workflows enabled by AI
Asynchronous background coding agents: delegating parts of the backlog to agents that work concurrently (e.g., updating tests, migrating dependencies). Tools like Claude Code, Gemini CLI, and GitHub’s agent experiments are exploring this.
The open question is the management surface: how many parallel agents can one engineer realistically oversee with proper human review? Most engineers will only handle a few at a time.
Vibe designing: designers using tools like Cursor to turn Figma designs into interactive prototypes. Shopify designers, for example, use Cursor to implement Figma specs and share semi-functional prototypes with engineers.
Trio programming: a potential new mentorship model pairing a junior, a senior, and an AI—where the senior uses the AI’s output as a teaching tool to explain system architecture and code connections.
Forward-deployed engineers: developers embedded with customers who build features rapidly with AI while feeding back requirements, blurring traditional PM/designer/developer boundaries.
The evolving roles of PMs and EMs
PMs may shift toward problem framing, metrics, and defining policies and guardrails for agents.
EMs may spend more time on evals, safety reviews, and enabling teams to work confidently with AI.
Taste in product engineering becomes a key differentiator: if anyone can prompt similar functionality, judgment about what to build and why becomes more valuable.
Seniors become more valuable, not less—their ability to write specs, decompose work, understand architecture, and review effectively lets them leverage AI as a force multiplier. Juniors move faster but still need mentorship to handle the last 30%.
Code review in the age of AI
Human review is becoming the bottleneck: AI increases PR velocity, but someone has to review. Some teams are tempted to use LLMs for code review too, creating a risky loop where AI writes and AI reviews without deep human understanding.
Addy treats AI review signals (or a junior’s LGTM) as one signal among many, not a substitute for human judgment—especially for critical code.
There’s a real risk of eroding criticality: as engineers trust AI more, they may accept suggestions less critically over time. Deliberately practicing without AI helps counteract this.
AI as a learning tool
LLMs are powerful for onboarding: new joiners can ask questions about a codebase 24/7, getting explanations of structure and connections without interrupting senior engineers.
Companies are reporting faster onboarding when new hires use AI tools to explore and understand codebases.
AI is also useful for cross-language/cross-codebase work: helping engineers understand patterns in one system and port them to another.
Claude Code’s learning mode pauses and asks the user to complete a part of the task—a clever mechanism for maintaining hands-on understanding.
What makes a standout engineer in the AI era
Lifelong learning and growth mindset remain the most consistent predictors of success. Engineers who experiment openly with new models, tools, and workflows—and are fine when things don’t work out—adapt fastest.
Staying technically current as a leader matters: Addy writes a weekly internal newsletter surfacing important AI developments, papers, and tools, helping his team cut through the noise.
Giving permission to experiment: teams that allocate time for exploration (even if some attempts “fail”) end up more confident about what works and what doesn’t, and more motivated overall.
Enterprise teams don’t need to wait for official company approval to start learning—side projects and personal experimentation with third-party tools keep skills sharp.
Rapid-fire favorites
Favorite programming language: JavaScript—not because it’s technically the best, but because it’s the most open and liberating, letting anyone on the planet build and ship to the web without gatekeepers.
Favorite tool: Bolt.new (by StackBlitz)—a vibe-coding scaffolding tool that now supports custom agents (e.g., Claude Code) and is improving its integration layer for auth, databases, and deployment.
Book recommendation: The Software Engineer’s Guidebook by the podcast host, and AI Engineering by Chip Huyen for foundational AI engineering concepts.
