Whispering to the Machine: A Snapshot of My AI-Powered Development Workflow

I had a conversation with another developer the other day that left me feeling energized. We were kicking off a new project, and as we started talking about process, it became clear we were both arriving at similar conclusions about how to actually work with AI in software development right now. It was one of those moments that validates the weird, winding path you’ve been on, making you realize you’re not just shouting into the void.

The landscape is evolving at a breakneck pace. It’s no exaggeration to say it changes daily. This year alone, I’ve worked with two major new series of models from Anthropic, and the difference between them is palpable. The experience is a constant state of flux. What works today might be obsolete tomorrow. That’s why I feel it’s so important to share these experiences—to learn and evolve in public. So, consider this a snapshot, a journal entry of what my process for collaborating with agentic AI looks like in the summer of 2025.

My thinking on this was crystallized by a recent hobby project. I had this pretty big app I’d built years ago, running on an old version of Rails with a Bootstrap 3 front-end. It was the kind of technical debt you just learn to live with. But as AI tools grew more powerful, I started to think, “I think I actually could tackle this now.” That project, migrating the app to a modern stack using Tailwind CSS and daisyUI, became my crucible for figuring out a workflow that works. The conversation I had just confirmed that the lessons I learned were not unique to me.

My current process, forged in that migration and validated by my recent chat, really boils down to five core ideas:

• Plan Meticulously. Before I write a single line of code or ask an AI to, I invest time on the front end crafting a plan. I’m talking about a gigantic document that outlines the objective, the approach, how we’re going to leverage AI, and what kind of prompting we’ll need. You can’t just tell the AI to “go migrate the app.” You have to give it a detailed, deliberate, and audited plan to execute against. It’s the difference between a helpful assistant and a chaotic mess.

• Work Iteratively. With a plan in hand, we break it down into the smallest possible chunks. The goal is to make small, atomic git commits that are easy to review and, more importantly, easy to understand. This iterative approach acts as a series of checkpoints. It keeps the project from spiraling out of control and allows for course correction without having to unravel a massive, tangled set of changes.

• Use the Right Tool for the Job. This has been a huge lesson. Not all models are created equal. In my migration project, I was banging my head against the wall on a particularly tricky asset pipeline issue for hours. I was using a powerful, capable model, but it was stuck in the same loops I was. On a whim, I remembered people saying that Claude Opus was exceptional at complex problem-solving. I switched over, fed it the context, and my god, it figured it out in maybe thirty minutes. It was just wild. The lesson is to have a toolbox of different models and tools like Cursor, and to develop an intuition for which one to bring in for a specific kind of problem.

• Embrace Collaboration. I’ve started to feel a bit like a “model whisperer.” It’s more than just giving commands; it’s about navigating the quirks of your new collaborator. I’ve been struck by the almost apologetic nature of some models, particularly from the Google Gemini family, which have a tendency to get frustrated and then repeatedly apologize for their failures. The behavior can be a bit cringe to witness. It’s a strange reminder that you’re in a partnership with a brilliant but sometimes fickle intern. You have to guide it, supervise its work, and be ready to jump in. The agentic features in tools are powerful, but they work best when you’re right there with them, not when you set it and forget it.

• Don’t Be Afraid to Start Fresh. This was my biggest breakthrough. During the Bootstrap to Tailwind migration, my initial approach was to have the AI refactor the views in-place. It was a disaster. The result was a rat’s nest of legacy styles, broken JavaScript, and endless bugs. The page would fail to load, and we’d waste hours trying to diagnose why. Then, in a conversation with the AI itself, it almost suggested a new path. We switched tactics. The AI would study the old .erb file, and then generate a brand new file from scratch with the same name (after renaming the original to .legacy). The difference was night and day. The process accelerated dramatically. Sure, it would sometimes forget functionality, and I’d have to piecemeal add things back in, but that was infinitely easier than debugging the five hundred errors we were getting before.

This is where I’ve landed for now. It’s a workflow built on planning, patience, and partnership. It’s about leveraging these incredible new tools not as replacements, but as powerful collaborators that, with the right guidance, can help us tackle challenges we might have previously written off as impossible. I’m sure in six months my process will look different again, and I can’t wait to see how.