What 4,000 Hours of Vibe Coding Taught Me About Working with AI Agents

I've spent 4,000+ hours working with AI coding agents. Claude Code, Cursor, GitHub Copilot, Devin -- I've used them all extensively, in production, on real projects that real users depend on. Before that, I spent 10+ years as a tech lead at FAANG companies, building and shipping large-scale systems.

What follows are eight lessons that took me thousands of hours to learn. Some of them were obvious in hindsight. Others contradicted everything I believed about software engineering. All of them changed how I work.

Lesson 1: You're an Architect Now, Not a Coder

The first few hundred hours, I used AI agents the way most developers do -- as a faster way to write the code I already had in my head. I'd think through the implementation, then dictate it to the agent. It was slightly faster than typing, but nothing transformative.

The shift happened when I stopped thinking about implementation and started thinking exclusively about design. Instead of "write a function that does X," I started with "here's the system architecture, here are the interfaces, here are the constraints -- build the implementation."

The quality difference was dramatic. When I gave the agent architecture-level context and let it figure out the implementation details, it consistently produced better code than when I tried to micro-manage the implementation. The model has seen millions of implementations. It knows the patterns. What it needs from you is the higher-level direction: what are we building, why, and how does it fit together?

Your time is now worth more as an architect than as a typist. The sooner you internalize this, the faster you'll move.

Lesson 2: You're a Reviewer More Than a Writer

In my FAANG days, I spent maybe 30% of my time on code review. Now it's closer to 60%. And that's the right ratio.

AI agents produce code at a rate that makes human writing speed irrelevant. The bottleneck is review -- making sure what was generated is correct, maintainable, secure, and aligned with the broader system design. The developers who are most productive with AI agents are the ones with the sharpest review skills: pattern recognition, spotting subtle bugs, understanding performance implications, knowing when something "works" but will cause problems at scale.

If you're spending more than 20% of your AI-assisted time writing code by hand, you're probably not delegating enough to the agent. And if you're spending less than 40% reviewing, you're probably not reviewing carefully enough.

Lesson 3: Think in Systems, Not Files

Most developers interact with AI agents at the file level. "Write this function." "Fix this component." "Add tests for this module." File-level thinking produces file-level results -- code that works in isolation but creates integration headaches.

The developers who get the most out of AI agents think in systems. They describe how components connect, what the data flow looks like end to end, where the failure modes are. They feed the agent a mental model of the entire system and let it figure out where individual files fit within that model.

Practically, this means your prompts should include system context, not just local context. Don't just tell the agent about the file it's editing. Tell it about the three services that call this code, the database schema that underlies it, and the error handling strategy your team has agreed on. The agent's output quality scales directly with the breadth of context you provide.

Lesson 4: Code Is Cheap, Decisions Are Expensive

This was the hardest lesson to internalize because it contradicts decades of software engineering wisdom. Code used to be expensive. Writing it took time, debugging it took more time, and rewriting it was something you desperately wanted to avoid.

With AI agents, code is nearly free. An implementation that would have taken a week can be produced in hours. This fundamentally changes how you should approach decisions.

When facing an architecture choice, don't debate it for two weeks. Build both options. Run them side by side. Compare actual results. The total investment is maybe three to four days to get empirical evidence, compared to two weeks of theoretical debate that still ends with uncertainty.

I've started what I call "architecture races" -- deliberately building competing implementations to test which approach works better for a given problem. It sounds wasteful by old-world standards. In practice, it saves time because you eliminate the wrong path quickly instead of discovering it months later.

Lesson 5: Context Is Everything

If I could boil 4,000 hours down to a single insight, it would be this: the difference between 1x and 10x productivity is the context you feed your agent.

Same model, same tools, same developer. Give it a vague prompt with no project context, and you get generic code that needs extensive rework. Give it detailed context about the project architecture, coding conventions, existing patterns, and specific requirements, and you get code that slots into your system on the first try.

I've measured this quantitatively across dozens of projects. Tasks where I invested 15-20 minutes in context preparation had an 85% first-pass acceptance rate. Tasks where I jumped straight to prompting had a 30% first-pass acceptance rate. That 15 minutes of context prep saves hours of back-and-forth.

Context isn't just "what the code should do." It's why it should do it, what else exists in the system, what patterns to follow, what mistakes to avoid, and how the output will be validated. The more you tell the agent, the less you'll need to fix.

Lesson 6: Design User Stories and Situation Matrices

This is the secret weapon that most developers don't use, and it consistently produces the biggest quality improvements I've seen.

A situation matrix is a structured table that maps user types against scenarios against expected behaviors. For example, a login feature might have a matrix with user types (new user, returning user, admin, suspended user) across the top and scenarios (correct password, wrong password, expired session, two-factor auth) down the side. Each cell describes the expected behavior.

When you feed a situation matrix to an AI agent along with a feature request, three things happen. First, the agent generates more complete code that handles edge cases. Second, the agent can self-validate by checking its output against the matrix. Third, you have a built-in test plan -- every cell in the matrix becomes a test case.

I started using situation matrices about 1,500 hours into my vibe coding journey, and they immediately cut my rework rate in half. Before the matrix, agents would build the happy path and miss edge cases. After the matrix, they handle the edge cases proactively because the expected behavior is explicitly defined.

If you adopt only one practice from this entire post, make it this one.

Lesson 7: Your CI/CD Pipeline Is Your Co-Pilot's Co-Pilot

AI agents hallucinate. They invent APIs that don't exist. They use deprecated patterns. They misremember library versions. This is not a bug in any particular model -- it's a fundamental property of how large language models work.

After the first few hundred hours, I stopped trying to prevent hallucinations and started building systems to catch them automatically. The single highest-ROI investment you can make in AI-assisted development is a comprehensive CI/CD pipeline.

My standard setup for AI-assisted projects includes type checking (catches hallucinated function signatures and nonexistent types), linting (catches style violations and deprecated patterns), unit tests that run on every change, integration tests that validate cross-service boundaries, and a build verification step that ensures the app actually compiles and starts.

This pipeline catches roughly 80% of agent-introduced issues without any human intervention. The remaining 20% are logic errors and subtle design issues that require human review -- which is exactly where you should be spending your review time.

Think of your pipeline as a filter. It handles the mechanical verification so you can focus on the judgment calls that actually require human intelligence.

Lesson 8: Living Documentation Is Non-Negotiable

Every AI coding agent has a mechanism for persistent project context. Claude Code has CLAUDE.md. Cursor has .cursorrules. GitHub Copilot has its workspace indexing. Whatever tool you use, this context mechanism is the single most important file in your project.

I treat my CLAUDE.md as a living document that gets updated with every significant decision. It contains the project's architecture overview and key design decisions with rationale. It includes coding conventions that are specific to this project, not generic best practices. It documents known gotchas, things the agent has gotten wrong before or edge cases that require special handling. It has recent changes that affect how new code should be written. And it includes links to relevant context like API docs, design specs, and decision records.

Teams that maintain their context files religiously see measurably better output from their AI agents. Teams that write them once and forget about them get diminishing returns as the project evolves and the context file becomes stale.

I update mine at minimum once per sprint. After a major refactor or architectural change, I update it immediately. The five minutes it takes to update the context file saves hours of agent misdirection.

The Bigger Picture

Looking back at 4,000 hours, the through-line is this: the developers who will thrive in the age of AI agents aren't the best coders. They're the best at enabling AI agents.

The skills that matter now are architecture and system design (giving agents the right high-level direction), context management (making sure agents have the information they need), quality judgment (catching what automated checks miss), and decision-making (knowing when to build, when to pivot, and when to ship).

These are skills that take years to develop, which is why experienced engineers with strong architectural instincts are seeing the biggest productivity gains from AI agents. The tools amplify what you already know. If you know a lot, the amplification is enormous.

Four thousand hours taught me that AI agents aren't replacing engineers. They're revealing which engineering skills actually matter -- and they always mattered. We just couldn't see it clearly when we were spending all our time typing.