Agentic development tools have started to change the way I approach software work. Instead of only asking for a small autocomplete suggestion or a quick explanation, I can now ask an agent to inspect a problem, propose a plan, make code changes, and even iterate on a solution. That can be incredibly useful, especially when I’m working through repetitive implementation details or trying to get a first draft of an approach out of my head and into the codebase.
But as I’ve used these tools more, I’ve realized that the most important part of the workflow is not how much the agent can do. It’s how intentional I am about staying engaged while it does it.
Outsourcing Your Thinking
The danger is that agents make it very easy to outsource thinking. They can generate plans quickly, summarize unfamiliar files, and produce code that looks reasonable at first glance. If I blindly accept that work, though, I may end up with a shallow understanding of the system I’m working in. That is especially risky because software development is not just about getting code onto the screen.
I still need to build system design intuition, recognize when a proposed abstraction is too complex, understand trade-offs, and review code with a critical eye. An agent can help move work forward, but it cannot replace the judgment I’m trying to strengthen.
Exercising Your Planning Muscle
To keep that from happening, I still make myself exercise my planning muscle. Before I ask an agent to implement something, I usually sketch my own plan first. That might be a short written outline, a rough sequence of files I expect to change, or a few assumptions I want to validate. Then, when the agent suggests an approach, I have something to compare it against.
Sometimes that plan exposes a gap in mine. Other times, I notice that it is optimizing for the wrong thing or missing context from the codebase. Comparing multiple approaches has been one of the most useful parts of this workflow because it forces me to think about architecture instead of treating the generated plan as the answer.
Slowing for Code Review
I also try to slow down when reviewing generated code. Agents are not automatically faster. Sometimes they speed up repetitive work, help create a useful first draft, or catch something I forgot to consider. Other times, they slow me down by producing code that needs heavy review, missing important context, or sending me down a path that does not fit the existing patterns of the project. Because of that, I try to look beyond whether the code compiles or the tests pass.
For example, if a change touches data access, I want to understand what queries are actually being run. If it adds communication between services, I want to think through the network behavior and possible failure cases. If it changes a shared path, I want to consider performance and how the code might behave under real use. The specific details vary by task, but the habit is the same: I do not want to approve code I only understand at a surface level.
My Checklist
Over time, this has helped me build better engineering instincts. I’m getting faster at understanding unfamiliar code, better at spotting edge cases, and more aware of failure modes and performance costs. My review checklist keeps growing, and that feels like a sign that the tools are supporting my development instead of replacing it. For me, the goal of using agents is not dependency. The goal is to become a stronger engineer while taking advantage of tools that can reduce friction in the right moments. Agentic workflows work best when I keep improving my own judgment, because AI should amplify expertise, not stand in for it.