My approach to agentic engineering
Using AI for coding has made me rethink how I work. Some of the habits I’ve built as a developer need to be unlearned. Instead of starting with files and functions, I try to start with the system, the requirements, and what I actually want to achieve.
In some ways, it feels closer to being an engineering manager or an architect. I set the direction, give the agent enough context to work, and check the result. If I’m micromanaging every line, I’m probably not getting much out of it. But trusting an agent to do the work doesn’t mean trusting everything it produces.
The agent writes the code, but I still own it. I need to understand the changes, explain the decisions, and take responsibility when something breaks. Code reviews, tests, and operational checks are part of that responsibility, not something I can delegate away.
As more routine development, troubleshooting, and configuration work gets automated, I think the value of understanding the business and the system grows. Knowing why a design exists, which trade-offs matter, and whether a change is actually useful matters more than typing the commands yourself.
How I work through it
My definition of an agent is straightforward: an LLM with tools and memory. The model matters, but so does the environment around it.
The principle I keep top of mind is: speed is useless without control.
That also shapes how I choose models. I prefer models with more reliable knowledge and fewer hallucinations, even if they’re slower. I’d rather wait for one iteration that gets the task right than spend several fast iterations correcting mistakes and polishing the result. What matters to me is the time it takes to reach a result I can trust, not how quickly the model responds.
For harnesses, I prefer CLI-based tools that are easy to tweak and configure. I want to be able to inspect the agent’s environment, see what tools it has access to, and change them if needed. I also want to be able to run the same harness with different models or configurations.
Set up the context
Before asking an agent to work, I want it to have fresh, relevant context. I keep an AGENTS.md focused on the project: its goals, stack, documentation, and instructions. I use MEMORY.md for learnings and references worth carrying into future sessions. Neither should become a dumping ground.
I also make sure the agent has the tools it needs, whether that’s CLI tools, MCP servers, or skills for common workflows. The goal is a deterministic (as much as possible at least), repeatable process that doesn’t depend too heavily on one particular model.
Agree on a plan
I start by defining the outcome and breaking the work into small, single-purpose tasks. For a complex change, I let the agent explore the codebase and propose an approach before writing code.
This is where I want to catch misunderstandings. Reviewing a plan is much cheaper than reviewing a large implementation built on the wrong assumptions.
Work in small steps
Once the plan makes sense, I give the agent one task at a time. I prefer small, incremental changes. If tasks are independent, I can run separate agents in separate tabs rather than ask one session to juggle everything.
When an agent goes off track, I stop it early. I’ll clarify the prompt or go back to a previous checkpoint. After a few failed corrections, I’d rather start a fresh session with a better prompt than keep piling instructions onto an already confused conversation.
I generally start each task in a new session. I also delegate verbose, read-only work, like digging through logs or fetching documentation, to subagents so the main conversation stays focused.
Verify the result
I give the agent concrete ways to check its work: specific tests, expected behavior, or output formats. That lets it catch mistakes and iterate without waiting for me at every step.
Then I review the changes myself. Passing tests and CI is necessary, but I still need to check that the implementation meets the requirements and makes sense in the system.
Leave useful context behind
Before closing a session, I update the task status, relevant documentation, and agent memory. If we learned something important or changed an architectural decision, I want the next session to know about it.
That’s the loop I’m trying to build: give the agent a clear direction, let it work, verify the result, and carry the useful context forward. Less time directing every keystroke, more time understanding and deciding what should happen.