For a while now, AI has been writing most of the code I ship.
Not a snippet here and there. Most of it. Multiple applications, shared packages, a multi-tenant database, real users on the platform. I review, I direct, I correct, but the typing is mostly not me.
When people hear that, they usually assume I have become a faster coder.
I have not.
I have become a different kind of worker entirely.
That is what this piece is about.
Because the question I started asking, after a few months of this, was not "how do I prompt better?" or "which model is best?". The question was quieter and more uncomfortable.
If the AI writes the code, what is left for me to do?
The answer turned out to be: almost everything that actually matters.
The thing the AI does not do
The AI writes code. It does not decide what to build.
It does not decide whether a feature earns its complexity. It does not decide which version of a contradiction is correct. It does not decide what to defer and what to ship now. It does not decide which decisions have to stay consistent across applications and which ones can vary locally. It does not decide what is true.
These are architectural decisions. They are decisions about the system, not about the code.
When the spec lived in my head, I could pretend these decisions and the code were the same thing. I would type, and the act of typing would surface the architectural questions, and I would resolve them as I went.
When the AI took over the typing, those two activities separated.
Suddenly the architectural decisions had to exist somewhere outside my head, in a form the AI could read, or they would not get made at all.
The AI would make them instead. Inconsistently. Differently in each session. Forgotten the next time.
That is the moment the work changed.
From coder to architect
What I do now, most days, is architecture.
I write specs. I write addenda. I keep decisions logs. I maintain a register of deferred ideas with explicit trigger conditions. I curate the skill stack the AI uses. I define the order in which it reads documents before a session begins.
The code is downstream of all of that.
And the strange thing is, the work feels harder than coding ever did. Not because architecture is intrinsically harder than coding. Because there is nowhere to hide.
When you are typing code, the act of typing produces the feeling of progress. There is a green checkmark, a passing test, a running app. Every keystroke is dopamine.
When you are writing a spec, none of that is true. You are just sitting with a question and deciding what the answer is.
Is this concept defined in more than one place? Then which is canonical?
Is this complexity earning its keep? Or is the smaller version just as good?
Is this decision actually settled, or am I about to re-litigate it in three weeks?
What has to be true before this deferred idea becomes worth building?
These are not coding questions. They are systems questions. The AI cannot answer them, because it does not know what I am building well enough to know what should be true.
That is my job now.
I am not a faster coder.
I am a better systems thinker, because I had to become one.
What helped
A lot of this came together for me when I started using a set of skills called L-GEVITY, by Patrick Savalle.
He describes them as "the architect for your AI coding agent". That phrase is exactly right.
Most agent skills are tactical. They teach the AI how to do specific tasks - scaffold a component, write a test, format some code. L-GEVITY skills are strategic. They teach the AI how to think about software at a structural level.
There are skills that force the question "is this feature worth its complexity cost?" before code gets written. Skills that score complexity along four independent axes - diversity, coupling, depth, quantity - so "this is simpler" becomes a measurable claim instead of a feeling. Skills that decide where in the pipeline a defect should be caught - type system, lint, test, runtime - so errors surface as early as possible. A skill called design-and-refactor that sequences the others into a gate order, so enforcement never runs before design and speculative generality gets caught at the first gate, not after a rewrite.
I added a few of my own on top - a single-source-of-truth skill for cross-layer coherence, and some project-specific ones.
The point of these skills is not that they make the AI smarter.
The point is that they make the AI think like an architect, on every session, without me having to manually inject that perspective each time.
Which means: the architectural standard of the codebase is no longer dependent on whether I happened to be sharp enough, that day, to push back on a sloppy approach.
It is encoded.
And the AI applies it more consistently than I would.
That is genuinely strange to admit. The skills do not make the AI better than me. They make the AI better than the version of me that is tired, or distracted, or in a hurry. Which, as anyone who has worked solo knows, is most hours of most days.
It is one thing to know the right architectural questions. It is another thing to have them asked, reliably, every time.
The skills do that.
The shift in role
Take this far enough and the human role changes shape.
Under the old model, I was a developer who used AI to type faster. The AI was a tool. The center of gravity was the code I produced.
Under the new model, I am an architect whose AI happens to do the implementation. The skills are not the tool, they are part of the architecture itself. The code is downstream of both.
What I actually produce, day to day, is decisions.
Decisions about what to build, what to defer, what is canonical, what changed, what has to stay consistent, what the AI is allowed to know on any given session. The artifacts that capture those decisions - specs, addenda, decisions logs, the deferred-ideas register, the skill stack - are the leverage. The code is what the AI generates from them.
This is a different job than coding. It requires a different skill set. It rewards a different kind of brain.
And it has a much higher ceiling.
A solo operator can ship a multi-application system this way, not because the AI is doing a team's worth of typing, but because the governance layer scales further than the typing layer ever did. One person can write the spec for a system that one person could never type by hand.
The ceiling moves from "what can one person code" to "what can one person decide".
That is a much higher ceiling. And, honestly, a more interesting place to work.
Where it falls short
I want to be honest about where this breaks down, because the version of this piece that just sells the approach would not be useful.
For prototypes and exploratory work, this is overkill. If you do not yet know what you are building, forcing yourself to write a definitive spec will lock in the wrong shape. The approach assumes you know enough to be definitive. Sometimes you do not.
The upfront cost is real and dopamine-free. Writing a PRD before code is genuinely slow when you are used to just starting. The first time you do this on a new project, you will feel it. There is no running app, no green checkmark, no satisfying feedback loop. Just you and a document.
Specs can become a substitute for shipping. The discipline of "document first" can quietly turn into procrastination wearing a productive costume. You can spend a week writing a beautiful spec for something you should have prototyped in an afternoon. I have done this. Well, maybe not a week, but you get the point.
Document maintenance is its own job. Addenda accumulate. Reading orders get long. At some point you have to consolidate or the doc set itself becomes the problem. This work produces no visible output, and it is easy to defer until the system becomes incoherent.
The AI is still the AI. A great spec does not fix model limitations. Context windows fill up. Reasoning fails. APIs get hallucinated. Regressions happen across sessions. Skills reduce variance. They do not eliminate error.
It rewards a specific kind of brain. People who think in systems and write naturally will thrive. People who think by building will not. The approach has a personality, and it is not universal.
Reversing course is heavier. When a foundational decision turns out to be wrong, you do not just change the code. You write the addendum, update the reading order, possibly retire sections of a PRD, and re-orient any in-flight AI sessions. The same governance that gives you coherence makes pivots more expensive.
It can be lonely. Working this way as a solo operator means the spec is also the conversation. There is no colleague pushing back on a bad decision before it gets written into a Decisions Log. The discipline that protects you from drift also removes some of the natural friction that good teams have.
None of this makes the approach wrong. It makes it real.
What this is really about
I keep coming back to the same observation.
A blank chat window with an AI can answer almost anything. But a system that has to stay coherent over time should not answer almost anything. It should know what it is building, what choices have already been made, what is deferred, and what to read before it starts.
That is not a model problem. That is an architecture problem.
And it turns out architecture is exactly the thing the AI cannot do for me, and exactly the thing the AI lets me do at a scale I could not have reached on my own.
I am not a faster coder than I was years ago.
I am a different kind of worker. One who spends most of his time deciding what is true, what has changed, what is deferred, and what should be allowed into the system. One who reads specs more than code. One whose most valuable output, on most days, is a document.
That is what is left for the human when the AI writes the code.
It turns out to be the part of the work I find the most interesting.
The skills I rely on come from Patrick Savalle's L-GEVITY pack - open-source, platform-agnostic, and the closest thing I have found to a real architectural standard for AI coding agents. You can find them at github.com/l-gevity/l-gevity-skills.
Originally published on LinkedIn.