I have now tried a lot of different approaches to agentic engineering, and I want to share some patterns I've learned and ways to think about it.

What you need to get started

A successful agent run needs three things: a codebase, style and taste guidelines (usually in the form of a CLAUDE.md or similar), and a clear specification of what the end goal looks like. Without all three, you're essentially asking the agent to guess at your preferences, and it will. The codebase gives it context, the guidelines give it direction, and the specification gives it a target. Missing any one of these means you'll spend more time correcting course than making progress.

Be specific about taste and style

You need to be very specific about where you want the agent to get its taste and style from. Do you want to enforce a global style across your entire codebase? Do you need to adapt to third-party integrations that have their own conventions? Do you want a compatibility layer that bridges different styles? These choices matter enormously, because if you don't specify, the agent will pick and choose a new style every time, especially with different models. Consistency is enforced through rules.

Missing context

There are a lot of socially encoded standards that agents don't know about. Things we teach others during onboarding, things we enforce during code reviews, conventions that exist only in Slack conversations or team wikis. The agent wasn't there for those discussions. It's probably a good idea to keep updating your CLAUDE.md regularly. Maybe once every few days, with a summary of all review comments and decisions. You need to capture that tribal knowledge explicitly, because the agent can't read between the lines.

Skills are weirdly effective

I still don't fully understand why providing skills in markdown format works so well, but it does. Something about the structured format, the clear examples, the way it breaks down complex tasks into steps. It seems to unlock capabilities in the agents that aren't there otherwise. It's one of those things that feels like it shouldn't work as well as it does, but I've stopped questioning it and just started using it. One of my favorite skills at the moment is Anthropic's frontend design skill, it manages to make really nice modern UIs that don't feel vibe-coded at all, as long as you get a bit creative with your prompts.

End-to-end feedback loops are worth their weight in gold

The most powerful thing I've discovered is that end-to-end feedback loops allow agents to self-correct. When an agent can run the code, see it fail, understand why it failed, and fix it, it starts iterating. Instead of you being the bottleneck that catches every mistake, the agent becomes a partner that learns from its own errors. This is why I've started to set up environments where agents can actually execute what they're building, not just write code that looks correct and guess at its functionality.

Agentic engineering compounds

When you start doing agentic engineering seriously, you begin building systems specifically so your agents perform well. You create better documentation, you structure your codebase differently, you write clearer specifications. This compounding effect is super important, and I think it's a major reason why there seem to be such dramatic differences between different orgs, users, and codebases in how well agentic engineering works. The places where it works best aren't just lucky, they've invested in making it work.

Always have the agent update the instructions when something unexpected happens. If it makes a mistake you've seen before, that's a signal that your guidelines need updating. Treat your CLAUDE.md as a living document that evolves with your codebase.

Agents have weird habits

Agents have really strange habits that you need to train out of them. They'll import things in the middle of functions, mock everything to smithereens even when it's unnecessary, and sometimes write code that looks correct but violates patterns you've established elsewhere in the codebase. You have to catch these early and adapt your CLAUDE.md to explicitly forbid them. It's like onboarding a new engineer who's very capable but has picked up some bad habits over time.

They're not equally good at everything

The agents are not equally good in all languages, especially when it comes to existing codebases. They might excel at writing new Python code but struggle with understanding the patterns in your legacy C codebase. You need to adjust your expectations and your guidelines based on what you're working with. Different types of problems and systems lend themselves more readily to agentic engineering than others. Greenfield projects with clear requirements? Great. Refactoring well-tested code with established patterns? Also great. Debugging subtle race conditions in distributed systems? Maybe less great, unless you find a good way to have it simulate these systems and analyze state & output. Understanding when agentic engineering will help versus when it will slow you down is a skill that comes with experience.