Nightly, I have OpenClaw pull the latest changes from a private GitHub repo that is my Obsidian notes vault. It then looks to see which new notes have been added and then runs a "create flashcard" skill to extract and author useful flashcards for spaced-repetition practice. I then gave it access to a custom web-based spaced-repetition flash card application that I built a few months ago. It uses an API to insert new cards, check to see when I last reviewed cards and optionally send me a nudge reminder if I haven't reviewed cards in a few days.

It is a nice workflow that has been working well. I go to class, take notes in Obsidian and check in my changes. By the next day, when I open my flashcard app on my phone, I have new cards to review from yesterday's class.

Congratulations.

When I was in first or second grade (circa 1982) our family got a TRS-80 Model 3 and I started learning BASIC on it. I built a bunch of small little programs and even started an ambitious project: a full text adventure game called "Manhole Mania!". You, as the player, were a public works employee sent into the sewers to investigate strange noises. I never made much progress, maybe only a few rooms.

Just a couple of weeks ago I had the idea of just pointing Codex CLI at my unfinished game idea and "one-shotting" it. I wrote a fairly detailed prompt, constrained it to use Elm and to make it a static website. Gave a rough outline of a simple, but playable Manhole Mania. 5 mins, 43 seconds later:

https://manhole-mania.com/

React is a library - your app still maintains control of application state and drives the main workings of the application. It is just simply using the React library to render that application state.

I still have a very distinct memory when my father told me he was buying us our first home computer. I remember him telling me that you could use the computer to make games. I was so excited by the idea and amazing by this technology (that I hadn't yet even remotely understood). I remember saying "Oh, you just tell it to make a game? And it makes a game?" He explained to me then what programming was.

When we got the TRS-80, he and I worked together to build a game. We came up with an idea for a text adventure game called "Manhole Mania" - you were a city works employee exploring the sewers after reports of strange noises. We never finished much of it - maybe just the first few "rooms".

Maybe this weekend I will tell Codex to make me a game.

So just because we now have "automated programming" agents, every project should eschew the use of a known, tested set of libraries or an entire framework and instead build everything from the ground up? That is insane.

The Codex support at the moment requires adding a comment "@codex review" which then initiates a cloud based review.

You can, however, directly invoke Codex CLI from a GitHub workflow to do things like perform a code review.

First, the assertion that the best model of "AI coding" is that it is a compiler. Compilers deterministically map a formal language to another under a spec. LLM coding tools are search-based program synthesizers that retrieve, generate, and iteratively edit code under constraints (tests/types/linters/CI). That’s why they can fix issues end-to-end on real repos (e.g., SWE-bench Verified), something a compiler doesn’t do. Benchmarks now show top agents/models resolving large fractions of real GitHub issues, which is evidence of synthesis + tool use, not compilation.

Second, that the "programming language is English". Serious workflows aren’t "just English." They use repo context, unit tests, typed APIs, JSON/function-calling schemas, diffs, and editor tools. The "prompt" is often code + tests + spec, with English as glue. The author attacks the weakest interface, not how people actually ship with these tools.

Third, non-determinism isn't disqualifying. Plenty of effective engineering tools are stochastic (fuzzers, search/optimization, SAT/SMT with heuristics). Determinism comes from external specs: unit/integration tests, type systems, property-based tests, CI gates.

False dichotomy: "LLMs are popular only because languages/libraries are bad." Languages are improving (e.g. Rust, Typescript), yet LLMs still help because the real bottlenecks are API lookup, cross-repo reading, boilerplate, migrations, test writing, and refactors, the areas where retrieval and synthesis shine. These are complementary forces, not substitutes.

Finally, no constructive alternatives are offered. "Build better compilers/languages" is fine but modern teams already get value by pairing those with AI: spec-first prompts, test-gated edits, typed SDK scaffolds, auto-generated tests, CI-verified refactors, and repo-aware agents.

A much better way to think about AI coding and LLMs is that they aren’t compilers. They’re probabilistic code synthesizers guided by your constraints (types, tests, CI). Treat them like a junior pair-programmer wired into your repo, search, and toolchain. But not like a magical English compiler.

For certain, the results are better when I use it to build new features into our platform - as opposed to making complicated refactors or other deep changes to existing parts of the system. But even in the latter case, if we have good technical documentation capturing the design and how parts of the system work (which we don't in many places), Claude Code can make good progress.

At first I was seeing a fair amount of what I would consider "bad code" - implementation and code that either didn't follow accepted coding style and patterns or that simply wasn't structured for reusability, maintainability. But after strengthening the CLAUDE.md file and adding an "elixir-code-reviewer" subagent which the "developer" persona had to use - the quality of code improved significantly.

Our platform is open source, you can see our current Claude commands and subagents here: https://github.com/Simon-Initiative/oli-torus/tree/master/.c...