Switch to agentic engineering
I like the term “agentic engineering”. It encompasses development still being a craft oriented on implementation and continuous refinement of both the result and the result-making process. It also introduces agents, i.e. coding agents as a significant part of those processes.
From my feelings, watching the industry for the past couple of years since great ChatGPT-3 boom, the significance of the agentic part will only increase. I find it very important to acknowledge this and to keep thinking and re-shaping your routine according to that knowledge.
Leading instead of doing
The first and the most obvious change known to anyone is that you no longer need to directly write the code. You are still free to make occasional changes if you think that time-wise and/or cognitive-wise it will be simpler to just do instead of explaining. But even such trivial cases need to be treated with care. Because if you close the gaps with yourself too often then something is wrong with your verbalization, project context or agency you have set up.
And it’s not new knowledge, it may sound familiar at least to those of you who have dipped into management principles. The more often you need to “come down” and sign off the solution or solve some tiny problem or just be present if anything, the less autonomous your subordinates are. And I think that good leading, be it leading subordinate human colleagues or automatic code agents, is built on top of well-ordered exhaustive context, minimalistic and precise mental map indexing that context and proper asynchronous communication.
Well-ordered exhaustive context is a knowledge base, both internal and external, along with different sources of truth. These sources of truth can vary from task boards with established flows and issue structure to design screens & logic schemas. A way of creating, reading and understanding them should be consistent and transparently described. Everyone should know, for example, what types of issues exist, when they are created, what mandatory and optional fields they have and how to work with them in the flow from creation to cancelling or completion.
Minimalistic and precise mental map is basically the index of your context. I think the art of context (re-)indexing was always neglected through manual times and is still slightly underrated, even though in agentic era it may be the most important or even the only skill left for humans - keeping the big picture. The less context artifacts there are, the better. You should keep a clear vision of where to look for what, where to add what, when to review, edit and delete something and what the procedures are. I think, well-thought, transparent and consistent context management is a skill to seek out in the current days.
Asynchronous communication is another well-known management principle, basically a soft skill from the era before any AI involvement. It means to verbalize your requests from others in a way that gives them enough context, frames your requirements and hopefully some basic metric of completion. The ideal asynchronous communication is when you write once and get responded once upon successful completion of your request. It’s not about avoiding any human contact unless you need something from someone. It’s a skill that enforces agency of others. Everyone has their own business, schedule or even timezone in our remote days so having to catch you five times a day to clarify something is more a bottleneck than an opportunity for communication.
Finally, you need to let go of doing to start leading. I know people who find it extremely hard. Even more, they don’t reflect on this topic at all. They assume a leading position and then they continue doing things, literally or mentally. When reviewing others, they compare others’ work with their implementation and if they don’t match, these leaders start fixing every mismatch on their own. There is something unsettling in the fact that something is not done directly by our hands but is still within our responsibility.
If you plan to remain knee-deep in the implementation process and effectively spend a similar amount of time and effort as if you wrote it yourself, then why bother at all introducing agents to your work? The idea is to scale things up, to lead and to orchestrate according to your vision. When someone goes through each line of code to make sure they are written the way they want them written, it is called… well, just engineering I suppose?
Leading or orchestrating requires an amalgam of trust and continuously built confidence.
Trusting the agents
Last week Claude Code team announced that from now on the default execution mode for Claude Code would be auto mode. In this regime Claude Code will auto-permit itself a wide range of presumably safe commands. It will still ask for permission if its constantly changing mechanism of unsafeness detection finds something potentially dangerous in the command it’s about to execute.
The blog post is overall interesting, I suggest you read it. They show experiment data where paid human participants unknowingly competed with the Claude Code auto mode in detecting unsafe commands. Well, the results are what you’d expect from a human-vs-machine mechanical competition:
Harmful actions caught, humans vs. auto mode. Source:
Claude Code blog
This shift had to happen because previous default mode asked you about every command it was going to execute, and in non-small tasks it was a savage violation of async communication principle. It illustrates building confidence in agents - you align them and build guardrails so that less review is required from your side. It should not come to dropping any responsibility from yourself eventually. It should only distill important vision-based decisions from mechanical execution things.
Delegating vs asking
I differentiate between delegating a task and asking to do something in a simple way: delegating assumes you know how to do it, asking does not. These are two operational modes I can see when working with agents. Obviously, delegating is agentic engineering but can you even call it engineering when you ask to do something you don’t know how to do?
Well, if the whole mechanism is mysterious to you, if you have no prior experience or understanding of your tech stack pieces then you can’t be responsible for the outcome because you do not have effective ways to influence the result or even verbalize particular changes.
On the other hand, I don’t know a single person that never asked to do something. And some people I know are extremely good agentic engineers. It’s just that sometimes they need to deviate from their field of experience while doing their work. These are cases where previously you would ask your older colleagues or Google things. Now you can just ask an agent to do it and move on.
I would call it asking to do on macro and micro levels. Asking to do something on macro level is about implementing ideas. You want something from your head to become reality - voila, here you have it, done somehow, but you don’t care. Asking to do something on micro level will most certainly happen from time to time in your engineering routine.
I find this mental note about whether I’m delegating or asking quite useful to stay in shape and also to estimate the extent of my personal responsibility.
Having fun
Even with the looming ASI threat, what an interesting informational era to be alive! It’s genuinely exciting to have tools that, with the right expertise and involvement, let you ship solutions incredibly fast. This is fun, no?
On a more domestic, even leisure level this opportunity shifts accents from refining knowledge to refining ideas. Recently I read an interesting post on LessWrong about how STEM competitions could hand younger generations meaningful, socially impactful problems to solve. It only requires acknowledging modern agentic nature of STEM activities. At some point the post author even suggests letting competitors select or even bring up their own problems, thus testing an even more important skill of solving the right problems.
This is certainly a new dimension of freedom. When I need to remind myself about the magnitude of changes that were brought about, I just open my agentically engineered local app for reading feeds. It is tailored for me personally, my own feed reader. And I own the app. Change requests and aesthetic preferences come from me and are immediately implemented.
I find this level of possibilities extremely fun.