Agentic Software Engineering — slides

A fifteen-slide deck walking through the seven phases of agentic software engineering — one idea per slide, with the diagrams from the canonical post. Use the arrow keys, the on-screen controls, or the Present button to step through.

Slides01 / 15
A SLIDE DECK · FROM THE BLOG
Agentic Software Engineering

Building trustworthy software with AI agents.


fifteen slides through the seven phases
The thesis

Code generation is becoming abundant. Engineering judgment is not.

The real leverage comes from turning product intent into architecture, executable constraints, reviewable changes, and production evidence.

Figure 01

The operating contract

The model supplies execution capacity. The engineer retains judgment and accountability. Gates keep the two connected without confusing their roles.

The modelGatesThe engineerproposes optionsdrafts the coderuns the toolsexecution capacitytestsacceptance criteriareview · securitynothing crosses uncheckeddefine the systemset constraintsapprove riskown the outcomejudgment + accountability
Figure 02

Seven phases, one loop

Five phases reduce ambiguity before production implementation begins. Build and ship run, then production evidence returns to the spec.

A specification that stops being true after deployment was a plan. A living specification incorporates what the system teaches you.

Think & defineBuild & learn01020304050607ConceptArchitectFoundationFeaturesSpecBuildShipproduction evidence feeds back into spec
Phase 01 · Concept

Prototype the experience before production code

  • Generate screens with a design tool — keep the output as raw HTML + CSS, not React.
  • Render each screen to a PNG and check it in.
  • Prototype the awkward states too: empty, loading, error, denied.
  • Don’t pick a stack yet. Choose late enough to choose against requirements.
Talk it outwhat to buildDesign toolClaude · Lovable · StitchHTML + CSSraw screensExport PNGone per screenReference setchecked in, used laterThe HTML is the sketchpad. The PNG is the survey marker.
Phase 02 · Architect

Separate product capabilities from foundation

  • Decide tech after the constraints are visible.
  • Record decisions as ADRs: context, options, decision, trade-off, tripwire.
  • Disagree productively with a model built to agree — specificity is signal, agreement is noise.
Feature pages · built on topDashboardSessionsSession detailSettingsFOUNDATIONstartup · routing · schema · security · observability · test harnessDefine the base before scheduling what rests on it.
Phase 03 · Foundation

Plan a walking skeleton. Every task must boot.

  • Task 00: the start command opens something.
  • Task 01: one route resolves end-to-end.
  • Task 02: real data layer + a test that uses it.
  • Task 03: test harness with teeth.

Build oracles, not pyramids. PNG is the design oracle. Acceptance criteria are behavioural. Testcontainers is the data oracle. Playwright is the flow oracle.

Task 00it startsTask 01one routeTask 02data + testTask 03test harness✓ boots✓ boots✓ boots✓ bootsA change that cannot run cannot give evidence.
Phase 04 · Features

Turn screens into contracts

  • Map the dependency graph. Two tickets touching the same data contract are not independent.
  • Cut into vertical slices that can be demonstrated and tested independently.
  • Write for a competent stranger with no memory — that’s the actual execution condition.

Could a fresh session with no conversation history produce the intended result from this ticket and its linked canonical artefacts?

Phase 05 · Spec & ticketing

The issue tracker is the agent’s external memory

  • Freeze the plan. Step away. Read it end-to-end — some errors live between tickets.
  • One ticket, one bounded context. Do not feed forty tickets into one session.
  • Publish with an idempotent script: draft / published / closed — recoverable from failure.

Persist the remote issue number. Re-running the synchroniser should update the intended issue, never create a duplicate.

Phase 06 · Build

Now — and only now — implementation begins

  • Per-ticket loop: requirement → implement → commit → PR → review → fix → merge.
  • Parallel by design — bought in Phase 04, not free. Worktrees materialise it.
  • Three-tier agent authority: allowed / needs approval / never.

PRs carry evidence, not claims. Commands, results, screenshots, traces, risks, rollback. No side channel for quick fixes to main.

RequirementImplementCommitPull requestReviewFixMergenext ticket →
Phase 07 · Ship

Shipping is a hypothesis

Before deploy, write down:

  • Which metric should move?
  • What error rate is acceptable?
  • Which signal shows a regression?
  • What is the rollback, in one sentence?

Instrument with the feature, not after. Correlate traces, metrics, and logs with the release and with the acceptance criteria.

Specacceptance criteriaBuildtests · review · mergeShipwith a stated checkEvidencetraces · metrics · logssurprises become tickets · the spec gets corrected
Aside

Prefer decisions that produce inspectable artefacts

The more rigorous version usually leaves something another person or session can inspect.
PhaseFragile shortcutDurable alternative
ConceptStart with a framework scaffold.Prototype the journey and freeze visual references before choosing the stack.
ArchitectUse the familiar technology.Record alternatives, rejection reasons, consequences, and a revisit trigger.
FoundationBegin with disconnected layers.Plan a walking skeleton whose every increment boots.
FeaturesKeep a list of screen names.Build a dependency graph and independently verifiable slices.
BuildReport that tests passed.Attach commands, results, screenshots, traces, risks, and rollback to the PR.
ShipDeploy and watch for complaints.State the metric, tolerated failure, regression signal, and rollback first.

Heuristic: if a consequential decision leaves no inspectable trace, a later engineer — and a later agent session — will have to guess.

The proof

The paper trail is the proof

What survives the session is not the code. It is the specification, dependency graph, decision records, test suite, closed issues, review trail, and production evidence — the code is one artefact among many, and often not the most durable one.


The thinking is the asset, not the typing.

Limits

Where this doesn’t fit

  • Exploratory spikes where the goal is to learn fast, not build forever.
  • Two-hour utilities that will be thrown away on Friday.
  • Cases where the concept is still wrong — a beautiful spec for the wrong thing.

Vibe coding optimises for time-to-first-working-thing. Agentic engineering optimises for time-to-safe-change.

Closing

The difference is not the model. It is the control loop.


git worktree · Testcontainers · Playwright · OWASP AI Agent Security · OpenTelemetry

from the blog · claude-lens, built in public · also available in বাংলা