Agentic Engineering

Index

1. Introduction
2. The Shift Happened at Work
3. An Agentic Engineer Is Not a Vibe Coder
4. My Workflow Is Still the SDLC
5. The Tools I Use
6. Parallel Work Is the Real Multiplier
7. Fundamentals Still Matter
8. Where This Is Going
9. The Engineer Owns the Outcome

---

Introduction

Before Claude Code, most of my AI-assisted development happened inside Cursor. It was useful for inline changes and quick questions, but I still had to be there for every step.

Cursor felt like someone sitting beside me while I coded. Claude Code felt more like handing someone a task, explaining what I expected, and reviewing what came back.

That was uncomfortable at first. I didn’t know whether I could trust an agent working through the terminal on a real codebase. Repeated good results slowly changed my mind.

The Shift Happened at Work

After a vacation, VantaSoft put me on a new client and started using Claude Code. Work gave me the chance to use it consistently on real tasks instead of small experiments.

I could deliver sooner while still following the project’s standards. The terminal harness mattered as much as the model. I was giving the agent a goal inside a codebase with tools, context, tests, and a definition of done, not asking for an isolated snippet.

The same thing happened with side projects. I used agents on Quant, Find My Matcha, and smaller ideas with friends. I spent less time on repetitive setup and more time deciding what the product should be and how the system should work.

That is when I started calling this agentic engineering instead of coding with AI.

An Agentic Engineer Is Not a Vibe Coder

A vibe coder gives an agent an idea and hopes the result works. They may not understand the architecture, tradeoffs, or risks behind it.

An agentic engineer stays responsible for those decisions. They might not write every line, but they understand what should exist, how it should behave, and how the system will prove it works.

Control doesn’t mean watching every keystroke. I get it from clear context, reviewed plans, project instructions, tests, tools, and approval gates. A powerful agent without that process can still create a powerful mess.

My Workflow Is Still the SDLC

I start with the goal, constraints, and edge cases. Then I let the agent question my assumptions before I approve a plan.

Once the direction is clear, the agent implements it. Tests are part of the plan, not something added at the end. If a change breaks existing behavior, the failing test gives direct feedback and the agent can fix it.

I still review the result. No Mistakes checks the work against my original intent, runs validation, and surfaces decisions that need me. This keeps my attention on architecture, risk, and product behavior instead of every routine line.

The flow is familiar: plan, implement, test, review, and ship. Agents now perform more of those steps, but the software development lifecycle is still there.

The Tools I Use

No single tool runs my workflow. Each one has a job:

• GSD turns rough ideas into requirements and plans.
• AGENTS.md, CLAUDE.md, skills, and commands store repeatable project rules.
• Claude Code, Pi, Codex, and subagents handle focused exploration, implementation, and review.
• Code Review, Code Simplifier, and Ponytail catch mistakes and unnecessary complexity.
• Tests and agent-browser verify code and real user behavior.
• No Mistakes validates work before I merge it.
• GNHF handles longer unattended runs. Superpowers stays opt-in when I want its structured workflows.

I don’t use every tool on every task. I use the smallest set that covers the work.

Parallel Work Is the Real Multiplier

The bigger change came from running independent agents at the same time.

Git worktrees give each agent its own checkout and branch. One agent can build a feature while another reviews a pull request and another investigates a failing test. Their changes stay isolated until I decide what to merge.

Claude Code Agent View lets me supervise top-level background sessions. Agent Teams coordinates teammates inside a task. I also use herdr to see which terminal sessions are working, blocked, or finished.

Parallel work needs clear boundaries. Five vague tasks create five times the review work. Each agent needs a focused task, an isolated worktree, and a clear point where I inspect the result.

Fundamentals Still Matter

Delegating code I don’t understand would make me faster at producing problems.

System design matters more now because I need to shape architecture and judge tradeoffs. I built that judgment by creating side projects, trying different stacks, and learning how the pieces connect.

When I’m learning a new technology, I work through it feature by feature before automating the pattern. Once I understand it and know it will repeat, I can put it in a skill or project instruction.

The learning comes first. Automation comes after.

Where This Is Going

I already run multiple agents through worktrees and session managers. I don’t yet run a fully automated issue-driven swarm.

That is the next direction: an issue gets triaged, an agent reproduces it, another prepares a patch, and tests and review gates validate the result. It is an event-driven version of the same software process teams already use.

I wouldn’t start there. One agent with clear expectations is better than five agents producing work I can’t trust.

The Engineer Owns the Outcome

Moving from Cursor to Claude Code changed where I spend my attention.

I write fewer routine lines by hand, but I spend more time deciding what should exist, how it fits together, what could go wrong, and how to verify it.

A vibe coder gives away the process and hopes for an outcome. An agentic engineer designs the process, uses agents where they help, and stays responsible for the result.

That is the kind of engineer I am trying to become.