PulseFlow Tecnologia
← Insights
·7 min read·framework-playbook·readiness·sdlc·governance
PulseFlow Tecnologia

A readiness framework for Agentic AI in the SDLC

Before scaling coding agents across the entire development cycle, an honest assessment is worth doing: which of the ten SDLC dimensions is the team already ready in, and which not yet. Three sources each document a different piece of that readiness - requirements, architecture/code, and governance.

Requirements: specs, not loose prompts

The first readiness test is simple: do requirements reach the agent as a structured specification - user journey, success criteria, technical plan - or as an improvised prompt? GitHub documents this distinction as the difference between spec-driven development and vibe coding: without a spec, "clarity about how it should interact with existing systems" only shows up after the code is already written, when fixing it is already expensive.

Architecture and code: legible to an agent, not just to a human

OpenAI's harness engineering experiment defines the second test: is the repository "legible" enough for an agent to understand the business domain from the code itself, without relying on tacit context in conversations it never sees? Ready teams document architecture decisions inside the repository; unready teams still keep critical knowledge scattered across Slack, meetings, or a single person's head.

Tests: part of the agent's execution, not a later manual step

A ready team treats tests as part of the agent's own execution cycle - running before any PR is considered ready for review, not as a manual check a human does afterward. That's process readiness, not tooling readiness: it requires the test suite to already exist and be reliable enough for the agent to run against it without constant supervision.

Security, DevOps, and observability: the same layer Microsoft describes

Microsoft's central thesis - "AI alone won't change your business. The system running it will" - sets the standard for these three dimensions: native security (not bolted on afterward), DevOps that treats agent deployment as part of the normal pipeline, and observability covering the full cycle - "source, test, deploy, observe, and improve." A ready team already has these three pieces working for human-written code; scaling to agents is an extension, not a build from scratch.

Data: governance that already exists, not created for the agent

Data an agent will access needs classification, scope, and retention policy that should already exist regardless of any agent - if that governance doesn't exist for human access, it won't magically appear once an agent enters the process.

Governance and metrics: defined owners, not diffuse responsibility

The final readiness test: is there a clear owner for every agent in production, with success metrics defined before deployment, not discovered after something already went wrong? Lack of clear ownership is the most reliable sign a team isn't ready yet, regardless of how sophisticated the technology they're using is.

The assessment's ten dimensions

  1. Requirements - structured spec, not a loose prompt
  2. Architecture - decisions documented in the repository, not in Slack
  3. Code - legible to an agent, explicit conventions
  4. Tests - part of execution, not a later manual check
  5. Security - native, not bolted on afterward
  6. DevOps - agent deployment in the same pipeline, not a separate process
  7. Observability - full cycle: source, test, deploy, observe, improve
  8. Data - governance that already exists, not created specifically for the agent
  9. Governance - clear owner per agent
  10. Metrics - success defined before deployment, not after

How to use the assessment

Each dimension gets its own independent score - it's common for a team to be ready on tests and code, but not on data and governance. The goal isn't a single "ready" or "not ready" score; it's a map of where to invest before scaling, because the weakest dimension is what determines the actual size of the incident when (not if) something goes wrong.

Sources