{"id":82,"date":"2026-07-31T14:58:03","date_gmt":"2026-07-31T14:58:03","guid":{"rendered":"https:\/\/www.dobryakov.net\/blog\/82\/"},"modified":"2026-07-31T14:58:03","modified_gmt":"2026-07-31T14:58:03","slug":"ai-sdlc-full-cycle","status":"publish","type":"post","link":"https:\/\/www.dobryakov.net\/blog\/82\/","title":{"rendered":"AI Is Not Just a Coder: How AI Covers the Entire Software Development Lifecycle"},"content":{"rendered":"

"Writing code is only a small part of the SDLC. There's also stakeholder interviews, requirements formulation, architectural design, testing, monitoring. AI is just a very fast coder \u2014 not a thinking member of the team."<\/p>\n

That argument is right. For stage one.<\/p>\n

At stage one, someone watches AI write code and concludes: "AI = coder." Then they notice that coding isn't the whole of software development<\/a>. "Therefore AI won't replace engineering entirely." The logic holds. The conclusion doesn't.<\/p>\n

At stage two, AI covers exactly what that argument says is missing.<\/p>\n

<\/p>\n

Requirements Gathering: The Clarify Gate in Jira<\/h2>\n

A stakeholder creates a ticket: "do the ERP integration." The team spends weeks on clarifications in messengers \u2014 conversations that never make it into the tracking system, don't get versioned, and disappear when the assignee changes.<\/p>\n

One setup already in production: an AI agent runs a structured clarify dialog with the stakeholder directly in Jira. It asks questions across axes \u2014 Scope, actors, data, NFR, dependencies, acceptance criteria<\/a>. The ticket doesn't move to development until goal, scope, and verifiable AC are documented.<\/p>\n

With project context (project bible + history of similar tickets + corpus retrieval), the agent doesn't ask generic questions. It asks grounded ones: "In the architecture, the catalog uses Elasticsearch and a B2B storefront in PostgreSQL. Is the report against the full index or just the storefront?"<\/p>\n

Output: a mature ticket with verifiable AC \u2014 the kind that goes into development without a subsequent "that's not what we meant."<\/p>\n

Reference trace: github.com\/dobryakov\/jira-clarify-bot<\/a> \u2014 FastAPI, Docker, webhook contract, ElicitationEngine.<\/p>\n

Design and Spec Negotiation<\/h2>\n

Integrating two systems from different companies: classically, weeks of meetings, correspondence, and manual OpenAPI contract maintenance.<\/p>\n

Experiment: two AI agents \u2014 one representing each organization \u2014 ran the negotiation themselves. Output: chat-history.txt<\/code> (transcript) and openspec.yaml<\/code> (agreed OpenAPI). The git history shows the contract forming step-by-step \u2014 a visible "collaborative" process, not one monolithic output.<\/p>\n

The architectural principle the agents reproduced on their own: the organizational boundary is crossed only by the contract (POST \/orders<\/code>), not by internal data. Ownership of amount recalculation is explicitly anchored in the endpoint description \u2014 without this, two services can both calculate total, diverge, and not know who's right.<\/p>\n

Reference trace: github.com\/dobryakov\/bots-discuss-spec<\/a><\/p>\n

Spec-Driven Development: specify \u2192 clarify \u2192 plan \u2192 tasks<\/h2>\n

Anti-pattern: one big prompt \u2192 agent immediately writes code. An hour later, the structure is unclear, rollback is expensive. At the retro: "AI can't handle architecture" \u2014 though the real reason is that no one documented what was being built.<\/p>\n

Spec-Driven Development reverses the order. A repository constitution (.specify\/<\/code>) \u2014 templates and project memory, filled in before the first feature. Then the chain: specify \u2192 clarify \u2192 plan \u2192 tasks \u2192 implement. The spec is the source of truth; code is its derivative.<\/p>\n

The agent doesn't reinvent structure each time: it inherits templates from project memory and operates within stable decisions about stack and conventions. Parallel features get consistent scope that makes sense in PRs and in conversation.<\/p>\n

Reference trace: github.com\/dobryakov\/ytrader-bybit<\/a> \u2014 full cycle of .specify\/<\/code> + specs\/<\/code>.<\/p>\n

Testing: Eval as Release Criterion<\/h2>\n

An AI feature that works in a demo breaks in production. Reason: "demo grade eval" \u2014 testing on the same inputs used in the pitch. The long tail of real traffic was never run.<\/p>\n

Three-layer eval as release gate:<\/p>\n

Layer 1 \u2014 Regression.<\/strong> A fixed set of cases with known expected output: edge cases from real incidents (not from demos), adversarial inputs for each output type. Any new failure blocks the release.<\/p>\n

Layer 2 \u2014 Distribution check.<\/strong> 20\u201350 fresh real inputs through the new version. Not checking against an "ideal," but against a diff from the previous release snapshot: length\/format distribution, changes in retrieved chunks, confidence shifting to extremes \u2014 the model is either certain about everything or nothing \u2014 fragility signal.<\/p>\n

Layer 3 \u2014 Human spot-check.<\/strong> Required before the first prod deploy of a new output type. A domain expert reads 10\u201320 real outputs with specific questions: is there data the model shouldn't have access to? Would an expert consider this correct? Any adversarial exploitation?<\/p>\n

One reviewer signs off. If you can't name one, that's already a problem.<\/p>\n

Reference trace: github.com\/dobryakov\/eval-harness<\/a><\/p>\n

Monitoring and Reproducible Multi-Agent Workflows<\/h2>\n

A chat agent solves the task from scratch every time. For one-off tasks \u2014 acceptable. For production automation, that means no reproducibility at all.<\/p>\n

Solution: the agent produces persistent, versioned artifacts rather than ephemeral responses. Dual-file pattern: .workflow.json<\/code> (workflow graph export) + <\/em>.meta.md<\/code> (YAML metadata with agent guidance and workflow_id<\/code>). The separation matters: the agent reads .meta.md<\/code> and sees the workflow already exists \u2014 it updates the same instance rather than recreating it. A recurring task reuses the validated workflow rather than regenerating it.<\/p>\n

LLM as consumer of an event stream (Kafka, webhooks, monitoring) \u2014 parses logs, flags anomalies, writes root-cause analyses. Multi-agent pipeline: one agent catches errors, one fixes them, one reviews and verifies, one runs security and fault tolerance checks.<\/p>\n

Reference trace: github.com\/dobryakov\/ai-n8n-workflow-builder<\/a><\/p>\n

What This Actually Depends On<\/h2>\n

Every practice listed here has an explicit human-in-the-loop checkpoint.<\/p>\n

The clarify gate needs an approve<\/code> from the stakeholder or PO; the eval harness requires sign-off from one named owner; cross-org negotiation additionally requires formal contract verification \u2014 outside the agent's autonomy boundary. This is not "AI thinks instead of people" \u2014 it's AI removing the preparation overhead so people can think about other things.<\/p>\n

None of this works without the right setup. A clarify gate without a project bible asks generic questions. Cross-org negotiation without an explicit trust model is a proof of concept, not a production tool. An eval harness without cases from real incidents becomes the same demo-grade it was trying to replace.<\/p>\n

Multi-agent pipelines need defined ownership and handoff criteria \u2014 they don't self-organize. "One AI catches errors, another fixes them" works exactly as well as the boundaries between agents are defined.<\/p>\n

Conclusion<\/h2>\n

The argument "AI is just a coder, the rest of the SDLC remains human" was accurate at stage one. That stage is over.<\/p>\n

Requirements, design, testing, monitoring, self-repair \u2014 each has working implementations with public artifacts. The only question is which teams have reorganized their work around this, and which ones are still running on stage-one assumptions.<\/p>\n","protected":false},"excerpt":{"rendered":"

‘AI is just a very fast intern coder’ is an accurate description of stage one. At stage two, AI becomes an executor of thinking at every step of the SDLC \u2014 from clarify dialogs with stakeholders in Jira to multi-agent pipelines that catch, fix, and verify themselves.<\/p>\n","protected":false},"author":0,"featured_media":81,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24,68],"tags":[26,51,70,71,69,72],"class_list":["post-82","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-engineering","category-engineering-leadership","tag-ai-agents","tag-eval","tag-multi-agent","tag-requirements","tag-sdlc","tag-spec-driven-development"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t