Overview
Basically, for this article, I’m just going to give a quick intro into the current state of how I approach AI driven development. I’m going to talk about the different skills and workflows that I use and also discuss the drawbacks and kind of just show you how I work right now. One thing to establish before you start reading this article is that basically my workflow changes every day, or probably at least every week and is subject to whatever new tool comes out or new model comes out it usually changes a bit.
Harness, Skills, etc.
TLDR: I follow the Matt Pocock skills workflow.
So the first thing I wanted to start with talking about is what harness I use and the different skills that I’ve been using to basically facilitate my entire workflow. For those who are not aware, harness is basically like the modality in which you write to the AI as a prompt, think of things like Claude code, Codex, GitHub Copilot, etc
At Microsoft, I predominantly used the GitHub copilot app, which was fantastic to work with. It really easily let you manage different work trees across multiple different repositories and handle multiple multiple different threads at once, which I really enjoyed. Now being outside of Microsoft and havign the freedom to choose what harness I use, I have been mostly using Codex CLI on Linux/Windows and sometimes using the Codex app on Windows. I have also tried out Claude Code a bit. Predominantly I use Codex more since at this point in time, I prefer GPT over Claude. GPT tends to do what I say exactly, Claude tends to take liberties interpreting what I say and then overengineers. This holds true for all things except React code, which I find Claude is still King for.
As for skills, I have been using a basic version or RPI (research -> plan -> implemnent) for quite a while. This basically involes a simple prompt like I need to add sub 100ms lookup to this table. Key requirements: x, y, z. Notes: a, b, c which then kicks off a research agent to grab information from the web. It will propose some bit of a plan which I then instruct it to split up into tickets. After approving each ticket / going back and forth I then instruct the agent to implement each ticket one by one. I found this worked well for a long time but it’s highly dependent on you providing excellent requirements and notes to the model to guide it. This isn’t always known when you go to implement the thing and can lead to issues down the line when you go to edit it to fit your new requirements.
Because of the above, I have decided to try out Matt Pocock’s skills workflow. These skills center around setting up some ground rules / way of working within your repository that the agent will follow. This is done via setup-matt-pocock-skills skill which chooses a place to set tickets for agents to implement, sets up a context map and some other useful instructions for agents. After doing this one time step in the repo the workflow is as follows:
/wayfinder-> creates a “map” that you and the agent agree on to get from your foggy requirements to a clear destination/to-tickets-> splits the map into small digestable tickets that a single agent can tackle/implement-> implements a ticket using two additional skills:/tddand/code-reviewwhich are about test driven development and code reviewing respectfully
A key distinction between Matt Pococks way of working and the simple RPI workflow is that you clear your context after each ticket is being implemented. There is a loose theory that as the AI’s context window gets filled up the general “intelligence” of the model decreases. I haven’t found some proper research on this but generally there seems to be a lot of anecdotal evidence that this is the case. Since adopting this workflow, I totally agree.
Model Choice
Like I mentioned previously, I’ve been predominantly using GPT over Claude, and there’s a few reasons why. The first one I noticed is that I used to really heavily use skills that aim to simplify the amount of tokens being used within a session, think skills like caveman and ponytail. Always found that on a multi turn session, GPT would stick with that for way, way, way longer than Claude would. It almost always felt like Claude would just ignore it and not really use less tokens and not simplify the output. Whereas GPT followed it for many, many turns, and then maybe only after I compacted the session or really started to get up to the high context window, it would maybe lose track of that a little bit.
So with that in mind, I recommend using GPT-5.6. Typically what I do now (since I’m paying for my own tokens) is I use Sol to plan and then use Terra or Luna to implement. I haven’t really found any way to properly measure the impact of doing this besides the fact that it feels as if I get more use of my plan doing this as opposed to just using Sol for everything.
MCP and Other Tools
Before I get into what MCP servers I use, I highly recommend you use Rust Token Killer. This is basically a CLI proxy that intercepts commands the LLM wants to run, runs it on its behalf, and then only returns the output that it needs, which drastically saves tokens if you run really long context workflows or let your AI do a lot of things on its own. I find that especially for orchestration related tasks like researching, planning and all this stuff it works really well and saves a lot of tokens.
Besides that, I should also mention that for MCP servers I basically just installed the ones that are useful to the context that I’m working in. For example, at Microsoft I had all of the Azure skills and MCP servers set up that way I could have an agent just automatically hook into these things and I wouldn’t have to go do it on its behalf or fetch the information in some suboptimal way I can just connect the MCP and it can do it all on its own. But then outside of work I predominantly use Supabase and Svelte to do a lot of my side project development, and for that I use both of those MCP servers.
The general will apply with MCP servers is that if there’s some piece of documentation, I want the agent to automatically kind of fetch when I ask it a question then I install an MCP server for it. Like when you’re working in Azure and you have a .NET project, having an MCP server to the Microsoft Learn documentation which has all of the API definitions, all of the guides you could possibly ever want it’s really useful for agents to produce higher quality answers.
One last note on MCP servers is that I find myself stating at the end of a prompt to specifically use an MCP server if I think it should. I find that this is optional and sometimes it will just do it automatically but I always like to put it because I find that it’s more definite if I state “use this MCP server”.
Conclusion
So this was a little bit of a workflow overview. I’m sure this will change over time and I’m sure I will adapt it. And to be honest, I don’t always follow it it’s just when I have a structured set of features that I want to implement. Sometimes I’ll just freeform and just prompt the AI simply without dwelling on the format. Sometimes I’ll just ask it a question. All’s to say, it’s not always the case that I follow this very strictly but definitely when I’m doing feature development I follow this workflow pretty closely.