# Vibes won't cut it

Chris Kelly, Augment Code | AI Engineer World's Fair 2025 | 15:34

Source: https://www.youtube.com/watch?v=Dc3qOA9WOnE
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/vibes-wont-cut-it
Published: 2025-08-03
Tags: agents, coding-agents, context-engineering, reliability

## TL;DR
- AI-generated code still needs software engineers to understand, review, test, and run it safely in production.
- Production software depends on context and accumulated decisions that an LLM cannot recover from simple pattern matching.
- Teams can get better results from coding agents by giving them documented standards, reproducible environments, clear boundaries, defined tasks, and a plan-refine loop.

## Summary
Chris Kelly argues that vibe coding is unsuitable for production systems because software engineering includes far more than generating code. Engineers decide what software should do, choose packages and architectures, understand existing behavior, and change systems without causing outages or data problems. LLMs generate text and patterns, but large codebases contain years of decisions and unusual behavior that cannot always be inferred from patterns. Kelly expects software engineers to remain necessary, with AI changing their work in the same way cloud and DevOps changed earlier infrastructure roles. He recommends preparing codebases for AI with documented practices, reproducible environments, fast local tests, clear task boundaries, and well-defined work. Code review will matter more as agents write more code. His practical workflow is to create a plan in a document, use it as context, generate the implementation, then refine both the plan and code. Engineers should also distrust claims about what an LLM actually did and distinguish code that is wrong from code that is simply different.

## Key ideas
### AI-generated code does not remove the need for production engineers
[00:01](https://www.youtube.com/watch?v=Dc3qOA9WOnE&t=1s)
Kelly rejects the prediction that AI coding will eliminate software engineers. AI still produces code that must run in complex production systems, where failures can emerge from interactions between components rather than from one bad line. Someone still has to diagnose outages, understand system nuances, and fix problems. He compares this change with the move to cloud and DevOps work, saying administrators who once racked boxes and booted kernels moved into more valuable work rather than disappearing. His tractor comparison makes the same point: automation changes the work and removes some tasks, but it does not remove the need to farm.

### Vibe coding is different from writing production software
[03:03](https://www.youtube.com/watch?v=Dc3qOA9WOnE&t=183s)
Kelly defines vibe coding as letting the AI write and reason through the code without examining it, while checking only whether the result appears to do what the user wants. That approach does not fit software with four nines of availability, thousands of users, and gigabytes of data. Production code has many small decisions and hidden dependencies. A working demo can still fail when it meets real traffic, existing data, deployment constraints, or unusual system behavior. Kelly's point is that production work requires understanding those conditions, not simply accepting an AI-generated result.

### Software engineering is the safe changing of software
[06:43](https://www.youtube.com/watch?v=Dc3qOA9WOnE&t=403s)
Kelly describes his work as changing software safely, whether adding functionality or modifying existing code. The goal is to keep the system available, make sure users receive the expected behavior, and protect data. Engineers have traditionally handled this with their knowledge of the codebase, version control, tests, type systems, and deployment strategies. AI may help when it has enough context about the codebase, but that does not remove responsibility for production behavior. Context can improve generation, yet the engineer still has to decide whether a change is safe.

### LLMs generate patterns, while architectures require decisions
[05:30](https://www.youtube.com/watch?v=Dc3qOA9WOnE&t=330s)
Kelly compares building the same flight-booking system as a monolith, a microservices system, or an event-driven system. Each choice brings many decisions about structure, behavior, and trade-offs. He says LLMs generate text and patterns rather than making those decisions. Pattern matching also breaks down in older systems with local conventions and unusual behavior, where one person may be the only person who understands a particular part. When software fails at two in the morning, those details matter. A prompt that produces plausible code cannot replace diagnosis of a system's actual behavior.

### AI-ready codebases need the same working conditions as engineers
[09:17](https://www.youtube.com/watch?v=Dc3qOA9WOnE&t=557s)
Kelly recommends documented standards and practices so an agent knows which packages, conventions, and architectural direction to follow. Developer environments should be reproducible, and tests should be easy and fast to run locally. Work also needs clear boundaries. Asking an agent to extract a module using a vague architectural phrase gives it too much room to guess. Tasks should state what needs to be built and how it should fit the system. Kelly says these requirements sound like ordinary software engineering because the AI is doing the same code-writing job as an engineer.

### Code review becomes more important as agents write more code
[11:25](https://www.youtube.com/watch?v=Dc3qOA9WOnE&t=685s)
Kelly calls code review the most important skill for engineers working with coding agents. He argues that the industry may have focused too much on solving abstract coding exercises and too little on reading another person's code and explaining why it is good or bad. Existing review tools often present changed files in alphabetical order, which does not match the order in which a software change should be understood. As agents produce more code, engineers will need to inspect the change as a system and assess whether it is correct, safe, and appropriate for the codebase.

### Engineers must treat an LLM's explanation as generated text
[12:15](https://www.youtube.com/watch?v=Dc3qOA9WOnE&t=735s)
Kelly warns that an AI can sound like a person while behaving like a machine. He describes an interaction where an LLM said it had scanned a file rather than read it, using language that sounded like a human apology. The model had learned that phrasing from written examples, but that does not prove it performed the claimed action. Engineers should therefore distrust statements about what an LLM has done and inspect the actual output and process. The model is generating text, so its account of its own behavior can be inaccurate.

### A create-refine loop gives coding agents useful context
[14:14](https://www.youtube.com/watch?v=Dc3qOA9WOnE&t=854s)
Kelly recommends starting with a document that describes the plan. The LLM can help generate that plan, which the engineer saves as a Markdown file and includes in later context. The agent then creates the implementation from the plan. The engineer edits the plan and code, runs the work again, and repeats the loop. This approach makes the task more explicit and gives the agent stable context across iterations. Kelly also advises accepting code that is different from an engineer's personal style when it is functionally sound, since linters, rules files, and style guides can settle many formatting disagreements.

## Notable quotes
- "Code is not the job in the same way that blueprints are not the job of an architect." (03:58)
- "LLMs don't make decisions. They generate text. They generate patterns." (05:47)
- "AI talks like a human but is actually a machine." (12:15)
- "Know the difference of is the code better or is it just different?" (13:26)

## Tools & references mentioned
- Augment Code
- Stack Overflow
- Jeff Atwood
- Meta
- New Relic
- GitHub
- Salesforce
- FireHydrant
- DevOps
- Sonic 3.5

## Who should watch
- You are deciding how much autonomy to give coding agents in a production codebase and need a practical boundary between experimentation and safe change.
- Your team generates AI-written code but lacks consistent tests, documented conventions, or a review process that follows the behavior of a change.
- You want a workflow for using agents without requiring their code to match your personal style line by line.

## Related talks

- [No Vibes Allowed: Solving Hard Problems in Complex Codebases](https://aietalks.com/talks/no-vibes-allowed-solving-hard-problems-in-complex-codebases) (Dex Horthy, HumanLayer, 20:31)
- [Software Development Agents: What Works and What Doesn't](https://aietalks.com/talks/software-development-agents-what-works-and-what-doesnt) (Robert Brennan, OpenHands, 16:46)
- [From Vibe Coding To Vibe Engineering](https://aietalks.com/talks/from-vibe-coding-to-vibe-engineering) (Kitze, Sizzy, 25:28)
- [Developer Experience in the Age of AI Coding Agents](https://aietalks.com/talks/developer-experience-in-the-age-of-ai-coding-agents) (Max Kanat-Alexander, Capital One, 18:20)
- [Agentic Engineering: Working With AI, Not Just Using It](https://aietalks.com/talks/agentic-engineering-working-with-ai-not-just-using-it) (Brendan O'Leary, Kilo Code, 27:03)