How my agentic engineering practice has changed
My last post on this is from February 2026, not even nine months ago, but it feels like a much longer time because so much has changed.
More tokens and a better model
First off, I’m using way more tokens since getting a Claude Ultra subscription. The subscription became easier to justify when Anthropic started to give an equivalent amount of API credits as a bonus (OpenAI has since done the same). My current default model is Opus 5.5 on high reasoning and it delivers good code and readable answers. It was a big upgrade from Grok, which was my previous daily driver. The trigger to switch wasn’t actually coding ability, it’s that I find Grok-4.7’s prose unreadable. That’s something benchmarks don’t show, but immensely influences my productivity.
From coder to architect
Since February, I’ve moved even more to an architect and product manager role. There is no practical need to write code line by line anymore, though I occasionally do it to not completely get out of practice. It’s easy to lose fluency and it already feels harder than during my manual coding peak in 2022-2024. I’m trading syntax memorization for higher output. It also let me zoom out more and focus on a project’s architecture. I’m less attached to an implementation - if I find a better way to structure it, I’m happy to scrap thousands of lines of code which previously would’ve felt like a setback.
Weekly tutor session
As I’m moving from syntax to concepts, I want to maintain the same or deeper technical understanding. So I’ve scheduled a weekly tutoring session: Claude looks through the chats we’ve had, identifies new concepts and picks out my dumbest questions about it or cases where it looks like I approved something without full understanding. Then it quizzes me about them, from memory, with strict grading. It also keeps track of what we drilled this way and uses spaced repetition. This tends to be one of the most intellectually engaging hours of the week.
Specs and organization
As an architect, my language is specs that the code will be graded against. Before committing to a direction, I let agents run spikes with different archetypical solutions. I do this for performance, code organization and design alike. A related trick is asking for the best ideas from a specific book, app, website or other resource and applying them to the problem at hand.
I also ask agents for visual presentations: artifacts, Storybook for UI components, and the same approach as prep for meetings. I spend tokens lavishly on letting agents create better explanations, often with interactive visualizations.
I’m also keeping a glossary. I was skeptical at first, as it seemed like an unnecessary extra file to maintain. However, my current main project sits at the intersection of two fields, natural language processing and social science, and defining one vocabulary helped clarify choices between many synonyms (e.g. code, label, tag, annotation).
Making agent-written code trustworthy
The goal is to design a process that lets agents reliably produce correct code.
Skills
I use a personal skills repo that I load into projects. In addition to general skills, it covers common elements of my tech stack, e.g. how to use Pydantic AI for provider-agnostic inference and how to log traces to Langfuse. On top of that, I create project-specific skills. I dislike loading multiple large skills from others and prefer to use my own rewritten versions, picking and mixing.
Among them is a selection of Matt Pocock’s skills, adjusted or rewritten for me. The most important ones for me are code-review spanning specs and standards and grill-me, an interview to systematically clarify requirements.
Agents own the PR workflow
I used to not want agents to touch git or GitHub issues because I worried they’d mess it up. It turns out that they do that at a lower rate than I do. Now I let them create worktrees and open PRs. I’ve set up permissions so that force pushes still require my approval and pushing to main is disallowed.
For large changes, I let agents build stacked PRs with the gh stack skill, which are often easier to review. Cherry picking commits is annoying for humans but agents don’t mind, so I let them do it until the stack tells a story I can follow easily.
Letting agents deploy to a test environment has increased my confidence in their correctness, and it’s nice to get a link to a working version right in the PR. Along with that, I let Claude put its agent chat ID as a link on each PR. I can click on it and get right back to the agent that created it, which is useful when I want to ask questions about the PR or have it make changes using the same context that built it in the first place.
Scheduled agents
Beyond the PRs, I run scheduled agents: for issues (tagging, commenting if a ticket has been overtaken by others, warning when PRs are likely to create merge conflicts), for suggesting model updates and for scanning logs. And if I have spare tokens at the end of a cycle, I let agents do complete top-to-bottom bug hunts.
I’m the bottleneck
I found Matt’s interview with Lauren Tan from xAI enlightening. She takes sheer output to an incredible level. Personally, I wouldn’t feel comfortable putting my name under that much new code, but I notice that my readiness for it has already grown tremendously.
The limit is how many technologies I understand and how many architectural and product decisions I can make in a day. I could let loose and let lines of code per day go to the moon. But while that would maximize velocity of code, it wouldn’t maximize usefulness of the software. Current agents are still tend to clutter codebases and have trouble stepping back and asking: should this even be done? Or: should we let this old pattern go, rather than forcing this new code through it when it doesn’t really fit? In addition to the codebase deterioration, I’d quickly lose the ability to answer questions about it in conversation, along with the opportunities to infuse technical decisions with practical understanding of users and market research. So I’ll continue to be the bottleneck, but will definitely keep iterating on the development process.