{"id":233,"date":"2026-11-01T09:01:34","date_gmt":"2026-11-01T09:01:34","guid":{"rendered":"https:\/\/www.dobryakov.net\/blog\/233\/"},"modified":"2026-11-01T09:01:34","modified_gmt":"2026-11-01T09:01:34","slug":"sdlc-no-human-needed","status":"publish","type":"post","link":"https:\/\/www.dobryakov.net\/blog\/233\/","title":{"rendered":"\u00abAI Writes Code, but a Human Still Has to Run the Project\u00bb \u2014 No. The Entire SDLC Runs on Agents Now"},"content":{"rendered":"

I read this opinion ten times a week. Okay, the argument goes, AI can write code \u2014 fine. But to actually run<\/em> a project, you need a human: talk to stakeholders, write a plan, set tasks for that same AI, configure infrastructure, Git, servers, monitoring. And surely no one is replacing the human there!<\/p>\n

My eyes roll back every time. What?<\/p>\n

Let me walk through the entire cycle. Step by step. At every step, I will show you not a fantasy, but a specific practice with a tool underneath it \u2014 because I have already run this cycle hands-on.<\/p>\n

<\/p>\n

Where the \u00abIrreplaceable Human\u00bb Actually Lives \u2014 and What It Costs<\/h2>\n

Faith in the irreplaceable human on the management loop costs money. While you keep a live analyst spending weeks reconciling the chaotic wishes of five stakeholders into a single document; while a tech lead manually slices an epic into tasks; while an engineer sits reading endless logs to spot an anomaly \u2014 you are paying for work an agent does in hours, and overnight too.<\/p>\n

And the real cost is that you fall behind. While one team takes a month to agree on requirements, another ships a feature. The difference is not who is smarter. The difference is who still keeps a human where an agent has been sufficient for a long time.<\/p>\n

Requirements: The Agent Won't Let an Immature Task Into Development<\/h2>\n

Building a conversational bot-agent that discusses a project with stakeholders over chat or email is something any student can do. Slightly harder is a voice mode where the bot initiates a Zoom or Google Meet call and conducts the conversation by voice \u2014 but there are no technical blockers here.<\/p>\n

The agent will not only read through all the chaotic wants and wishes of stakeholders, but will form a single, consistent picture, ask questions, and clarify details. Don't believe it? Throw random wishes from three to five of your stakeholders into a pile of files and give a prompt like: \u00abConsolidate this data into a unified picture, detect contradictions, compile a list of questions, group them, and format as emails to specific recipients.\u00bb This is elementary.<\/p>\n

Then the cycle continues: new data arrives \u2014 feed it to the agent \u2014 it solders it into the documentation or asks a new question. As soon as there are zero open questions \u2014 go to the next step.<\/p>\n

The agent will then knock together an HTML prototype, show it to each stakeholder, and ask: is this what you wanted? Really? Click through it, let me watch.<\/p>\n

A couple of days of automated correspondence \u2014 and the output is strict, consistent FRs, NFRs, priorities, and goals.<\/p>\n

This is not theory. I built a clarify-gate directly in Jira: the agent conducts a structured dialogue across axes (scope, actors, data, NFRs, dependencies, acceptance criteria) and does not let a task into development until the definition is mature<\/strong>. With project context, the questions are not generic, but grounded in the specific system. The output is a mature ticket with verifiable ACs, not \u00abdo an integration with ERP\u00bb. The code is public: jira-clarify-bot<\/code>, FastAPI, Docker, a webhook contract. And I started embedding AI into the management loop \u2014 requirements and definition \u2014 back in my enterprise role, targeting the management layer, not the code.<\/p>\n

Design: Two Agents Negotiate the Contract Themselves<\/h2>\n

What's next? Design and negotiation \u2014 supposedly another sacred human zone.<\/p>\n

Take two AI agents, one for each side of an integration, and let them conduct the negotiation and agree on the contract themselves. The output is not \u00abwe agreed on a call\u00bb, but an artifact: openspec.yaml<\/code>, a transcript of the negotiation, and a git history of the contract's step-by-step formation. The principle is simple: the organizational boundary is crossed only by the contract (POST \/orders<\/code>), not by internal guts; who owns what is wired directly into the endpoint. The transport across org boundaries is A2A over Git, with a shared repo as the live channel (bots-discuss-spec<\/code>, a2a-example<\/code>). I have written about this agent-to-agent engineering approach<\/a> before \u2014 two agents, one live call, and the plumbing required to make it work.<\/p>\n

If you fear the agent \u00abdoesn't understand architecture\u00bb \u2014 make it read a book. RAG over Tanenbaum plus a wiki graph, so decisions rest on canon, not on model memory.<\/p>\n

At Askona, I locked in asynchronous event-driven integration as the corporate standard across dozens of services and teams with different owners \u2014 a pipeline handling millions of events per day. This is not a sandbox.<\/p>\n

Planning and Infra: \u00abWhat's So Hard About It?\u00bb<\/h2>\n

Decomposition into a work plan? Anyone who has watched agents build plans has seen this. If plan mode in Cursor isn't enough for you, look at how GitHub SpecKit or BMAD works. With those, the agent writes out the decomposition for itself.<\/p>\n

I run this through Spec-Driven Development: specify \u2192 clarify \u2192 plan \u2192 tasks \u2192 implement<\/code>. The spec is the source of truth; the code is a derivative. The agent doesn't invent the structure from scratch on every prompt, but inherits templates from the project's captured memory. This cures the exact anti-pattern everyone trips over: \u00abone prompt \u2192 agent writes code immediately\u00bb, an hour later the structure is incomprehensible, rollback is expensive, and the retro is full of complaints that \u00abAI can't handle architecture\u00bb. AI can handle it \u2014 you just didn't have a spec. A separate planning tool: git log as a dataset \u2014 churn, co-change matrix, pivotal commits, plus LLM interpretation on top (git-evolution-audit<\/code>).<\/p>\n

Set up infrastructure, Git, Linux, CI\/CD? I don't know what could be hard here. First, GitHub SpecKit will write this into tasks and lay out all NFRs, from load to security. If you struggle to imagine a basic prompt like \u00abset up a server, prepare a docker-compose.yml for this project, and install Zabbix with these templates\u00bb \u2014 I don't know what you are doing with AI. Are you just chatting with it?<\/p>\n

Code: This Is Team Practice, Not a Solo Stunt<\/h2>\n

Coding is already a baseline for many; there is nothing to argue about here. But I will add proof that this isn't \u00abone vibe-coder having fun\u00bb.<\/p>\n

In an enterprise context, I built real production microservices through AI-assisted coding during regular team training: a next-best-offer ML model (predicting the next item in a cart and email), a tracker for event timestamps across an order lifecycle, and a proxy microservice for geo-resolution (coordinates \u2194 address). This is production, not a demo.<\/p>\n

Two layers are required, without which the agent spins in circles. The first is reproducibility: the agent produces persistent, versioned artifacts (dual-file: .workflow.json<\/code> + <\/em>.meta.md<\/code>), not ephemeral replies; a repeated task reuses a proven workflow instead of regenerating it. The second is agent memory: errors are recorded into a structure from which it learns, rather than stepping on the same rake.<\/p>\n

Tests, Demo, and Release: Eval as a Gate, Not \u00abSeems to Work\u00bb<\/h2>\n

Test plans, test cases, and the autotests themselves \u2014 also the agent.<\/p>\n

But here, honestly, against myself: an AI feature that runs beautifully on a demo breaks unpredictably in production \u2014 because you ran the same inputs as the pitch, and nobody ran the long tail of real traffic. So I treat tests not as a checkbox, but as a three-layer release gate: regression on cases from real incidents (a new failure blocks the release), distribution check on fresh live inputs with a diff against the previous snapshot, and a human spot-check before the first production deploy of a new output type. One person signs off; if you cannot name that owner, that is the first red flag (eval-harness<\/code>). When I implemented proper QA, bug tracking, and CI\/CD during the SaaS transformation at UMI, the defect flow dropped from 5\u201310 per day to \u22645 per week, and releases went from \u00abonce every few months\u00bb to weekly.<\/p>\n

Prepare a demo for the client? No problem: the agent will write the docs, build the presentation, open the browser, and click through everything on screen for a training video.<\/p>\n

At the release boundary, I keep guardrails: prompt injection checks, data isolation, human-in-the-loop checkpoints. And review as a gate, not theater \u2014 to catch real defects, not to simulate control.<\/p>\n

Operations: Who Parses Logs, Emails, and Complaints<\/h2>\n

What's left? Monitor logs and Zabbix alerts, fix bugs on the fly, parse emails from live users with complaints and wishes, and feed them into the same backlog \u2014 back to the start of this process. An agent for this can be built by anyone.<\/p>\n

In operations, AI is a consumer of the event stream: Kafka, webhooks, monitoring. Parsing endless logs, highlighting anomalies, automated root-cause analysis. This is production-level engineering practice, not an experiment. At Askona, I hooked an AI bot to the data lake: a business question in natural language turns into SQL (read-only, with table name validation), and Time-to-Insight dropped from days in a Jira queue to seconds. At PersonaClick \u2014 streaming ML retraining on 199M+ profiles, so recommendations don't go stale. Enabling this kind of agent network inside a conservative enterprise<\/a> requires plumbing \u2014 mapping the estate, naming the systems you won't crack first \u2014 but the operational payoff is immediate.<\/p>\n

The Cycle Is Closed<\/h2>\n

The cycle is closed from beginning to end. No human is needed here. Feed this thing a regular stream of market hypotheses on the input, and it will stamp out features on a conveyor belt. I have done this.<\/p>\n

You can argue with me that there is room for things to go wrong, places where hands \u2014 or a live human head \u2014 will be needed. I agree. But the entire SDLC maps onto agents right now, today. You can obsess over minutiae, argue about nuances \u2014 information security, autotest reliability \u2014 but let's be honest: that is wasted effort. The core thesis doesn't change.<\/p>\n

You can keep your irreplaceable human on the management loop. The market will simply ship features while your human is still scheduling a call to reconcile stakeholder wishes.<\/p>\n","protected":false},"excerpt":{"rendered":"

Requirements, planning, infra, CI\/CD, tests, monitoring \u2014 every step of the cycle, pinned to a specific tool and a production case. No human in the loop required.<\/p>\n","protected":false},"author":0,"featured_media":232,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[209,24],"tags":[26,140,223,73,71,69],"class_list":["post-233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-agents","category-ai-engineering","tag-ai-agents","tag-automation","tag-devops","tag-engineering-leadership","tag-requirements","tag-sdlc"],"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