I mean both things that are enabled by AI coding agents but also things we couldn't do because computers weren't fast enough in the past.

HCI (Human-Computer Interaction), as an overall subject matter area. Keyboards and screen and mobile devices... they all grew incrementally from what came before, and people are used to it, but we can do better.

The AI-driven work these days has not actually re-imagined much. We're doing the same stuff, putting the same UIs on the same screens as we were before AI. It is faster, and the content is changing, but not the core interactions with devices. Do we need to output to screens? Do we need keyboards and mice and digital keyboards on phone as input mechanisms?

People are dabbling in VR and AR, and voice control. We're using watches a bit. And those are interesting directions, but some (VR and AR, mostly) of that hardware requirements comes with the baggage of awkward experiences and societal stigma, and often prohibitive costs for non-wealthy consumers.

I don't have the answers, I'd just encourage everybody to really ask yourself - is the goal I'm trying to achieve best solved by defaulting to the same "put it on a screen" UX as before, or can we do something completely new?

Pascal.

Like, all of it. People who decry it think of Wirth's original implementation but never the decades of (admittedly slow, Delphi was hardly blazing trails here...) improvements so they think it sucks. Pascal is great.

With AI, I think it's a future worth exploring. Great low-level and efficient string handling, unlike C.

Stupendously fast compiler and linker, and it generates code that's near C++/C/Rust performance with relative ease. Cram more useful features into it; keep the memory and pointer system as it is; add more useful language concepts from other places. Hell, strap an optional GC into it for things where you don't care.

“Space/time tradeoffs” I guess would be the name of it. Memory latency and bandwidth trails op/s of the CPU - operations beat fetches by ~2 orders of magnitude; memory complicates both SIMD and parallelism across cores which is another ~1 order of magnitude each. The back of the envelope suggests we left a 25,000x speedup factor on the table because our systems and tools and intuitions have converged on load-op-store-load-op-store, instead of load-op-op-op-[…]-op-op-store.

It is well past due time to revisit memory allocation from first principles. I recently finished my PhD on the topic, and realized that we have yet to agree on a consistent definition of fragmentation (see Wilson et al's seminal survey on "Dynamic Storage Allocation"), much less how to deal with it.

When I was in the trenches, I had constant cognitive dissonance against the fact that (i) "it's a solved problem" and (ii) low-to-no-malloc was often presented as a feature of low-level code.

My take is, train a SOTA deep learning system on solved static memory allocation instances (which is NP-complete already) and build a dynamic malloc on top.

To see where the static SOTA was a couple years ago, see this: https://arxiv.org/abs/2504.04874

And also my general audience-friendly presentation of it: https://cappadokes.github.io/jekyll/update/2025/07/16/welcom...

Disclaimer: I've moved on past academia and I may have missed one or two breakthroughs. But the older the problem, the higher the probability of it staying open.

Operating system design, and distributed operating system design (k8s falls well short of a distributed OS; it’s more like a toolkit that does the compute part)

Reconfigurable computing.

Read: have FPGA-like reconfigurable hardware as a core feature. With the reconfiguring being as easy as starting an executable or changing a setting.

NOT: "stick an FPGA onto a CPU, upload 'kernels' to accelerate some task". I mean the platform itself being dead-easy to reconfigure, like change the workings of a particular CPU instruction on-the-fly, or have a # of processing elements encode/decode/process a data stream, reroute traffic from output A to output B by reconfiguring some multiplexer, etc.

Transistors are cheap now. Configuring logic as if it were a simple RAM matrix should be toootally doable.

Evolutionary programming. Very suited to goals and agentic stuff. I'd be surprised if it's not yet in production somewhere.

Procedurally generated content is also a lot more interesting. Without structure, you get slop.

You can set the beginning of a story and an ending, as well as a story contour. Then procedurally generate content that ends at these points, even if they seem to veer away.

Metaprogramming for similar reasons, things like writing scripts/languages for very specific problems.

There's good techniques for all these, but the ROI was too low compared to the returns. It was difficult to write tests for the output space, but now it's a lot simpler.

- https://en.wikipedia.org/wiki/Ternary_computer

- https://en.wikipedia.org/wiki/Sloot_Digital_Coding_System

Plan 9 was cool.

Computer Lib / Dream Machines

Xanadu

Asynchronous digital design!

GUIs, quality, digital garbage: every version of a program is incompatible with the one before and require a new toochain to build and run, bloat

All types of unconventional/exotic computing. I think this has been criminally neglected ever since the ascendancy of the von neumann architecture digital computer.

1) The Zen of Exotic Computing by Peter Kogge - https://epubs.siam.org/doi/10.1137/1.9781611977295

2) Handbook Of Unconventional Computing in 2-vols (Vol1-Theory, Vol2- Implementations) by Andrew Adamatzky et al. - https://www.worldscientific.com/worldscibooks/10.1142/12232#...

Lisp Machines. And if you're a real freak, Forth Machines

Languages not made for people that are optimized for tuned LLMs

Analog computing

what fast and performant really means.

Love

How about giving a shit about efficiency?

Coding without LLM AI.

tech debt