Jono's Corner

AI DevEx Log - July 2026

This is a time capsule post, since I'm interested in keeping track of the quickly evolving experience of AI development.

I recently started a project that makes your phone into a context aware desktop controller. Sort of like the stream deck. The project itself is not important for this post - only the development methodology. With every new project, I try to use a new tool. This time that was mostly focused on skills experimentation.

Models

I have several subscriptions to the lowest plan offering from providers. Today that's Claude, Cursor, MiniMax, OpenCode Go. So I have been bouncing between these models mostly because I like to see how they vary:

I recently tried this method of encoding orchestration between models via my AGENTS.md, but I never got it quite working how I liked.

Surfaces

I still have not found that holy grail client that does all I want:

This area has exploded, and my list of ones to try has become exhausting. I have also filed bugs against a bunch of them, which helps me know which are active projects, and alerts me when to come back to them. At this point these projects seems like one offs that scratch an itch, but don't solve the whole problem, or they are forks of Happy, which has its own issues.

For now here are the ones I have been regularly driving in order of preference.

opencode (web only)

Using the existing nix home-manager service. Quite stable and great with tons of models, but cant use claude subscription (though apparently there are workarounds)

t3code (web only)

This gives me access to all the models: opencode, claude, cursor, codex, etc. Active development, but mostly toward the desktop side which I don't use. Buggy, but improving.

claude remote control

I have always liked claude web. Its simple and to the point - but model restrictive. Using remote control gives me access to my whole dev setup, so quite nice.

Side thought: Looking at stars and last commit is a good high level of project activity. But how about looking at ticket churn, PR comments, etc. Or maybe looking for dependents so you know who is using it. Are there tools that extract this data for us?

Inception

I typically start with a conversation at claude.ai (not claude.ai/code). Here I ruminate on ideas, look for prior art, narrow down the goals until the project becomes somewhat tangible. This often happens over days of casual discussion.

Then we discuss naming. I particularly like this part. It generates a bunch of ideas. Then I narrow it down and have it look to see if any of the top candidates are already crowded. Mostly that means it checks for existing domain names, github repos, PyPI projects.

Then I tell the agent to generate a comprehensive inception document. This is pre-planning. So it should contain everything we talked about and how we arrived at the current state. This document is the seed where we can start materializing a spec, so I create a git repo with just that single file.

Execution

This is the first time I went all in on a development framework - to see what the hype is all about.

I tend to shy from skills because I see them used for mundane things, and modern agents should not need micromanagement. For this I tried Matt Pocock's skills which gives a standardized structure to your development workflow.

For the most part, I was following this type of workflow, but straight from my engineering brain, not from a canned repository.

Pros

TDD

I never got TDD to work quite how I wanted when I explain it in a prompt, so its nice to have this all worked out. These models have basically read every book on testing, but they still don't stick to the rules.

Context aware ticketing

In the stage where the spec is turned into tickets, particular focus is taken to keep each one self contained. But more importantly some calculus as been done such that each ticket fits well in a standard context window, and doesn't get muddy during implementation. That's genuinely something I never did before. Neat.

Works across agents

This may be somewhat specific to Matt Pocock's skills setup script, but they can be installed across agent harnesses since I bounce between them quite a bit.

Cons

Sometimes it feels like overkill

Do I really need a hierarchy of documents to describe how a grilling session should go down? For small projects some parts are overkill. Specs, milestones, adr...

There are still gaps

I should probably create skills for these at some point:

Creating a proof of concept

Actually I am talking pre-proof of concept. Often I need to see if some technology even works before I commit to continuing with a project. This is table stakes. For example in deckd, I have never made a web app that can control a mouse on the desktop. I know the tech exists, but will it actually work? Don't trust the LLM's intuition - since it can be wrong. So I need to build a couple demo apps that can test this out before committing to the rest of the project.

Manual testing

After each ticket is implemented I get a report of how it works, the clean up, the testing, etc. Even if the tests pass sometimes the feature is still broken. And even if it runs without a problem, does the feature actually work as expected? Maybe it lead to some visual regression, or it used the wrong wording on the page. I need to roll up my sleeves and try it.

NixOS

A last note on my main driver, NixOS. Some of these tools don't work out of the box there, so I often have to do some upfront work to get them running. For example t3code has an existing package, but not a set up web service, so I had to create one. Nothing an LLM cant handle.