AI coding tools do their best work after you have already done the difficult thinking. Start with an idea, use AI to expose what you need to research, read the sources yourself, refine the idea, run deeper research, and add your own expertise. Only then should you hand the result to a builder. If you do not understand the problem well enough to challenge the output, you are not ready to generate it.
Fable wrote the first pass of most of this website's code, infrastructure, and deployment in hours instead of weeks. That speed came at the end of the process. The preparation took longer than the build.
This AI-assisted development workflow is for work where the output has to survive production, not just look convincing in a demo. The tool can move quickly. Someone still has to know what good looks like.
An AI-assisted development workflow starts before the build
"Write the plan first" undersells what happened. I did not start with a prompt detailed enough to generate this site. I started with an idea, asked ChatGPT to expand it and give me links, then read those links and researched the subject myself. What I learned went back into the idea. The stronger idea produced better questions, and those questions went through another round of refinement before Deep Research ever touched them.
Expand the idea
Start with the rough idea. Ask ChatGPT to expand it, challenge it, and provide links to relevant material. The output is not a specification; it is a map of what I do not know yet.
The first five stages produced no code. They were about learning what the site needed to prove, who it needed to convince, which assumptions needed evidence, and which decisions I had to make myself. Deep Research came late because deep research against a vague idea only produces a deeply researched vague answer.
The research still was not enough to build from. I added what I knew from architecture, engineering leadership, delivery, design review, and operating production systems. Then ChatGPT helped expand the content, expose gaps, and document the decisions. Fable received that prepared foundation, not the original idea.
Give AI a foundation it can build on
Preparation does not mean deciding every line of code before the model starts. It means deciding enough that the model can fill in implementation gaps without inventing the product. The foundation needs a purpose, constraints, authoritative sources, structural decisions, examples of the intended behaviour, and a standard the result has to meet.
For this site, that foundation ran past three thousand lines. It included a responsive-first mandate, a DRY and SOLID standard for every component, a content schema for every collection, the states and user flows each component had to support, and the architecture behind the site. The defensive CSS work began by reading defensiveCSS.dev and deciding which rules applied here: min-width: 0 on flex children, object-fit on images, and no careless fixed heights.
The nebula shows the difference. "Make a nice space background" leaves the important decisions open, so the model has to invent the visual system. A foundation says what the layers are, how they relate, how they move, and how they respond to the pointer. The model can then fill in shaders, particle behaviour, component boundaries, and implementation details inside a direction that is already coherent.
That is the useful division of labour. I provide the foundation and decide which gaps the model is allowed to fill. The model supplies speed and detail inside those boundaries. The same foundation becomes the review standard: when the output drifts, I can compare it with an agreed decision instead of relying on a vague feeling that something is wrong.
Expertise makes AI coding cheaper
The model ships bugs. Engineers ship bugs too, so this is not a complaint. The point is who catches them. Every bug below surfaced on a phone screen, and each one took a single message to fix because I could name the cause instead of asking the model to guess.
The page scrolled sideways on mobile. The cause was a hidden layer shifted right by a transform. Invisible content still widens the page when it moves toward the right edge. That is a known class of CSS bug, and naming it turned a hunt into a one-line fix.
The fixed background jumped during scroll and snapped back. The mobile URL bar changes the viewport height mid-gesture, and anything sized to the dynamic viewport moves with it. Sizing the canvas to the largest viewport unit ended it.
Text refused to shrink inside flex rows until the columns got min-width: 0. Grid tracks needed minmax(0, 1fr) for the same reason. Defensive CSS is a checklist, and the model applies it well when told, but recognizing the symptom in a screenshot was my job. Here is that exact bug, alive:
min-width: auto (default)The URL cannot wrap, the child cannot shrink, and the row runs off the edge. The dashed border is the clip saving this page.
Tokens are the budget here. A model that has to discover a root cause by trial reads files, proposes theories, and burns a session. A model that is handed the root cause writes the fix. General knowledge is what makes the tool cheap.
Treat AI-generated code as a draft
Every change went through the same pull request process a human contributor's would. A feature branch opened, the diff got read line by line the way I would read a coworker's PR, and only a reviewed diff merged. Deploys trigger off main and dev alone, so an unreviewed branch cannot reach production by accident.
That is the same release discipline behind my CI/CD and release automation work: control what can move upward, make the artifact identifiable, and do not let speed bypass review.
That habit caught things a glance at the running site would have missed. A color palette that looked fine to my eyes failed a contrast check under review and got swapped for one that passed. A "fix" that solved the symptom in one component turned out to duplicate logic that already existed elsewhere in the codebase, and the review caught the duplication before it shipped. Treating the model's output as a draft, not an answer, is what the process is for.
Production readiness is more than code
The build reaching "done" was the halfway mark. What followed was two days of short working sessions with the model, spent on the parts of a website that never show up in a screenshot. The full architecture and deployment behind this site had to work as a system, not merely render a homepage.
The list from those two days: the title and description each page shows in a Google or Bing result. The card a link unfurls into on LinkedIn and Slack. Structured data that validated but carried datetime warnings in Google's testing tool. An accessibility pass. A navbar that wrapped to two rows on Chrome for Android and nowhere else. Dead scroll space under the footer that only existed on phones. Favicons and the web manifest. A Lighthouse score dragged down by the WebGL sky rendering on a CPU inside the test lab. Whether the site still reads when an AI agent browses it instead of a person. Cache policies per asset class at the CDN. Analytics to measure whether any of it works.
The model fixed each item in minutes once asked. Knowing what to ask was the work. No screenshot announces a missing timezone in structured data or an uncached asset. Each surface needed a name, its own checking tool, and the same review loop as the code.
When this workflow works
This workflow only works when someone involved knows enough to judge the result. AI can point you toward useful sources and teach you the vocabulary of an unfamiliar domain, but that does not make the output safe to ship. Read the material and have someone with real domain expertise review the decisions.
If nobody can recognize a wrong answer, stop at a prototype. More prompting does not replace expertise.
Know the problem better than the AI
Judgment in, quality out. That held at every stage of the pipeline, not only the one that wrote code. AI expanded the idea, exposed research paths, deepened the refined brief, added detail, and executed the build. I still had to read, understand, decide, and review.
You need to know the problem better than the AI building the solution. Otherwise, you cannot tell whether it filled a gap correctly or confidently invented the wrong thing. The teams that get real pace from these tools will be the ones that prepare for them.