Agentic AI in Practice: How We Build Apps with AI in 2026
How agentic AI changed the way we build software: from written specs to coding agents, human review gates, and automated verification — what the process looks like and what it means for clients.
Two years ago, AI in software development mostly meant autocomplete: a model suggested the next few lines, and a developer accepted or rejected them. That era is over. Today we hand coding agents a written specification, they plan the work, implement it across many files, run the tests, check the result in a real browser, and come back with working software for review.
This changed where the effort goes. Typing code is no longer the bottleneck. The bottleneck moved to two places: describing precisely what should be built, and reviewing what the agents produced. Teams that adapt their process around those two activities ship dramatically faster. Teams that just "use AI" without a process get inconsistent results. This post describes the process we use at DevRain to build applications with agentic AI.
TL;DR: our agentic delivery process
- • Written spec - every feature starts as a document with success criteria, not a chat prompt.
- • Agent-drafted plan - the agent explores the codebase and proposes an implementation plan; a human approves it.
- • Parallel implementation - one or several agents implement the approved plan.
- • Review gates - AI code review runs as a first pass, humans review what matters.
- • End-to-end verification - agents verify against the criteria, run tests and browser checks, and provide evidence before human acceptance.
%%{init: {'theme': 'base', 'themeVariables': { 'fontSize': '20px' }, 'flowchart': { 'rankSpacing': 80, 'nodeSpacing': 40 }}}%%
flowchart TD
A["Requirements captured as a written spec"]
B["Agent explores the codebase and drafts a plan"]
C["Human approves or corrects the plan"]
D["Agents implement, often in parallel"]
E["AI code review, then human review"]
F["Agents verify against criteria: tests, browser checks, evidence"]
G["Working software shipped to the client"]
A --> B --> C --> D --> E --> F --> G
What "agentic" actually means
A chatbot answers a question and stops. An agent works toward a goal. Give a coding agent a task and it will read the relevant files, search the codebase for existing patterns, write the change, compile it, run the tests, read the error output, fix its own mistakes, and repeat until the result works — the same loop a developer runs, executed by a model with access to tools.
The practical consequence: the unit of work you can delegate grew from "suggest a line" to "implement this feature according to this spec." Tools like Claude Code, OpenAI Codex, and GitHub Copilot's agent mode all follow this pattern. At DevRain, we actively use both Claude Code and OpenAI Codex in real delivery work because relying on more than one agent gives us useful diversity: we can choose the tool that fits the task, have one agent implement while another independently reviews, and reduce dependence on a single model or workflow. But the tools alone are not the story — without a process around them, agents confidently build the wrong thing. The process is the five steps below.
Step 1. Start with a written spec, not a prompt
Every feature we build starts as a document: what the feature does, who uses it, what the edge cases are, and the success criteria that define what "done" means. This used to be optional on small projects — a conversation was enough because a developer would fill in the gaps over days of implementation. With agents, the gaps get filled in minutes, by a model making assumptions. A vague prompt produces plausible software that solves the wrong problem.
Writing the spec is itself an AI-assisted step: we draft requirements together with the client, use AI to find contradictions and missing cases, and keep the result in the project repository where agents can read it. The spec becomes the contract for everything downstream: planning, implementation, verification, and human acceptance.
Business benefit:
Clients get a precise, reviewable description of what will be built before any code exists — and the spec remains as living documentation after delivery.
Step 2. The agent plans first; a human approves the plan
We never point an agent at a codebase and say "go." The agent first works in a planning mode: it explores the existing code, finds the components and conventions that matter, and produces an implementation plan — which files change, what the approach is, what could go wrong. A senior engineer reads that plan and approves, corrects, or rejects it.
This is the cheapest quality gate in the whole process. Catching a wrong approach in a one-page plan takes minutes. Catching it after the agent produced two thousand lines of code takes hours, and the temptation to accept "almost right" code is real.
Business benefit:
Architectural mistakes are caught before implementation, when they cost minutes instead of days.
Step 3. Agents implement — often several in parallel
With an approved plan, the agent implements it: writing code, running the compiler, fixing errors, following the codebase's existing conventions. For larger features we split the plan into independent tasks and run several agents in parallel, each in an isolated working copy, so backend, frontend, and test work proceed at the same time.
One engineer now supervises what used to be a small team's worth of implementation. The engineer's job during this step is not typing — it is answering the agent's questions, unblocking it, and spot-checking direction while the work runs.
Business benefit:
Features that took weeks now take days. Iterations get short enough that clients see working software within the same conversation, not the next status meeting.
Step 4. Review stays — but AI reviews first
Agent-written code goes through the same review gate as human-written code. The difference is the order: an AI code review runs as the first pass, catching bugs, missed edge cases, and deviations from the spec. A second, independent agent reviewing the first agent's work catches a surprising amount. Humans then review with the boring problems already gone, focusing on what machines judge poorly: whether the change fits the product, the architecture, and the client's actual intent.
We treat "the agent wrote it and it compiles" as the beginning of quality control, never the end. Every line that ships was reviewed — by another model, and by a person accountable for it.
Business benefit:
Review capacity stops being the delivery bottleneck, without lowering the bar for what reaches production.
Step 5. Verify end-to-end, not just compile
The final gate is behavioral: does the software actually do what the spec says? Agents verify their work against the predefined success criteria, run the application, click through the changed flows in a real browser, call the APIs, read the logs, and run the test suite — then attach the evidence: screenshots, test output, request traces. "It builds" is not verification; "here is the feature working against the criteria, and here is the proof" is.
Because agents make verification cheap, it happens on every change instead of once before release. That reduces repetitive intermediate manual testing: reviewers get criteria-based evidence first, then spend their time on judgment, edge cases, and acceptance. For important flows, we add end-to-end tests that exercise the software the way users experience it, so regressions surface the day they are introduced.
We also use an AI evaluation framework to measure the quality of AI-assisted workflows over time. It helps us evaluate prompts, agent outputs, review quality, and verification evidence as a process — not just judge one delivery by whether it happened to pass a build.
Business benefit:
Fewer surprises in acceptance testing and production, because every important change is checked against clear criteria and exercised the way a user would exercise it.
Where humans stay in the loop
It is worth being honest about limits. Agents drift without a spec, over-engineer without review, and will happily solve the wrong problem with great confidence. The process above exists precisely because of those failure modes. People still own every decision that shapes the product:
- • Product decisions - what to build, for whom, and what to leave out.
- • Architecture - the structures that must survive years of change.
- • Security and data - anything touching credentials, personal data, or money gets human eyes, always.
- • Acceptance - a person, not a model, decides that the work is done and ships it.
The engineering role did not shrink — it moved up. Less time typing, more time specifying, reviewing, and deciding.
What this means for our clients
- • Working software earlier - first usable versions in days, so feedback starts immediately.
- • Shorter iterations - "can we change this?" is often answered with a deployed change, not an estimate.
- • Specs as an asset - the written specifications and plans remain with the project as durable documentation.
- • Senior attention on every task - because engineers supervise rather than type, senior judgment touches all of the work, not just the hard parts.
Final take
Agentic AI did not remove engineering discipline from software delivery — it raised the price of not having it. Specs, plans, reviews, and verification were always good practice; now they are the difference between agents that multiply a team's output and agents that multiply its mess.
The way we build apps in 2026: write down what should exist, let agents plan and build it, keep humans on the decisions that matter, and prove that it works before it ships. The tools will keep changing. The process is what makes them work.