Agentic Development Survival Guide

When was the last time when you were in the state of flow? Where hours passed by unnoticed as you were deeply focused on solving a tricky problem. I don't remember mine. I remember how it felt, I remember there were many, but which one was the last one I can't recall.

Endless rounds of layoffs, uncertain economic conditions, and the darn pressure to use more AI has been wreaking havoc to professional identity of myself, my team, my friends, my colleagues and strangers on the internet. So I know I'm not alone in this.

This article is my attempt to summarize my own coping strategies and turn it into a practical guide opinionated enough to be actionable and flexible enough to work for others. I can't help it - I'm an engineer, I don't like dwelling on problems especially when the solution is within my reach.

AI is Yet another automation tool

First thing first, we really need to talk about what AI is and what it is not. It is not magic, it is not consciousness and it is not a mythical ethereal power. It is a giant statistical model that is taught to predict the next token in a sequence.

The human brain has an estimated 100–500 trillion synaptic connections. Claude Mythos is rumored to carry around 10 trillion parameters, and while comparing a parameter to a synapse would give a neuroscientist an ick, the numbers are still humbling. A macaque's neocortex alone contains roughly 1.25 trillion synaptic connections. And, unlike Mythos, the macaque runs all that on fruits, seeds, leaves, and flowers.

Don't get me wrong, it is very impressive that AI came that far. But that's not even close to match a human in both capacity and efficiency.

So let's agree that AI is just a tool that we can choose to use to automate some of human tasks.

The Golden Rule of Automation

With that out of the way, let's look at what we already know about automation. If you search "The Golden Rule of Automation" you'll find a few different versions of it: "We must make deliberate decisions about how, when, where, and why to automate" or "Simplify and standardize processes before you automate them" or, my personal favourite, "Never automate a process you haven't done manually at least X times".

Mind you, these are the rules that allowed us to mass produce food, shelter and clothing. But the process of industrialization hasn't eliminated manual labor in developed countries entirely - it made it a choice.

With that said, you have probably guessed that step 0 in this guide is to shift the mindset from catching up with AI to grabbing the reins back. We could talk more about who and why promoted the AI superiority mindset, but I think Hanlon's Razor gives enough of an explanation, so let's dive into the solution instead.

Observe the process

The first step to automating a process is to observe it. As counterintuitively as it may seem, I would like to suggest that you set all AI tooling aside and try to implement something old-school. But in this case the purpose is not to abandon your favourite agentic harness entirely, but to note which parts of the process are genuinely a hurdle before automating it.

It can be something small, a side-project or a feature. Pick something that you are more or less comfortable with. If you've been relying on AI for development for a long time it will feel weird at first. But don't worry, it's like riding a bike.

If it helps - think about it as an AI detox, not permanent withdrawal.

Keep a note on the side - a paper one or a digital and whenever you feel stuck or annoyed - write it down.

It can be anything from "Forgot which command to run and needed to look it up in the code" to "The code structure fills me with dread and feels illogical". It doesn't matter how (ir)rational or (un)common your hurdles are, even if you're somehow the only one in 8 billions facing them, so don't judge or worry about solving them just yet. Fix if it's something small, otherwise just note and keep going.

Repeat the process a few times, keep taking notes and observe emerging patterns.

Refactor

With data in hand, you can now identify potential improvements. And I bet that the majority of them could be fixed with a refactoring. Move files around, decouple functions, clean up unused code, rewrite confusing bits, change tooling to a better one.

It is generally a good idea to spend between 20% and 50% of your time doing that. For starters, you can adopt the same observe-note-fix steps while working on a feature or task, but with time you'll be able to weave it into your regular workflow in a more natural way.

It doesn't matter how much or how little AI you're using in your development - your developer experience matters the same. And, subsequently, what is good for your DevX would make it easier for agents too.

Gradually introduce AI agents

Speaking of agents, I also bet you'll miss them during your observation/detox phase and hopefully you'd note when that happens. These are the parts you probably give back to agents first.

From my experience, there are a few tasks that are generally safe (for your flow and sanity) to involve agents early on.

Fill-in-the-Blanks

LLMs excel at predicting the next token. You don't even need a huge model for that, in fact tiny FIM (fill-in-the-middle) models that you'd find in IDEs autocomplete functionality are often so cheap to run you get them for free.

And hey if autocomplete covers all your AI needs and you feel productive and happy - maybe that's how the perfect flow looks for you right now. Being curious about technical advancements and trying things out is what's needed to stay relevant. Adopting a workflow, even a hyped one, that diminishes your abilities is not.

The same approach can be applied to LLMs, if you'd like a bit more AI in your flow.

Here are a few steps to try and see how it works for you:

1. Write types and/or interfaces for a small slice of functionality
2. Create a test file and write only titles for the tests you'd like to write
3. Ask your favourite coding agent to write the tests and functionality

And if it sounds familiar it's because it is the infamous test-driven development in a nutshell.

I don't follow the purist red-green-refactor loop. I write tests and code pretty much at the same time. And from my experience, there's no reason to force agents to do it differently. But I do prefer having tests over elaborate documentation.

Think about the development flow the same way you think about unit tests: the task for the agent needs to have one clear, well-defined purpose that should be easy for you to validate.

And while reviewing the agent's output might seem like the most straightforward way to do so, it is extremely tedious and I'd recommend building linter rules and static checks into the codebase before subjecting yourself to this torture. Unless you absolutely enjoy reviewing code written by someone else, of course. I do not.

Brainstorming

What I do enjoy doing is brainstorming a solution! Before chat bots I used to do that with a pen and paper and occasional thinking partner. Nowadays, AI becomes this thinking partner more often than I'd like it to be.

It's not that the world changed when AI became capable of maintaining a conversation. Facebook, Reddit and your run-of-the-mill Google search could yield plenty of delusional ideas and fabricated facts. But a post is not personal, it doesn't adapt to your situation and as much harm as it does - it doesn't become an echo chamber.

AI, unfortunately, can. So fair warning, if you feel isolated and have limited contact with other people and risk of developing delusions, please talk to your healthcare provider before using AI as your thinking partner in any capacity.

For general use, I find the "quiz me" approach the safest for brainstorming and the prompt for it looks something like this:

I am exploring <topic>. Ask me one question at a time to help me with <outcome>.

This way your thinking is still your own, AI can make suggestions, but you hold the decision power. Including the decision to shut down the darn thing and go back to pen and paper.

More Power - More Guardrails

Speaking of power, when it comes to finding the right balance between human and AI driven development, the crucial concept to keep in mind is that the more autonomous you let the AI be the stricter should be the guardrails.

And regardless of how much or how little AI you end up using, you don't want to rely on a document, verbal agreement or someone else's opinion to keep things under control.

The exact implementation of these guardrails will vary depending on the specific use case, the tools available and your personal preferences and way of working.

Here are the rules I follow that might or might not work for you:

1. Greenfield codebase should be setup by a human.
2. Core context should be written by a human.
3. AI should never be given more context than they need to complete a task.
4. Strategic thinking (brainstorming, planning, architecting) and implementation should never happen in the same session.
5. Deterministic checks > human review > AI review > no review.

There are multiple workflows that would follow these rules, including the ones where no AI is involved in the process. And if that is what works best for you, then there is no reason to change that.

It is also possible to setup a workflow where AI is doing most of the work, but it requires mature codebase and a very experienced developer who is comfortable with that way of working.

And all of that starts with somewhat selfish process of improving your own daily work first.

I became a developer because I fell in love with the process of turning words into digital worlds. I stayed because I enjoy solving other people's problems. I can do that with a lot of different tools, languages and frameworks.

AI is just one of many.