I've come back from paternity leave and the landscape of software development has dramatically shifted towards agentic coding. What wasn't working is now working. What wasn't possible is now possible. Here are some notes I made as I catch up on the new status quo.

Tokenmaxxing

A good metric for how effectively you are using coding agents is how many tokens you are spending.

I vibe-coded a small tool (inspired by CodexBar) to help me visualize it. Contrary to CodexBar's motto "May your tokens never run out", this tool shows a progress circle that encourages you to finish the token treadmill on time. Ideally I’d really like it to run out of the limit just before the cycle resets. An additional sweet feature is it shows token distribution by projects, similar to how screen time shows usage by app. So I’m calling this app "Token Time".

Human-in-the-loop minimizing

On the opposite side, human-in-the-loop, while previously an important feature of agent, has become a minimization function to optimize.

Tools and Knowledge

Sometimes, it’s necessary to identify that the tools available to the agents are clunky and it’s worth the investment to ask them to build or refine the tools. All-mighty AGI still needs tools and can’t build anything from ground. Just imagine Optimus robots have to do plumbing without any tools. Examples of tools include log utilities, devtools panels, test harness, etc. One helpful term to think about it is backpressure. You progressively give agents more capable tools to verify its work so that it comes back to you less.

It’s also helpful to ask your agents to document sufficiently, do plans, writeups, postmortems like what a typical engineering team would do, so that it has a wealth of knowledge available.

Verifying work

Verifying work is the highest leverage part of reducing human in the loop. Giving direct feedback is an obvious part of human-in-the-loop. But a non-obvious part is when you are doing work outside of the agents, especially verifying the results of the agents' work. Any time you work manually outside of the agents is an opportunity wasted not letting the agents go on an autonomous cycle. Ask the agents to remember always build, test, deploy, run the app, verify after every fix or feature, and before you need to intervene.

Start by treating the screen real estate outside of agents as read-only, and then step up the game to not look at the screen real estate at all. (Or with the emergence of tools like OpenClaw, develop just by messaging - more on that later.)

Front-load steering

On bigger tasks, it’s useful to front-load steering. You can ask claude to interview you first, with the AskUserQuestion tool.

Here’s an example prompt when I make a learning website.

I want to build [brief description].

Be as agentic as you can to work on this and only ask for my feedback upfront. agentically work on the feedback gathering until you are sure that's all of the questions you are going to need. seek little or no feedback wile you are going at it.

Interview me in detail using the AskUserQuestion tool. Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered. Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

Include a README.md and Makefile (with help command) when you have finished.

Prompt - Steer - Upskill - Loop

The Read-Eval-Print-Loop (REPL) is an age-old concept in software engineering. The new age breeds a new loop: Prompt-Steer-Upskill-Loop (PSUL).

Prompting and Steering becomes AGENTS.md (Looking at you - Claude please support AGENT.md), hooks, skills, subagents, plugins. Long-term, inevitably the skills will be dissolved in the models. But for now, save useful prompts, recognize the pattern, upskill your agents, rinse and repeat. The best part is you can upskill your agents using agents themselves.

Coding agents are the makers now

REPL and PSUL are not one-to-one comparable. It would be like comparing crafting verses herding cats. If you are a maker type it might need some getting used to because your job now looks more like an engineering manager. You are responsible for articulating your vision, providing strategic context, shielding your agents from complexity, balancing their creativity and discipline, giving coaching, optimizing their capability.

Your agents are the primary makers and you’ll want to protect their maker schedule by not doing the equivalent of inserting a meeting in the middle of their work session, aka context pollution.

Automate the unautomatable

One of the things that are not feasible before is the automation of everything. Automation was either tedious, boring or the effort to automate is often greater than the thing it automates. With the advent of coding agents, the activation energy collapsed. The cost benefit analysis reduces to token pricing.

Just ask Claude to do X. Claudes wields Chrome, playwright, osascript,XCTest like extension of its own hands. It finds every APIs, finds creative use of programming languages to complete the task.

One of the most amazing time saver that Claude Code did for me is automatically generating app screenshots from automated tests, and generating / uploading App Store's marketing images. I refer it to an existing app’s pipeline which helped, but the amount of intervention I need is minimal. This used to take hours.

Workflows tips

Agentic workflows are becoming more important than coding skills.

Here are some workflow tips, some stolen from Boris’s (Claude Code Creator) setup and Claude Code Best Practices:

• Start in Plan Mode (shift tab twice) for involved sessions.
• Anytime you see Claude do something incorrectly add it to CLAUDE.md.
• Give Claude a way to verify its work. If Claude has that feedback loop, it will 2-3x the quality of the final result.
• Use Subagents. I sometimes tell Claude Code to launch a research agent to deep dive on some topics or launch parallel subagents if the tasks are not inter-dependent.
• Code-simplifier subagent to simplify code. Verifier subagent to verify end-to-end.
• Run each Claude in a separate git checkout.
• To roll back, just press Esc twice.
• /clear and /compact <focus> for manual context managmenet
• I direct Claude Code to use specific tools. (It’s useful to understand what tools Claude Code have: Tools and system prompt of Claude Code). Sometimes I need to explicitly ask claude to use curl vs web search to fetch the desired information.
• When doing explorationg work and I'm not satisfied with a plan, I ask Claude to save its thinking and proposal to a writeup. And I say "Let's table it." and revisit in the future.
• For quick look ups I added an alias vf to fuzzy-find and open a file in vi: vf() { vi $(fzf) }
• I made a yolo plugin for automatically approve or bypass permissions using Opus as security reviewer.
• I made a plugin for notifications in ghostty tabs.

Useful Skills and Plugins

Skills

If you come from the MCP era like me and wants to know when to use Skills vs MCPs, a good reading is What if you don't need MCP at all? where Mario Zechner used an agent-please-read-this-on-demand README.md. This pattern recurs enough, and skills as an abstraction emerge. There is also mcporter by @steipete the ClawFather, if you need to create CLIs from MCPs.

Here are some good collections of skills: anthropic, vercel, mitsuhiko.

Plugins

Code simplifier plugin: After installing the plugin, you can tell Claude to use code simplifier agent to simplify the generated code.

Design plugin: It generates multiple design variations for refining and doesn’t clutter your workspace. I used this to redesign RecurseChat’s website. 

Some amazing moments

Moment 1: I looked at a feature implementation, something unrelated broke. I asked Claude to revert the changes. It still breaks. Then Claude reasons that it must not be the changes it made in the session that breaks it, and goes full git blame mode, and of course, it finds the bug and the root cause analysis. I ask Claude to write a postmortem writeup about the original bug and it happily did.

Found it. This is a pre-existing bug introduced by commit d308c0e (find bar), not by this session's changes.

Moment 2: Local build succeeded but Vercel deployment failed. I gave Claude the Vercel API token and it starts autonomously fixing various errors, deploying, and watching for build errors. After several loops in a row, Claude says:

We'll keep playing whack-a-mole unless we fix the root cause. The right fix is to make Vercel use Yarn 4 to match your local environment.

And went on to fix the underlying root cause.

Moment 3: I made a system monitoring app with egui, then I asked:

Can we make the app more evangelion design inspired in the overview page? use your imagination and be ambitious (for evangelion theme).

And Claude one-shotted it.