"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 — not a thinking member of the team."
That argument is right. For stage one.
At stage one, someone watches AI write code and concludes: "AI = coder." Then they notice that coding isn't the whole of software development. "Therefore AI won't replace engineering entirely." The logic holds. The conclusion doesn't.
At stage two, AI covers exactly what that argument says is missing.
Requirements Gathering: The Clarify Gate in Jira
A stakeholder creates a ticket: "do the ERP integration." The team spends weeks on clarifications in messengers — conversations that never make it into the tracking system, don't get versioned, and disappear when the assignee changes.
One setup already in production: an AI agent runs a structured clarify dialog with the stakeholder directly in Jira. It asks questions across axes — Scope, actors, data, NFR, dependencies, acceptance criteria. The ticket doesn't move to development until goal, scope, and verifiable AC are documented.
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?"
Output: a mature ticket with verifiable AC — the kind that goes into development without a subsequent "that's not what we meant."
Reference trace: github.com/dobryakov/jira-clarify-bot — FastAPI, Docker, webhook contract, ElicitationEngine.
Design and Spec Negotiation
Integrating two systems from different companies: classically, weeks of meetings, correspondence, and manual OpenAPI contract maintenance.
Experiment: two AI agents — one representing each organization — ran the negotiation themselves. Output: chat-history.txt (transcript) and openspec.yaml (agreed OpenAPI). The git history shows the contract forming step-by-step — a visible "collaborative" process, not one monolithic output.
The architectural principle the agents reproduced on their own: the organizational boundary is crossed only by the contract (POST /orders), not by internal data. Ownership of amount recalculation is explicitly anchored in the endpoint description — without this, two services can both calculate total, diverge, and not know who's right.
Reference trace: github.com/dobryakov/bots-discuss-spec
Spec-Driven Development: specify → clarify → plan → tasks
Anti-pattern: one big prompt → agent immediately writes code. An hour later, the structure is unclear, rollback is expensive. At the retro: "AI can't handle architecture" — though the real reason is that no one documented what was being built.
Spec-Driven Development reverses the order. A repository constitution (.specify/) — templates and project memory, filled in before the first feature. Then the chain: specify → clarify → plan → tasks → implement. The spec is the source of truth; code is its derivative.
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.
Reference trace: github.com/dobryakov/ytrader-bybit — full cycle of .specify/ + specs/.
Testing: Eval as Release Criterion
An AI feature that works in a demo breaks in production. Reason: "demo grade eval" — testing on the same inputs used in the pitch. The long tail of real traffic was never run.
Three-layer eval as release gate:
Layer 1 — Regression. 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.
Layer 2 — Distribution check. 20–50 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 — the model is either certain about everything or nothing — fragility signal.
Layer 3 — Human spot-check. Required before the first prod deploy of a new output type. A domain expert reads 10–20 real outputs with specific questions: is there data the model shouldn't have access to? Would an expert consider this correct? Any adversarial exploitation?
One reviewer signs off. If you can't name one, that's already a problem.
Reference trace: github.com/dobryakov/eval-harness
Monitoring and Reproducible Multi-Agent Workflows
A chat agent solves the task from scratch every time. For one-off tasks — acceptable. For production automation, that means no reproducibility at all.
Solution: the agent produces persistent, versioned artifacts rather than ephemeral responses. Dual-file pattern: .workflow.json (workflow graph export) + .meta.md (YAML metadata with agent guidance and workflow_id). The separation matters: the agent reads .meta.md and sees the workflow already exists — it updates the same instance rather than recreating it. A recurring task reuses the validated workflow rather than regenerating it.
LLM as consumer of an event stream (Kafka, webhooks, monitoring) — 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.
Reference trace: github.com/dobryakov/ai-n8n-workflow-builder
What This Actually Depends On
Every practice listed here has an explicit human-in-the-loop checkpoint.
The clarify gate needs an approve from the stakeholder or PO; the eval harness requires sign-off from one named owner; cross-org negotiation additionally requires formal contract verification — outside the agent's autonomy boundary. This is not "AI thinks instead of people" — it's AI removing the preparation overhead so people can think about other things.
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.
Multi-agent pipelines need defined ownership and handoff criteria — they don't self-organize. "One AI catches errors, another fixes them" works exactly as well as the boundaries between agents are defined.
Conclusion
The argument "AI is just a coder, the rest of the SDLC remains human" was accurate at stage one. That stage is over.
Requirements, design, testing, monitoring, self-repair — 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.