I read this opinion ten times a week. Okay, the argument goes, AI can write code — fine. But to actually run 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!
My eyes roll back every time. What?
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 — because I have already run this cycle hands-on.
Where the «Irreplaceable Human» Actually Lives — and What It Costs
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 — you are paying for work an agent does in hours, and overnight too.
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.
Requirements: The Agent Won't Let an Immature Task Into Development
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 — but there are no technical blockers here.
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: «Consolidate this data into a unified picture, detect contradictions, compile a list of questions, group them, and format as emails to specific recipients.» This is elementary.
Then the cycle continues: new data arrives — feed it to the agent — it solders it into the documentation or asks a new question. As soon as there are zero open questions — go to the next step.
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.
A couple of days of automated correspondence — and the output is strict, consistent FRs, NFRs, priorities, and goals.
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. With project context, the questions are not generic, but grounded in the specific system. The output is a mature ticket with verifiable ACs, not «do an integration with ERP». The code is public: jira-clarify-bot, FastAPI, Docker, a webhook contract. And I started embedding AI into the management loop — requirements and definition — back in my enterprise role, targeting the management layer, not the code.
Design: Two Agents Negotiate the Contract Themselves
What's next? Design and negotiation — supposedly another sacred human zone.
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 «we agreed on a call», but an artifact: openspec.yaml, 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), 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, a2a-example). I have written about this agent-to-agent engineering approach before — two agents, one live call, and the plumbing required to make it work.
If you fear the agent «doesn't understand architecture» — make it read a book. RAG over Tanenbaum plus a wiki graph, so decisions rest on canon, not on model memory.
At Askona, I locked in asynchronous event-driven integration as the corporate standard across dozens of services and teams with different owners — a pipeline handling millions of events per day. This is not a sandbox.
Planning and Infra: «What's So Hard About It?»
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.
I run this through Spec-Driven Development: specify → clarify → plan → tasks → implement. 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: «one prompt → agent writes code immediately», an hour later the structure is incomprehensible, rollback is expensive, and the retro is full of complaints that «AI can't handle architecture». AI can handle it — you just didn't have a spec. A separate planning tool: git log as a dataset — churn, co-change matrix, pivotal commits, plus LLM interpretation on top (git-evolution-audit).
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 «set up a server, prepare a docker-compose.yml for this project, and install Zabbix with these templates» — I don't know what you are doing with AI. Are you just chatting with it?
Code: This Is Team Practice, Not a Solo Stunt
Coding is already a baseline for many; there is nothing to argue about here. But I will add proof that this isn't «one vibe-coder having fun».
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 ↔ address). This is production, not a demo.
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 + .meta.md), 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.
Tests, Demo, and Release: Eval as a Gate, Not «Seems to Work»
Test plans, test cases, and the autotests themselves — also the agent.
But here, honestly, against myself: an AI feature that runs beautifully on a demo breaks unpredictably in production — 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). When I implemented proper QA, bug tracking, and CI/CD during the SaaS transformation at UMI, the defect flow dropped from 5–10 per day to ≤5 per week, and releases went from «once every few months» to weekly.
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.
At the release boundary, I keep guardrails: prompt injection checks, data isolation, human-in-the-loop checkpoints. And review as a gate, not theater — to catch real defects, not to simulate control.
Operations: Who Parses Logs, Emails, and Complaints
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 — back to the start of this process. An agent for this can be built by anyone.
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 — streaming ML retraining on 199M+ profiles, so recommendations don't go stale. Enabling this kind of agent network inside a conservative enterprise requires plumbing — mapping the estate, naming the systems you won't crack first — but the operational payoff is immediate.
The Cycle Is Closed
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.
You can argue with me that there is room for things to go wrong, places where hands — or a live human head — will be needed. I agree. But the entire SDLC maps onto agents right now, today. You can obsess over minutiae, argue about nuances — information security, autotest reliability — but let's be honest: that is wasted effort. The core thesis doesn't change.
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.