Agentic engineering

You delegate execution. In a regular chat, a model suggests text or a code snippet. An AI agent gets tools to work with the project and performs a sequence of actions. Its autonomy is limited by the permissions granted and the task conditions.

Agentic engineering is suitable both for a new application and changes to an existing one. It is easiest to start with a task where success is immediately clear.

Suitable if you are ready to accept the work. An experienced developer evaluates a solution from experience; a beginner starts with a small task and learns from its result. For a personal catalog, manually searching for a product can be the first check.

The expectation that “everything will work by itself” is not suitable. If an application serves customers, you need to check errors, access permissions, and data integrity. It is too early to delegate this responsibility to an agent without reviewing it yourself.

Ready to try it? Move on to first task. The chapter includes a brief you can use as a starting point.

The agent works from feedback. It reads the project, chooses an action, and sees what happened. A build error, failed test, or human feedback becomes the basis for the next change.

Let's take a learning example with an application form. The requirement "make a good form" leaves the agent with too much guesswork. The condition "an empty field cannot be submitted, and a hint appears beside it" can be verified.

A plan is needed where there are choices. Before changing several parts of an application, agree on the solution design. For a typo, the change itself is enough.

Give the agent a project description, files relevant to the task, and verification commands. When the discussion history starts to sprawl, save the decisions made in a short document.

This approach can be seen on Open, where we show agents working on vibecoding.tech. Open a change in the log and trace the assignment that led to it.

The first task should fit into one verification. Take an existing learning project and add a small feature, such as list search. This lets you see the full path from task to acceptance without dealing with payments, registration, and app publishing at the same time.

Task example. You can adapt this brief to your own catalog. The agent first determines file names and commands from the project.

Write in the language of your task. Describe requirements in the language of your task for the first try, and check how the agent understood them. Keep exact file names, commands, and errors as they appear in the project.

Instead of "make it look nice," attach an example. Specify what should be replicated from it.

Save rules that repeat. It is convenient to keep run commands, checks, and code conventions in an instruction file. Different tools support the AGENTS.md format, but you should check the exact file name and reading order with your chosen agent. Claude Code also uses CLAUDE.md.

Choose a workspace for the task. An agent can be part of an editor, a standalone app, or a terminal program. More importantly, it should be able to open your project, run its checks, and show changes for acceptance.

Claude Code and Codex can be included in the list for your first try. If you prefer to work inside an editor, see Cursor. Look for installation instructions, run requirements, and capabilities that change faster than the method itself on tool cards.

Compare on the same work. Give candidates a source copy of the project and one brief. Record whether the requirements were met, how much the attempts cost, and where you had to intervene.

In RuBench you can view comparisons on tasks in Russian, and in agent table assemble candidates. Choose one tool from them to try on your own application.

From Russia, check the terms of the chosen service. Program access, model access, and payment may differ. An agent's open source code alone does not resolve these questions. Terms are collected in tool cards and in the guide to paying for AI services.

Calculate the cost of an accepted task. Track model usage, repeated attempts, and your own time. One cheap run says nothing about the cost of an accepted result.

If the chosen tool has free or trial access, find out its limitations. For an open-source program, separately check model and hardware requirements. Compare costs with the current plan before you begin.

Measure changes in your work. Record how long a similar task took before, and now include every stage through acceptance. Compare tasks with the same quality requirements.

After the first task, you will see where the time went. If it went on explaining requirements, improve the task description. If it went on repeated mistakes, add a check that catches them before your acceptance.

«Done» is confirmed by checks. Compare the result with the original requirements, review the changes, and walk through the main user flow. Check the test itself against the requirement too: a successful run confirms only the property that was tested.

Permissions set boundaries. To work on a form, an agent does not need permission to change payments or delete production data. An isolated project copy and appropriate permissions let you verify changes before people use them.

Give the requirements and completed change to another agent or person to find errors. Then reproduce the issues found and verify the fixes.

Multiple agents require dividing the work. In parallel, you can explore different parts of a project or verify independent changes. If everyone edits one file, coordination costs can consume the gains. Decide in advance who merges the results and verifies the whole.

An instruction file stores persistent rules, a skill describes a repeatable procedure, and MCP connects tools and data sources. Add them for a specific need. Start with a clear brief and working checks.

The difference is visible in the acceptance method. The terms «vibecoding» and «agentic engineering» are used differently. Simon Willison distinguishes these approaches by whether a person examines the generated code. For acceptance, it is also important to verify the program's behavior.

One tool can be used in different ways. If you accept the first attractive screen without checking other flows, agent mode will not make the work engineering. If requirements are written down, changes are reviewed, and the result is verified, the person's role remains regardless of how much code was generated.

The method has related names. In search results, you may encounter agentic engineering, agentic coding, and «agentic engineering». Here, we use the name «agentic engineering» for the whole path from task to acceptance. The history of the names is covered in AI programming glossary.

The term «agent programming» can also refer to an older approach to building interacting software agents. This meaning is described in Yoav Shoham's Agent-Oriented Programming. The Stanford repository dates it to November 1990. And «agent-based development» belongs to another field.

It is best to learn from completed tasks. After your first feature, learn to review changes in Git, run tests, and read errors. Then move on to working with context and multiple parts of an application. In Guide you can choose the next practical task.

The learning program should lead to acceptance. Check whether there is an independent project, requirement verification, and error analysis. A course on building chatbots solves a different task, even if its title also includes agents. For independent practice, take a small task from your project and bring it to a working result.

For recurring company processes, we develop this way of working in Spec-Driven Company. It starts with the same habit: a task has requirements, and completed work has verification.