BACK TO BLOG
The leap from 'Vibe Coding' to Spec Coding

The leap from "Vibe Coding" to Spec Coding

Steering docs and spec docs and task docs, oh my!

If you've been following my posts about building my portfolio with Cursor, you know I've been loving the "vibe coding" life—just flowing and iterating. That experience gave me the confidence to ask for an Amazon Q license at AssetWorks Inc to use the Kiro IDE.

But now that I'm here, I'm realizing that Enterprise AI is a different beast entirely.

I've moved from "Vibe Coding" to "Spec Coding."

When I was building my portfolio, I could just wing it. But yesterday, working on a Storybook component for our Common Component Library (CCL), I had to formalize the process. I wrote two distinct types of documentation for the AI:

Steering Documents: The "Constitution." These are the strict rules (naming conventions, file structures, branching strategies, etc) that the LLM reads to understand the process my developer mentor wants me to follow.

Specification Documents: The "Mission." The specific checklist for the component I am building right now.

Taskdoc and Figma

The result? Relief. Pure relief. I didn't have to micromanage the LLM. It read the Steering Docs, followed the rules, and tore through the specs using the Figma MCP (which, by the way, vastly outperformed the native design-to-code Figma Power in Kiro for some reason).

To everyone who cheered me on with my portfolio updates: thank you. (I am still chipping away at the final pages on that with Cursor.) That side project was the training ground for this professional breakthrough.

#UXEngineering #AmazonQ #Kiro #Cursor #DesignSystems #AICoding #figma #designtocode #ai #vibecoding #enterpriseAI #assetworks #UI #UIdesign