At this point, I’m about three years into my AI adoption, and throughout the process I’ve learned what burns me out, what speeds me up, what helps keep me thorough, and, most importantly, how I stay engaged in agentic development work. The best part—most of these are the same strategies I’ve used since becoming a software developer.
Can We Talk About This?
Problem: it’s easy to allow the agent to “solve” all of your problems.
Sometimes, the robot has great ideas for architecture changes, new features, or refactoring. You know who else does? Your coworkers—the ones more than willing to share their war stories. There was a point deep into my AI adoption where I asked the agent for database design ideas, and it came up with propositions that would have probably worked.
But then I turned around and asked a coworker the same thing. His answer? Way more appropriate and simply stated. For me, the single best way to stay connected as a developer is to engage with the minds of people around you—their wealth of experience and context into your shared project is invaluable. I’ve walked away from those conversations feeling like I had a solid plan and a clearer picture of the project and work ahead.
Since that discovery and others, we’ve made the time and space to design (architecture, frontend, etc.), knowledge share, and plan work with humans in the loop. Certainly, the agent can help generate ideas, but those with the best context are the people on your team. Another note: speaking to each other is an incredible balm after reading endless plans filled with robot technobabble.
Doodle More.
Problem: it’s easy to outsource your mental-model-building to the robot.
I often draw before taking on a piece of work: on the frontend, it helps illustrate a series of steps a user takes or states they can be in; for backend work, it provides helpful architectural insights. And, drawing is a simple way for me to test my own understanding, whether it be splitting up an epic or debugging.
Why are both important to me though? Can’t the agent just do that? Can’t it see all the blind spots? It might. But drawing gives me clarity, reinforcing what I know to be true, and what I have yet to learn—my mental model of the project. Have I thought of all the implications? Do the tradeoffs I’ve made make sense? Does my vision for this piece of work lack any considerations that change my approach?
These are all questions drawing elicits, and, at the end of the day, the agent isn’t the one who will reap the consequences of bad design. As developers, I can’t afford to let my mental model atrophy; it’s my job to understand the constraints of the project.
Moreover, with a clear picture of the project, the unknowns, and the implications of the proposed changes, I can communicate in a way that sets up the agent for success. I’m able to articulate to the agent the broader context and architecture we’ll be hooking into, and the impacts the changes in the backend will have in the frontend. It’s a way of world-building for the agent, so that it knows the environment it’s operating in. Also, drawing feels a lot more like I have the reins, and I’m guiding the robot (not the reverse).
Weave Verification Into Your Process.
Problem: the robot can’t do all your testing for you.
Verification? Seems standard. But is it in the age of YOLO programming? For me, I need testing to stay engaged, and I want it because, ultimately, I’m responsible for the quality of the code and the outcome of this work. I don’t let the robot tell me that it did the thing, and leave it there. I need to prove it.
The rate at which an agent can spit out a story complete with unit test coverage is insane. There are developers out in the world that take those tests as assurance the agent has written a solution that “works,” and, much of the time now, your agent(s) gets it (mostly) right. But there’s nothing like coming up with the testing strategy yourself, and running through manual testing.
When I’m at my most engaged, I can tell you exactly the best ways to test the changes. It means I understand the scope of the work, the context, and the architecture. Seeing that the changes impact the frontend, the database, the structure of a payload are all groundings in reality that tell me the agent took my prompting and implemented it the way I intended.
Know the Robot’s Limitations.
Problem: the models are so good now, we don’t doubt the agent can do the work, especially if we’ve gotten into a pattern of them delivering.
As developers, we know of the existence of hallucinations, and we know that sometimes the context of the work is lost in translation. Knowing when and where an agent will struggle is a good way to stay engaged — lean into it. I ran into many of these on my most recent epic.
Limitations
Architecture: the agent gave me some interesting database design ideas, but the most elegant solution came from my coworker.
Flow of data: the agent couldn’t describe the data flow from one end of the system to the other.
Patterns: it attempted to follow some bad patterns in older parts of the codebase. Sometimes, it delivered the most beautiful types for interfaces, but not always. And, likely, it delivered on those types because we’d already established a plethora of solid types within the codebase.
Size: it dropped the ball on some of the feature sets because there was so much to do, and too much context.
It takes the easy way out: often, not always, the agent will take the easiest path forward, which is not always the best way. Remember that the robot will mostly be tactical and not strategic. If you want a pattern extensible to other uses, you need to be explicit about that, and should rope that into the design work you do with the other humans on your team.
Knowing these limitations keeps me engaged because I know where I’m needed the most. I absolutely need to know the context of the work and the flow of the data; to recall where and why the best patterns exist; to understand that directive documentation exists to help the agent review its work; and to articulate the architecture, but also the history of why it’s there, and how it’s intended to be used.
These limitations will likely change in the future with new, interesting limitations. I see the big task for developers as understanding the limits of each new model and tool (just like we have with every new technology we’ve adopted).
You Fabled Too Hard and Found Out.
Problem: too much scope! The robot makes it easy to think you can do everything, but orchestration takes focus and energy, too.
Where I’ve gotten into trouble 🙈
It’s easy to allow the robot to zip through a bunch of your TODOs. The problem is that, on the other side of all that work, the parts of development that still need a careful eye remain. Here are some of the quandaries I’ve gotten myself into:
- Goliath PRs: I thought I could quickly tack on that tangentially-related change, or that “small” bug fix.
- PR shepherding too big of a flock: so many PRs, so many review bots, and teammates asking for context and changes. It’s hard to do when you have 5 or more PRs at once.
- Forgetting an agent was working on something: you thought you’d quickly switch to another task, and, hours later, you realize your agent has outstanding questions about the work you asked it to complete.
- Shifting context repeatedly, and too quickly: it’s hard to stay focused when you’re constantly switching between tasks.
- Reviewing other people’s Goliath PRs: you might have the context, but the 3k lines of changes are impossible to review and reason about. It will almost certainly result in a slew of new bugs.
The constant orchestration does take its toll.
Recently, I was so deeply into working with Fable that I completely forgot about a few stories I’d completed the day before, and, when trying to articulate other work I’d had a huge hand in, I couldn’t remember a key component of the workflow. Was it a bad day? Maybe, but my hypothesis is that I Fabled too hard. I’d taken on more than I should have.
How I came back ✨
As developers, it’s good to test our limits, especially when we want to understand the new power tool and its limits. But don’t forget that part of this process is figuring out what works for you and your team. During my agentic adoption, certain moments have left me feeling exhausted and directionless. They’ve also triggered my greatest fear: missing important details. Because we need to keep the reins on our agents, here are some levers I pull to keep myself engaged:
Keep PRs small and focused! Make sure they are consumable, testable pieces that a human and a review bot can easily reason about. When I break this rule, I keep the unrelated change to under 10 lines.
Plan out your work ahead of time! Remember when we used to break up epics into smaller stories? That’s still a good idea! I usually stack the PRs if my agent and I are cooking. Then the team and the review bot can see the works’ context and progress. My favorite part about this strategy is how much less often the review bot asks for changes.
Balance the priority of what you take on. If you’ve just started an epic and are laying down large architectural pieces, lay off the side jobs unless they’re easy one-offs (small bugs, copy update, docs, etc.). Basically, you want a story whose context is straightforward or small. If you’ve got a medium with a couple of side quests, you’re probably fine. A whole slew of small bugs, you’re likely good. Pick up an epic? Maybe don’t choose another medium-sized story to run in parallel.
My ability as a taskmaster has changed over time, and certainly I’m growing in stamina and skill in my orchestration. But scoping to fit your limits and energy is the best way to sustain your engagement.
Use AI to Fight Cognitive Surrender
Problem: we’re all worried certain skills we’ve built up over years will atrophy.
I really love testing myself with the robot. Similar to drawing and chatting with coworkers, testing yourself forces you to rely on your knowledge of your project and experience as a developer to write the story. You’re just offloading the majority of the typing. I like to do the following:
- Race the robot to the correct file, function, or class. It’s rewarding to know the repository structure.
- Make your hypothesis about the bug, and then let the robot do its recon. Debugging is a skill that requires a deep understanding of the tech stack, the architecture, and the product. Don’t lose it!
- Once in a while, write some code by hand—especially when you’re setting a pattern you want the agent to follow. Honestly, not a ton of time for this during a work day, but I still do it during personal projects.
- Have the agent pick apart the solution you came up with and see if it can improve on it. Don’t let it just tell you; make it work through the solution. It’s a good way to test the agent’s understanding of the codebase and the problem.
- Get a second opinion! Sic another agent from a different model family on the same problem. It’s a good way to test the agent’s understanding and your own.
Conclusion
I don’t expect that all of these tips will work forevermore, but, thus far, they’ve been the trustiest ways for me to stay engaged during agentic development. Until we find the true limits of AI in agentic development, stay curious, and stay engaged. Don’t accept the robot’s happy-path answer; ask questions, test the solution, and keep your skills sharp.