On some project work recently, I'd been churning out a lot of code for a handful of primitive UI components all week. I needed our core primitives to adhere to our new figma design spec, while still following internal code patterns, all the while they needed to pass accessibility testing with flying colors. For this specific type of work I had found myself deviating from my traditional agentic workflow, which had largely been spec driven development.

Spec driven development can be an over-loaded term sometimes because it means something different to everyone, but my typical workflow involved a series of claude skills that walked me through gathering requirements in a Jira ticket or Figma file, agreeing on an implementation plan, and over-seeing the execution and review of that code before opening a PR. This workflow has felt relatively sane and overall it's been effective. But with my recent primitive component audit work, the spec was Figma only, and I didn't have developer access to the Figma file. A lot more of the plan-creation overhead fell to me, the developer.

In more nuanced project situations like this, where the task at hand hasn't already been fully spec'ed out by a senior developer or TPM, I found myself giving a newer coding strategy a try, which involved a little less planning out front. Why? My hypothesis was that the means didn't matter so much as the output. For example, in one instance I knew I needed a Multi-select component, and I knew how it needed to look. I trusted, lossely, that my agent, with the help of codebase rules and session context, could identify patterns in related components, use the necessary design tokens, and put together a halfway decent solution that might actually be a more efficient way for me to ship while maintaining high quality and low comprehension debt.

While building, I began to feel like I was sitting back in my eleventh grade creative writing class. My teacher used to tell us to "throwup on the page", whenever we were just getting started with a story. He wanted us to let our creative juices flow, and to not get caught up in process or perfection. I always found this to be an effective strategy for writing, but before now I hadn't necessarily been able to apply it professionally at work. Sometimes in claude, just throwing up your thoughts and all of the context you have, could quite possibly be the most effective way to accomplish the task. At the end of the day, any missing context during planning is likely going to show up during code review or a bug ticket later. I've found it to be an effective strategy to throw up all over your claude session, especially in the beginning.

The next step my process would involve doing a manual review of the code, and calling out things that seemed off or confusing to me. I would also move on to do manual testing, since it was UI components. I'd share all of my questions and feedback with my agent, and iterate with it until I'm comfortable with both the code and the functionality. This part I think is important. It's important to intimately test the UI component in the browser, manually, as that is exactly what users are going to do. I'm very particular during this phase, and try to settle for nothing less than perfection. After that, I start thinking about what's for lunch, and I ask my agent to kick-off an automated local code review. This typically catches a few more things, and I'll iterate with my agent until everything looks great. At that point, I'm comfortable opening my PR because I've already self-reviewed and manually tested it.

Til next time!