And for bonus points you can have the agent write you a Pre Bash hook. Tell it to make the hook look in the command for anything that’s a git commit. The vaguer your instructions here the better. Let it pull some crazy regex out of its hat. You’ll be impressed.
Humans pattern match against thousands upon thousands of criteria subconsciously.
AI is a different intelligence - a 200 point list shoved in its face all at once doesn’t overwhelm it. That’s only 5-10k tokens!
Bear in mind though, because I added all the items on the list I’ve seen the reasons they’re there & act as a backstop against it missing things. There’s always got to be a quality bar, it’s part of being a professional and signing your name on your work.
There’s a saying for this - “don’t ship your first draft”.
Its first attempt WILL be crap. You can refine its output in the loop as a human, or let it go and then do a quality pass post-hoc.
The beauty of the latter is you can codify and automate a subset of the work, and the agent can loop until those bars are cleared then you get a higher quality work product to look at.
This technique incrementally codifies the subset of my personal definition of code quality that can be codified. I’ve found a discovery based approach is better than anticipatory, because it forces everything you spend tokens to prove its worth.
I still do code review - how else would I know what to codify! But since starting this about a year ago, I don’t review menial dumb AI mistakes anymore.
Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed.
Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider: ...” and proceeds to a bullet list of things.
Any time I notice something in code review and have to get the agent to fix it.. I throw it on the list!
My list is like 200 items now. Know what? Agents don’t care that they just got a wall of generic feedback, they happily look into all the bullet points.
I added “ensure the new things aren’t duplicating code that already exists elsewhere” and it gave me such a surprise - it really truly started planning cleanups!
We are just scratching the surface. We have to give tools to our tools so they can use them to be better tools for us.
Software has several unique properties on both ends of its production process that make assertions of progress based on the software use case invalid.
Software is easy to define as “working”: just run it. But - useful software requires an absolute truck worth of code - 100k loc before you’re talking about a real product, or else dozens of iterations of a toy you make for yourself before it’s useful enough to quit toying with and just use for what you wanted it for.
Sure, the success of software is hard to anticipate and what “good” UX is is hard to pin down - that’s not what I’m talking about. I’m talking just making the code and having no lint errors. That shit is a slog but it’s a slog with a clear goal amenable to hill climbing.
Through that lens software is mostly pattern matching. It’s very rare that an activity in software construction is out of distribution because even if the core of the thing is novel it needs a massive blanket of UI and a tech stack and a production environment to run in and observability and and and and. You get it I hope.
Meanwhile most work out there is a mess of undocumented, un-codifiable detail with no objective criteria for success, only a very wide gradient of “job well done” to “what is this garbage go and fix it”.
We are solving the easy parts of software and soon all that’s left will be the parts that are just like other work. And then we engineers will also be doing mostly squishy subjective judgment stuff.
70s thru 90s computing and even into the early 2000s every new bit of computer meant new capabilities.
Eventually it plateaued and now you can do a decent chunk of your computing on something from 2012.
People keep saying scaling will top out, for example. But scaling keeps stubbornly refusing. New techniques keep coming along too. It's really still exploding into existence and every new generation brings new capability. Eventually it'll clear a ceiling for your key use cases and you'll stop worrying about new models.
It always pays to look back at history and see if you can pattern match.
I use hooks to enforce TDD but the agent has to use bash tool calls to call a script before the hooks allow it to do its job.
tdd_log.py is a short python file with a #! at the top to make it executable, that (due to other hooks) the agent must run to declare its intent to make some tests red or green.