If you often switch between coding agents, or if you don’t do it because it is too tedious to set up (and keep in sync) skills, prompt templates etc, try using an agent skills management utility.
The most popular one is npx skills from Vercel and I use @sentry/dotagents.
Even though models have gotten much better at explaining things, they sometimes still end up dumping a wall of text that is very painful to go through.
Dillon Mulroy’s /bro skill cuts through the crap surprisingly well. The entire prompt is:
Restate your last message. Stop using jargon and speak coherently. State it more simply and concisely, like one human talking to another.
Use it when an agent’s explanation gets too dense. You can install it as a skill or prompt template and invoke /bro, or just paste the prompt.
There is a meme on X that frontier LLMs have gotten so good that how we prompt doesn’t matter. Absolute BS.
Here are a couple of magical prompts that improve the quality of generated code. Try them in a non-trivial agentic coding session and you’ll see what I mean.
now that you have written the code, how would you do it better and SIMPLER?
Try this after the agent has written the code. Both Claude and GPT models usually come back with some nice ways in which the change could be better done; sometimes, if the change is obvious, they will just do it. They will also usually tell you what they believe should not change.
You can read through and pick what you want the agent to change. Even if you choose to not change anything, the possibilities give you an idea about the solution space and what assumptions & directions the agent took.
review your complete body of work, and try to simplify it. remove code that is now dead. simplify code that can now be simpler. reuse code that makes sense to be shared. find leftovers from previous attempts.
I typically send this after the previous prompt and the agents inevitably find something to clean up and/or simplify.
I’ve not been posting as much to this blog recently. In order to force myself to be more regular, I’m going to post a short note with a tip for using AI every day of November.
Most of these are going to be around agentic engineering, but not all. The common tag for all these will be #ai-tip.
Chris Kiehl:
Reading Hacker News makes me feel like I need to write this: it's still OK to enjoy programming.
Yes, at work, where you are paid to produce value for a business, the economics of purely hand-written code have changed. But that's work. Work is not life. The loudest voices on the internet are the saddest and most infectious.
It's OK to enjoy things. Doing so requires no economic justification.
I feel this. There was a time, when I was young, that I used to program purely for fun. For a few years, my only hobby was programming. Sad? Maybe (or maybe not).
But for the last year or so, I have felt that writing code by hand was somehow “wrong”. I’m going to change that.
Nolan Lawson:
So how do we fight this horde of agents colonizing our brains? In short: stay human, friends. Resist the whispering earring. Be jealous of your time and attention, and try to find other sources of artistic sustenance than the chatbots. As doomed as it may feel, try to keep a part of yourself that is the tiny little village of Gauls holding off the Roman invaders. Whatever your inner sanctum is, protect it from AI infiltration.
Plus, I know that as soon as I ask the chatbot for help on even a single sentence (“can you help this land better?”), it’s all over for me. I’ve already given up on keeping my own voice in my code: I used to care a lot about variable names, function arrangement, which kinds of for-loops to use… and now I just accept Claude’s little stylistic quirks because they’re not worth fighting. If I let the same thing happen to my English writing, I’d feel like it had lost some indelible stamp of me-ness.
A lot has been written about AI writing. This is one of the best I’ve read, perhaps because it echoes a lot of my worries.
Zach Kehs:
Software is in the domain of the abstract. It is not like a building, or a bridge, that is in the physical realm where you can see and feel the nature of the thing. If you continue to add floors and rooms to a building forever, it will collapse. Software faces no such constraint. The code can always get worse. There can always be a new layer of indirection or a reduction in performance.
The pedants will rightfully point out that software can completely fail to function if it gets bad enough. In practice, such breaking changes are quickly reverted. The thousands of changes that came before to make the code worse are not. The software continues to 'work'. Other cases without a single breaking change to revert are where the ballooning costs of the bad software eclipse its benefit, or if development velocity approaches zero because nothing can be shipped without a breakage. In all of these cases, it is the business that dies long before the code hits any hypothetical floor (so don't act like there's a floor!).
Ignore the ostensibly main point about the use of language like “sinking ship”. The argument put forth for it is more interesting. Really good.
Philip Zeyliger:
We are all grappling with what it means to be an organization with agentic tools. We are seeing a Cambrian explosion of workflows in how to produce software. It is unwise, right now, to declare The Solution and enforce it. Developer Productivity teams that are pushing a workflow on their users are being counterproductive. Instead, the moment calls for experimentation and for giving people the agency to experiment, to learn, to iterate.
I agree. Boy, do I agree. My setup and workflow are constantly changing—maybe every month or so. But I see so many people stuck in a local minimum, just using Claude Code the way they were using it back in December last year.
I’m not saying everyone should be constantly tweaking setup/workflow; that’s definitely not for everyone. But not experimenting at all is perplexing to me.
Pieter Hintjens:
This article is an extract from Chapter 6 of the ZeroMQ book, on community building.
I’m not quoting from the actual parable so as not to spoil it. It’s short but profound.
So much good stuff in there. I’ll quote from across sections.
Florian Herrengt:
But then users start to report a weird bug. It's the 4th time your team has been trying to fix it. I mean... asking AI to fix it. Unfortunately, it seems like not even Fable can figure it out.
You go talk to the person who worked on this feature.
- "So where does the data come from?"
- "Hmm... actually I don't know. Let me ask Claude."
You sit next to each other watching an endless wall of text appear on the screen. Neither of you has any idea whether any of it is true but Claude seems very confident.
"Let's just turn on ultracode and ask it to double-check?"
This one will take a while. You start talking about the latest drama on X.
You finally get an answer back.
- "Does this make any sense to you?" * "I'm not sure."
- "Didn't you build this like... last week?"
Silence.
On not understanding large codebase:
Whenever I talk about this, someone eventually tells me that nobody ever fully understood large systems anyway. It's true.
You were never expected to understand every service and every database. But at least someone did and would explain it to you.
Now they ask an LLM because they don't actually know themselves.
Concluding:
Of course, bad engineers were always a liability.
It has been like this for decades, well before OpenAI or Anthropic existed. Bad decisions compounded, unnecessary complexity accumulated and teams ended up maintaining systems nobody really understood.
The difference is that there used to be a limit to how fast you could do it.
Today, implementation is cheap. You are paid to make good decisions. To build software that will scale while managing complexity.
A lot of good decisions have to be made to keep a large/complex codebase healthy. Bad decisions compound. Fast.
Bad engineers make bad decisions, and AI allows encourages them to do it at a speed that wasn’t hitherto possible. Worse, thanks to the deluge of changes that AI enables, it makes it difficult for the good engineers to review & curtail the bad decisions.
The conclusion is obvious: we can’t afford to have bad engineers.