Here's how I'm currently coding.
If it's front end or something we interact with, I start by describing what I need to do and initial ideas for interface. I'll then generate 30 mockups (10 each from GPT, Claude, Kimi), asking them to make each quite different, and to make each one an isolated html file with embedded JS and CSS. I'll then go through the 30, dismiss most, keep a few, then keep iterating until it feels right for what I want it to do. I find this iteration loop much, much faster than trying to manually spec out a front end design, or trying to write it within a live system while simultaneously hooking up the back end functionality. If it's just a front end change, I'll then ask the LLM to integrate it into the codebase, otherwise I'll park it until the backend is done.
For backend, I start by describing all the things I need it to do with initial ideas for implementation. Normally this is me speaking as I use voice to text all day long. I'll point it to parts or the codebase I think will be relevant. I then get the LLM to write a plan file, which we'll iterate over until it gets to a stage where nothing is ambiguous and it can single-shot the development.
This stage will often involve experimentation and testing. For example, yesterday I added functionality that extracts all upcoming broker-hosted company calls and meetings from our emails and shows it to us in a nice interface where we can limit it to portfolio stocks. A core part of this was making sure we had a system that can consistently extract the right information, so I had the LLM check my email and download a few examples and extract the details it needed, so we had sample emails and sample data it could test the implementation against. Often I'll get it to write CLI tools for backend functionality too, as that makes it much easier to test and once all done allows our agents to easily access this functionality.
I'll read through the plan myself and question the implementation of various things that don't look right or that I don't understand. I'll get it to review it from scratch and identify any issues, both in terms of implementation and ambiguity. Eventually we'll get to a well structured plan and I'll give it the go ahead to implement. Normally this does result in a single-shot implementation that works, but if not, the CLI commands normally make it easy to diagnose where the issues are.
Then, if this feature involves both a front end and back end, I'll point the LLM to the html mockup and get it to implement it. In my dev setup I always work in worktrees, where a setup command updates hosts so the worktree name is accessible locally at
name.t.com. The LLM (or I) can run a "tdev restart" command that reloads the code/server for the worktree it's in. The LLM has access to agent-browser by Vercel, so in this step I get it to test all functionality itself, reviewing the look of every page, clicking buttons, etc. This has saved a lot of time and greatly increased the chance of single-shotting the UI implementation.
Then if all is good, I'll get it to commit changes, merge back into master, deploy to production with Kamal, and move on to the next thing to implement.
I'm mostly using OpenCode for the above, but will sometimes use Claude Code or Codex directly.
Yesterday I added over 10k lines of code this way -- the broker call tracker above, upgraded YouTube stream tracking and analytics code, enhancements to our agents to add heartbeats, better memory and background jobs, a minor update to the Minotaur Capital homepage, and a few other minor fixes and changes.
Feels like what you can get done on a Saturday has taken a massive leap from a year ago.