[buzzbyjool]

I get the discomfort — I felt the same early on. But I think there’s a misunderstanding of what’s actually happening under the hood with modern code-focused LLMs.

We’re no longer in the realm of vague completions. Models like DeepSeek or Claude 3.7 aren’t just stochastic parrots — they operate like abstract interpreters, capable of holding internal representations of logic, system design, even refactoring strategies. And when you constrain them properly — through role separation, test feedback, context anchoring — they become extremely reliable. Not perfect, but engineerable.

What you describe as “managing” or “influencing” is, in our case, more like building structured interpreter stacks. We define agent roles, set execution patterns, log every decision, inject type-checked context. It’s messy, yes, but no more magical than compiling C into assembly. Just at a radically higher level of abstraction.

There’s a quote that captures this well. In March 2024, Jensen Huang (NVIDIA CEO) said:

“English is now the world’s most popular programming language.”

That’s not hyperbole. It reflects a shift in interface — not in intent. LLMs let us program systems using natural abstractions, while still exposing deterministic structure when designed that way.

To me, LLMs are not the death of engineering. They’re the beginning of a new kind. I truly believe the next 10 years will make most traditional programming languages obsolete. We’ll go from prompt → code to prompt → compiled binary, bypassing syntax entirely.

[exceptione]

Thanks for following up, maybe I can learn something. I wonder what you mean by a "shared context layer"? Do you run everything local on big rigs and did you train your own models?

The idea I have got now is that you let general off-the-shelf AI models role-play, and one hands it over to the other? But how would you be able to let those use a shared context layer, that is also typed? How is feedback organized in that process?

[buzzbyjool]

Great questions — and yes, you’ve got the right intuition: we orchestrate role-specific agents using off-the-shelf LLMs (Claude 3.7, DeepSeek GPT 4.1, GPT-4 Turbo), and they “hand off” tasks between each other. But to avoid total chaos (or hallucinated collaboration), we had to build a few things around them.

The “shared context layer” is essentially a lightweight memory and coordination layer that persists project state, intermediate decisions, and validated outputs. It’s not a traditional vector store or RAG setup. Instead, we use: • A Redis-backed scratchpad with typed slots for inputs, constraints, decisions, outputs, and feedback • An MCP (Model Context Protocol) template that defines what agents should expect, expose, and inherit • Each agent works statelessly, but gets a structured payload that includes relevant validated history, filtered to reduce noise

Agents don’t have full access to each other’s output logs (too much context = hallucination risk). Instead, each one produces an “artifact” + optional feedback object. These go into the shared layer, and the orchestrator decides what the next agent should receive and in what form.

We don’t run anything locally (yet). It’s all API-based for now, with orchestration handled in a containerized layer. That will probably evolve if we scale into more sensitive verticals.

Hope that helps clarify. Happy to dig deeper if you want building something similar.

[exceptione]

That clears things up, interesting for sure. Would love to see how this works in practice. If you ever give demo's or write blogs count me in. :)