In 2019 I wrote that I think more than I code. The main point was not that coding was beneath me. It was that I could progress on larger concepts without implementing everything — keep moving the architecture, the paths of thought, the systems picture, even when leaf code could not keep up. That was a real compromise. The punchline, years later: we no longer have to make that compromise. With LLMs, thinking can turn into code at a pace that matches the concepts. In 2020 I looked to Neuralink as a possible path; what we got first was models that compile structured thought into candidate implementation.
The old claim: thought ↔ code. The new tool: models that turn structured thought into running code.
What I argued then
In why don’t I code as much as I think? — the year ahead (Dec 2019), the point was not laziness. It was how to keep moving when you cannot implement everything as fast as you can think it. The valuable part is the path of thought — channel it into repeatable patterns, and you can think in code even when the leaf work is unfinished. Implementation can change. The thought pattern is what matters.
“As long as thought patterns can be channeled into standard repeatable patterns, it should be possible to in-effect ‘think in code.’”
So “I think more than I code” meant: stay on the larger concepts; do not let unfinished leaf work freeze progress. That was empowering — and it was also a compromise. You accepted a gap between how far the thinking had gone and how much was actually built.
In Revisiting the idea of thinking in code — Neuralink (Aug 2020) I restated the thesis — “Code is thought and thought is code — it’s bi-directional” — and took Neuralink seriously as a candidate path: if thought could be read as signal, then thought is code in a much more direct sense. I also wrote about gamification and physical visualization as ways to organize thought into structure people can steer.
That was not a metaphor. It was a real bet on how the last mile from mind to machine might close. What actually closed a usable last mile — sooner, and without an implant — was generative coding models. They did not replace Neuralink as an idea; they validated the process I cared about: channel thought into something a machine can realize as code.
One place the idea showed up: levels of code
One application: thought → pattern → DSL → orchestration → running compute. Not the only home for the idea.
Thinking in code is bigger than any one stack. DSLs, Kubernetes, and orchestration were not the whole thesis — they were a context where the idea seemed to apply to problems I was living in: how do you express control across a fabric of compute without drowning in leaf detail?
In that lane, the same idea showed up as levels of code:
- The ability to cycle through resources phase 2 (Oct 2020) — “second-level coders” write orchestration that moves lower-level logic across resources; multi-level chess.
- OpenKruise Sidecar set for data locality (Sep 2020) — containers as beans, Pods as local contexts, Kubernetes as parent context: OO thinking lifted into infrastructure.
- What can be created with CDK8s? (Jan 2021) — “configuration is code”; intent → DSL → object graph → running infrastructure.
- Finally took another look at MPS… (Jul 2023) — a DSL to write code, then ChatGPT to write the code that writes code: another force multiplier in the same spirit.
In that application, a useful chain looked like:
Thought → repeatable pattern → execution DSL → orchestration graph → running compute
Useful — and still only one surface. The core claim was that thought patterns, once channeled, can become verifiable reproductions in code, wherever that code lives.
Where the ideas landed: Uber Language of Compute
Over years of posts — DSLs for execution, resource, and data; multi-level orchestration; operators; locality; CDK8s; MPS — those threads did not stay as separate notes. They coalesced into a larger working model: the Uber Language of Compute (and later notes, v2.0 with AI-powered design).
That model is where details like “realizable in many languages” and “control flowing across a fabric of compute resources” belong — not as the definition of thinking in code, but as how the uber-language was meant to work in practice: patterns that compose across containers, graphs, and control planes. The smaller posts were applications and probes. The uber-language is the larger working model that held them.
And here is the part that still surprises me looking back: the blog series itself ended up becoming the spec. There was no separate requirements doc waiting offline. Writing the ideas in public — iterating titles, diagrams, “how would this work?” pieces — was specifying the larger system. Progress on the concept lived in the posts. Implementation could lag; the series kept the working model alive until tools (and later LLMs) could catch up.
That catch-up is no longer hypothetical. There is working code for the uber-language now: jmjava/uber-lang-of-compute. The blog was the spec; the repo is the implementation catching the concepts.
What actually arrived: LLMs validate the process
Same notebooks of intent — now with a model that can emit the leaf code.
Generative coding models did not replace the need to think. They validated the process — and removed the compromise. You can still progress on larger concepts first. Now you do not have to leave so much unimplemented. With an LLM in the loop, structured thought can become running systems at a velocity closer to the thinking itself — not via a brain interface, but via language, prompts, and review.
With an LLM in the loop:
- You still have to think in patterns — intent, constraints, structure, acceptance criteria (DSL when it fits; plain language when it does).
- The model can materialize large amounts of candidate code from that thought — so the concept does not sit unimplemented by default.
- You remain responsible for judgment — review, tests, architecture, what not to ship.
“I think more than I code” was the honest description of how progress used to work under a hard ceiling on implementation speed. That ceiling moved. The scarce resource is still the thinking; the model aids turning that think into code so the larger concept and the build can advance together. Neuralink remains a separate, literal bet about reading the brain. What we have now is different: natural language and structured artifacts as an encoding of thought, and the model as a compiler from that encoding toward running systems.
I did not see LLMs coming when I wrote the 2019 piece. Looking back, the multi-level orchestration posts — and the uber-language they fed — were already progress at the concept level, with the blog as living spec. LLMs make closing the implementation gap available far beyond any single DSL or platform.
What this is not
- It is not “the AI thinks so I don’t have to.” Unstructured vibes still produce slop.
- It is not claiming Neuralink was never serious — only that LLM-aided coding is what validated the thinking-in-code process first.
- It is not “DSLs were the answer.” They were an application. The process can exist in many contexts.
- It is not the end of craft. Contracts and verification still decide whether thought becomes a system you can trust.
Closing the loop
2019: progress larger concepts even when you cannot implement everything — think in code under that compromise.
2020: restated as bidirectional — and a real look at Neuralink as a possible path.
Along the way: the threads become the Uber Language of Compute — the blog series becomes the spec; uber-lang-of-compute is working code for that model.
Now: LLMs validate the process and lift the compromise — thinking can turn into code with model aid, so concept and implementation need not diverge by default. Not Neuralink. Review still matters.
Neuralink may or may not arrive later. The process was always the point. The series was already the blueprint — and the larger concept is no longer only half-built.
— John · earlier posts linked above on jmenke.blogspot.com
No comments:
Post a Comment