It hit me while I was working on my own products: I could not remember the last time I had written a feature completely by hand.
It has been days since I wrote code myself. I do not say that as a confession or a flex. It is simply what my work looks like now, and I think more developers are going to recognise it.
The old loop was simple. Think about a feature, open the editor, write the code, find the bug, search for the answer, fix the bug, review the files, and repeat.
My loop does not look like that anymore.
I begin with the product I want to exist. I explain the behaviour, the constraints, the infrastructure, the edge cases, and what a correct result should feel like. AI handles the implementation. It can inspect the repository, plan the work, write the code, spot bugs, review its own changes, run tests, fix failures, and keep iterating.
I still open the editor, read the diff, make decisions, and take responsibility for the result. My responsibility is just no longer to type every part of the solution.
It is to create the conditions in which the right solution can emerge.
The future of development is not writing code faster. It is turning ideas into reliable software faster.
Code was never the product
Users have never cared who typed a function.
They care that the button works. They care that the payment arrives once, not twice. They care that their data is safe, the page is fast, the experience makes sense, and the product solves the problem they opened it for.
Code was the expensive bridge between an idea and that outcome.
For years, we treated construction as the centre of software development because construction consumed most of the time. A feature that took ten minutes to describe could take days to implement. An experiment could die before reaching a user because testing the idea cost too much.
That cost is collapsing.
When code becomes cheap to produce, the valuable question changes. It is no longer, “How quickly can I type this?” It becomes, “Do I know exactly what should be built, and have I created enough context for it to be built correctly?”
AI is not just autocomplete anymore
The biggest mistake is treating AI like a faster keyboard.
Writing code is only one part of what it can do. Given access to the right repository and tools, it can trace execution paths, inspect existing patterns, compare possible designs, implement a feature, reproduce a reported bug, read logs, run a build, create tests, review a diff, find inconsistencies, and correct its own work.
That changes the unit of development.
I am no longer asking for isolated snippets and manually stitching them together. I am giving the system a complete outcome and enough information to work toward it. The closer the environment gets to the real development loop, the more of that loop AI can handle.
A vague sentence still produces a vague product. A clear system can produce surprisingly complete work.
Context is the new source code
If AI is capable of doing the implementation, why does one person get an excellent result while another gets polished nonsense?
Usually, the difference is context.
“Build authentication” is not context.
Which users exist? How do sessions expire? What happens when an account is deleted? Which routes are protected? Where is authorization enforced? Which existing conventions must remain? What should the interface show while identity is loading? How will the result be tested?
AI fills empty space with assumptions. If I leave the important decisions unstated, I should not be surprised when it builds the wrong version beautifully.
So I feed it the information that actually shapes the product:
- The outcome a user should experience.
- The architecture and infrastructure already in place.
- The constraints it must not violate.
- The relevant files, patterns, documentation, and external interfaces.
- The failure states and edge cases that matter.
- The commands and checks that prove the work is complete.
This is not about discovering one magical prompt. It is about building a high-quality environment around the task.
My AI-first development loop
My current workflow begins before any code is generated.
1. Define the result
I describe what should change from the user’s perspective. I include what must remain unchanged and the exact conditions that mean the task is finished.
2. Let AI inspect before it acts
The repository already contains decisions. I let the agent read the relevant code, understand the structure, find related behaviour, and identify the likely impact before proposing an implementation.
3. Improve the plan
A plan exposes misunderstanding while it is still cheap. If the approach is solving the wrong problem, I correct the direction before that mistake spreads through the project.
4. Give it the tools to complete the loop
The agent should not stop after producing files. It should be able to run type checks, builds, tests, formatting, browser checks, and any project-specific validation. When a check fails, it should inspect the failure, fix the cause, and run the check again.
5. Use AI to challenge AI
The same system that implements a change can inspect it from another angle. I ask it to search for missed edge cases, security issues, duplicated logic, regressions, unnecessary complexity, and behaviour that technically works but does not match the original goal.
6. Test reality
This is the part I refuse to skip.
A green build proves that the project can build. It does not prove that the product feels right. I use the feature, follow the real path, try the empty state, provide bad input, slow the network, reload midway, and check what happens when reality is less cooperative than the specification.
I am not validating whether the code looks like something I would have written. I am validating whether the product behaves like the thing I intended to build.
AI can review and debug too
I do not believe humans must manually perform every stage just to remain in control.
AI can review code. It can find bugs. It can compare an implementation against a specification. It can analyse a failure, inspect related files, suggest a fix, apply it, and prove that the original failure no longer occurs.
More importantly, it can do these jobs repeatedly without getting bored.
That repetition matters. One implementation pass followed by one quick human glance is not an AI-first workflow. It is a shortcut. The real advantage comes from creating loops where the system continues until the evidence is strong enough.
Implementation, review, debugging, and testing can all become parts of the same automated process.
The human contribution moves toward deciding which evidence is trustworthy and whether the final behaviour solves the actual problem.
Infrastructure determines how intelligent the workflow feels
An agent with no access to the project can only guess.
An agent with the repository, clear documentation, working commands, useful errors, automated checks, test data, and a realistic preview can operate like a complete development system.
This is why good infrastructure matters more now, not less.
If the build is unreliable, the agent receives a noisy signal. If requirements live only inside somebody’s head, it cannot discover them. If errors are swallowed, it cannot diagnose them. If the project has no repeatable way to verify behaviour, confidence becomes theatre.
The best AI-assisted codebase is not the one with the longest instruction file. It is the one that makes correctness observable.
Clear boundaries. Useful logs. Reproducible environments. Focused tests. Small tasks. Honest failure messages. Documentation that explains why a decision exists, not only what a file contains.
These things give AI the rails it needs to move quickly without disappearing into the wrong direction.
The skill is knowing what to build
If implementation becomes almost unlimited, ideas do not automatically become valuable.
It becomes easier to build the wrong thing too.
A person can now generate ten features in the time it once took to build one. That sounds like progress until none of the ten solve a real problem. Speed without taste produces more software, not necessarily better software.
The scarce skills are moving toward product judgment.
Can I notice a painful problem?
Can I reduce it to a clear experience?
Can I choose sensible infrastructure?
Can I explain constraints without prescribing every line?
Can I recognise when a result is technically impressive but useless?
Can I put the product in front of reality, listen, and change direction without becoming attached to the first version?
Those abilities are what turn unlimited implementation into something useful.
What I have stopped doing
I have stopped treating manual code production as proof of seriousness.
I have stopped spending an hour on syntax that can be produced in seconds.
I have stopped assuming that debugging must begin with me staring at the same files until the answer appears.
I have stopped measuring a productive day by the number of lines I personally added.
Those days are over for me.
Not because I care less about software, but because I care more about what the software achieves.
What I spend that time on now
I spend it thinking about the user.
I spend it deciding whether a feature deserves to exist, refining the experience, choosing the architecture, connecting the right services, creating useful constraints, testing the real behaviour, and shipping another iteration while the idea is still alive.
I can explore more directions. I can discard weak implementations without mourning the time spent typing them. I can move across the stack without waiting to become the fastest human syntax generator in every layer.
Most importantly, I can stay closer to the reason I wanted to build software in the first place.
To make things.
This is only the beginning
I think the coming years will be the most exciting period software development has seen.
Small teams will build what once required departments. A person with a sharp understanding of a niche problem will be able to create the product without waiting for permission, funding, or a perfect collection of specialists. Experiments will reach users before the original excitement disappears.
The advantage will not belong to the person who can produce the most code manually.
It will belong to the person who can combine imagination with context, infrastructure, verification, and speed.
AI can write the feature. It can review it. It can find the bug. It can fix the bug. It can run the tests and improve the result.
My job is to point that capability at a problem worth solving, give it everything it needs, and make sure the thing that reaches the user is genuinely good.
It has been days since I wrote code myself. The work still feels like mine; I have simply moved closer to the decisions that make it worth building.