GoKawiilMy AI-Assisted workflow How I built a structured AI-assisted development workflow as a Tech Lead, where the real work happens before a single line of code is written.
You open a chat, describe what you want, iterate on the output, and ship something that more or less works. It feels fast. The features work, technically. But nobody, including me, fully understood what is there. Edge cases nobody thought to handle, architecture that made sense in the moment but didn’t survive contact with the next feature. A growing sense that I was building faster and understanding less.
The problem I kept running into was this: how do you get the speed benefits of AI assistance without losing the clarity and intentionality that makes software maintainable? The short answer is that the real work happens before the coding starts.
The core idea: thinking in writing, not in code
What is AI actually good at? Implementation. What is it genuinely bad at? Figuring out what you actually want, catching the assumptions you forgot to make explicit, and telling you when your mental model of the problem is wrong. That’s your job. It will always be your job.
The single most valuable shift I made was treating every feature as a thinking problem first and an implementation problem second. The workflow is designed to force that thinking to happen before any code is written, and to use AI to stress-test it, not to skip it.
This workflow has been adapted to work with me from Mark Pocock’s skills.
The workflow
Step 1: Free-form plan
Everything starts with a document I write myself, in plain language, with no required structure. I describe the problem, my initial thinking about the solution, the constraints I’m aware of, and the things I’m uncertain about. This is not a deliverable, nobody reads it but me. Its only purpose is to get the thinking out of my head and into a form I can examine.
... continue reading