The Evolution of AI Coding, As I Lived It: From Autocomplete to Loop Engineering
Language Mismatch Disclaimer: Please be aware that the language of this article may not match the language settings of your browser or device.
Do you want to read articles in English instead ?
TL;DR: AI coding evolved through clear stages: autocomplete, vibe coding, prompt engineering, context engineering, spec-driven development, agentic coding, and now loop engineering, where agents run in loops governed by skills and gates. What: this post walks every stage. Why: each one banked a lesson we still use, and knowing the arc tells you where to stand today. How: I lived each stage building real products, and I show the receipts.
The short answer
The evolution of AI coding is not a graveyard of hype cycles. It is one continuous discovery. Autocomplete proved models could finish our thoughts. Vibe coding proved they could build whole things. Prompt engineering proved the input matters, context engineering proved the input is an entire discipline. Spec-driven development proved intent belongs in writing before code. Agentic coding proved models can act, not just answer. And loop engineering, where we are now, is proving that agents running in loops, with skills to follow and gates to pass, can ship production work you trust. Each stage kept what the previous one proved and added what it was missing.
Autocomplete: the model finishes your line
Where everyone started, me included. Copilot-style predictive coding: you type, it completes the line or the function, you accept or reject. Every suggestion passed through your hands, so nothing needed governance. It felt like typing faster, not like a new way of working.
What we banked: speed, and the daily habit of reading machine-written code. That habit mattered more than the keystrokes saved. It trained a generation of us to review AI output as a reflex.
Vibe coding: describe it, get it
Then chat models got good enough to build whole features from a description. Andrej Karpathy named it vibe coding, and the name stuck hard enough to become Collins' word of the year in 2025: prompt, accept, run, repeat, architecture optional.
I tried it on side projects. It was honestly exhilarating: ideas became running code in an afternoon. And I moved on quickly, not because it failed me, but because its ceiling shows fast on anything you have to maintain. Vibe coding is a sketchpad, and sketching is a legitimate phase of building.
What we banked: ambition. Vibe coding recalibrated what one person dares to attempt.
Prompt engineering, then context engineering: the input is a discipline
The first response to vibe coding's ceiling was craftier prompts. That was prompt engineering, and it helped, but clever wording does not scale across a real codebase.
The durable insight came next: what the model needs is not a better sentence, it is better context. Project conventions, architecture docs, memory that persists across sessions, the right files at the right moment. Context engineering turned "talking to the AI" into an engineering surface with its own files in the repo. Most serious teams now maintain context the way they maintain tests.
What we banked: the input side became infrastructure.
Spec-driven development: write the intent down first
This is the stage that converted me for good. Instead of prompting toward code, you write the specification first: what to build, what done means, what must not change. The agent implements against the spec, and review happens against the spec too. Even Karpathy, who named vibe coding, called its era over and pointed here.
In my work this became a literal pipeline: brainstorm, spec, adversarial critique of the spec, plan, then implementation, with a human approval gate before any code. The surprise was how much of the value lands before the agent writes anything. A spec that survives critique is most of the work.
What we banked: correctness by intent, not by luck.
Agentic coding: the model acts
Meanwhile the models learned to do more than answer. An agent reads files, runs commands, edits, runs tests, and keeps going for minutes or hours. The unit of work stopped being a snippet and became a task: a branch, a migration, a reviewed PR.
This is where the harness started to matter as much as the model, because the harness decides what the agent can touch and how it asks permission. I wrote about that layer separately in my harness and engine post.
What we banked: autonomy with an audit trail.
Loop engineering: where it lands today
The newest stage has a name that is just now settling: loop engineering. The idea: a single agent turn is a loop of gather context, reason, act, check. Loop engineering is the layer above it, designing how many turns run, what each one must satisfy, and when the loop stops. Repetition, validation, orchestration, stopping conditions, designed on purpose.
This is where I live now, and it is the way, especially with fleets: many agents working a board of tickets in parallel lanes. Two practices carry all of it.
First, skills. We found a way to qualify the practices we carry in our heads into literal skill files an agent can follow: step one, step two, the checks, the exit report. My blog pipeline is a skill. My deployment process is a skill. When an agent picks up work, it does not improvise process; it follows the file, and when a run teaches us something, the lesson is committed back into the skill.
Second, gates. Nothing merges because an agent feels done. On one national registry system I run this way, the fleet works like this:
ticket
|
v
[spec gate] human approves scope before any code
|
v
lane opened (non-colliding write scope, own worktree)
|
v
implement agent follows the skill files
|
v
[review gates] code review · compliance audit · focused tests
|
v
[release gate] orchestrator runs the FULL preflight, alone
|
v
[merge gate] gate-owner authorizes; nothing self-merges
|
v
merged, lane closed, board updated
Every arrow is an agent working autonomously. Every bracket is a gate it cannot pass alone. That combination, loops for the speed, gates for the trust, is what finally makes fleets of agents shippable in production.
The loops do not even need my laptop anymore. Part of my fleet runs on ephemeral cloud agent sessions I drive from my phone, through the same skills and gates as any local lane. Once the process lives in skill files and the trust lives in gates, where the loop physically runs stops mattering. That is how you know the stage is real.
What we are banking: trust, at scale.
The pattern across the stages
Look back and there is no wreckage. Autocomplete banked speed. Vibe coding banked ambition. Prompt and context engineering banked the input as infrastructure. Specs banked intent. Agents banked autonomy. Loops are banking trust. Nothing failed; each stage was us finding what works and moving forward with it, which is just what engineering has always done.
Where I stand
I run a real product on this today. GPS fleet tracking, paying customers, production traffic, and an engineering process where agents do most of the building inside loops I design, against specs I approve, through gates I own. The productivity gains are not a demo. And the quality holds, because the gates hold.
So here is my closing take. AI coding is not the future of our craft. It is the present. I am watching it ship reliable work every single day, and I am more excited about building now than I have been at any point in my career. There is no going back, and I would not want there to be.
