(Image by Gemini AI)
This is my third post in the Reverse Vibe-Coding series. If you prefer watching an 8 minute video over reading a 20 minute blog post, check here.

This post isn't directly about Reverse Vibe-Coding or RVC sub workflows like the one for refactoring, instread it is about the direction where I believe AI usage is heading, for starters in its use in Software Engineering, because Software Engineering has been the leading both AI trends and in AI trends going completely off the rails. I think RVC is part of that direction, and I'll touch on it multiple times in an illustrative way, but please note that this is NOT a blog post aimed at prompting RVC use. It is a context post, outlining the bigger picture of how RVC, or more likely, workflows like RVC will fit into the future of AI usage in software engineering, and the direction AI in general is likely to go.

I am writing this post at a pivotal moment in AI history, a point where my vision here can either act as a big warning for those considering investing in AI at a moment that xAI (through SpaceX) is about to go IPO and OpenAI and Antopic are expected to both follow with their own IPO within the next months, or what follows these IPOs may invalidate my predictions before this decade is over.

Crypto and ASICs

I'm posting this blog post on the HIVE platform. A Web 3.0 blockchain based social blogging platform (and more).

Everyone with more than passing knowledge about blockchains knows that many blockchains are called Proof of Work (PoW). In the early days of blockchains, blockchains like BitCoin would allow you to use your computer's main processor to 'mine' new coins. Your CPU would do a lot of work in a sort of beauty pageant for CPU intensive secure hashes.

Then, however, graphical cards entered the blockchain arena, and soon noone entering the secure hash beauty pageant had any real chance anymore to win the pageant because the GPUs were simply so much faster than CPUs, and the electricity needed by the CPU to even try to compete was no longer in any relationship to the miniscule chance of winning.

The dominion of GPUs lasted quite some time, to the dismay of many gamers who saw GPU production being gobbled up by miners, but at some point ASICs entered the arena, and the same thing that GPUs did for CPU mining, now happened to GPU mining. With ASICs entering the secure hash beauty pageant, GPUs no longer had much of a chance to compete, nor was their energy consumption justified anymore.

Right now AI is going through a similar transition, a transition a little more complicated than the one we saw with PoW blockchains, but a transition that should have everyone rethink where AI, AI usage, and quite possibly the AI industry is going.

Submarines can't swim

There is continuing debate about if AI is in a bubble. And what is meant by that differs between who is talking. There is talk of an AI race, but again what the race is actually a race for differs between who is talking. One of the bubble narratives centers about the idea that the AI race is about Artificial General Intelligence (AGI). While AGI in its original meaning was about the ability of AI to take knowledge from its training in one field, and apply it in a completely different field, in recent years AGI as a term in practical use has been shifted to map to anthropomorphic capabilities. AI labs started using benchmarks around things a human can do, while the general public started conflating AGI to actual thinking or even to consciousness. In other words, while according to the original meaning there is no confusion if language models are close to or even might have reached AGI, the anthropomorphic definitions of AGI are creating a situation where AI labs are claiming their race to AGI is about to end or even that AGI might have already have wooshed by.

Let's roll back about 40 .. 50 years to Edsger Dijkstra. In 1977 Dijkstra spoke up against the anthropomorphization of language in computer science, blaming von Neumann for being the source of this unfortunate trend. In 1984 in EWD936, Dijkstra showed the question "Can Computers Think" is as meaningless as "Can submarines swim?". It is not that the answer is no, it is that the question itself is meaningless. Antropomorphism has been meaningless questions for longer than I have been alive, and with current AI advancements it creates a disconnect with reality bigger than Dijkstra could ever have imagined.

Closed vs open weight models, and low drift vs high creativity

It is too late to fully disconnect from anthropomorphic terminology, so by lack of a non anthropomorphic word, let's look ar reasoning. Reasoning again is a severely anthropomorphic for a fundamentally technical construct. In chasing the reimagined anthropomorphic meaning of Artificial General Intelligence, better (by anthropomorphic measures) reasoning, frontier labs have been turning a dial that hasn't been free to turn. My throwing more inference power at the input, or rather by looping back a growing part of the output to the input of the model, the model will give more human like or with another anthropomorphic name more creative output.

So what is the price of turning that dial? The price is one form of a broader concept called drift. LLMs suffer from drift from multiple causes, but the result of these is the same. The same prompt over the same or similar data leading to wildly different outcomes. Create a perfect prompt for refactoring a class that has overgrown being just one class into two classes today, use it again in three weeks on an almost identical class, and the refactor action completely fails.

When using AI to write an article this drift might be acceptable. In some cases it may even be desirable. But in our refactoring example, drift is a liability. So much of a liability that the price we pay for reasoning is just too high for refactoring purposes. This is one of the things RVC aims to address, and using smaller self hosted models and occasionally turning of reasoning have shown to be effective tools towards more stable results.

So what sources of drift exist? Well after reasoning, a second source is very simply upgrading the model. Cloud based closed models are known for getting in-version upgrades. Even if you lock into an older version of Opus to keep your drift low, Antropic doesn't give you stability as a service in a model you may expect to be completely static. The core model might be static, the post-processing engine is not.

As a result, when repeatability is important, open weight models that you can run locally will give you repeatable low drift results where huge closed models don't. It may be anti-intuitive, but for predictability a 70 billion or even a 30 billion parameter model that you can standardize on with no to low reasoning gives better results than a trillions parameters closed model with expensive extensive and yes almost human like (in the way that mirror reflections are human like) reasoning models.

High inference power vs large unified memory

So having established that for many tasks where repeatability and low drift really matter more than extensive 'reasoning' self hosting open models is the best option, when looking at the options right now, even if cloud-model subscriptions are already not cheap (starting at around €200 a month for subscriptions that give enough power for modest daily professional usage), the hardware for self hosting, despite more affordable options becoming available, still isn't cheap.

Working with RVC, I've come to the conclusion that different models have their strength, and to do the most tedious tasks that benefit the most from low drift self-hosting, you need to combine at least two, and very likely three or four local models. While the smallest models like starcoder2:15b have their use, qwen3-coder:30b I think is currently (June 2026) the primary daily driver to expand on with more specialized models like codestral:22b. For some tasks like high-context code-reviews, the programming language really matters for what additional model to pick. For some tasks a 70b+ model might be interesting, but my personal findings have been that given available space, combining three distinct models each with their strengths for different classes of problems yields better use of resources than assigning all space to a bigger more generic model like llama3.1:70b.

But enough of specific models. What does it take to run models of at least 30 billion but possibly more than 70 billion parameters? Well, there are currently two main options depending on your team size and latency needs. While RVC has no strong
low latency needs given that the agents in RVC are not used interactively and aren't babysitted, but other workflows might have tighter low latency requirements.

Well, the classical solution for running locally hosted models is using graphical cards in a well powered PC or in a server. A 32 GB RTX 5000 will set you back maybe €4000 for the card alone. Want some more comfortable space and get a 48 GB card that should give space enough for the bigger models, an RTX 6000 ADA is bound to set you back €8000. Put it into a powerful desktop model PC and you are well over €10,000, and you'll have a system that probably eats up 500 Watts at least for a single node. But you will have serious inference power, suitable for a small team, or a solo dev with very high low latency requirements.

On the other side of the spectrum we have systems like the Mac Mini with unified memory, and like the NVIDIA Jetson Thor. It is a machine that goes for less than €5000, and you don't get the raw inference speed of a RTX 6000 ADA, but instead of raw power you get respectable power for just over 100 Watt with a whoping 128 GB of unified memory. Currently the Thor is a very good option for running RVC setups on. For completeness we should probably also mention the NVIDIA DGX Spark, a system with similar specs to the Thor that I unfortunately haven't had the opportunity to test, but what makes it interesting is that it is very well suited for the more mobile developers that want to take their AI infrastructure with them wherever they go.

ASICs for frozen models

So that is where we are now, fat GPUs or lean compact unified memory, so how about ASICs?

Well, right now a Canadian company is leading the pack on that. Taalas has demonstrated the possibility of running smaller frozen models on its HC1 chip.The 8 billion parameter version of Llama 3.1 to be precise.

While not for mass production yet, the company is working on the successor HC2 and if things turn out well, they might very well start shipping ASICs powered frozen models on PCIe cards by next winter or spring, but that is currently speculation. But even if Taalas doesn't end up shipping these, some company for sure is. Especially once the industry starts waking up that the shortcoming of ASIC based AI hardware with hard frozen models on them is actually a huge strength in a world that simply runs more reliable on low drift, this development is simply unstoppable, and in the light of current IPOs in the AI space, it is a fact that I fear is underappreciated by the markets. We will look into this deeper.

A return to provenance and strict human code ownership.

While on platforms like X, disconnected employees of frontier AI companies will gladly promote techniques that increase drift more, reduce the notion of provenance and human accountability even more, and that of course will drive up your token consumption needs, in the real world people need reliability, accountability, and when changing work flows, they need ways to measure if what they are doing is having a positive or negative effect.

Studies have shown that people will quickly feel that they are more productive, while in effect they are less productive. We need to measure, well, .... , basically everything we can measure. No stupid metrics like lines of code or numbers of pull requests. We need full provenance. In Reverse-Vibe-Coding we make git the one and only hand-over between humans and AI, and we ban the history erasing practice of git rebasing. This gives us two things. It gives us strong provenance that allows us to measure the effects of things like adding an extra open model for specific tasks, and if we have functional metrics for our velocity, and we also measure negative production artefacts, we can decide if our choices were the right ones. And when things go wrong, with strong code ownership, the provenance allows people to learn from their failure.

After all, that good is a PR count if 60% of PRs were for bugs that should never have had to be introduced. And what good is a high LOC count if hand written code would have yielded the same functionality in a quarter of the lines?

From English as Prompting Assembly towards a prompting FORTRAN

Now we get to the core of things, the core of why drift is such a big deal if we want to move forward with AI from where we are today, and the core of why frozen model ASICs for AI. and other model-in-a-box solutions will turn out to be such a big deal.

As we see in the Tweet above by Uncle Bob Martin, we know things are off track when the father of Clean Code is telling us to disengage from syntax. The problem is, by using plain ambiguous English for prompting, we have been doing just that. We've decoupled intent from syntax, and the result is that we end up learning and writing English prose that sorta does what we want. But when we switch models, we learn the other model doesn't quite respond to us the first model does, so we are back to learning how to prompt in English as if English is a different language all of a sudden.

And actually, that is the right mindset to think about English prompts. Think of English as an assembly language. Not any specific assembly language, all assembly languages. If you have different CPU families you have a different assembly language, and code for an ARM processor won't run successfully on an RISC processor similar to how an advanced highly precise prompt for Qwen3-coder won't run on Codestral. We need to start realizing that English is just an assembly language, not a final destination in prompting. And here is where drift comes back in, drift changes the CPU, and changes the way the prompting assembly code will run.

RVC advocates for a first step towards fully reengaging with syntax. A first step towards creating what will basically be the FORTRAN of prompting. A structured prompting language that lets us engage with syntax on a prompting level in order to express intent.

RVC doesn't give us that prompting FORTRAN. Instead it gives us direction. A direction that through bespoke DSLs based on a growing english sub-prompt template library for a specific preferably frozen model, should give us the experience we need to eventually converge on a generic prompting fortran.

[1] 
LANGUAGE CPP
CONFORM TO GUIDELINES:
  ALEXANDRESCU
  CORE
FORMAT WITH:
  RATTLIFF
HOUSESTYLE innuendo
REFACTOR Foo FROM src/foo.cpp INTERFACE inc/foo.hpp:
  OWNER Bar FROM src/bar.cpp INTERFACE inc/bar.hpp
  OWNER FooTester FROM test/foo_test.cpp
  TEMPLATE class_proxy_split VARIANTS ALL:
    VAR takeout [_pBax, _pQuaz]
    VAR newclass FooPart
    VAR membership unique_ptr
    MODIFY:
      TEMPLATE constructorspec VARIANTS [move_nocopy, copy_nomove]

An RVP prompt like the one above will expand to a relatively huge context+prompt, one for which the slightest bit of base drift will result in dramatically expanded end results drift. The above example will, if the number of available variants of class_proxy_split are three, spawn two (move_nocopy, copy_nomove) sub variants for each of the three variants, leading to 6 parallel agents doing basically the same with intended variation rather than drift. In RVC we allow all these six agents to fail up to eight times, looping baseline tooling output back to the agent on failure, and then the surviving variants get triaged.

Because the whole above prompting DSL syntax maps to nested model specific or at least model tuned nested prompt sub-templates, the whole can be seen as a programming language that gets compiled to a specific compiler, in our case local model, and in some cases, to a set of models because we may run variants on different models before triage.

Again, model upgrades are an important source of drift, that we can not afford without extensive testing and porting and tuning. Consider a model upgrade like you would expanding a compiler with support for a new CPU.Knowing this, it becomes clear just how much of a strength the non-upgradability of ASICs AI hardware actually is.

About Perl and lawyers

Drift isn’t the only reason to reengage with syntax. We have actually been here before. Perl is a programming language written by a linguist. When it was introduced it brought us the same promises that prompting in English is currently giving us. The ability to write a program in something close to how the human mind thinks linguistically. Close to natural language.

But what happened? Like vibe coding, Perl was very popular for a while until reality hit. Having expression freedom may feel like a good thing, in the end it makes bigger bodies of intent much harder to reason about. For Perl this was just for humans, but I think the data clearly shows that the same is true for AI. Large bodies of Perl code ended up getting discarded, or rewritten in Python or other languages as a result of this mess.

And if we go a bit further and look at actual English, it should be clear from the field of law that human language is highly ambiguous. It often takes years and many law experts trained in low ambiguity language to write a law. Then when the law is set in stone, lawyers will still find ways to interpret the law in ways that the legislative lawyers hadn’t considered, and judges will need to add additional language expressions to disambiguate the original language.

With prompting we are trying to express intent in a non ambiguous way in a language that was never meant to be non ambiguous, and most of us aren’t €4000/hr lawyers trained at spotting the ambiguity of natural language. Natural language for intent expression is one of the pitfalls of anthropomorphic thinking. Syntax in code is there for exactly that reason. So even if drift wasn’t a problem, we need to reengage with syntax, We need to code our prompts.

The new AI race: Taalas vs Alibaba ?

So is Taalas going to win the AI race as an unexpected winner? No, probably not, but they are first movers in a game with new rules, rules that can practically sideline the current big players to a great extent. A game where other players are likely to enter soon. But not necessarily a game ruled exclusively by ASICs. ASICs are relatively affordable and lightning fast, but don't dismiss unified memory appliances. Apple and NVIDIA are

What this could mean for frontier labs and their IPOs

In this blog post we have been focusing on the use of AI in software engineering, currently the most AI developed field, and we have seen the potential of the model in a box idea, with its most disruptive form undoubtedly being ASICs based, but with cheap unified memory options being a possible augmentation of that market into different user profiles. While even for code cloud models still have their value for things like code prototyping and ideation, the rise of more engineering, quality and provenance geared workflows like RVC aligns perfectly with a move to open self hosted models that is about to take a sprint into the frozen model hardware space to such an extent that the need for the subscription branch of AI, the space where frontier labs like Antropic, xAI and OpenAI live. But there are many more, less matured fields for AI that would benefit from the ability to automate in extensive low drift ways, and where would that leave the future for labs that have subscription based meter based business models. xAI, through SpaceX is about to have its IPO at a valuation approaching two trillion. SpaceX is more than only AI, but AI is a huge part of the perceived value. Later this year Antropic and OpenAI will follow with their own IPOs, also at massive valuations. Valuations that we must ask ourselves if they are realistic in the light of emerging low drift needs upcoming advances in self hosting possibilities.

We can expect a frozen model in a box disruption in 2027, the subscription and meter cloud business models are about to see a huge collapse in the size of their role in the logistics of software engineering. A collapse likely to extend into other application domains.

The future of AI for software engineering: git + model in a box

With all of the press going to frontier labs AGI narratives, workflows and harnesses that turn software engineers into stressed out managers of agents, and big names like Uncle Bob Martin telling us to disengage from syntax, even bigger names like Richard Dawkins and Geoff Hinton believing AI might be conscient, it is easy to lose track of the concerns of real world AI users, both in software engineering and outside of it who need reliability more than human like behaviour. We forgot the wise words of Edsger Dijkstra on anthropomorphism and went all in on treating computers as being or need-to-be beings. A submarine can’t swim, and engineering as opposed to management style workflows show us the way forward, at least for AI for software workflows, but likely for many other application domains as well. A way forward with less anthropomorphic nonsense, and also as things look now with a much smaller role for frontier labs and closed models that aim to be more human-like. Just like in robotics, there is way more use for specialized R2 units than for C3PO protocol droids, and in SE we have been deploying protocol droids to X-wing starfighter repair, and it’s a mess. Right now Apple and NVIDIA are giving us a taste of what the mass produced R2 units equivalent would look like in the AI space, and it’s pretty decent. The Thor is already a decent astromech droid for AI workflows for software engineering, and Taalas is making waves with what could very well be the equivalent of bitcoin mining moving from GPUs to ASICs, lightning speed inference for medium sized frozen models. A technology where other players are bound to enter the field soon, including possibly players like Alibaba that are already in the AI model space “and” in the low margins low budget tech space. A player like Alibaba could take its models Qwen3 and Qwen3-coder and either ship a Taalas style ASICs QwenBox model in a box at sub €2000 prices, and hedge and go the unified memory way at lower inference, and release a sub €600 QwenBox-lite for hobbyists and consumers. They could even go all the way and package either box with a built-in Gitea server and an out of the box RVC-like git based workflow complete with it’s own prompting template collection and QwenDSL as a full QwenBox-coder coding AI solution in a box. This last bit is very much speculation and Alibaba is just one company of multiple that could introduce disruptive technology like this to the market in 2027. It is highly likely that some company will disrupt the cozy position that Frontier labs have right now because of just how misaligned anthropomorphic AI is with the actual market needs. The current status quo isn’t sustainable as engineering driven AI workflows reengage with syntax and as new ASIC technology is set to align perfectly with these new AI workflows.
As the first of three IPOs is about to occur in three days from me writing this blog post, and don’t take this as financial advice, I think it is probably prudent for anyone considering stepping into any of these IPOs to examine if Dijkstra was right about anthropomorphic language in computer science, if workflows like vibe coding and anthropomorphic manager-style agentic harnesses and workflows have any chance to survive as part of the community moves towards reengaging syntax with a prompting FORTRAN and reengaging actual engineering practices in bespoke git centric high provenance workflows that will expose both ineffective and effective practices for what they are. So again, no financial advice, but if after reading this post you are still considering buying into these IPOs, I wish you the best of luck.