My Development Workflow in 2026

My workflow for new projects usually follows the same pattern it always has: open the editor, write some code, make it work. The tools around that loop have changed significantly, but the loop itself hasn’t.

Here’s how I actually work in 2026.

Start With the Data

If I’m designing something that involves a database, I start there. The schema forces you to think through the domain before you write a single line of logic. I still over-design at this stage — I’ll list objects I’ll never end up using, plan for cases that never materialize. That’s fine. The exercise of thinking through the full shape of a problem is useful even when half of it gets cut.

If it’s not a DB project, I work through the workflow another way: list the pages if it’s a site, list the commands if it’s a CLI tool, list the API endpoints if it’s a service. Something concrete to anchor against.

Build One Thing, Then the Next Thing

Once I have a rough map:

• Build one unit of work — a command, a component, a route, whatever the atomic piece is for this project
• Make it work
• Break out any new objects or abstractions that emerged while building it
• Write tests if other people will ever touch this code
• Commit

Then repeat.

I shoot for 70–80% test coverage on shared projects. If it’s something only I’ll ever use, I’m more pragmatic about it. I don’t trust others’ code very much — that’s not a knock on anyone, it’s just honest — and tests are the contract that makes collaboration possible.

AI-Assisted Coding: Where It Fits

This is the part of the workflow that’s changed the most. I use Cursor as my primary editor and Claude Code CLI for longer-running tasks. Both are deeply integrated into how I work now.

Where AI assistance actually helps me:

• Scaffolding: Standing up the skeleton of a new project, generating boilerplate, writing initial test structure. Things that are tedious and mechanical.
• Refactoring across files: When I want to rename something, restructure a module, or apply a consistent pattern across a codebase. Claude Code handles this better than find-and-replace.
• Code review: I’ll ask Cursor or Claude to review a diff before I commit. It catches things I’d catch in a human review but faster and without scheduling a meeting.
• Unsticking: When I’m looking at something for too long and not seeing it clearly, describing the problem in plain language and getting a response often breaks the logjam.

What it doesn’t change: I still iterate until it works, not until it’s done. AI makes the scaffolding cheaper and the refactoring faster, but “works until it works” is still the job. The loop is the same. The tools inside the loop are faster.

Source Control: Always, Even Solo

Every project I build is under source control. That hasn’t changed and won’t.

Solo projects: I’ll work in main if it’s brand new, or cut a branch if I’m iterating on something existing.

Collaborative projects: feature branches, always. It keeps history readable and makes code review possible.

Iterate Until It Works

I iterate until it works — not “until it’s done”. Every project I’ve ever built is incomplete. There are always things I could add: new features, tests, better abstractions, cleaner code. I asked an artist friend of mine once, “When do you know it’s done?” He said art is never done.

My code doesn’t rise to the level of art, but I agree with the sentiment.

My Indispensable Tools

• Docker — per-repo, still the foundation
• Git — non-negotiable
• Cursor — primary editor, replaced Sublime Text and PHPStorm
• Claude Code CLI — agentic tasks, refactoring, multi-file work
• pnpm — for Node/frontend projects
• MySQL Workbench — still useful for visual schema work
• Astro, Magento, headless — the project types I work with most these days

That’s it. That’s how I work.