What to build: behavior, architecture, contracts, and scope.
GoalScopeArchitectureContractsNon-goals
Learn
What is agentic engineering?
Agentic engineering is a discipline: you own the functional spec, the architecture, and the design — reviewed and approved before a line is written — and coding agents write the code to it. You keep the agent's speed. What it leaves behind stays maintainable, explainable, and yours.
You stay the engineer. The agent becomes the fastest way to build what you designed.
Vibe coding hands the agent the design and the code at once — you type an instruction and hope the diff is right, and what comes back is a system nobody specified and nobody can safely change. Agentic engineering splits those two jobs back apart. The functional spec, the architecture, and the design are human-owned artifacts: written down, reviewed, approved. The code is the agent's job, written to that approved design. Speed comes from the agent; ownership stays with you.
The point is not to slow the agent down. The point is to make its work reviewable, attributable, and yours to keep.
The reframe
Vibe coding produces a diff. Agentic engineering produces a system you still own.
A chat message leaves nothing durable behind: no spec to approve, no architecture to inspect, no trail from intent to commit. Agentic engineering makes the design an artifact that outlives the run — so the change can be reviewed while it happens and understood long after.
| Approach | Who owns the design | What you're left with |
|---|---|---|
| Vibe coding | The agent, implicitly, inside the run | Code that works today and that nobody can safely change tomorrow |
| Ticket-driven AI coding | A human, in a tracker the agent never reads | Intent, design, and execution living in three disconnected places |
| Agentic engineering | You — an approved spec, architecture, and design the agent builds to | A maintainable system, plus a reviewable record from intent to commit |
Prompting harder is not the same as engineering with agents.
The workflow
Agentic engineering is the discipline. Agent-Native Development is the workflow that runs it.
A discipline needs a loop you can actually run. Windy runs Agent-Native Development (AND) — the same seven stages for every change, large or small. Each stage produces something the next one reads, and something a human can review. It is the mechanism that keeps the spec, the architecture, and the design human-owned while the agent moves at full speed. The full treatment lives on How Windy works.
- IntentA Work item captures what should change
- ProposalThe agent drafts the spec, architecture, and design to build from
- ReviewYou approve or revise it — this is where you own the design
- Task ListThe approved proposal becomes ordered tasks
- ExecutionThe agent writes the code, commit by commit
- ChangesetDoc updates stage as one reviewable set
- MergeApproved, the changeset lands atomically
The loop closes: the merged changeset becomes the memory the next Work item builds from.
Read the full workflow → How Windy works
The unit of work
A Work item holds everything about one change.
A Work item is the top-level container: an intent, its proposal, its task lists, and its executions, all in one place. You start it by picking a Work Type — Feature, Bug Fix, Refactoring, and so on — which bundles the right templates and a copy-ready prompt to hand your agent.
- Intent — a short statement of what should change and why, captured before any code is written.
- Work Type — chooses the templates, custom fields, and instruction prompt for this kind of work.
- Attachments & context — the references the agent should read before it proposes anything.
You describe the intent once. Everything else in the workflow hangs off it.
The design you approve
The agent drafts the design. You own it — before it writes a line.
This is the centre of agentic engineering. Before touching code, the agent authors a proposal in two parts. The implementation spec says what to build — behavior, architecture, contracts, scope. The verification spec says how to prove it worked. Both are yours to question, revise, and approve. Reviewing them up front means you approve the design and the definition of done together — and the code that follows is written to a design you signed off on.
An approved design is what separates agentic engineering from a lucky diff.
Review
Humans and agents review the same work, inline.
Review is not a rubber stamp at the end. Comments attach to specific lines of the proposal, the agent that authored it can answer and revise, and nothing advances until the proposal is explicitly marked ready. The changeset it eventually produces is reviewed the same way before it merges.
- Inline comments, anchored to the spec. A reviewer questions a line; the thread stays attached to it, not buried in chat.
- Agents answer, not just humans. The agent that authored the proposal can reply to a comment and revise the spec.
- Ready is an explicit gate. Nothing moves to a task list until the proposal is marked ready — approval is a state, not a vibe.
- The changeset gets its own review. Knowledge-base edits are reviewed again before they merge, so the source of truth stays trustworthy.
You stay the architect and the reviewer. The agent does the work in the open.
Task Lists & Executions
An approved design becomes ordered tasks — and a commit for each.
Big, cross-cutting work breaks a single prompt. The Agent-Native Development workflow decomposes the approved proposal into a Task List: small, ordered tasks, each with its own objective and acceptance criteria. An Execution runs them one at a time and records a per-task commit SHA, so the run ties straight back to your repository. This is where the agent's speed shows up — against a design you already approved.
A sprawling change becomes a sequence you can steer — with an audit trail from task to commit.
Changesets
Knowledge-base edits land through a reviewed gate.
When the work changes the project's design, the agent does not publish edits silently. It stages them as a Changeset — a git-commit-like set of document changes — which is reviewed as a unit and merged atomically. The source of truth only moves when a reviewer approves the merge.
No more silent doc writes. Every change to the project's design is reviewed before it lands.
Durable memory
Durable project memory is one part of the workspace — kept honest by the loop.
A coding agent still needs durable, project-scoped context: the specs, architecture, and decisions it reads before it builds. In agentic engineering that memory lives in the knowledge base — and because every update flows through a reviewed changeset, it stays aligned with the code instead of drifting away from it.
- The knowledge base is the long-term memory. Specs, architecture, diagrams, and decisions live in one project-scoped source of truth agents read over MCP before they build.
- Proposals are the short-term working set. Each Work item has its own proposal store — the design for that change — separate from the durable knowledge base.
- Changesets keep memory honest. When behavior changes, the agent stages a changeset; once merged, the knowledge base reflects reality instead of drifting from it.
- Every run starts from the current truth. Because the memory is updated as work lands, the next agent reads today's design — not yesterday's prompt.
Memory matters — but it earns its keep as the part of the workspace the loop keeps current, not as the whole story.
Windy
Windy is the workspace for agentic engineering.
Humans shape and review the design in a polished web app. Coding agents read and write the same Work items, proposals, task lists, and changesets over a per-(user, project) MCP endpoint — so every agent change is attributed to a person, and the whole Agent-Native Development workflow lives in one place.
The knowledge base — your durable memory.
Specs, architecture, diagrams, and decisions in one project-scoped source of truth, updated only through reviewed changesets.
Work items — the workflow in motion.
Intent → proposal → review → task list → execution → changeset → merge, with every step attributed and inspectable.
Your coding agent still writes the code. Windy makes sure you can still own it.
FAQ
Questions, answered.
Agentic engineering is a discipline for building software with coding agents in which the human owns the engineering artifacts — the functional spec, the architecture, and the design — and the agent writes the code to them. The design is written down, reviewed, and approved before implementation starts, so you keep the agent's speed and the system it produces stays maintainable and yours.
Vibe coding hands the agent the design and the code in the same breath: you prompt, you get a diff, and nothing durable is left behind — no spec to approve, no architecture to inspect, no record of why. Agentic engineering separates the two jobs. You approve the spec, architecture, and design first; the agent implements against them; and the change lands through a reviewed changeset. Same speed, without the black box.
Windy runs Agent-Native Development (AND) — the workflow that delivers agentic engineering. A Work item captures intent, the agent authors a proposal (implementation spec + verification spec), humans and agents review it inline, the approved proposal becomes an ordered Task List, an Execution runs the tasks and records a commit for each, and knowledge-base updates land as a reviewed, atomically-merged changeset. See how Windy works at /how-it-works/.
Usually, yes — and more design. The agent writes most of the implementation. Your time moves up the stack: to the functional spec, the architecture, the tradeoffs, the review, and the merge decision. The role gets clearer, not smaller.
A Work item is the top-level unit of work: it holds the intent, the proposal store, the task lists, and the executions for one change. A Work Type (Feature, Bug Fix, Refactoring, and so on) bundles the templates and copy-ready instructions for that kind of work, so the agent starts from the right prompt.
The implementation spec says what to build (behavior, architecture, contracts). The verification spec says how to prove it worked (acceptance criteria and a test plan). Separating them makes review concrete: you approve the design and the definition of done before any code is written.
A changeset is a project-scoped, git-commit-like edit to the knowledge base: a set of document changes that is reviewed as a unit and merged atomically. It replaces one-off, immediately-published edits, so the source of truth only changes through a reviewed gate.
The knowledge base is the durable, project-scoped memory: specs, architecture, and decisions agents read over MCP before they build. The Agent-Native Development workflow keeps it current by making every knowledge-base update flow through a reviewed changeset — so memory is one part of the workspace, kept honest by the loop.
Related
Keep exploring.
Keep the speed. Keep the system yours.
Your coding agent still writes the code. Windy gives it the approved design, the task list, and the reviewed changeset the work should flow through.
windylogic.ai