A few months ago, I pointed an AI at some code I wrote years ago and asked it to tear it apart. Find the architectural problems. Tell me what I did wrong.
It did. And honestly? It stung a little.
Issues I’d overlooked as the codebase grew. Decisions that made sense at the time but aged poorly. Patterns that worked until they didn’t. The kind of stuff that accumulates when you’re heads-down shipping features and not stepping back to look at the big picture.
But here’s the thing… that experience taught me more about working with AI effectively than any YouTube tutorial or Reddit thread ever did.
The Feature That Sat on My To-Do List for Years
I had a feature request on one of my web apps that I’d been avoiding for years. It wasn’t that I couldn’t build it. It was just big. The kind of thing where every time I opened the request, I’d look at everything involved, lose motivation, and find something else to work on. Call it maintenance mode, call it procrastination, whatever.
When I finally tackled it, I used a combination of hand-crafted work and AI assistance. It only took a few days of real effort. By the end, I had a working feature set. I tested it multiple ways, thought through edge cases, tried to think like an average user would. I was ready to ship.
Then I did something that would have been impossible a couple years ago.
I tasked an agent to do a full code review. Not just “does this work,” but: act like a user, look for bugs, look for ways things could happen that we didn’t consider, and check how other modules we built years ago might interact with this poorly.
Nine minutes later, it came back with 16 issues I hadn’t thought of.
Sixteen. In nine minutes.
Some were edge cases I’d missed. Some were interactions with old code I’d forgotten about. Some were just things that a fresh set of eyes catches that you can’t see when you’ve been staring at the same code for days.
That’s not AI replacing me. That’s AI doing what a senior developer would do in a code review.
What Makes This Work
Here’s what that interaction wasn’t: me throwing code at an AI and hoping for magic.
By the time I asked for that review, I’d already done the architecture. I understood what the feature was supposed to do, how it fit into the existing system, and what the constraints were. I’d understood what we were trying to accomplish from an architectural standpoint and even written some of the code myself, with AI helping on implementation details. I knew what I was looking at.
When I prompted for the review, I gave it context. What the feature does. What modules it touches. What I was worried about. What I wanted it to look for specifically.
That’s the difference between agentic engineering and vibe coding. I’m not asking the AI to think for me. I’m asking it to extend my thinking. To catch what I miss. To be the second set of eyes I don’t otherwise have.
The Workflow
When I’m building something new, the pattern usually looks like this:
I start by getting clear on what I’m actually building. Requirements, constraints, how it fits into what already exists. This part is still all me. AI can’t tell you what your users need or how your business works.
Then I’ll often talk through the approach with an AI before writing code. Not “write this for me,” but “here’s what I’m thinking, what am I not considering?” Sometimes it catches stuff early. Sometimes it confirms I’m on the right track.
Here’s the thing though. Agentic engineering doesn’t require me to write every line of code. Sometimes I do, when the mood strikes or when it’s something nuanced. But often I’m architecting and directing while the AI writes. That’s actually one of its biggest strengths. It can hold context across an entire codebase and move insanely fast compared to a human brain. My job is to provide the direction, review the output, and make sure it actually fits what we’re building.
Once I have something working, that’s when the code review happens. Fresh context, specific instructions, let it find what I missed. This is where I get the most value.
Then I fix the issues, verify the fixes make sense, and ship.
The Part People Miss
Here’s something people seem forget when “crapping” all over AI. Bad code existed long before AI. Developers have been writing unmaintainable spaghetti, missing edge cases, and shipping bugs to production since the beginning of software. AI didn’t create that problem. It just moves faster, in whatever direction you point it.
Any developer who claims they can write code, self-review, and never have errors is full of it. We all have blind spots. We all miss things. The best teams have code reviews for a reason.
As a solo developer, I didn’t have that. I’d review my own code, convince myself it was fine, and ship it. Sometimes it was fine. Sometimes I’d find bugs in production that a second set of eyes would have caught in five minutes.
Now I have that second set of eyes. It’s not perfect. It misses things too. But it catches enough that the quality of what I ship has noticeably improved.
That’s what agentic engineering actually is. Not AI writing code for you. Not vibe coding your way to a product. It’s using AI as a collaborator, a reviewer, a tool that amplifies what you already bring to the table.
You still have to know what you’re building. You still have to evaluate the output. You still have to be the architect.
But you don’t have to do it alone anymore.
