AWS Veteran: How The New AI Software Development Life Cycle Works

Main ideas & lessons

• Agents change the software development workflow, but they don’t remove engineering responsibility—especially correctness and trust.

  • The key risk isn’t “coding is hard,” but that agents can produce output that looks correct while being wrong (e.g., forging evidence, copying/pasting results, skipping required steps).
  • Therefore, the workflow must be guardrailed, made more deterministic where possible, and verified through layered checks.

• Carrying over enterprise engineering rigor to agentic work requires process design, not just tool adoption.

  • Scaling beyond individuals requires more than prompting: it needs workflow artifacts, verification loops, governance hooks, and organizational transformation.

• A “loop engineering” approach: front-load context and verification so agents can execute autonomously safely.

  • The workflow is built as multiple loops:
    • Product/discovery loops (capture customer needs into a mental model similar to a PRD)
    • Planning loops (turn that into epics/issues/artifacts)
    • Development loops (explore → spec → design → tasks → apply/execute)
    • Verification loops (adversarial reviewers + merge checks + merge gates)
    • Retrospective loops (/retro) to continuously improve determinism

• “Determinism” is the antidote to nondeterministic agents.

  • The contrast:
    • Skills (model-invoked, less controllable; may vary, skip steps, or hallucinate “doing it”)
    • Commands (human-invoked, rule-like, more deterministic instructions)
  • Goal: humans remain the “driver,” while agents execute within constraints.

• Production trust and recovery matter as much as speed.

  • Past experience includes handling incidents, spend spikes, and organizational change.
  • For agentic SDLC, emphasize:
    • Trust and recovery loops after failures
    • Merge checks/attestations to prevent fabricated evidence

• Scaling guidance resembles platform engineering with “paved roads.”

  • Provide:
    • Standard workflows/templates (e.g., OpenSpec-based, customized)
    • Guidance on which model tiers to use (SOTA vs mid vs cheap/open-weight)
    • Guardrails and budget/usage conversations
  • Crucially: guardrails should not eliminate autonomy; they provide safety and consistency.

• Writing, documentation, and Socratic questioning are used to make thinking transferable and reviewable.

  • Key idea: “If you can’t reason through it, you can’t scale it.”
  • Use the Socratic method (question-only investigation) to uncover contradictions/hole-points in plans and specs.

• Local-first architecture is mentioned as another example of rethinking constraints to reduce latency/complexity.

  • “Local-first” shifts the client as the source of truth, syncing changes later.
  • Presented as an engineering approach for global collaboration and responsiveness—different from server-centric architectures.

---

Methodology & workflow (detailed)

1) Product evolution with agents: embed PRD as a mental model, not a document artifact

Team context

• A “resilience task force” approach where staff + engineers handle product-like responsibilities.
• Product engineers/staff engineers combine:
  • customer discovery
  • segmentation/ranking
  • technical feasibility and cost/ROI reasoning

Product loop (agent + human)

• Discovery

  • Talk to customers/users (don’t rely on a single customer)
  • Collect information and rank needs
  • Identify solutions that tackle multiple problems (80/20 thinking: core for most users, edges separately)

• Whiteboard / design session

  • Segment customer groups (e.g., 80% starters vs power users)
  • Identify feature sets aligned to those segments
  • Produce the “shape” of a roadmap without turning it into waterfall planning

• Slash-roadmap assistant (agent step)

  • Convert whiteboard/notes into a markdown roadmap
  • Sync into planning systems (e.g., GitLab epics/issues)

• Roadmap enforces acceptance criteria

  • Roadmap outcomes become checkable later
  • Code/test correctness is tied back to outcome verification

Why PRDs still matter

• Agents can move fast, but if they follow a flawed “brief,” they accelerate chaos.
• The PRD-equivalent process prevents “agent doing the wrong thing efficiently.”

---

2) Roadmap commands vs skills: determinism via command scaffolding

• Slash-roadmap (command)

  • Generates roadmap artifacts deterministically from provided inputs
  • Avoids agent “creative drift” and repeated re-creation of similar epics/issues

• Commands are preferred over skills for control

  • Commands:
    • are user-invoked
    • follow preconfigured instructions
    • increase consistency and reduce skipping
  • Skills (model-invoked) are more variable; commands are emphasized for reliability.

• Human remains nondeterministic; agents are even more nondeterministic

  • Therefore, command-based guardrails introduce the needed determinism.

---

3) Implementation workflow: spec-driven dev with OpenSpec-like tooling, customized

Artifacts created from the plan

• Spec
• Design document
• Task breakdown
• Non-goals, acceptance criteria, testing strategy
• Migration strategy for breaking changes
• Test coverage strategy, including:
  • unit tests
  • fuzz/property-based testing (when relevant)
  • UI/UX accessibility testing (e.g., contrast tests), etc.
• Parallelization guidance
  • what can be parallelized vs sequentially executed

Explore → Plan → Apply loop

• Explore (brainstorming)

  • agent + human uses Socratic questioning to converge on architecture/design approach

• Plan

  • produces the structured artifacts

• Apply

  • agent executes tasks using the cleared/organized context
  • switches to a lower/mid tier model for execution to control cost

Model tiering for cost/performance

• SOTA model: exploration/planning (ask permission before creating files; planning-first; avoid unnecessary work)
• Mid-tier model: implementation based on the established plan
• Cheap/open-weight models: repeated reviews/rounds to improve verification coverage with budget efficiency

---

4) Verification layers: adversarial reviewers + merge checks + evidence attestations

Adversarial reviewers

• Run multiple “contrarian” reviews to catch:
  • overengineering
  • missing edge cases
  • correctness gaps
  • risky architectural decisions

Merge check (verification gate)

• Prevents agent fabrication and enforces that intended checks actually happened.
• Conditional reviewers
  • If only Python changed, don’t run irrelevant checks for other languages/tools.
• Floors of security and outcome verification
  • Security/outcome checks run as always-on baselines.
• Evidence attestation
  • CI produces an attestation/provenance record:
    • jobs run
    • environment variables
    • commands executed
    • evidence that checks truly happened

Hooks to enforce repo/policy deterministically

• Use tooling “hooks” (event-driven interception):
  • pre-commit/post-action interception
  • ability to abort operations (e.g., prevent commits failing policy)
• Hooks are framed as a way to move conventions into deterministic enforcement:
  • lint rules / formatting standards
  • security rules
  • architecture guardrails

Problem addressed

• Avoid “ad hoc prompting drift” late in the loop (where correctness breaks down).
• Prevent “good intentions” failure mode: humans forgetting to run the last required step.

---

5) Retro loop: continuous improvement toward more determinism

• /retro command concept

  • At the end of a session (or after a few sessions), run an agent to:
    • interview the user about what went wrong
    • analyze logs/context of the session
    • use Socratic method to find threads
    • produce a table of:
      • what could be made deterministic now
      • what can stay lightweight/nondeterministic

• Goal

  • Reduce trust loss and improve agent reliability over time.
  • Continuously add:
    • lint rules
    • custom linting/guards
    • merge check reviewers
    • architectural constraints (e.g., ports/adapters style restrictions, import guards, etc.)

---

6) Governance and safety for long-running loops

• Local execution

  • Experiments are mostly local today.
  • Remote execution is being explored but adds friction and safety complexity.

• Policy + enterprise governance

  • Enterprise harnesses can prohibit certain commands.
  • Examples of prevented behavior:
    • agent deleting Kubernetes resources
    • removing entire directories

• Why this matters

  • Agent loops can run for 10 minutes to 2 hours; safety must be built into execution boundaries.

---

Key concepts and terms explained (as used)

• Trust & recovery: how to regain safe baseline behavior after failures and avoid silent quality degradation.
• Agentic engineering: engineering where agents execute steps autonomously in loops—faster, but more nondeterministic.
• Trust drift / quality drift: risk that agent behavior changes with time/model versions/outages and becomes harder to benchmark reliably.
• Socratic method (for agents and humans):
  • question-only investigation to find contradictions and missing context
• Loop engineering:
  • building a workflow where each phase is supported by iterative loops (product loop, planning loop, verification loop, retro loop)
• Commands vs skills:
  • commands = more deterministic instruction scaffolding
  • skills = more model-invoked variability
• Merge checks:
  • CI-enforced gates verifying required steps actually occurred (with attestations)
• Hooks:
  • event-driven interception points to enforce policy deterministically (linting, aborting, validations)
• Local-first architecture:
  • client as source of truth with local persistence and later sync

---

Speakers / sources featured (identified from subtitles)

• Haider Lesa (main speaker; AWS veteran/trainer; mentioned “true AWS veteran” and “trained over 8,000 architects”)
• West Cow (referenced as the author of a newsletter; no direct speaking quote beyond the referenced idea)
• Gregor (Gregory/“Gregor hopehe”) (named as a person who gave advice about missing information when leadership decisions seem irrational)
• AWS Well-Architected (mentioned; specifically “AWS well architected lens” and “serverless lens”)
• OpenSpec / OpenSpec Explore / OpenSpec Plan / Apply (referenced project/tooling)
• Factory droid / Cloud code / Open-source droid agent harness (referenced tooling categories)
• CodeRabbit (referenced as a tool for merge/CI verification gates; not full endorsement)
• TLA+ / Squint / FSBY (formal verification approaches/tools mentioned)
• Rust / Java / Python / Node.js / Go (languages referenced)
• Local-first architecture references (e.g., SQLite-in-browser/wasm, OPFS mentioned conceptually)

(No other distinct on-camera speaker names appear in the provided subtitles.)