How I'm coding in March 2026

Published

The way we build software is changing rapidly. All of the ingrained mental loops and best practices are being torn up and innovated on at an incredibly high rate and so I've written this blog post for a few reasons:

It will be fun to 'draw a line in the sand' and see how much things have changed in 3 months, 6 months, 1 year etc with something to look back on.

I want an excuse to think about my approach more deeply and writing is a good way to do that.

Previously everyone was pretty much doing development in the same way - now with developers innovating in their own bubbles, creating solutions and practices that fit their own needs, it would be easy for blind spots to appear. Please critique my ideas in this post and let me know if you have preferred alternatives or solutions to my problems.

Many of the things noted here have been inspired by/stolen from public figures in the field - I would love to get similar insight into how my friends/colleagues are working so I'm hoping to start a trend.

Current usage

Web applications

I've been spending some time writing small-scale web applications, largely as an excuse to experiment with new tools and techniques in a low-stakes-but-still-production context.

I'm making heavy usage of Claude Code, mainly running Opus 4.6 and depending on the complexity and particularity of a feature I'm generally interacting with it in one of the following ways:

Claude Code CLI locally in plan mode

For large features that require careful oversight due to security or are likely to need a back and forth to get the implementation or look and feel the way I like it.

I generally spend a good amount of time asking the model to elaborate on parts of the plan and structure my prompts so that it asks me lots of questions about how the feature should be implemented. When writing code this way I will somewhat regularly switch into vscode and make small changes manually or via the Claude Code extension.

Some features implemented this way:

  • authentication
  • persistence
  • initial application sketch out

Claude Code CLI remote

For medium or large but well scoped features and more ambitious experiments that I want to see if the model can one shot.

Accessible at https://claude.ai/code this interface links in to your git repo and runs on a customisable remote environment. To test a feature I run a GitHub action on the automatically generated branch to deploy to a staging environment. PRs can then be created via the interface and reviewed and merged in GitHub without ever having the code locally. If I want more fine control on the implementation or to experiment locally I use git work trees to keep things separate whilst still being able to work on multiple features simultaneously.

Some features implemented this way:

  • dark mode
  • connect four scoring visualisation

GitHub issues with Claude GitHub action

For minor features, bug fixes, documentation, and other small changes.

  1. create issue in GitHub (depending on mental load I'll either write a full 'jira ticket style' issue off the bat or create a reminder for myself and come back to it later)
  2. when clearly scoped, comment "@claude, assess whether this is required and create a pr if so" or something similar
  3. the Claude GitHub action implements the change and responds with a link to create a PR
  4. I create the PR with the link and can then asynchronously iterate by writing a comment mentioning @claude
  5. deploy via GitHub action to the staging environment if it requires manual testing
  6. merge PR and automatically deploy to production

Some features implemented this way:

  • README.md updates
  • swap the positions of two UI elements
  • fix issue with record deletion order

Each of these interactions has a different impact on my mental load, for example, I can only really manage one 'Plan mode' session at once (plus a combination of the other two interaction types). Managing this mental load is a constant push and pull and is a fresh skill for me, previously I coveted deep, focused work on a single problem but that seems to take a different form in the new age. Nowadays, flow state for me looks like having ~2 agents running under direct supervision with various asynchronous small jobs in the background and Lane 8 playing as a sound track.

Additional habits

I use a boilerplate repo containing bare-bones implementations of common functionality and ask the agents to implement features from it piecemeal - this ensures consistency between applications so that I don't have to worry about maintaining two different authentication approaches for two different applications etc.

I regularly ask agents to cross reference between applications, eg "Implement dark mode, use ../payout-calculator as a guide for how I like this to look". I will have already had a back and forth with the agent to get the first implementation the way I want it so this saves time and again ensures consistency.

My applications are implemented using the most ubiquitous, standard approaches possible with Next.js, Shadcn, etc - there is a lot of public code that utilises these so models are good at using them and labs train specifically for them (although there is some debate about the validity of this thinking). I have gone slightly off book by deploying via Cloudflare with opennext as a cost saving measure, in this case I've provided lots of context in CLAUDE.md like pointing the model directly at the relevant documentation.

Personal blog

This blog solves a simple problem - I need somewhere to put stuff - with that in mind I decided to use the simplest tools possible and see how LLMs could handle the scale.

More info on the approach is available on the about page but for development that means that, as an experiment, all the heavy lifting that would normally be done via a framework (React, Ruby on Rails, Astro) is handled with the new tools that models provide.

That means no components and no sass, instead I lean very heavily on skills and agent self checks to keep things aligned which seems to be working okay so far. I quite often ask the agent to 'do a semantic html/SEO/spelling review of the whole site' then assess and address raised issues individually or in groups. It raises plenty of things I don't want to change but that's fine as very often there is also stuff that I do want to fix. One thing I want to try is wrapping this functionality in some sort of automation - maybe precommit or a GitHub action.

Whilst creating the bikepacking blog posts I've been really impressed with Claude Code's capability on visual tasks. Through access to tools like imagemagick it has been effective at:

  • generating retro gifs from scratch
  • creating SVG icons
  • generating alt text for images
  • making exposure adjustments with masks

Linux and scripting

I recently installed Omarchy Linux on my Huawei Matebook D15 to try something new and to be more intentional with my development setup. If I didn't have access to Claude Code I would absolutely have switched back to Windows by now. It has reduced the time it takes me to resolve issues and implement adjustments from a whole day of poking around forums to a couple message back and forth plus writing sudo a few times.

I document all scripts, configuration changes and OS related adjustments in markdown files that I trigger Claude to update.

The impact on my day to day workflow can be explained through referencing the 'Is it worth the time?' xkcd comic - by reducing the time it takes to implement a script/adjust configuration it becomes sensible to automate/optimise more things and much more time is saved (do not take this as me claiming a 100% hit rate...).

I do not use --dangerously-skip-permissions but I do actively keep my list of allowed commands up to date and relatively broad to help things flow as easily as possible.

Managing context

Although I rarely find myself actually exceeding the context limits of a model, according to the experts there is value in keeping a minimal context for model performance. Here are some approaches I'm using to tailor context to a specific task:

Espanso snippets

Espanso allows me to type something like ":docs" and have a predefined snippet of text inserted. I use these to help write high quality prompts more quickly. For example, whenever I am making an operating system related change I lead with the below snippet then type the actual request below it.

My current system is running Omarchy which is based on Arch Linux - it has the following things configured:

  • Hyprland
  • Hypridle
  • Hyprlock
  • Hyprsunset
  • Swayosd
  • Walker
  • Waybar
  • Xcompose
  • Alacritty

Whilst completing the following instructions please ensure to use any standard approaches, in particular when related to these things - do not reinvent the wheel. If you need to run some diagnostics initially to see if functionality is already implemented by some means then do.

Markdown docs

I maintain topic specific markdown files in individual repos and in a central obsidian vault that can be brought into context as required. These contain summaries of how and why I've implemented features and pointers for using tools. The why is quite important here, there is some interesting thinking going on around spec driven development which suggests that documenting the user need and reasons for technical decisions will be an important part of development with agents. The topic is also mentioned around minute 6 of this episode of Cheeky Pint.

To reduce friction when referencing the central obsidian vault I've created a sign post in my root CLAUDE.md that references the exact file location so I can just mention 'claude docs' and the agent knows where to look.

CLAUDE.md

I keep strong delineation between project specific context and overarching root context and I aim to keep the ~/.claude/CLAUDE.md as small as possible. Here is what is in there:

For image and gif modification use magick

When you have performed an operation on an image or gif I will want to view the end result afterwards using the appropriate tool such as imv or mpv

When asked to "check my claude docs" or similar, look in /home/sam-molyneux/shared/obsidian/Claude outputs/ for relevant documentation.

Some of the things I keep in the project specific files are:

  • specifications of which technologies to use
  • exact commands to run
  • specific corrections for places where the model has slipped up in the past, for example "remember that the backend will run on cloudflare workers so ensure to use only packages that will work there"

References and inspirations

I'm quite happy with how I've curated my twitter feed to get some of the latest thoughts and news, here are the highlights:

Boris Cherny - creator of Claude Code at Anthropic, using it to build more Claude Code. Acts as a really good aggregator of other Anthropic employees and products. Boris's version of this post.

Karpathy - previously head of AI at Tesla and a founding member of OpenAI, coined the term 'vibe coding' - generally a leading thinker in what he now refers to as 'agentic engineering' and AI research more widely. Andrej's version of this post.

Pieter Levels - for the absolute insanity of remoting into the production server, editing php, javascript, html, and css in place via Claude Code and only committing to git once a day

Elvis - for a dose of care and caution

DHH's version of this post as a converted sceptic

gabriel - OpenAI and general chaos

Cory zue's version of this post

disclaimer: some of these people unfortunately have moral/political views that I strongly disagree with, please take their ideas and use them for good

As a final note and to reiterate the sentiment from the opening, if you found this useful/interesting my favourite way for you to show your appreciation would be to write your own version or send me a tip/critique (if you're seeing it, I value your opinion).

How I used AI whilst writing this post

Here's how I used LLMs to help create this post:

  • small sanity checks and research questions to jog my memory such as 'is this a silly thing to write: low-stakes-but-still-production' (apparently not) and 'list some static site generators'
  • as a first pass editor I used the below prompt

You're going to be my editor for the blog post "How I'm coding in March 2026". You won't directly edit the file, I'll do that myself.

We're going to go in a few stages:

  1. spell checking
  2. grammar checking
  3. flow and structure

Ensure that I am happy with the state of each stage before moving onto the next.

In each case please only highlight glaring errors, its important that the voice is maintained.

Thanks to George for being my human editor!