I have been using agentic engineering for the past few months, not just for coding, but across my entire workflow: coding agents, personal productivity automations, custom agents, skills, tools, and computer use through Claude Code, Codex, Kiro, and Pi. I have built so many personal automations with agents that they have become a part of my daily work, and I can’t live without them.
As with any new technology, it was amazing and incredibly powerful at first. But after living with it daily, the initial excitement settled into something more nuanced.
Make no mistake, agents and agentic engineering are here to stay. This isn’t a hype cycle that fades. But like any powerful tool, using it well requires learning where it shines and where it burns you.
Here are my observations:
Don’t let the agent get ahead of your grasp
As soon as you lose track of the codebase, it’s already a problem. Getting back on top of things is extremely tough. If you can’t explain what the code does without reading every line, you have already lost control. The agent will keep building on a foundation you don’t understand, and every fix turns into a risk.
Write your plan to a file
Small, planned changes can be the difference between chaos and productivity. Don’t let the agent work without guidance. Give it a clear spec. When I started writing step-by-step plans in a Markdown file before doing anything, the quality of the output improved a lot. The agent stays focused, you stay in control, and you can review each step meaningfully.
Your job is architecture now
Generating and rewriting code is easy now. Everyone’s job is more about being an architect. Knowing how to design systems matters more than ever. The bottleneck isn’t typing speed or how fast you can implement. It’s about knowing what to build, how to design it, and where to set boundaries. If you can’t design well, the agent will quickly create a mess.
Static typing is essential
The stronger your types, the better your experience. “If it compiles, it works” was always a good rule, but with agents, it’s critical. Use Rust, Go, or at least TypeScript. Your experience will be much better than working in dynamically typed languages. Types act as guardrails for the agent, catching problems right away. The compiler becomes your automated code reviewer. In dynamically typed codebases, the agent can produce code that looks fine but quietly breaks at runtime, and you might not notice until it’s in production.
Know when to stop refactoring
Refactoring is never-ending now. It used to be about finding time for it, but with agents, it’s easy and can go on forever. Agentic engineering can get obsessive. You could spend a whole day having the agent restructure, rename, and reorganize things and feel productive while doing so. But shipping is what counts. Set limits. Refactor with purpose, not just because the agent makes it easy.
Code review is harder, not easier
When you wrote the code yourself, you understood the intent. When an agent writes it, you’re reviewing someone else’s work, but that someone only knows what you told it. Treat every agent-generated PR like it came from a junior engineer who doesn’t know your business logic.
The codebase is the product
Your architecture, module boundaries, and naming conventions aren’t just for people. They’re the interface the agent reads to decide what to do next. A clean codebase compounds. A messy one spirals.
Moving fast isn’t the same as being productive
I have had days where I shipped thousands of lines with agents and days where I shipped fifty lines by hand. The fifty-line days often made more progress. Speed without direction is just movement.
What’s your experience been like? Are you using agents in your daily workflow? What patterns have you found that work, or traps you have fallen into? I would love to hear how others are navigating this shift.