How I Work With Agents

I had an epiphany in February of 2026. There are some days you remember because they have such a significant impact on the trajectory of your life - this was one of those days. My teams had been using models in their IDEs (Cursor and Windsurf) for about a year at this point, most recently GPT-5, and I was already beginning to see the upside of models applied to real world applications (not just a glorified Google search). However, the approach most engineers were using was still what I’d consider the first level of model assisted software development - an assisted auto-complete. Already this was great, but it paled in comparison to what was about to take over most top-tier tech companies in Silicon Valley.

What had changed #

Over the Christmas and New Years break, I had seen lots of articles about how people were having an AI psychosis moment with Claude Code. This was intriguing to me, but I was traveling with my family at the time and hadn’t fully dipped my toes into the agentic waters. At work, I was in a leadership role that had me managing managers and senior tech leads rather than doing hands-on coding. In my personal life, I had projects I was working on that involved coding, but that was more for pleasure. Nothing had really forced my hand into adopting the new agentic workflows.

Most of my experience at that point was in building agents and agentic experiences into products. I am very hands-on with the development process, design, and architecture of the systems and products that my team builds. I’d built many 0-to-1 product experiences over my career, and over the last couple of years we’d started adopting more models into our workflows - but I hadn’t yet started directly using coding agents myself. That all changed in February, when I attended a mandatory workshop where I was able to take time away from the day-to-day to actually use the tools myself.

I was totally blown away by how much had changed in just the last 12 months. In February 2025, Anthropic had announced the release of Claude 3.7 Sonnet - and tucked away in that article (not even given a shout out in the URL slug) was the introduction of Claude Code, in a limited research preview, to the world. At that point in time, the models (and the harness) weren’t mature enough to really show the full potential of what had changed. Sure, there were early adopters who were way ahead of the curve, but most folks still weren’t using coding agents at scale. That changed in December of 2025, when people were finally getting their hands on Opus 4.5 in Claude Code.¹

By the time we get to February, everything had changed - and fast. Andrej Karpathy - one of the LLM forefathers - summarized it well in the opening of his post:

It is hard to communicate how much programming has changed due to AI in the last 2 months: not gradually and over time in the “progress as usual” way, but specifically this last December.

— Andrej Karpathy, on X, February 2026

I was having that same experience myself, and it was eye-opening. No longer was the model limited to generating code; it was actively testing and debugging, reading codebases, and solving problems the same way a human would. I immediately felt like I was already behind the curve, and I devoted myself to learning and experiencing as much as I possibly could.

What I learned #

There are plenty of how-tos and advice articles written about AI and agents - however, there is still value in sharing personal experiences. The landscape is changing rapidly, and what constitutes best practice is being rewritten regularly. Since that moment in February, I’ve gone back deep into hands-on coding (really, agentic engineering), something I had thought I’d have to give up as I moved further up the career ladder. It’s been exhilarating. I’ve spent time programming in - and learning - languages I’d only briefly used in the past (Rust, SwiftUI). I’ve tested out the various levels of autonomy I give the agent based on the project, to see just how far we can push the limits. I’ve adopted goals and loops to automate work autonomously. And I’ve been an evangelist to non-technical friends and family on how they can use AI to help them in their lives.

I think one of the biggest misnomers about Claude Code is that you can use it only to “code”. Anthropic realizes this and has created Claude Cowork as a solution for people a bit too timid to adopt a tool with code in its name. OpenAI realizes this as well, and has the advantage of Codex (a great harness) not being as well adopted as Claude Code as a brand; last week they folded the Codex app into the new ChatGPT desktop app to lean into their strong ChatGPT branding, which is more well known outside the technical crowd. I’m not going to try to convince you to get your non-technical friends to adopt a coding agent for non-coding tasks (although you should), but I will say that the tips I give here are aimed at being generally applicable to many use cases, not just software engineering.

The practices #

Below is a short list of curated advice from the countless hours I’ve spent working with agents since February. I imagine this advice will change over time - and I plan on periodically updating this post as it does - but for now, these are what I consider to be some of the best practices for using agents effectively.

Do your best Socrates impression #

This is perhaps my most widely applicable advice - constantly ask questions. If you ask an LLM to give you an answer, it will. Will it answer what you’re actually looking for, or open the door to other possibilities? Not unless you allow it. As the models have improved (and this is especially true for Fable and Sol), the labs have invested tremendous effort into making them as proactive as possible. This is a consequence of prior iterations failing to continue their work and stopping mid-stream. The initial solve was to have the harness loop on a prompt that pushes the agent back to work, but I’m seeing less and less need for that recently. The models will take your direction (or loose steer) and run with it. While that’s a nice improvement, I find the most value comes when you’re able to engage in a discussion with an agent to really lock in what you want done. The more context an agent has on why you’re doing something and what you want done, the better results you’ll get. The more descriptive and specific you can be in your prompts, the higher the likelihood the output matches your expectations.

Use context - carefully #

Speaking of context - use it. A lot. I realize this is somewhat contradictory to the current conventional wisdom, so let me explain. Whenever I’m having an agent pick up a task, I want to frontload as much reading as possible to ground it in exactly what it’s going to do. I don’t want it reading the code on-the-fly - if it’s going to be working in a specific package, read the full package into context before doing anything. There’s a monetary argument too: token reads are less expensive than token writes, and cached reads are an order of magnitude cheaper still - so a pile of reading up front costs less than writing the wrong output once (the full economics deserve their own article). The huge unlock is that frontier models now support incredibly large context windows, which let you keep a conversation going without facing compaction - which wipes the context window and replaces it with a half-hearted summary you pay to generate. The one hedge: models do get confused when there’s too much conflicting information in play. If you’ve spent a long conversation steering the agent away from things you don’t like and toward things you do, it can lose track of what you really want. I’ve never found that to be true of reading code before writing it - that’s been universally good. It’s the prose and discussion where the confusion seeps in.

Don’t take no for an answer #

Sometimes the agent will ask you to run a command yourself, with an exclamation point in front of it (! bash_command...). Don’t. Just tell it to do it. When it says “I can’t find a way to do xyz,” tell it to try harder. This doesn’t always work, but it works so much more often than it doesn’t that it’s generally applicable. The agents can do so much now that I never take an initial “no” as an inability to do something. If the agent asks you to do some routinized task that is (likely) a waste of your time, just flip it back to it. It will more than likely do the work; it just needs a little push.

Never trust, always verify #

You should never trust what an agent says without being able to verify it yourself. I’m not even talking about hallucinations (which have gotten less frequent, but still exist). You might say “Do xyz every time!” and later ask “Did you do xyz?” and get “No - I didn’t, and I should be straight about it rather than let my ‘entire fix surface’ phrasing stand.” That was a literal response from an agent when I followed up on some work I had it doing. This seems bad (and it is), but it’s also actually sort of good. You don’t want AI to do “everything” you say - you want it to have some judgment. But that means you need to follow up and check its work. The fuzziness of an LLM is both its greatest strength and its greatest weakness at the same time.

Injection molding, not hand carving #

Start thinking about your work in a different way. When you’re leveraging an agent to code, you’re shaping the mold and then flipping the switch - not shaving wood off piece by piece, not stacking LEGO. I think of it like plastic injection molding. You create the perfect mold (through design discussion and alignment), and once you have it ready to go, you push the button and the LLM fills the mold at lightning speed. The name of the game is constraints - when the cost to produce output has gone to almost nil, you need to rethink how you get back control over quality.

You’re shaping the mold and then flipping the switch - not shaving wood off piece by piece, not stacking LEGO.

Leverage agents to drive agents #

This recommendation applies in many ways, so I’ll give a few concrete examples. I routinely ask Claude to generate a prompt I can use to pick the work back up at the end of a session. When I return the next day, I simply paste it in (with fresh context) and I’m off and running. For code reviews, have Sol review the code Fable wrote, and vice versa. You’ll find interesting quirks and differences between models, and getting a second opinion is almost always valuable (and relatively cheap in both time and cost). Another example is how I do image generation - I find that ChatGPT Images 2.0 and Gemini are very good at producing the type of image I want when I feed them a prompt written by Claude. Iteration works well too: I share the output back to Fable and ask it to tweak the prompt (or do a follow-up prompt) to get the final output I’m looking for. Agents driving other agents is going to be an interesting space for a long time, and I expect the best practices here to evolve quite a bit.

Harness specifics #

When it comes to harnesses, I probably use Claude Code the most, followed closely by Codex (both CLI). Claude Code was the originator of this way of working, and I still find it to be the most useful (but not without faults). Some quick tips:

• Auto-mode: with Claude Code, I admit I’ve gotten a little more comfortable letting the agents run free. This is in part due to Auto-mode being so much better now. I regularly find the classifier catching the agent before it does something I didn’t fully approve (a hedge against the proactiveness I mentioned before). For Codex, I don’t yet trust it in the same way, so I don’t give it full access. I do greatly appreciate that the Codex harness itself is open source.
• Fable/Sol, max context: just use the best. I seriously hope the competition from OpenAI forces Anthropic to stop using model availability as a differentiator. Every paid plan should have access to the same models (limited by usage, not model tier). This advice applies to personal and work use, not to building models into a product, where model choice (and cost) is an important part of the equation.
• CLAUDE.md / AGENTS.md: don’t go crazy here. The context you pull into every session should be fairly dynamic based on the task. Also, use the @ import capability in CLAUDE.md to pull in AGENTS.md, so you have a single approach that works across harnesses.

The only constant #

If you take just one thing from this, it’s that the only constant in life is change. I spent the last few years assuming that, due to my role, I had traded away my hands-on coding work for good - only to be pleasantly surprised that the entire software engineering paradigm is changing, and the power to drive impact through AI has re-opened doors I thought were closed.

If you too are an engineering manager - or someone who isn’t in a technical role at all - I’d encourage you to give these tools a try. Pick a real task - something you actually need done - and before you let an agent touch it, have a conversation. Ask it what it would do. Ask it what could go wrong. Make it ask you questions back. Everything I’ve shared here grew out of that habit: the quality of what an agent gives you closely tracks the quality of the discussion you had before you sent it into execution mode. I’m building more (and having more fun doing it) than I have in a decade - and the tools are still improving month over month. That’s the real reason to start now: the curve is still early enough that one week of deliberate practice puts you ahead of it. I felt behind in February. You don’t have to.