Coding agents were released and popularised in early to mid 2025, and have taken the developer community by storm ever since. They have been discussed a lot on the internet and how everybody is running out of their rate limits, buying more expensive plans for their projects and shipping projects more than ever.

Due to this noise, I initially avoided these tools and I was quite skeptical about using one. Whenever I would hear coding and AI together, I would usually think of going to the ChatGPT website, copy-paste my code along with screenshots as well as describe the problem.

My mind was absolutely blown when I started using one. It gave me a whole new perspective about using AI for programming and building projects. Suddenly these same models could access my codebase, read through files, identify bugs and fix them on my behalf and add new features faster than ever before!

In order to better use these coding agents, I started to cut through the noise, read some blogs, understood new concepts and learnt some of the technologies behind these agents, which I'm going to share with you in this blog.

What comprises agents?

Before I give you some tips about getting started and utilising these coding agents better, I think it's a good idea to know what a harness is and how does it associate with an AI model.

1) Prompt Engineering: This is the art of writing input prompts for the models, assign a particular role for a more aligned response, altering LLM parameters like temperature or top k sampling, adding negative prompts, or using an existing output to regenerate outputs or use them for other queries. In simple terms, prompt engineering is simply writing better prompts to get better outputs.

2) Context Engineering: When prompts become insufficient, providing more context is a better idea. Instead of sending one long prompt with all the information and hoping it would generate an apt response, you can now connect it to external APIs, store the relevant information in the cache or dynamically access information from a storage like a Vector database.

3) Harness Engineering: Harness Engineering is an emerging field under AI Engineering which comprises of a model and a harness. To simplify:

Agent = Model + Harness

A harness is everything except the model in an agent. If the model is the 'brain' of an agent then Harness would mean the 'hands' or the 'feet' of the agent. It comprises of a collection of drivers to connect with MCP servers, or allow a means to interact with the environment, have a persistent storage and memory, a set of instructions when executing different tasks and present in a sandbox (such as Docker).

The reason why I introduced this concept is to give you an idea of what exactly we are working with and what are the different ways that we can enhance these tools for better outputs.

Claude Code, Codex, OpenCode are all coding harnesses which act on a terminal environment. It is possible to change the models (e.g. using OpenAI models with Claude Code), but even the best models wouldn't be able to provide a real value if the harness isn't configured properly.

All that being said, let's look into how one can get started with these coding agents for their projects.

Working with Coding agents

Nowadays, there are a lot of coding agents available. The most famous ones out there are Claude Code and Codex . A typical coding agent runs in your local terminal, and is controlled by a model hosted on the cloud.

You can use any coding agent you prefer and some of them have generous weekly rate-limits in free tier. A lot of coding agents come with their own configuration files like .claude/ or GEMINI.md, but the tips that I'm going to discuss are going to be agent agnostic.

Take a look at the below image. This is a Next.js with Supabase project with all the agent related markdown files and configurations setup. With this setup, I will walk you through on how we best utilise these coding agents.

Project root files

Let's start with the entry point: AGENTS.md. This file is read by agents to read and understand the project, specifications, tech stack, best practices, project specific conventions and things to look out for. Very similar to CLAUDE.md or GEMINI.md.

Nowadays on scaffolding a new project, the maintainers already prepare a starting point files for you. But you can write your own AGENTS.md file, describe your project in detail, or you can even ask the coding agent itself to write it down for you.

If you want to use the agent to create one for you, open the agent in the project directory and write the prompt:

Create an AGENTS.md file for this project. List down the project folder structure, site architecture, file conventions, libraries used, minimum requirements and common pitfalls. 

For accessing library/framework specific documentation, use the agent skills folder to understand best practices and conventions to follow and write them down as well. Also mention what MCP servers an agent has to use if the skill is not available.

This is an example prompt. You can write one to your project specific requirements and application. The agent will then scan the entire codebase, ask for certain permissions to run some scripts, think for a while and then generate the file in the root directory.

As the codebase gets larger, so does the file. Introducing everything in one file adds too much noise for the agent to focus on one specific part, increases the token costs, takes up large context in a new session and it becomes harder for humans to maintain as well.

A better idea is to split the file down into different files such as SPEC.md to define specifications and base requirements for the project or a feature, ARCHITECTURE.md to define the project and system architecture and many more.

Defining a Knowledge Base

In the root, we create a directory called docs/. Each file or folder in this directory acts as a 'knowledge centre' and it focuses on very specific aspects of the codebase

Here's an image from my project implemented below:

The agent file is now more of a look-up table instead of storing the full context.

Here's an example of the file docs/integrations/SUPABASE.md. You can see that this file contains everything about integrating with Supabase, common pitfalls, how to integrate, which files are responsible and so on.

I could ask the agent, for example, to integrate Supabase authentication into my project. Now instead of scanning through the entire AGENTS.md and the codebase, it can first simply look up SUPABASE.md to know what to look for, common pitfalls, which files to work with and execute the task.

This results in better guidance, lower context usage, faster execution and lower token costs.

It opens up an opportunity for having multiple coding agents (either different sessions or different agents altogether) to work on the same codebase but executing different tasks in parallel.

MCP and skills

You might have noticed that I mentioned agent skills and MCP servers when defining an AGENTS.md.

An agent skill is a modular-capability packaged with instructions, scripts and resources to enhance an agent's capabilities and provide a domain expertise. An agent can utilise one or multiple skills to better achieve a particular task with more accuracy.

I'd recommend checking out skills.sh. It is a huge repository for agent skills which are predefined by organisations and can be installed with simple npx commands. You can also define your own skills within the .agents/skills directory as long as it follows the Agent Skills Standard.

Model Context Protocol or MCP is a protocol for agents to communicate with external services so that the agent could perform actions on that service.

MCP skills act as pipes to a particular service. As an example, if I wanted to run table migrations on Supabase, I could simply connect an MCP server with my Supabase instance and the agent can perform those migrations on my behalf.

Here's a list of MCP servers that I have currently installed in my Claude Code:

A lot of services provide MCP servers for their products: Slack, GitHub, Vercel and many more. Always make sure to check out if any service you are using has an MCP server available with it.

A recommended way to go ahead is to use skills and MCP servers together as they complement each other. You use an MCP server to give raw access to your service, and the agent utilizes it's installed skill to understand how exactly should the task be performed.

Skills take up less context window than MCP since the former is file based and sends only the meta-data to the agent while the latter loads all the tools from every session.

The session loop

Planning

A typical coding agent has 2-4 modes. But the main ones are Plan mode and Execution/Auto mode.

Here is an example prompt in plan mode. This implements Supabase-Next.js authentication in one of my projects:

In plan mode, the agent is set to read only mode. As you can see I have set the reasoning to 'max'. This is a good practice to ensure that the model understands the entire context, your prompt, the codebase as well as learn what resources it been provided with.

You can also see how I have written my prompt. The prompt includes how the authentication flow is to be carried out, what external service we are using (Google OAuth in this case), how the UI should look, where the data should flow and which skills and MCP servers the model should use.

Writing a solid prompt is important, otherwise even with the best tools the agent won't be able to understand your intent and perform the task well. Check out prompting guide to understand how to write such prompts.

The model takes a few minutes, scans the codebase, utilizes it's skills and accesses external resources via MCP. It then churns out a solid plan within the terminal and prompts you whether to proceed with the plan or make some changes in markdown format.

You can either update the plan and tell the agent about the changes, or you can accept the plan and the agent will automatically work on the tasks in the background.

Execution

Once the plan is finalized, the agent asks you to switch modes and start working on the plan. You can now change the reasoning to medium or low since the plan is finalized, and all left to do is to execute that plan.

Now the agent works autonomously in the background performing the task. Now you can either interupt the task in between and ask the agent to perform some other actions, or you can wait until the task is finished. The agent also might ask you for your permissions to run certain scripts and make changes.

Whenever a task is completed, at the end of the session I would write the following prompt:

Update the AGENTS.md and the files/folders in the docs/ directory based on the above conversation, new features added, things we learned and mistakes to avoid.

This is a very simple prompt, but it significantly improves the context within the codebase as well as improves the quality of output. We are basically asking the agent to write down what it learnt in the docs/ directory.

Thinking in sessions

Now if we start a new session or even a different agent altogether, the model is fed with the latest information, pitfalls and complete knowledge about the codebase.

You should, by default, use a new session for every new feature you are integrating in your project. In this way, your context for that session stays fresh and is only focused on that particular feature without unnecessary information from other sessions.

However, if your new task is closely related to a previous session or has something to do with refactoring old work, I would highly recommend re-using that conversation. Use /resume (or similar) command to find out and open up the old conversation, and start with planning mode again.

Behind the scenes, the model loads up that conversation from the database, converts it to KV-cache with all the skills and MCP loaded and it can pick up right where it left off without re-reading the entire codebase.

This results in better output quality, less time spent on reading the context and planning and if using API, reduced token costs.

Conclusion

In this blog, I have discussed my understanding of coding agents, how we can better utilize them by understanding what Harness Engineering is and how do we store context within the codebase itself.

These agents have also made it possible to ship entire apps by only writing english prompts. Now someone who is not from a technical background can utilize these agents to ship projects.

However I think it's still important to have the skill of writing code by hand and understanding technical concepts have never been more important. Although these models have access to powerful tools and write code faster than humans, they don't have a real-world perspective, lack a systems-level thinking and constantly need guidance from the developer.

Only someone who has experienced the pain of writing code by hand is able to understand the true value of these tools. They know the ins and outs of the tools they are using and so they are the ones who write the best prompts for a task.

I hope this blog gave you a motivation to start using agents in your workflow. Happy coding !🚀