There are a million blog posts out there talking about this. This is just the setup which has been working for me. I’ll keep it short and to the point as usual.

Philosophy

Before outlining steps, let’s first talk about what are the philosophies to keep in mind when doing agentic engineering.

Progressive disclosure

Agents thrive in context, but also get overburdened when there is too much context. Progressive disclosure helps the agent learn stuff when it needs it. Not remember everything by default. Makes the agent smart.

Domain

Domain is more important than ever. Agentic engineering helps you go fast, but if you are going fast in the wrong direction. You’ll be at the wrong place. Focus on domain from day zero. Refactors are fast in the AI world, but that should not mean that you differ important decisions in the future cause fast does not mean absent.

Plan extensively

Think of the entire stack of solution before commiting to development. A flushed out plan has very high returns,

Closing the loop

Agents are only as good as you let them be. If the agent vaguely understands where it’s supposed to go, but has no clarity. Again it’ll run fast and reach the wrong place. Closing the loop means giving it enough tools so that it can understand if it has completed the implementation correctly or incorrectly. If you are reaching out to tools, remember that your AI also needs it.

Reflection & Taste

Different people have different opinions. Some people prefer functional to object oriented, prefer dynamic to statically typed languages etc.. This taste needs to be captured incrementally so that

Implementation

Now that the philosophy is out of the way, let’s talk about tangible steps to get there.

Flush out AGENTS.md / CLAUDE.md

This is the single most high leverage item you can possibly do. Keep it short and sharp. Cover

1. What does the service do, why does it exist, what is it solving for
2. Stack in a couple of words, instructions on how to run, pull secrets etc..
3. Programming principles & repo level conventions (preferred logger, preferred programming and testing patterns etc..)
4. For local testing, how to bypass/generate auth tokens etc.. so that the agent is not blocked until you explain how to test (Close the loop)

Do not make this too large. If there are domain specific content, put it in the corresponding folder so that when needed the agent picks it up (progressive disclosure).

Fundamentals – lint, typecheck, test, format

The usuals, just putting this out for completeness. Make sure all of this is well done so that the agent can do the basics and get consistent code out.

Skills

Do this if and only if you are done with the above point. Skills are one more way of progressively disclosing steps to achieve a goal in a repeated task. Skills again can be configured at a user level & project level.

If you have tools which you frequently use, I would suggest installing/creating a skill for that and reusing it.

Here are some skills I use on a daily basis

User level Skills

1. frontend-design
2. copywriting
3. seo-audit
4. agent-browser
5. skill-creator

Project level skills

Most of these are manually created using the skill creator, most of these are very specific to the project being worked on & the environment it was setup into.

1. debug-data-pull : with instructions on how to pull data from the postgres/mongodb/redis databases. Which tables are important and how do they relate etc…
2. debug-logs : with instructions on how to pull logs, which stream to read from in corresponding environments etc…

Integration tests

Test like the user. With end to end integration tests, its easier than ever to test the entire application. Its even better because once you tell the agent how to write e2e tests, it can write pretty complex UI interaction tests using agent browser skills.

This is a big part of closing the loop. once the test suite is up, then the agent can run the backend, run the frontend, write and run tests, figure out if the expected behaviour is met or not. If not, then explore the codebase and fix the implementation, run tests again. This loop is what makes agents so damn powerful.

Prefer a mono-repo

I’ve never really supported the idea of having hundreds of microservices. I’ve always been a believer of the majestic monolith. I think its a better idea than ever before to subscribe to majestic monolith.

The fact that you can run frontend, backend, integration tests, share types, from the same repo is beautiful for agents because they can just go and see how stuff is implemented and learn from it. It can also aggressively run compile/type check to see what implementations are breaking and how if something does break.

With agent browser and other skills, agents can also now run the frontend and the backend, e2e tests, fix bugs & make PRs along with notes. Once you see the potential, there is no going back.

Reflect periodically

Every time you see the agent stumble, remember to add something in the corresponding claude.md . This is tedious at first, but compounds very fast. In a week or two, you’ll have a very strong file which outlines your taste and then depending on the steer-ability of the LLM, it’ll radically simplify your life.

I would suggest even having a skill, which you can run every end of session to see if there is any learnings to add. But along with this, you should also make sure that you’re claude.md is not too large.

MCPs

These are far and few, but they are important. MCPs bridge the gap where CLIs don’t exist. if there is a cli, you should just write a skill for the CLI and let the agent use it as it sees fit. But for some applications, MCPs tend to be better.

The only MCP I use on a daily basis is metabase-server. Just because there is no official metabase CLI yet.