Engineering the Machine Rig: Taming AI Code Generation Without the Token Bloat
Published on: 2026-06-09 Author: Jon Brookes

TL;DR
The article outlines a structured framework for "Machine Driven Development" as a disciplined evolutionary step beyond pure AI "vibe coding." The author details a practical coding rig built to maintain control over LLM workflows and eliminate regression risks: Using Opencode for structured, step-wise planning and execution, strict execution control via Git and VSCode for diff tracking and easy rollbacks, and Laravel Boost to enforce standards, testing, and best practices. The author advocates for keeping agent specifications simple (adhering to the KISS principle) to avoid model hallucinations and session truncation. Finally, the piece addresses the shifting economic landscape of AI development—specifically GitHub Copilot's transition to pay-per-use token models—and argues that self-hosted local models (e.g., Llama.cpp) and structured human oversight are essential for indie developers to scale efficiently without skyrocketing subscription costs.
A New Era
How should we code applications now, in the advent of AI and Large Language Models ? Should we follow the path of the ‘Vibe Coders’ ? Are we to become ‘Prompt Engineers’ ? What of AI ‘Spec Driven’ development ? Or could we adopt all of these approaches combined to suit different scenarios and use cases ?
We as programmers, must be aware of and welcome to this field those that may not have coded to a great degree that are now empowered to do so by AI.
I as a programmer must acknowledge that I can create code and applications much faster than by manually coding everything without an AI
If we are to make headway in this new world of AI driven development, we need to focus on new tools, new ideas and ways we perhaps might have summarily rejected in the before times.
Machine Driven Development
Calling this approach ‘Machine Driven’ allows me to stop saying ‘AI’ all of the time. It is a much over used term right now and can drive one to distraction.
So my ‘machine driven coding rig’ has started to take the following form
Opencode
to create and implement ‘plans’ to define a given task or set of procedures
to implement a given plan, sometimes step by step, allowing me to review at each stage what has been created and if I’m happy with it or not
Git
I’m using Git pretty much all of the time to check in each step, stage or to rollback where I see fit, protecting the code from being trashed by a rampant model that decides to remove functionality for no reason, or make unnecessary changes that are outside of scope.
Managing Git at the command line is a must have skill for any accomplished developer but VSCode does a not bad job when it comes to GUI alternatives.

Git when combined with VSCode, does a pretty good job of managing 'diffs', that is changes of before and after edits.
VSCode
I’m using VSCode now to:
visually manage code differences in each step wise implementation
free code, sometimes with models used for code completions and suggestions.

I tend to use VSCode to diff changes in Git, in preference to other notable tools such as Meld in Linux or Winmerge in Windows. These are all worthy candidates for this task as is Github Desktop, still used by many, including Taylor Otwell.
Laravel Boost
Laravel has become my go-to toolkit for developing applications with Livewire, React, Inertia, PWAs and more.
The Laravel Boost component ties my machine rig together by adding the necessary specifications and prompting to nudge the models in the right direction when it comes to things like testing, coding best practice and more. Reading through the AGENTS.md file and .agents/skills that are generated by running php artisan boost:install is interesting reading and informative to us as humans, let alone the AI incumbent.

Boost already supports popular code editors and frameworks and some I’ve seen recently added that I was not aware of. So you could find your niche already catered for.
An Example Code Fix
To prove a point and to expand on what I mean by maintainability, I'd like to explain how I recently fixed an issue I had with an application in Astro, where pagination was working but broken semantically in that the ‘first’ and ‘last’ pagination links pointed to the 0’th and N+1’th element in pagination. This application had already been in part ‘machine driven coded’ to this point using the above step-wise approach in Opencode.
I first created a prompt, for insertion into opencode’s ‘plan’ mode in which I defined the problem, clearly showing the html that was generated and explained the error condition and how I needed it to be rectified.
I was able to review the plan, iterate over points I needed clarified and to answer questions the agent had for me.
With Git at the ready, with no changes to commit and in a branch I could diverge from if necessary I switched from plan to build mode.
In this instance, I was happy to say ‘implement the change’. In other plan scenarios, where there are more steps and perhaps stages, each with steps, I would say ‘implement step / stage X and stop for me to review’.
For each step or iteration I can review the code that is generated, make changes as required or roll back to a safe place where damage can be undone.
Concluding Thoughts on Models and Cost
I have found that I can reduce the cost and competence of a model when implementing in code, once the more risky plan has been written with a more competent one.
I have also found that overly complex plans can lead to hallucinations, sessions being truncated and general mayhem. So the KISS principle is still relevant. Keep specs as simple as you can. Do not take on more that you can chew at a time. Have an overall plan in mind but don't expect the model to have human comprehension.
Where the Broligarchy would take us
Github copilot have recently changed their costing to be ‘pay for use’ rather than the free for all buffet model it and others had for subscription based billing.
This means you pay for the tokens at the rates decided by Github and when you run out, you have to buy more if you’ve blown your monthly quota.
Inevitably, more competent models will blow 30% of a typical allocation in a couple of days that used to run for most of the month for moderate use.
Some scare stories I have read about estimated that a corporate user on a $40 or so plan before last month could easily hit a few thousand dollars each month on the new tariffs.
The tech bros clearly intend for us to pay more for AI.
As we become dependent and they hope, hooked on their models, we will be forced to pay more for them. And let's face it, if you are working for an employer that wants to fire its employees to replace them with an AI and a few prompt engineers, they may well have a point.
But if you are an indie dev, small fiery start up, you value effort, work and people as this is the life blood of your business.
The New Hope
Hope is on the horizon. Some models run better on self hosted infrastructure and new technologies like LlaMAC++ make the goal of running models on our own, private and subscription free kit a more reasonable expectation.
I would like to think that the way we code has already changed and will continue to do so. Non coders will be able to use AI to initially vibe code but then learn about code and how to manage it better. Those more familiar with code will become more proficient at ever greater rates, become more productive and manage reliable outcomes. Senior developers, systems programmers and software professionals will become like the character portrayed by Walt Disney in the film 'Fantasia' in which the master returns to bring calm to the chaos, wielding ultimate power over the automatons and wayward magic antigenic workflows.