Jan 2026

Over the last few months, since the original blog post on vibe coding, I have been experimenting with workflow and development methodologies.  Modern vibe coding has its limitations, but for a subset of “jobs to be done”, it works incredibly well.  Engineering software tool design is one of those areas in which I think it excels.

Over the years of racing, I have developed several engineering tools that have been a core part of my learning.  The first such tool was a suspension geometry analysis, first shown to my colleagues on a black and white laptop with a VGA screen in the early 90s!  I wrote the software because I was asked to draw up roll centres on a large piece of paper at full scale.  CAD was not that common at the time (1990), and I was taking computer programming classes, so it seemed like the perfect starting point for writing my own software.

The second piece of software I developed was a simulation. I developed it because we didn’t have a data logger, and, being curious, I thought the only way to learn more about how the car worked on the track was to write a simulation.  Again, at the time, there wasn’t much information about this sort of thing, so I had to start from scratch.  My correlation methodology was to ask the driver to recall RPM and gear at different corners and at the end of different straights.

The tracks were created from aerial photos (not from Google, I had to buy them from the aerial surveyors) correlated against track distance stated in the program of the race.  I then traced the tracks into AutoCAD and created a DXF driving line.  The first simulations consisted solely of straights and corners.  Why was this accurate enough for the first development stages?  The answer lies in the simple integration of a parabola.  You can use algebra to solve for the area under the curve, or you can do several approximations based on numerical methods.  Best to look again at High School maths to prove this one to yourself.

The first simulation used distance as the integration variable. Each solution step varied in length depending on the rate of change of forces and velocities, and although the model was primitive, the learning curve it produced was steep. Years later, I wrote up that experience in a blog post, “Simple Vehicle Simulation,” reflecting on how constructing even a rudimentary model forced me to understand weight transfer, tyre forces, transient response, and the simple mathematics hidden beneath the apparent complexity of vehicle dynamics.

That early simulation is relevant here for the same reason SpringForge exists: when you don’t have the tools, you build them. And when you build them, you learn far more than you expected.

Those early tools for engineering were strong evidence of how we might use LLMs and vibe coding.

I have been looking for a good starting point to try a complete workflow and came across the perfect thing: a paper (in paper form!), written for my design assignment for Computer-Aided Design of Machine Elements—an ideal test of running through an entire workflow.

Could I go from a paper, PDF (this one was scanned from a paper copy found in my parents’ garage!), through ChatGPT, write a Product Definition Document, then pass that PRD to Google Antigravity running RooCode, create a specific Prompt to get the LLM to write a complete specification for the coding plan, then autocode the final result?

What made this assignment the perfect candidate wasn’t nostalgia. It was structure. The report contained every formula, every constraint, every decision branch that the original Pascal program handled. It’s engineering distilled into equations—and therefore an ideal substrate for Vibe Coding. A human engineer understands the why behind the formulas. An LLM can process the what with extraordinary breadth. Together, they make a surprisingly potent hybrid.

The workflow went something like this: extract all formulas, assumptions and tables from the scanned PDF; turn that material into a clear, modern PRD; hand the PRD to RooCode’s planning mode in Google Antigravity, which reasons more like a systems architect than an autocomplete engine; generate a detailed implementation plan; and finally switch to autocode mode to build the full browser‑based tool. Throughout this process, the LLM wasn’t replacing engineering judgment—it was amplifying it, allowing me to explore many more branches of the design space than would be sensible by hand.

And the results were startlingly good. SpringForge.tech now reflects the 1990 program’s intent while avoiding its limitations. It manages geometry, solid height, natural frequency, fatigue, buckling, clash allowance, wire selection, and the whole zoo of design constraints. It validates inputs, surfaces warnings, and provides explicit design messages rather than cryptic Pascal errors. It even generates clean drawings in the browser, which would have felt like witchcraft to my 1990 self armed with graph paper.

To make it practical, I also purchased a URL for £10, springforge.tech, where you can review the final code. 

The most interesting discovery wasn’t that an LLM could write the code. It was that the act of building the tool—even in this new hybrid way—provoked the same learning sensation I remember from the suspension tool and the early vehicle simulator. Writing software to embody a theory forces you to test that theory. The moment an equation doesn’t behave the way the text implies, your understanding tightens. The ambiguity collapses. You see the physics more clearly.

This is where Vibe Coding really shines. It isn’t magic, and it absolutely isn’t a replacement for experienced engineering intuition. But as an accelerant? As a way to run the entire arc from paper → reasoning → spec → code → validation in days? It’s transformative. It lets you treat software like modelling clay. You can re‑shape it, re‑run it, and re‑test it at a pace that makes experimentation almost playful.

For mechanical engineers, in particular, this matters. Much of our world remains locked in PDFs, textbooks, or legacy syntax we no longer run. Vibe Coding unlocks that material. It enables us to extract knowledge from static documents and transform it into living, testable models. SpringForge is just one example, but the pattern is broadly applicable: take a well‑defined engineering domain, extract the rules, write a PRD, use an LLM to boost the planning stage, then let autocode handle the grunt work while you keep your hands on the steering wheel.

I’ll be refining SpringForge further—by adding optimisation, exporting to CAD formats, and eventually integrating more advanced analysis—because the barrier to iteration is now low. This was the promise I hinted at in the previous blog: that the combination of human judgment and AI‑accelerated development would enable engineers to create tools rapidly, creatively, and with a new sense of agency.

Re‑engineering the past is a powerful way to build the future. And if a 1990 spring‑design assignment can become a modern web app in 2026, I suspect we’re just scratching the surface of what this approach will enable next.

If this journey sparks ideas about how AI and vibe‑coding workflows could accelerate innovation inside your own organisation, I’m sharing these stories for a reason. Over the past months, I’ve been refining practical ways to bring these methods into real engineering and executive settings — not as hype, but as demonstrations grounded in actual tools like SpringForge. If you’d like a talk, workshop, or executive‑level session on how AI can be applied pragmatically inside your teams, please reach out.

Workflow:

• PDF specification/paper scan
• ChatGPT -> Product Requirements Document (PRD)
• Google Antigravity – RooCode -> Planning Prompt Mode
• Gemini 3 & Claude Sonnet 4.5 running through OpenRouter

References:
1- Zhao, Chengshuai, et al. Is Chain-of-Thought Reasoning of LLMs a Mirage? A Data Distribution Lens. arXiv:2508.01191v3, 2025, arxiv.org/abs/2508.01191.