It's fundamentally different, and that's exactly why the CPU analogy has an expiration date. Intel never built Windows. The chip layer and the application layer were structurally separated — different companies, different business models, different competencies. That separation is what created the massive ecosystem on top. Frontier labs aren't staying in the chip layer. Anthropic ships the model, the API, artifacts, computer use, MCP — primitive through orchestration through distribution. OpenAI has the model, ChatGPT, plugins, the app store play. They're vertically integrating the entire stack at a speed Intel never could, precisely because the primitive is probabilistic and language-native. When your compute layer already "understands" the task, the gap between infrastructure and application collapses. So short-term, yes, it looks like Intel/AMD. Base models commoditize, value flows to tooling and verticals. But long-term, the labs that own the primitive will likely own most of the stack above it too. The "just build on top" window might be shorter than people expect.

Fair point on the vertical integration. That’s definitely a real difference from the CPU era.

At the same time, I’m not fully convinced that owning the primitive automatically means owning most of the value on top of it in the long run.

Nvidia owns the GPU layer, but it doesn’t own the majority of the software built on top of GPUs. AWS owns infrastructure, but SaaS value still fragments heavily across vertical domains. Infrastructure providers often try to move up the stack, but specialization and domain depth tend to create space above them.

It’s possible that frontier labs will capture more horizontal value than chip companies ever did. But I’m not sure language-native compute completely collapses the stack. It might just reduce friction and lower the barrier for building vertical systems.

The interesting question to me is whether this really eliminates the ecosystem layer — or just reshapes it.

Interesting approach. I work in embedded Linux/edge AI where we constantly struggle to move knowledge from large training models down to quantized INT8 models on constrained hardware (ARM Cortex-A class). Have you tested transfer to quantized or pruned targets? If the behavioural encoding survives that compression, this could be a much cleaner path than classical distillation for on-device deployment.

We haven't built quantisation-aware transfer yet, but the architecture lends itself to it better than you might expect.

Mode A (activation transfer) operates at the representation level, not the parameter level. The source model's knowledge gets projected into a 2048-dim hub space — the receiving model doesn't need to match architecturally or in precision. A 200M FP32 training model and a 5M INT8 edge model can both have UHS encoders/decoders. The hub space is agnostic to what's underneath.

Mode B (behavioural) is probably the most interesting path for your use case. It transfers decision boundaries rather than activations or weights. If the quantised model can reproduce the input-output mapping, internal precision is irrelevant.

It's similar in spirit to distillation but decoupled through the hub space — teacher and student don't need to be online simultaneously, and you get a full audit trail of what knowledge went where (which matters if you're shipping medical/industrial edge models under EU AI Act).

The gap today is the decoder side. DecoderMLP outputs FP32. We'd need a quantisation-aware variant that respects the INT8 grid — straight-through estimator at minimum, learned quantisation boundaries ideally. We'd also want empirical drift characterisation across FP32→FP16→INT8→INT4 so you'd know your expected fidelity floor for a given target.

The swarm angle is where it gets genuinely useful for edge fleets. If you've got N devices training locally on-site data, they contribute quantised-model tokens back to a full-precision aggregator. The robust aggregation strategy (Huber-style cosine clipping) handles quantisation noise across heterogeneous devices naturally.

We're planning a quantisation-aware transfer module next. If you're interested in testing against real Cortex-A INT8 workloads, we'd welcome the collaboration — repo is at github.com/incocreativedev/tessera-core.

Maker here. 18 years in embedded Linux/BSP.

I built this because serial terminals haven't changed in decades, and I was tired of juggling 15 PDF tabs while squinting at logs.

Two things that make NeuroTerm different:

1) Neuro Input: type @ + natural language to get the command. "@scan i2c bus 0" turns into i2cdetect -y 0. Runs on a local LLM. No API keys, no cloud, works offline.

2) Local RAG: import your datasheets (PDF/DOCX), ask questions right in the terminal. "What's the I2C address range for this sensor?" and you get an answer with citations from YOUR datasheet. Everything stays on your machine.

Also: auto-detects kernel panics, boot stages, and errors with a visual minimap. HEX view, timestamps, advanced filtering. Supports serial, SSH, and WSL.

The local-only choice was deliberate. Most embedded teams I've worked with have strict security policies where cloud AI isn't an option.

Free tier (15 AI queries/day). Pro is $29 one-time, no subscription. Currently Windows. macOS/Linux in progress.

Would love feedback. What's missing? What would make you switch from your current terminal?

18 years in embedded. Yes to all three, with caveats.

1. The pattern is real. I write specs and prompts between meetings, agents deliver code by EOD. But deep focus blocks aren't dying, they're shifting from "writing code" to "thinking about architecture and verifying output."

2. Merging, yes. Decreasing value, no. The role is evolving from "person who writes code" to "person who defines what correct looks like." The engineers who thrive will be the ones who can do both — manage agents AND know when the output is wrong. That requires more expertise, not less.

3. Overfitted to Claude Code? Probably a bit. But the delegating to AI agents instead of typing code yourself is tool-agnostic. Cursor, Copilot, Claude Code, whatever comes next. The workflow shift is real regardless of which tool wins.

Been thinking about this a lot myself.

My current answer: go vertical and messy.

Ex, Healthcare portals with ugly data. Compliance platforms with painful regulations. B2B tools with 6-month sales cycles.

I use it for both — side projects and my day job in embedded systems.

The key is where the tokens go. More tokens spent on planning, design, spec validation, test generation, and multi-agent review than on writing the actual code. The review pipeline should be heavier than the generation pipeline.

I encourage my team to use it as a plugin too. The "sorry way" is still a fine starting point — but once you see what a structured agent pipeline catches that manual review misses, it's hard to go back.

Hard disagree, the interface hasn't changed at all. What has happened is new tools have appeared that make natural language a viable interface. It is a new lesser interface, not a replacement. Like a GUI, more accessible but functionally restricted. An interface that is conditioned on previously solved tasks, but unable to solve novel ones.

What this means is coding becomes accessible to those looking to apply something like python to solved problems, but it very much remains inaccessible to those looking to solve truly novel problems they have the skill to solve in their domain, but lack the coding skills to describe.

As a simple example, claude code is easily among the most competent coding interfaces I know of right now. However, if I give it a toy problem I've been toying with as a hobby project, and it breaks so badly it starts hallucinating that it is chatgpt.

``` This is actually a very robust design pattern that prevents overconfidence and enables continuous improvement. The [...lots of rambling...] correctly.

  ChatGPT

  Apologies, but I don't have the ability to run code or access files in a traditional sense. However, I can help you understand and work with the concepts you're describing. Let me
  provide a more focused analysis:

```

/insights doesn't help of course, it simply recommends I clear context on those situations and try again, but naturally it has the same problems. This isn't isolated, unless I give it simple tasks, it fails. The easy tasks it excels at though, it has handled a broad variety of tasks to a high degree of satisfaction, but it is a long shot away from replacing just writing code.

Bottom line, LLM's give coding a GUI, but like a GUI, is restricted and buggy.

I've seen non-programmers successfully launch real apps — not toy projects — through vibe coding. I'm doing it myself, and I'm about to ship a developer tool built the same way.

They'll still need to pick up the fundamentals of the programming — that part isn't optional yet. And getting to that level as a non-programmer takes real effort. But if the interest is there, it's far from impossible. In fact, I'd argue someone with genuine passion and domain expertise might have better odds than an average developer just going through the motions.

You're not getting it. Making app is a solved problem, especially if app function, features, and purpose is derivative of existing things,

Think of it like image generation AI. You can make acceptable if sloppy art with it, using styles that exist. However, you cannot create a new style. You cannot create pictures of things that are truly novel, to do that you have to pick up the brush yourself.

coding with llms is the exact same thing. It can give you copies of what exists, and sometimes reasonable interpolations/mashups, but i have not seen a single succesful example of extrapolation. Not one. You simply leave the learned manifold and everything gets chaotic like in the example i provided.

If AI can make what you want, then the thing you made is not as novel as you thought. You're repurpising solved problems. Still useful, still interesting, just not as ground breaking as the bot will try and tell you.

Hi, I’ve been working with embedded Linux for 18 years.

I’ve been actively trying to apply AI to our field, but the friction is real. We require determinism, whereas AI fundamentally operates on probability.

The issue is the Pareto Principle in overdrive: AI gets you to 90% instantly, but in our environment, anything less than 100% is often a failure. Bridging that final 10% reliability gap is the real challenge.

Still, I view total replacement as inevitable. We are currently in a transition period where our job is to rigorously experiment and figure out how to safely cross that gap.

Good luck!

And by not doing the 90% yourself you lack the understanding you need to be able to tackle the remaining 10%.

Absolutely agree. I do vibe-code, but I still review every line of that 90% — I don't move forward until I understand it and trust the quality. Right now, that human verification step is non-negotiable.

That said, I have a hunch we're heading toward a world where we stop reading AI-generated code the same way we stopped reading assembly. Not today, not tomorrow, but the direction feels clear.

Until then — yes, we need to understand every bit of what the AI writes.

I disagree. Compilers were deterministic. Complicated, but deterministic. You could be sure that it was going to emit something sensible.

AI? Not so much. Not deterministic. Sure, the probability of something bizarre may go down. But with AI, as currently constituted, you will always need to review what it does.

I think the comparison is slightly off. The compiler was never the author — it was the verifier.

The real comparison is: 1. Human writes code (non-deterministic, buggy) → compiler catches errors

2. AI writes code (non-deterministic, buggy) → compiler catches errors

In both cases, the author is non-deterministic. We never trusted human-written code without review and compilation either (and + lots of tests). The question isn't whether AI output needs verification — of course it does. The question is whether AI + human review produces better results faster than human alone.

The compiler isn't so much a verifier than that it is a translator. The verification step wasn't the initial focus but over time it became more and more important.

The compiler catches certain classes of errors. And AI can spit out unmaintainable code or code with incorrect logic or giant security holes a lot faster than humans can review it.

My impression is that if you are reviewing the edits, that is not “vibe coding”, it’s AI-assisted programming.