# The Agentic PDLC for Software Engineers: Build With Agents
The model does the typing and the sweep. You own the floor it stands on, the boundary it cannot cross, and the check that decides what merges.
6 min read · Beginner · Lesson 4 of 9 in By role · Updated 2026-10-03 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/agentic-pdlc-for-engineers/
> **In short.** In the agentic PDLC the engineering lead writes the context file every coding agent reads and builds
> each bolt from a story file. The lead puts every number the product acts on in tested code, enforces
> every limit in a tool's signature, and wires the harness that blocks a merge when a slice falls
> below its bar. The lead ships a slice a day, letting the model type and never letting it hold the
> boundary.
**In this lesson** you'll learn:
- the engineering lead's eight steps, and why P0 is deliberately not on your clock;
- the three things you own that no model may: the floor, the boundary and the merge check;
- how to use coding agents so they make you faster rather than busier.
## Sound familiar?
- The agent re-implemented a calculation inline, confidently, and it was wrong by eighteen dollars.
- "Review your answer before returning it" was added to the prompt; scores did not move and the bill rose.
- The evaluation job posts a comment on every pull request, and on the Thursday before the pilot someone clicked past it.
Each is a boundary held by a request instead of by code. The engineer's job is to move each one into
code.
## What changes for an engineer?
**You stop treating a prompt rule as a control, and start shipping a slice a day.** Coding agents make
the typing cheap; they do not make it correct. What you own is everything around the typing: the
context the agent reads, the file it builds from, the deterministic floor under it, the limits it
cannot cross, and the check that decides whether what it built may merge.
## Your eight steps
### P0 · Frame: not on the clock
You read the brief and start nothing. An engineer who starts building in P0 is building the prototype
the requirements will later be written around.
### P1 · Design & Spec
**1 · Prepare** the context file every coding tool reads: stack, context layers by path, conventions,
commands that have actually been run, a never-touch list. An hour's work, and the biggest quality lever
you have. [AIDD's five habits](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/what-is-aidd/)
### P2 · Build & Prove: the phase you lead
**2 · Slice**: build each bolt from a six-part story file, never a chat thread. **3 · Floor**: every
number that gets acted on is a function with a unit test. SkyWays' prompt returned $80 where the ledger
said $62. **4 · Layer**: the model calls on top, with an independent checker after the expensive ones.
**5 · Gate**: caps and confirmation tokens in tool signatures, each with two tests seen failing first.
**6 · Harness**: the golden set in CI as a required check, in cost order, per slice.
**7 · Ship**: one bolt a day in dependency order, the shadow path behind a flag, the rollback rehearsed.
[P2 Build & Prove](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/p2-build-and-prove/)
### P3 · Run & Learn
**8 · Operate**: caching that hits, routing by complexity with a loop cap, a trace that redacts, an
injection suite run weekly, and the effort-and-token ledger the product manager's cost number is built
from. [Why the bill is 4×](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/ai-agent-costs/)
## What is yours, and what is not
| Yours to own | Not yours |
| --- | --- |
| The context file, and the story file every bolt is built from | The bolt cut: the architect's; you say whether each bolt can be built alone |
| The deterministic floor: every acted-on number is a tested function | The acceptance bar: the product manager derives it; you make it run |
| The boundary: caps and confirmation tokens in signatures | The golden set's contents and the judge rubric: QA's |
| The harness in CI, and the per-slice rule that blocks a merge | The cut-over and widening: you build the flag; the PM throws it |
| Build order within the cut, integrated the same day, and the ledger | |
## How to use a model in this role
Use a model for **the typing and the sweep, never for the boundary**. It will write a correct function
faster than you can, and just as happily write a cap into a prompt and report the cap as done. Let it
draft *inside* something you wrote: a context file, a story file, a signature you already fixed. Every
line that moves money, changes a booking or writes a trace row is read by a person before it merges.
## Where you'll use it
- **On day one of a repository**: the context file, before the first agent session.
- **The evening before each bolt**: its story file, so the chat window can stay shut.
- **On every change to a gated tool**: two named readers, and the over-cap and no-confirmation tests.
## Why it matters
Coding agents amplify whatever habits surround them. With a floor, a boundary and a harness, they
produce more working software; without them, they produce more plausible software, faster, and the
difference only shows in production.
## Try it
An agent wrote `issue_credit(customer_id, amount)` and the prompt says credits over $50 need approval.
**What do you change before this merges?**
Show the answer
**The signature, and two tests.** Give `amount` a bound so a value over $50 raises unless a valid
confirmation token, created only by a person's approval, is passed; write `test_over_cap_raises` and
`test_no_confirmation_raises`, and see both fail before the fix makes them pass. Keep the sentence in the
prompt so the agent behaves well by default. Band the tool as money, so the change needs two named
readers.