0xecro1

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.

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.

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.

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.

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.

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.

Hi,AI tools just shifted the interface of programming from code to natural language. The tool you've been sharpening your whole career — words — is now the primary tool of software development. You're not a non-programmer learning to code. You're a native speaker arriving in a country that just switched to your language. And that's exactly why it's been "one of the most fun things you've ever done." We're always drawn to the things where our strengths quietly do the heavy lifting. Trust that signal. Keep going.

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!