10-100x faster? Maybe for strictly IO bound applications - but if you are building a web app you won't see that performance as network latency dominates.
I don't understand the point of writing and sharing this.
Don't want to use a service anymore? Fine, stop using it and move to something else. But why publish something that you knows for sure is just going to be bad press for another company and organization?
And I'm sorry to nitpick - but "People who rely on AI are the ones who will be left behind" is NOT the opposite of "People who don't use AI will be left behind".
I had used Anki for a few years but recently migrated all my cards out of it and into a custom app I built just a few months ago. It is as an Elixir/Phoenix app with a simple UI but also with a rich API for Agent integration.
I have it installed on an extra macbook pro that I had available. I'm really only using it at the moment for one use case:
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.
Very nice and I just did the exact same thing recently!
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:
Lost me at "React is a Framework" assertion. The key difference between a "framework" and a "library" is the inversion of control that exists in a framework.
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.
Wow this hits home - I just turned 51 and I also started coding at age 7, writing BASIC on a TRS-80 Model III.
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.
This is great that Codex CLI is adding skills - but it would be far more useful if the CLI looked first in the project (the directory where I've launched codex) `.codex/skills` directory and THEN the home directory .codex dir. The same issue exists for prompts.
I've been developing full-time in Elixir / Phoenix for the last 6 years. I can assure you, momentum in the ecosystem has not slowed at all since the language was declared to be "feature complete".
Wow, I didn't realize at first this is Edward Packard - of the "Choose Your Own Adventure" book series fame. CYOA were the first real series of books that I got into and devoured, probably around age 9 or 10. Great to see that he is still writing.
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.