Agentic Engineering

A software developer with ten years of experience starts using a coding agent. The agent writes code far faster than any person can type. The developer's first worry is whether those ten years still count for anything.

They do, and the term agentic engineering describes how. It is a way of building software in which an AI agent writes most of the code, and an experienced person directs the work: the person says what to build, gives the agent the rules of the project, and checks every result.

This lesson covers what kinds of work an agent can do, what directing an agent means in practice, how a developer's unwritten knowledge is turned into a file the agent can read, and what one round of work looks like. After this lesson you can explain the term and describe the part the human plays in it.

1. One agent, many kinds of work

Nothing about an agent is specific to programming. An agent is a model in a loop with tools, and its job is whatever it is pointed at.

In data science, a "messy export" is a data file with problems such as missing values, repeated rows, or dates in three different formats. The agent repairs the file and then plots the cleaned data. In research, the agent reads many documents and returns an answer together with the places it found each claim. In software development, the agent writes code, runs it to see whether it works, reads the error messages, and corrects the code.

The same agent loop is behind all three. At the time of writing, software development is the field in which this way of working is most widely used, and it is the one this lesson follows.

2. A different skill becomes the important one

A codebase is the complete set of code files that make up one software project. A real codebase can hold thousands of files written by many people over many years.

When an agent is pointed at a codebase, the developer's daily work changes. Before, a large share of the time went into typing code. Now the agent types. The skill that matters most becomes a different one: directing the agent so that what it produces is correct and fits the project.

This skill is what the term agentic engineering names. It has three parts, and the following sections take them one at a time:

1. Giving the agent the rules of the project.
2. Asking for a change precisely.
3. Reviewing what comes back.

3. What steering means

An agent that receives a loose request has many directions it could reasonably take. Ask it to "add discount codes" and it could store the discount in several different ways, put the new code in several different places, and handle errors in several different styles. All of these might run without errors. Only a few of them fit this particular project.

flowchart LR
    A["The agent<br/>everything it knows<br/>how to do"] --> D1["A direction it could<br/>plausibly take"]
    A --> G["Your guardrails"]
    A --> D2["Another direction it<br/>could plausibly take"]
    G --> C["The change you<br/>actually wanted"]

The diagram shows the agent on the left with many possible directions fanning out from it. The person's guardrails narrow that fan to one path, and the path ends at the change that was actually wanted. Guardrails here means the limits and rules the person sets: project rules, a precise request, required tests, and review. The word comes from the barriers along a road that keep a car from leaving it.

Neither half is of much use alone:

• The agent without guardrails produces a lot of code quickly, in whatever direction seemed plausible to it. Much of it will not fit the project.
• The guardrails without the agent are a list of rules with nobody to carry them out at speed.

Steering does not take anything away from the agent. Its broad knowledge and its speed are still there. They are pointed at one target.

4. The developer's judgement is the input

It is tempting to think that an agent that writes code replaces the knowledge of the person who used to write it. In agentic engineering the relation is the opposite. The person's judgement is what goes into the process. It is not the thing being replaced.

An experienced developer knows what good work looks like in their field. They know which shortcuts cause trouble six months later, which errors cost money, and what the rest of the team expects. An agent has general knowledge from training, but it does not know this project's history or its unwritten rules.

Those years of knowing what good looks like keep their value. They are used in two places: before the work, to set the direction, and after the work, to judge the result. A person without that experience can still ask an agent for code, but cannot tell whether the answer is sound. That difference is the subject of the next lesson, on vibe coding.

5. Writing the knowledge down

Much of what an experienced developer knows about a project was never written anywhere. It lives in the heads of the team. An agent cannot read heads, so the first practical task is to put that knowledge where the agent can use it: in a file.

Here are four rules a developer on a payments project might know without ever having written them down:

- money is integer cents, never a float
- every request carries the tenant id
- retries belong to the caller, not to the client
- only the repository layer is allowed to touch the database

And here is the same knowledge as a file in the project:

conventions.md

# How this codebase works

Money is integer cents. Never a float.
Every request carries the tenant id.
Retries belong to the caller.
Only the repository layer touches
the database.

A convention is a rule a team has agreed on for how its code is written. Each of the four deserves a sentence of explanation, because they show what kind of knowledge is meant:

• Money is integer cents, never a float. An amount such as 18.50 is stored as the whole number 1850 (cents). A "float" is a way computers store numbers with a decimal point, and it can introduce tiny rounding errors. With money, tiny errors add up to wrong totals.
• Every request carries the tenant id. A "tenant" is one customer organisation in a system shared by many customers. Every operation has to state which customer it is for, so that one customer's data is never shown to another.
• Retries belong to the caller. A "retry" is a second attempt after a failure. The "caller" is the code that asks for an operation, and the "client" is the shared piece of code that sends the request on to another system. The rule says that only the caller tries again, so that two parts do not both retry and send the same payment twice.
• Only the repository layer touches the database. A "layer" is one part of the code with one job. The rule says that all reading and writing of stored data goes through that single part.

The model could not guess any of these. Other projects make other choices. Once the rules are in conventions.md, the agent can read the file at the start of a task, and the rules become part of its context. This is the same idea as an agent skill: knowledge written once, in a file, and reused.

The work in this step is not typing code. It is noticing what one knows and writing it down clearly.

6. One round of work

With the conventions in place, a round of work has three steps.

Step 1: the person asks.

Add a discount-code field to checkout. Follow conventions.md, and write the test first.

This request does three things. It names the change (a field for a discount code on the checkout page). It points the agent to the project rules. It also says how to proceed: write the test first. A test is a small piece of code that checks whether other code does what it should. Writing it first means the agent has to state what "working" means before it writes the feature, and it can then run the test to check its own work.

Step 2: the agent works.

checkout.ts edited  ·  discount.ts added  ·  checkout.test.ts added

The agent changed one existing file and created two new ones. The names ending in .ts are code files. The file with .test in its name holds the tests.

Step 3: the person reviews. The developer reads the diff. A diff is a view that shows exactly which lines were added, changed, or removed, so the reader does not have to compare whole files by eye. In this example the developer finds two things that need to change. The rest of the work is accepted as it is. The two corrections go back to the agent as a new request, and the round repeats.

flowchart LR
    A["Person: precise request<br/>plus conventions"] --> B["Agent: edits and adds files,<br/>runs the tests"]
    B --> C["Person: reads the diff"]
    C -- "changes needed" --> A
    C -- "accepted" --> D["Change is kept"]

The loop shows who decides what. What gets built is the person's decision. What counts as good enough is also the person's decision. What has changed is how much of the code the person types.

7. What the person is still responsible for

Since the agent wrote the code, it may seem that the agent is responsible for it. It is not. The person who accepts a change is responsible for it, in the same way as for code written by hand.

This is why review cannot be skipped in agentic engineering. A model can produce code that looks right and is wrong, in the same way that it can state a false fact with confidence (see the lesson on hallucinations). Tests catch some of these errors. A reader who understands the code catches others. Both are part of the guardrails.

The pieces of the practice, collected:

Interview points

• An agent is not specific to code. The same loop of model and tools does data cleaning and plotting, research with sources, and software development.
• Agentic engineering is software development in which an agent writes most of the code and an experienced developer directs it and reviews the result.
• Steering means narrowing the many plausible directions an agent could take to the one change that was wanted, by means of guardrails such as conventions, precise requests, tests, and review.
• The agent's knowledge and speed and the developer's guardrails are each of little use without the other.
• The developer's judgement is the input to the process. Knowing what good work looks like is needed to set the direction and to evaluate the output.
• Unwritten project knowledge has to be written into a file, such as a conventions file, so that it becomes part of the agent's context.
• A typical round is a precise request that refers to the conventions and asks for a test first, followed by the agent's edits, followed by the developer reading the diff and requesting corrections.
• The developer still decides what is built and what is good enough, and remains responsible for the code that is accepted. The amount of typing is what changes.

Summary

• An agent's job depends on what it is pointed at: data, research, or code.
• Agentic engineering is the skill of directing a coding agent.
• Guardrails turn many possible directions into the one intended change.
• The person's experience is used to guide and to judge. It is not replaced.
• Project rules are written into a file so the agent can read them.
• Work goes in rounds: request, agent edits, review of the diff.
• The person decides what is built and whether it is good enough.
• The person types less and stays responsible for the result.