I agree with this. If it’s text, I do it in the terminal, but I still use GUI for Chrome or Zoom. I think the discoverability depends on the product. On the other hand, in the terminal, it’s a help flag or a man page.
Technically when you write in the domain, you are effectively making your own Lisp and then using it. It’s one of the amazing things that macros can do.
I would call these different dialects of Lisp. The data doesn’t have to be a function. It’s illustrative. The patterns of application still work. What’s the difference if delimiters are different or if you are calling JVM libraries? The high-level ideas are still right there. Consider JavaScript. It is definitely not a Lisp, but if you model it as Lisp in C’s clothes, then all of a sudden IIFEs make total sense. The point is that it’s a helpful mental model for languages other than Lisp.
An untested codebase doesn't just lack tests. It actively teaches every contributor, human or agent, that tests aren't part of the work.
Coding agents pattern-match on what they find. If the convention is no tests, that's what they'll write. And the longer it goes on, the more the codebase is shaped in ways that make testing harder, which entrenches the pattern further.
New post on why testing is no longer optional in the new world of agentic coding, how to start when you have zero tests, and what to do when the code resists being tested at all.
I built a tool. It scaffolds a Claude Code agent harness into any project.
A harness is the system that lets an AI coding agent produce correct, high-quality code consistently. It has four parts:
Guidance: CLAUDE.md and rules in .claude/rules/ that shape what the agent writes.
Guardrails: automated checks (lint, tests, build) the agent runs.
Flywheel: review feedback updates a rule file. The next conversation starts smarter.
Workflows: agents, commands, and skills under .claude/ that turn institutional knowledge into runnable procedures.
sellier ships a generic, slim version of all four. You run it once, then run a Claude command to fill in the placeholders.
If you let an AI agent loose on a non-trivial codebase, two things happen. First, it gets a lot done. Second, it gets a lot done in the style of whatever it last read. Drop it into a file with anemic models and inline authorization checks, and the next thing it writes will be an anemic model with an inline authorization check. Agents are mirrors with momentum.
This post is about how we stopped fighting that and started using it. It covers two iterations of a system we call the harness — the set of files, rules, and workflows that constrain what an agent produces in our Laravel + React monorepo. The first iteration was a scattering of CLAUDE.md files in subdirectories. The second is a .claude/ folder with rules, agents, commands, and skills. The second is dramatically better, and the reasons are worth writing down.
The audience here is engineers who are picking up agentic coding and want a concrete pattern they can copy.
You can use AI coding agents on real production codebases and get predictable, high-quality results if you treat the agent like a junior engineer who needs guardrails, not a magic wand.
Note this series is half-published and updates will be coming over the next few days.