Agentic Methods: Coding With AI Agents, Designing For Agents

TL;DR

"Agentic methods" covers two distinct things colliding right now: AI agents that code alongside the team (read, write, run, verify, in a loop), and agentic architectures we design into our own systems (orchestrating autonomous agents on the product side). In both cases, the same principle applies: an agent is only useful if the contract around it is explicit — scope, errors, permissions, stopping points. The Tech Lead role doesn't disappear, it shifts: fewer lines typed, more specification, review, and governance. The underlying topic isn't tooling, it's clarity — exactly like a well-modelled business workflow.

Introduction — one word, two meanings
Coding with AI agents: what actually changes
Designing agentic architectures
Where humans remain irreplaceable
A Tech Lead checklist for adopting these methods
Conclusion — agents reveal a team's maturity

Introduction — one word, two meanings

"Agentic" has been everywhere for a few months, but it means two different things depending on who's talking:

Coding with AI agents: a tool that reads code, writes diffs, runs commands, launches tests, and iterates until it reaches a correct result — instead of suggesting one line at a time.
Designing agentic systems: a software architecture where autonomous agents (often themselves LLM-based) make decisions, call tools, and cooperate to accomplish a business task — a support chatbot that triggers refunds, a document pipeline that routes complex cases to a human on its own.

These are two separate topics, but the same underlying principle runs through both: an agent — human, AI, or service — is only reliable when it operates inside an explicit frame. It's the same ground I covered when talking about modelling a business workflow: the tool matters less than the clarity of the contract you hand it.

Coding with AI agents: what actually changes

From autocomplete to the agentic loop

The difference isn't the quality of generated code, it's the loop: perceive → plan → act → verify → repeat.

A coding agent can:

read several files to understand the real context,
propose a plan before changing anything,
run the tests and read the failures,
fix its own proposal without intervention,
stop and ask for a decision when ambiguity is too high.

It's no longer "finish my line", it's "own this task, within a given scope." That change in scale also changes how work needs to be framed: a poorly defined task will produce a poorly defined result, agent or not.

The developer's role shifts toward review

What an agent produces has to be read, understood, and validated — not just accepted because the tests are green.

Concretely, this shifts the work:

less time spent typing mechanical code,
more time writing precise specifications,
more time in review — and a more demanding review, not a lighter one,
a responsibility that remains entirely human: what ships to production is signed off by the team, not by the agent.

An agent moving fast on a poorly scoped task only accelerates the production of technical debt. Speed is only a gain if the scoping was already good.

Explicit guardrails

An agent that can read, write, and execute is an agent that can also get things wrong at scale. Guardrails aren't optional:

explicit permissions — what the agent can do on its own, what requires approval,
isolated environments — sandboxes, disposable containers, never direct access to prod,
reversible actions by default — prefer a branch over a push --force, a commit over a reset --hard,
systematic security review — an agent doesn't replace human review on sensitive changes (auth, payments, personal data).

It's the exact same instinct you'd apply to a junior developer: a clear frame, for as long as it takes for trust to be earned through results.

Designing agentic architectures

An agent is a box with a contract

When designing a system where agents (AI or not) cooperate, the first question isn't "which orchestration framework?" but:

what is each agent's exact scope?
what errors can it return, and in what shape?
which tools is it allowed to call, and with what permissions?
what happens when it doesn't know what to do?

An agent without an explicit contract is a service without an interface: it works in a demo and falls apart in production the moment the real case diverges from the tested one.

Orchestration or autonomy: a choice, not a default

Two broad design families keep coming up:

Orchestration: a conductor agent distributes subtasks to specialized agents and arbitrates the results. Predictable, traceable, easier to debug.
Choreography / autonomy: agents decide their own next actions based on context, with no conductor. More flexible, but harder to bound and audit.

Just like with any architecture pattern, the "pattern everywhere" trap applies here too: making a system autonomous because it's the trendy topic, when a classic pipeline would have been enough. Not every domain fits an agentic architecture either — a simple, deterministic process often needs neither an agent nor AI.

Observability: if you can't replay it, you can't debug it

An agentic system makes dynamic decisions — the same input can produce different paths. Without fine-grained traceability, a bug becomes impossible to reproduce:

log every decision and every tool call,
keep a trace of intermediate reasoning, not just the final result,
be able to replay a scenario with the same inputs,
measure cost (tokens, latency, external calls) as a first-class production metric.

An agent you can't observe is an agent you can't evolve with confidence.

Where humans remain irreplaceable

No agent — coding or product — replaces:

business judgment on an ambiguous rule or an undocumented edge case,
architecture decisions that commit the project for years,
arbitration between several valid solutions, when the choice depends on business context,
final accountability for what ships to users.

An agent executes a frame well once you've given it one. It doesn't replace the person who decides on that frame.

A Tech Lead checklist for adopting these methods

Before introducing agents into a team or an architecture, a few questions are worth asking out loud:

Is each agent's scope written down explicitly?
Are permissions (read, write, execute, network) explicit and minimal?
Is there a clear stopping point when the agent hits ambiguity?
Do sensitive actions go through human approval?
Is the system observable: logs, replay, measured cost?
Does code and security review remain mandatory on agent-produced changes?
Can the team still read and understand what the agent produces, without depending on it blindly?

A fuzzy answer to any of these rarely points to an agent problem. It points to a scoping problem that most likely existed before.

Conclusion — agents reveal a team's maturity

Agentic methods alone won't transform a team. But they reveal, faster than ever, whether the fundamentals are already there: clear specifications, explicit errors, well-cut scopes, real governance.

A team that already had a readable business workflow and clear contracts will see agents — AI or architectural — amplify what was already working. A team that was navigating by sight will see the same tools amplify the existing fog, just faster.

Agents are only a tool. The real value stays in the clarity behind them: the contracts, the specs, the guardrails a team chooses to own.