What you're describing is very close to what education theory calls "assimilation" and "accommodation". When we assimilate knowledge, it just fits into our schema of understanding. When we accommodate knowledge, we need to change our schema, and that is where the feeling of being challenged (and often the feeling of profundity) comes from.
For example, a child learns that "foreigner" means someone from outside their country. Then, when they're 11, they go on their first holiday abroad and realise "Wait! _I_ am a foreigner here!"
So, maybe one way to frame what you're saying, is that LLM output tends towards being easily assimilable.
The article presents hypothesis as fact with insufficient science. I have no problem discussing speculation, but if the author wants to promote their claims to any more than that I would want to see more journalism.
This is pretty unfair. If the author didn't establish some context there would be someone else here saying "Check out this dilettante telling me what to think."
I have a degree in mathematics followed by twenty years in software development (pillory me, if you like). My conclusions after 6 months of using LLMs every day are remarkably similar to the author's. I increasingly think in shapes, architectures, data structures and ideas; less and less in lines of code.
And I fully understand his point that, once the architecture of an idea is settled, reading LLM code does not feel worse than reading human generated code. Especially if you have a strong style and conventions guide.
The idea is the hard part, and it's the right place to focus your effort.
Online chess is taken seriously as an e-sport, especially at the top levels, and is played for cash prizes. Imagine if the best cs:go or competitive programmers were found to be cheating. They would be ostracized.
Very close to this at my company. We have docs each of which having its description in the yaml. An MCP tool lists the doc sections, a full section with its descriptions, or the entire contents of a doc. A kind of progressive disclosure. Works really well. We even write "skills" this way so they can be used in all our chat environments.
Fable is really good at front end (Opus 4.8 is decent too) but it really needs a verification loop - it can't always infer the output from the code alone. Give it Playwright to check its work, and it'll generally do a good job. Also if you're using a framework, add to your CLAUDE.md to always rtfm before making changes!
I do quite a lot of what this post describes in a reasonably large project. Here's what works for me:
- write gherkin features for new features; update them for enhancements; don't touch them for refactors. Label your PRs with these nouns.
- use pre-push hooks for type checks, linting, unit tests, and other quick, scriptable validations.
- make a viteperess subsite in your repo, have the agents maintain it - document important principles, architecture, etc.
- make a cli command which lists all pages along with the yaml frontmatter description so agents can choose what to read without blowing up the context window.
- use ddd and monorepo - write your logic in headless layers, and compose layers into apps. agents navigate layers very successfully.
- use zod (or your language equivalent) and contract-first API development; this is my favourite bit tbh, I use orpc
- make a single skill called "code" which describes the lifecycle: open a worktree, setup .env to guarantee no conflict with other agents (choose unused ports etc - docker is good here), write or update feature file (this is where you negotiate the spec), implement, validate (e.g. using playwright mcp), pre-push checks, push and wait for review, tear down and fast forward main
- testcontainers is great for ensuring multiple agents can run tests that don't conflict
Seriously I only have one skill that's it. Everything else is in the docs. I'm feeling very productive like this, in a "making good software" sense not a LoC sense.
For each new feature, I open a worktree, spar with Claude to work up a gherkin spec with @todo on each story. Each agent pushes commits to a WIP PR in GitHub where I review and leave comments or questions. Once the spec is done we mainly interact on the PR. @todo becomes @wip and @done as the agent progresses. I really like gherkin for agentic engineering, it's very clarifying.
I have about 2-4 agents running at a time. Large test suite, linters and formatters enforced on push.
Far from being motivated by some applications, the most useful discoveries in mathematics are usually discovered "for their own sake" and their application is only discovered later. Sometimes centuries later!
If you think of it as being an accumulator function it can feel a bit more natural - the _definition_ of this accumulator is that, F(x) is the area from 0 to x
The fact that the derivative of this accumulator function is equal to the original function, this is the fundamental theorem of calculus, and I violently agree with you that this part is shockingly, unexpectedly beautiful
I'm with you on this (I think). Digitising my org is much easier if I can assume my colleagues' agents will be acting on their behalf. Even if I can't convince most humans to cooperate with solutions, I can usually trust their agents to do so. MCP hides the wiring somewhat, which I enjoy.
I am building _exactly_ this for my org for the past month, using Nuxt Content.
A "draft" is a row in a database with live preview. Users can click a button to make a checkpoint (git commit, by GitHub API, but they don't know that). When they click "publish", the PR for their draft is merged.
Writers in my team can use a nice Tiptap editor with custom components. I get the change management of git.
The API for reading content and editing drafts is also exposed over MCP meaning AI can collaborate in the authoring process from anywhere that can connect to MCP.
I still believe looking up the answer in the back of the book is completely fine. It creates a moment of tension. It invites you to justify in your own head that the answer is right before checking. The cognitive dissonance when you see your answer is wrong and really have to challenge yourself, or ask your neighbour, to see why - is all really valuable.
I just don't think "instant feedback" is as important as we think in mathematics education, and might even rob us of moments to practice mathematical behaviours like justifying, communicating and accommodating. Slow feedback does have benefits.
I am a tech enthusiast to put it mildly. I also taught maths in schools from roughly 2010 to 2020 so saw the iPad/app revolution in my classrooms. Anecdotally, I think it made my lessons and my students worse. Books, paper and each other are the best tools (in my very personal opinion).
Sorry for the late reply. When I was studying my A Level physics me and my teacher read Angels and Demons at the same time. It is a silly story really but just scratched that sci-fi bit of my brain in the right way at the right time. It is pulp fiction but sometimes that's just what you want.
I have a vitepress package in most of my repos. It is a knowledge graph that also just happens to produce heat looking docs for humans when served over http. Agents are very happy to read the raw .md.
For example, a child learns that "foreigner" means someone from outside their country. Then, when they're 11, they go on their first holiday abroad and realise "Wait! _I_ am a foreigner here!"
So, maybe one way to frame what you're saying, is that LLM output tends towards being easily assimilable.