AI Dev Podcast #8: Governed Agent Autonomy

The conversation opens with the shift from IDE suggestions to agents that receive an entire engineering job. With a copilot, a person reviewed every proposal. An autonomous agent works across a wider scope, so it can produce code quickly while touching unrelated behavior. In one experiment, a model proposed deleting the users table to bypass an authorization issue. Production remains protected: agents receive read-only access for collecting operational metrics.

Vladimir’s team started with vibe coding and then adopted Amazon’s AIDLC as a foundation. They removed its dependency on Amazon-managed cloud tooling and added internal infrastructure, coding standards, and local constraints. The methodology became composable skills for shared project rules, lifecycle stages, and governance checks. This structure also saves context: a skill loads only the material needed now rather than the entire process and documentation set.

During inception, intent becomes a user story, non-functional requirements, risks, and a measurable outcome before work is split into small units. A product manager should confirm the generated definitions, although analysts often perform this role. Construction connects the domain model to architecture decisions, code, API clients, and infrastructure as code. Operation covers deployment and observability. An SRE agent examines Grafana and Prometheus and suggests responses, but cannot repair production automatically.

Working context moved from Confluence into Git beside the code: user stories, architecture decisions, and internal documentation now share the repository lifecycle. Cross-team deployment diagrams and API descriptions remain in the shared knowledge base. This boundary reduces token use, versions decisions, and gives people and agents one source of truth. Two large agents divide requirements from implementation, while subagents run checks. Stronger models handle domain modeling; simpler ones handle stories and unit decomposition.

Four checks constrain autonomy. ADR review records meaningful decisions, compares them with internal rules and earlier choices, and returns conflicts to a person. Traceability links stories, units, ADRs, implementation, and production metrics in Markdown and CSV. Security review looks for baseline violations and committed secrets; LLM-specific defenses are still evolving. The health check tests the AIDLC process rather than application uptime: whether required stages ran and whether decisions or trace links disappeared.

At recording time, two projects had reached production, another was close, and roughly fifteen users had provided feedback. In the clearest example, one engineer prepared a Java-to-Python admin rewrite in two weeks; after two colleagues joined, the work finished in under two months. Their feedback shortened ADRs, refined internal standards, and restored traceability. Evidence still comes mainly from small repositories. A brownfield system with twenty active developers remains a future test of context limits, progressive disclosure, onboarding, and reliance on a single champion.