Agentic Engineering in Python: From Vibes to Evidence

Agentic engineering is a disciplined approach to delegating bounded software tasks to AI coding agents while you retain control over intent, constraints, review, and release decisions. Coding agents can turn a vague request into working Python code in seconds. The hard part comes next: deciding whether you understand that code well enough to keep it.

By the end of this tutorial, you’ll understand that:

• Vibe coding asks whether a result looks plausible, while agentic engineering asks what evidence backs the change.
• Agentic engineering runs on two loops: a fast agent execution loop and a slower human acceptance loop.
• The Engineering Evidence Ladder names the evidence you’ve gathered and the evidence you still need.
• The RECAP method reviews a candidate diff by role, edges, contracts, assumptions, and proof.
• Automated checks produce repeatable evidence, but accepting the diff stays your decision.

Agentic engineering may sound novel, but it rests on practices you’re likely already using as a Python developer, like writing tests, adding type hints, refactoring for simplicity, and reviewing changes before merging them. What’s new is how you combine them into a workflow that produces evidence you can check before accepting an agent’s patch.

The resources linked above go deeper into the guardrails and concepts behind an agentic engineering workflow. You don’t need to read them first, but they’re useful next steps.

What Is Agentic Engineering?

Agentic engineering means handing an agent a bounded task and a condition that ends the run, then deciding for yourself whether the result earns a place in the codebase. You supply the goal, the boundaries, and the stopping condition.

The agent inspects the repository, plans the work, edits files, runs tools, observes the results, and iterates until it reaches that condition. For example, you might tell the agent that the task is complete only when the implementation passes the tests in tests/.

You can think of this workflow as two connected loops: the agent execution loop creates a candidate change, and the human acceptance loop decides whether that change belongs in the codebase:

As a quick example, your workflow might look like the following:

• First, in your Define Intent step, you might start with a planning pass in Claude Code’s plan mode or OpenCode’s plan agent. Treating LLMs or agents as brainstorming tools can dramatically shorten the time it takes to define the intent for your feature or project. You also benefit from having the stored plan artifact for future auditing and review processes.

• Next, with your intent as context, the agent begins its agent execution loop. First, it inspects the repo to see what files and directories are available. Then it performs any additional planning it deems necessary to accomplish the goal. Once done writing code, it runs the checks you’ve set up: linting, unit tests, and type checking, to name a few. If these don’t pass, it goes back to its planning phase and continues to iterate.

• Finally, with a diff that has passed your automated checks, you enter the human acceptance loop and systematically check the changes by asking a standard set of questions about the code. If you don’t approve, you clarify your intent and the agent runs another execution loop, and then you repeat the same review cycle. When you do approve, the change has evidence to back it up and goes through continuous integration (CI).

You don’t need to stop for a full manual review after every agent action. Automated checks are what make the agent execution loop fast. Human review remains the acceptance step, and it happens at checkpoints that matter, like a completed diff. As agents take on bigger tasks and produce larger diffs, you’ll shift from reading every line of code to weighing the evidence behind the change: behavior, boundaries, tests, architecture fit, and risk.

The terminology around coding with AI is still changing quickly, but as of now, you’ll see several related terms in the space: