Don’t hesitate to build your own tool or even a whole program for a single operation. For a woodworker this is a fairly common situation. When there is no tool at hand that fits the job exactly, they make one. A one-off tool improves the precision and elegance of the solution. With an agent, it takes minutes.

For inspiration, here is the “Playground” skill: https://github.com/anthropics/claude-plugins-official/tree/main/plugins/playground and an elegant demonstration of building a one-off tool (the author is a designer, not a developer): https://www.youtube.com/watch?v=lkKGQVHrXzE&t=2172s

Before the agent writes a plan or a spec, let it interview you. Matt Pocock calls this grilling. The AI will happily ask you 30 questions, to the point where it gets a bit uncomfortable. But that is the point, fill in all the gaps and replace the agent’s hidden decisions with your own.

For me this works better than reading through a lengthy spec the agent generated from a thin brief. A side product is a shared vocabulary for more efficient communication, and a record of the important decisions.

Details and a concrete skill here: https://www.aihero.dev/skills-grill-me

Out of the box Claude Code can do more than I need day to day, and every tool and feature costs tokens right at startup. In settings.json I limited what I rarely use and dropped about a third of the system prompt and built-in tools. The difference between models is even bigger. With optimized Opus 5.5 I start a session at 8k tokens, with unoptimized Sonnet 5 at 25k. Comparison: https://html.lukastrumm.com/claude-context-compare/

The saved context lets you stay in the “smart zone” longer, making better use of the model’s own intelligence. Any feature can be turned back on for a single session when needed. Here is each setting I limited and why: https://github.com/lttr/dotfiles/blob/master/claude/README.md

You still need to review code, but these days it often makes more sense to look at it from a higher level. And when you spot something, you want to give the agent targeted feedback right in the context of that code.

You can get the higher-level view by grouping the changes into distinct areas. Try it on any GitHub PR with a tool by Anthony Fu: https://pulls.review

The feedback part is a review tool you start right from an interactive session with the agent, which then hands your comments back to it. Matteo Collina built such a tool: https://githuman.dev I tried to build my own that combines both ideas and adds a bit more. It turned out not to be that hard: https://github.com/lttr/git-history-viewer

If some simplification is welcome, or necessary because of the amount of changes you have to take in, it can help to have an HTML overview generated. Simon Willison described the approach: https://simonwillison.net/guides/agentic-engineering-patterns/linear-walkthroughs/

Over the weekend I built a simple photo editing app (none of the existing really suit me 🙂), but at the end I wondered how I had actually built it. I used a coding agent, but also a surprising number of technical terms. I wrote zero lines of code and read only a couple. And yet I used quite a lot of software engineering. So was it vibe coded? Not really, since I care about the source code even though I haven’t read it. It was definitely not AI assisted development either. So it had to be agentically engineered, although on a very small scale. A weird term, but quite precise.

The term was coined by Simon Willison, who first tried vibe engineering https://simonwillison.net/2025/Oct/7/vibe-engineering/ but later settled on agentic engineering https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/

Here is a kind of interesting report on how Claude analyzed my work on the mentioned photo editing app: https://html.lukastrumm.com/photo-cruiser-agentic-prompting/

So far I’ve used AI agents mostly interactively. Recently, though, I found a useful job for them: filtering the content I want to follow.

With a Claude Managed Agent I built my own news feed that pulls together blogs and social media posts every day. The upside is that I can read it on an e-ink tablet, without being interrupted by ads or irrelevant posts.

The second example is keeping track of software changes. For Claude Code, I occasionally run a skill that reads my configuration and works out which of all the new features are relevant to me. The skill is here: https://github.com/lttr/claude-marketplace/blob/master/plugins/cc/skills/changelog/SKILL.md

Text output from LLMs doesn’t have a good reputation. It’s too long, hard to follow, and uses the wrong words or tone. That’s why I think it still holds that text meant for another person is better written by hand.

Still, the cases where we have to read something generated by agents will probably keep growing. So how do we make the text output better? First, upgrade an old model. Opus 5.5, for example, is miles better than Opus 5.

I often use a skill inspired by a tool for spotting odd AI clichés: https://tools.simonwillison.net/llm-cliche-highlighter I built a script for it that checks some of the principles deterministically too, e.g. the distribution of sentence lengths.

Another skill I have is trained on what I wrote myself. I use it when it annoys me how formal some text is.

And finally, when the agent’s answer is just needlessly long, I use the /tldr skill, which says: “Write it in 3 points at most”, and quite often that’s enough.

You can find the skills mentioned above in my marketplace: https://github.com/lttr/claude-marketplace/blob/master/plugins/writing/README.md