/dev/null
Job Chong

Models are now really good at producing standard frontend enterprise code, to the point where I can skim PRs they create and approve them. They have some tics I don't like (e.g. excessive modularisation), and as I was considering prompting this behaviour out I thought to myself: what are actual useful metrics for code review today?

IMO the only really useful metrics for UI/UX have never been code-related. I've tried to focus on standard web vitals, memory usage, etc. aside from the usual usability concerns. When we used to have to write React cruft by hand "code quality" counted for a lot for an engineer's mental model of the app, but now with models churning correct and ugly code out? I'm not sure previous models of clean code apply.

Perhaps now the good way to think about frontend work is to really commit to the bit with model generation. I've found a lot of success with a loop that includes the following:

1. Get an architecture diagram and implementation plan going. I get them to create tasks that they estimate will fit within half a context window. Not sure if I'm superstitious or plain behind, but if it ain't broken…
2. Either do TDD or compulsory coverage levels after writing code. This includes integration tests.
3. Get your models to write a demo doc detailing how'd they show their changes. For UI work this would be a visual demo. For backend stuff, perhaps a series of curls, a script for infra.
4. Let them do the demo. They can use their browser tool, Chrome devtool MCP, bring up the service container and run scripts, whatever. Tell them to note any discrepancies from the script and implementation plan and fix them.
5. After all this works they can check that they haven't degraded metrics. I'm still figuring out how best to automate this bit without the model writing debug scripts to get into the browser console.

You can repeat this loop ad infinitum if you have good agent control and an unlimited budget. I find the model-directed verification of its code's output (visual, JSON, whatever) that is not test-driven cleans up a lot of the last 90% of work that we usually have to do.

As noted in many places Claude Code and Codex are now harnesses of exceeding quality. Personally I can't bear to use IDEs and plugins and whatnot, so it's been a great pleasure to have an LLM interact with my code in the same tools I use. Perhaps that's the main developer experience value-add for these model harnesses.

I'm (or more accurately, Claude/Codex) are working on harp, which is the start of the equivalent in Emacs. Perhaps my IDE snootiness is hypocrisy given that I'm working on this, but oh well.

Some things I've noticed about both Claude/Codex while observing their output:

• They're incredibly bad at matching parentheses in Lisp. Like five minutes to find a missing/extraneous parenthesis bad. I find this extremely funny, and it reminds me of the r's in strawberry stuff. I'm watching codex run perl -ne multiple times trying to match them.
• Codex is so good at creating a harness for itself I suspect it's been specifically trained to do it.
• /review in Codex is great for spotting security issues and edge/corner cases with malformed user input.

Org-mode complaint: I do wish there were some elegant org-native way to specify links to open in a new tab. Alas, we only have the #+HTML_HEAD global directive, and so most links on here are inline HTML.

I've somehow managed to create a CI issue in a Pages repo, where publish.el doesn't copy over the CNAME to ./public. So every time I push changes I nuke the CNAME in gh-pages, which uses the ./public folder. Wonderful.

Surprisingly Codex didn't catch this issue. Perhaps I didn't describe the Actions stuff clearly enough? In the future I should go through build details with Codex as well when coming up with an implementation plan.

Also GitHub should really only allow you to set the custom domain from the CNAME itself, and remove that field in your Page settings.

Publishing flow:

1. Add or edit Org files under content/ (use subfolders as you like).
2. Run emacs -Q --batch -l org -l ox-publish -l publish.el -f org-publish-all from the repo root.
3. Inspect the generated HTML in public/ and commit if you want to track it locally.

If you prefer to keep the main branch clean, let the GitHub Actions workflow deploy public/ to the gh-pages branch for you.