Progressive Intent: I Built This Working Application in About Three Hours
Progressive Intent: I Built This Working Application in About Three Hours
I’ve written quite a bit lately about Progressive Intent and Intent-Driven Engineering.
So instead of explaining it again, I decided to give you the whole thing.
The application is live.
The source code is public.
The intent files are in the repository.
You can play with it, download it, fork it, break it, improve it, or use the approach on something completely different.
And the interesting part?
I built this working application in roughly three hours.
Not three hours to create a mockup.
Not three hours to write a specification.
Not three hours to generate a bunch of AI code that nobody tested.
About three hours to progressively take a simple Whack-a-Mole application through multiple iterations until I had the game behavior, scoring, difficulty, timing, sound, architecture, testing, TypeScript conversion, and deployment working the way I wanted.
Play It First
Here is the actual deployed application:
Live application:
Go whack a few moles.
Then come back.
Now Look Under the Covers
Here is the complete public repository:
GitHub repository:
Nothing is hidden.
The repository includes the application code, tests, automation, architectural guidance, and—most importantly—the intent files used during the development process. The current application is React + Vite + TypeScript and includes separate components, hooks, scoring logic, local high-score storage, synthesized sound effects, linting, type checking, testing, and a production build. (GitHub)
That is the point of this experiment.
You don’t have to believe an AI productivity benchmark.
You can inspect the evidence.
What Is Progressive Intent?
Progressive Intent is remarkably simple.
Instead of attempting to write a giant specification describing everything the system will ever become, you define the next meaningful outcome.
The AI examines the current repository.
It understands the existing state.
It develops a plan.
It makes the changes.
It validates the result.
Then you look at what exists now and decide what the next intent should be.
The cycle becomes:
Intent → Discover → Plan → Implement → Validate → Stop → Next Intent
That is very different from:
Prompt → Generate a lot of code → Hope it works
And it is also different from trying to predict an entire application in a 40-page requirements document before writing anything.
The Repository Becomes Part of the Context
One of the most important concepts behind Progressive Intent is that the AI should not operate as though every request starts from zero.
The repository already contains information.
It contains architecture.
It contains conventions.
It contains previous decisions.
It contains tests.
It contains code.
It contains failures.
And increasingly, it can contain its own intent history.
In this project, for example, the repository now contains several intent artifacts showing how the system progressed. The original analysis documented the existing application and guided the refactoring. A subsequent Progressive Intent file provided a runner-neutral instruction for improving the repository. A later intent drove the TypeScript migration, component decomposition, and sound capability. (GitHub)
The development history becomes part of the engineering asset.
That is important.
I Didn’t Tell the AI Every Line of Code to Write
This is where AI-assisted development often gets unnecessarily complicated.
I didn’t want to become the world’s fastest prompt writer.
I wanted to state what I wanted the software to accomplish.
There is a major architectural distinction here:
Structure the boundary, not the reasoning.
Give the AI clear intent.
Give it the necessary context.
Define the expected outcome.
Give it success criteria.
Give it constraints.
Then allow the engineering system to reason about implementation.
That is fundamentally different from writing procedural prompts telling an AI:
Open this file.
Change line 42.
Create this method.
Name this variable.
Now modify this other file.
That makes the human the workflow engine.
I want the AI to do more of the engineering work.
The Application Progressed in Cycles
The application didn’t magically appear in its final state from one giant prompt.
It evolved.
The first job was understanding what existed.
Then the structure improved.
Then functionality improved.
Then additional requirements appeared.
Sound was added.
Game behavior was refined.
Components were separated.
Hooks emerged.
TypeScript replaced the earlier JavaScript structure.
Testing and validation became part of the system.
Eventually the application reached a state where the requirement was satisfied.
Then we stopped.
That last part matters.
AI systems need to know when they are done.
Otherwise an agent can continue “improving” software forever.
Progressive Intent should therefore include a stop condition:
Are the requirements satisfied?
Did validation pass?
Is the application in an acceptable working state?
If yes:
Stop.
The next change should become another intent.
About Three Hours
The entire exercise took me roughly three hours of actual iterative work.
That included working through the game mechanics, timing, scoring, visual behavior, sound, code organization, and several iterations of improvement.
Could somebody build Whack-a-Mole traditionally?
Of course.
That isn’t the point.
Whack-a-Mole is deliberately small.
It gives us something much more valuable than a complicated demo:
A controlled experiment.
Because the application is small, we can actually observe the engineering process.
We can see what happened.
We can examine the artifacts.
We can inspect the code.
We can run the tests.
And we can compare each iteration with the intent that produced it.
Now imagine applying the same model to a business feature inside an enterprise repository.
That is where this gets interesting.
Progressive Intent Is Not About Whack-a-Mole
The game is irrelevant.
The engineering pattern is what matters.
Imagine instead that the intent says:
Add customer address validation to the existing order-entry application while preserving the current API contract and existing tests.
Or:
Analyze this legacy repository and identify the safest modernization path without changing observable business behavior.
Or:
Add a new API endpoint using the existing repository architecture, authentication model, observability conventions, and test patterns.
The AI doesn’t need a completely new software-development methodology for each one.
The loop stays largely the same.
Understand the existing system.
Understand the intent.
Make the smallest appropriate change.
Validate it.
Stop when the requirement is satisfied.
Then repeat.
This Is Why I Call It Intent-Driven Engineering
AI changes the unit of software development.
For decades, much of software development has been organized around translating requirements into increasingly detailed instructions for humans.
AI gives us the opportunity to move the abstraction upward.
The human can increasingly concentrate on:
Intent
Inputs
Outputs
Success Criteria
The engineering system can increasingly handle the implementation reasoning underneath those boundaries.
That doesn’t eliminate engineering discipline.
It makes engineering discipline even more important.
Testing matters.
Architecture matters.
Security matters.
Observability matters.
Governance matters.
Repository conventions matter.
But now those things can become persistent capabilities of the engineering system instead of reminders buried inside somebody’s prompt history.
Don’t Take My Word for It
That is why I am publishing the whole experiment.
Play the application
Inspect or clone the source
Look at the code.
Look at the intents.
Look at the repository structure.
Look at the automation.
Then try the same approach yourself.
You don’t need to build Whack-a-Mole.
Take a small application you already understand.
Give the AI the repository.
Describe the next outcome.
Let it examine what is already there.
Require it to plan.
Require validation.
Give it a clear stopping condition.
Then run another intent.
Start Small
I believe one of the mistakes organizations are making with AI coding is starting with enormous transformation programs.
Start with one repository.
Start with one feature.
Start with one intent.
Prove that the loop works.
Then do it again.
When the process becomes repeatable, capture the reusable engineering capabilities as skills, hooks, agents, workflows, MCP services, tests, policies, and automation.
Now you are no longer simply helping a developer write code faster.
You are creating an AI-native engineering system.
That is the bigger idea behind Progressive Intent.
And sometimes the easiest way to prove a big idea is with a very small game.
Whack a mole. Inspect the repo. Then imagine what happens when the same engineering loop is pointed at real enterprise software.
I’d use “Progressive Intent: I Built This Working Application in About Three Hours” as the Wix headline. The public repo currently shows 13 commits and explicitly documents the intent-driven refactor, TypeScript migration, component decomposition, testing and synthesized sound implementation, which gives the article unusually good supporting evidence.
Play the live Whack-a-Mole app
View the complete GitHub repository
Comments