The AI Workflow That Works For Me

I thought it’d be interesting for my future self to write down how I’m using AI tools now after having settled into a groove after ~8 months of heavier usage and trying different approaches. It’s fascinating to me how everyone adopts AI in their own ways and on their own timeline. I’m mainly interested in seeing how much my own approach will change over time as the tools evolve but hopefully this post will be interesting for you to compare your own approach to as well. Claude Fable dropped as I’m writing this so who knows, this may be out of date before it’s even published.

For a little context, I’m working on an internal application written in Next.js with one other very experienced coworker. We mostly work on different parts of the application but sync up regularly to talk about anything that affects both of our work. There’s an extensive documentation folder that our AGENTS.md points to with docs for all the major subsystems, common developer commands, and repo conventions. The application also has a strong type system that checks everything from sql queries with Kysely, how the data is mapped into internal and external APIs, the query and path parameters for advanced filtering, to all the external API types that are shared with the frontend so any type mismatch throughout the system can be caught and fixed by an agent.

We don’t do “normal” human PR reviews since they’d slow both of us down too much but instead just do self & AI reviews. We trust each other to commit good code and own the consequences of it. I still review every line, but with varying degrees of scrutiny. If you’re building an app where you feel comfortable YOLO’ing it, feel free to ignore the rest of this. I’m currently primarily using Opus 4.8 since it’s been out inside of Cursor and occasionally switching to ChatGPT 5.5 (codex) and Composer 2.5 for quicker straightforward tasks.

What I’ve Tried#

Instead of giving a whole diatribe of every possible thing I’ve tried, I’ll focus on the popular ones that I’ve seen/heard coworkers and friends use that didn’t work for me.

• Using agents to write a giant very detailed multi-step plan all up front, getting specialized agents to review and modify the plan in a loop, then having them go build it all in one go. I’ve found this approach is too prone to going off the rails for me in a couple of ways. First, it’s very tedious to review giant plan documents, not miss anything, and make sure they’re staying true to your intent as they’re being rewritten all the time so I fall into the trap of skimming over them and just assuming the agent will know what it’s doing. Then when it comes to implementation there are inevitably a number of assumptions the agents make that I missed or didn’t think about in the plan that need to be unwound which of course takes time and tokens proportional to how much code is built on top. Lastly, I like feeling out the problem space and making big decisions during the process of implementation and testing. Some of my best ideas come from using the feature in app and projecting out the problems. I find it very difficult to think of all of these up front in the planning process. Besides, isn’t this approach just waterfall anyways? I could see this approach working well if you have a very well defined problem to solve and can verify implementation easily (i.e. have lots of tests).

• There’s another workflow where you generate code through whatever means and then put up a PR before looking at any of the code. You then treat the PR as if another teammate wrote it and use GitHub to review the PR by leaving comments. After your review you then use a skill hooked up to the GitHub CLI that pulls all your comments and either fixes them or answers your questions. I don’t think there’s anything wrong with this approach but for me it felt too cumbersome using the github UI (both web and VS Code GitHub PR extension) to manage the review and the sea of back and forth conversation threads. I prefer to review the code in Cursor after it’s been generated but before it’s committed so I can make light touch ups if needed and know everything checked in has been reviewed.

• Lastly, I haven’t been able to effectively manage multiple medium to large tasks in parallel for any real length of time. By the time I get a couple prompted and going the first has finished and needs review, which takes enough time that the other workstreams complete. It’s too much context switching on top of all the other distractions (slack/support requests/meetings) that I end up missing things I should catch in reviews. The models are fast enough now that you can use the bits of generation time to think about the next step in the process or think about what you’re looking for in the code you’re about to review.

What Works For Me#

Small tasks —> For anything that’s a simple bug fix or feature where I know exactly what the change looks like I’ll write a detailed description in the Jira ticket and then I’ll have a custom skill I made automate all the rest of the work. In a nutshell, the skill creates a worktree with the ticket number, fetches the title and description from the Jira ticket, implements the change, open a PR using the GitHub CLI, waits for the automatic AI review comments and test results, then does one iteration of addressing the comments and fixing any tests. Since I only use this on simple task I don’t want the agent spinning its wheels and going off on tangents so just one round of feedback is ideal. With this workflow I can parallelize a bunch of tickets and then just review the PRs when they’re done.

Medium tasks —> For anything that is a little more involved or ambiguous I’ll use the built in plan mode with the agent to some research and ideating on the change to make sure it’ll go in the right direction when I let it loose. I’ll usually use a faster model for the implementation since the plan can keep them on track well and then I’ll do my review/testing/touch-up/reprompting loop.

Large tasks —> Anything that’s a multi-day effort requires a bit different tactics. I’ll start by brain dumping everything I can think of into a planning doc organized by the phases it should be implemented. In each phase I’ll list any and all that apply and I want to enforce: requirements, business logic, API contracts, data models, performance characteristics. By the nature of learning more as you go, there will be more details in the earlier phases and the later phases will mostly be just user requirements and goals. Then with an agent I’ll give it the whole doc for context but tell it to create a new section for implementation plan (so it doesn’t overwrite your section) being clear to just focus on the first phase. I ask it to do any research needed to resolve ambiguities or come up with alternative approaches to weigh and then architect how the phase will be built. After I loop enough times refining this first phase plan and I’m satisfied with it I’ll hand it over to an agent to build just the first phase.

From there on out I’ll focus on reviewing, steering, testing, and deploying the first phase which inevitably will refine my thinking about how the later phases should go as well as features that might be needed that I couldn’t think of up front. Going through the phases systematically actually using the software and imagining how your users will use the software is so much better than just aiming it in a direction and coming back much later to find it thinks it done but actually ended up in a very different place than you intended.

A Couple Closing Thoughts#

It’s an absolutely wild time for the industry right now. We’ve always had to keep up with the technology treadmill but it’s going faster than ever and only speeding up. Remember that the point isn’t to create as much software as possible, the point is to create as much good software as possible. And as insanely powerful as the tools have become, I still think creating good software will require an experienced human at the helm for the forseeable future.

Here’s a bit of further reading on the subject that I connected with:

https://www.caimito.net/en/blog/2025/12/07/the-recurring-dream-of-replacing-developers.html

https://newsletter.pragmaticengineer.com/p/ai-impact-on-software-engineers-part-2