My AI Workflow
How I actually use AI day-to-day: tools, philosophy, project structure, and the orchestration patterns that let me ship far more than I could alone.
Between my job and personal projects, there is genuinely no way I could accomplish even 20% of what I do on a daily, weekly, or monthly basis without AI tooling. I wanted to share my personal workflow, thought process, philosophy, and the specific tools that make it work.
A few disclaimers first
Everything I'm describing is based on what I've personally used and tested. I primarily work with Anthropic models (Haiku, Sonnet, and Opus) and have spent the most time with Cursor and Claude Code as my main harnesses. I haven't found OpenAI's models particularly useful for my workflow in the last few months, though I've heard Codex might be worth a look. I just haven't tried it yet.
One tool I use constantly that's easy to underestimate: Wispr Flow for dictation. Most of my prompts to Cursor, Claude, and other tools are dictated rather than typed. It's significantly faster and keeps me in a thinking-out-loud mode. I've heard of Super Whisper but haven't made the switch yet.
The philosophy
I multitask a lot. Across work and personal contexts I'm running multiple projects at any given time, and my entire workflow is built around that.
The core unit of organization is the thread (called chats or conversations depending on the platform). On Cursor I maintain separate workspaces for work and personal contexts, and each workspace has all relevant repos indexed. This matters because I'm often working across multiple repositories, not just a single codebase. Having everything indexed in one workspace means the context spans the whole system. I name every thread properly so that a project I put down a month ago is something I can pick up instantly when I return to it. I switch between threads constantly, often while one prompt is running. On Claude Code, the /resume command lets me return to named sessions, and the Cursor integration gives me a visual IDE layer on top of that when I want it.
Work trees are useful when I'm working on multiple contexts within the same repo simultaneously. I explain to the model what I want to do and it handles the branching and setup for me.
On the topic of branches: without going too deep into the whole release process, for infrastructure I work off main with a feature branch per change and a PR to merge back. For applications I keep a develop branch with feature branches off develop, merged back via PR that auto-deploys to staging. Releasing to production is a PR from develop into main, which auto-deploys to the production environment.
Starting a new project
When I'm starting something from scratch, I open Cursor with the IDE visible so I can see the directory structure and watch the code land as it's being built. Being able to look at the code in real time, especially at the beginning, is something I find important.
From there I do a lot of prep work in the planning phase, usually in the same thread before starting to build anything. I ask as many questions as possible, have it do as much research as possible, and find all the available tools. I don't like to reinvent the wheel. I prefer tried-and-true open source tools over building from scratch, and I tell the model to ask me questions to fill any gaps it finds. Once the plan is comprehensive and I've reviewed it, I move into plan mode and have it build out the full plan.
When I'm satisfied with the plan, I press build. The goal is for the entire foundation of the project to come out of that first pass. Everything after that is iteration on a real foundation rather than scaffolding from scratch.
CLAUDE.md and STANDARD.md
Every project gets a CLAUDE.md: the context file that gives AI the information it needs about this specific codebase, architecture decisions, naming conventions, what tools are used and why, and what to avoid.
I'm also building out what I call a STANDARD.md: a broader document that defines best practices across development, architecture, infrastructure, and engineering. The goal is consistency. AI is inherently inconsistent, but code and programs aren't. Once something is working and documented, the standard enforces that it stays that way across projects and contexts.
Standardizing this across my entire personal stack and eventually my company's is the next thing I'm working toward, so that every AI-assisted decision is anchored to a source of truth.
What I actually use AI to build
The pattern I've landed on: AI builds the programmatic things, and the programmatic things then run the infrastructure.
Concretely:
- Terraform for infrastructure. I describe what I want, AI writes the modules, Terraform applies it.
- CI/CD pipelines (GitHub Actions, Cloud Build, etc.) defined as code and generated by AI.
- Ansible for self-hosted environments or managing VMs if necessary.
- CLIs and scripts in Go for internal tooling.
- Full-stack web apps in Next.js/React for anything with a UI, Postgres with Prisma as an ORM where it makes sense (which is most of the time).
I don't typically let AI run agentically without structure. I have it build the thing that then runs autonomously, not run autonomously itself.
The orchestration layer
Once a project has a working foundation, I start thinking about orchestration and abstraction.
The pattern I've converged on: build a combined CLI + MCP/API server on top of whatever the project does. The CLI gives command-line control. The MCP server makes it available to AI agents in any MCP-compatible tool. The REST API makes it available to web frontends or other services.
The key is that all three are generated from the same underlying definition. I define the API contract once as Zod schemas, use `@asteasolutions/zod-to-openapi` to generate the OpenAPI spec from that, and then `oapi-codegen` to generate typed Go clients from the spec. On the CLI side, Cobra structures the commands and wires them to the generated client. One contract, every access point stays in sync automatically.
From that orchestration layer you can:
- Interact with the system from a web UI
- Have Cursor or Claude interact with it directly via MCP
- Write skills that wrap specific workflows
- Build a command layer that manages CI/CD, opens PRs, deploys services
At that point you have a system where agents can operate using the tools you've built, anchored to documentation that is the source of truth for every decision. You get the speed of agentic operation within a system you designed and understand.
For my personal work, this is what J.A.R.V.I.S. is: all of these layers running on my own infrastructure, integrated with my home, my tools, and my data. An AI that operates within a system I built, not a black box I'm renting time from. I'm actively building it out right now — there's already quite a bit there, but it's a lifetime project and there's a lot of room to grow. You can see what it is so far on the projects page.
The bigger picture
The through-line in all of this is that AI works best when it's building things that can then run reliably and repeatedly without AI. The goal is to have AI build the infrastructure that does everything. Terraform doesn't need AI to apply. An Ansible playbook doesn't need AI to converge. A CI pipeline doesn't need AI to deploy.
AI helps you build those things faster and better than you could alone. Once they're built, they're just software. That's the part that scales.
What's next
The next post on this topic will go deeper on the standards side: specifically, the STANDARD.md and what I've been figuring out about making this kind of workflow actually function within engineering teams and companies, not just as a solo developer at home. I see both sides firsthand, and they're pretty different. The tools and the philosophy carry over, but the challenges and the constraints don't. More on that soon.