Identify SDLC Steps Where Agents Add Leverage
Map the canonical agent loop onto the SDLC and recognise the high-leverage steps where AI agents amplify a team — without replacing the engineers who own the outcomes.
Identify SDLC Steps Where Agents Add Leverage
An agent is not a chatbot with a clever prompt — it is a control loop that observes the world, proposes a plan, takes action, then observes the result and decides what to do next. The exam frames this as the canonical agent loop:
Perceive → Plan → Act → Observe → Reflect
The leverage moves you can pull along the SDLC map directly onto these phases. The trick is to recognise which SDLC step is bottlenecked by which phase of the loop.
The mental model
Think of an agent as a junior engineer with infinite patience but zero institutional knowledge. The senior engineer (you) writes the intent and the guardrails; the agent fills in the mechanical middle.
| SDLC step | Agent leverage | Loop phase that matters most | | --- | --- | --- | | Triage incoming bugs | Read the issue, gather context, draft a repro | Perceive | | Implement a small feature | Propose a diff and a test plan | Plan | | Run the implementation | Open a PR, run CI, iterate on failures | Act → Observe | | Code review prep | Summarise the diff and surface risks | Reflect | | Post-merge follow-up | Watch error rates, file follow-ups | Observe → Reflect |
The points where agents fail spectacularly are almost always the same: someone skipped plan (so there was nothing to review) or skipped reflect (so the agent never noticed it broke the build).
Quick check
Quick check
Which step in the canonical agent loop is most often skipped, and what does skipping it cost you?
Where this shows up on the exam
GH-600 leans heavily on this domain because every later domain assumes you can map a feature to the loop and pick the right SDLC checkpoint to insert a guardrail. If you can explain, in one sentence, where the plan/execution boundary sits for the scenario you're given, you are usually one step from the correct answer.
Key terms
- Canonical agent loop
- Perceive → plan → act → observe → reflect. The minimum cycle every agent runs.
- Plan / execution boundary
- An explicit checkpoint where an agent's proposed plan is approved (by a human or policy) before any side-effects are produced.
- Inspectable artifact
- A durable, reviewable output (file, PR, log, trace) that lets a human audit what the agent did and why.
- Autonomy level
- A classification (e.g., suggest → review → auto-apply) that pairs the risk of an action with the gating it requires.
Common pitfalls
- Treating the agent as a black box: with no inspectable plan or trace, you can't debug bad behaviour and can't onboard reviewers.
- Letting an agent take an irreversible action (force-push, prod migration, external API call with side-effects) at the same autonomy level as a code suggestion.
- Skipping the *observe* and *reflect* steps so the agent never learns from its own failures within a single run.