We Let AI Build Our Engineering Tool. Here's Why We Still Have Jobs in Mid-2026
Lessons from building a motorsport optimization tool almost entirely with AI.
Over the past several months, my friend Josh and I developed an optimization tool for designing heat exchangers.
The optimization problem itself wasn't unusual.
The way we built it was. Roughly 99% of the implementation was generated using Cursor and AI. We wrote remarkably little Python by hand.
We started the project by asking a simple question: How much could we leverage AI to build this tool?
We found out that, for engineering software, the bottleneck is no longer writing code. The bottleneck has shifted to knowing what should be built.
The Prerequisite: You Still Need to Know the Fundamentals
One misconception I want to address immediately is that Josh and I already knew how to build engineering software. We had experience with:
• Python development
• Git and collaborative development
• CI/CD workflows
• High-Performance Computing (HPC)
• Remote Linux environments
• Conda environments
• Engineering optimization
• Numerical methods
Could we have built this project without AI? Absolutely. It simply would have taken much longer.
The reason I mention this is that if you don't already know what you're trying to build, I expect the journey will be much bumpier. At the end of the day, AI in 2026 is still guided by your prompts.
Our responsibilities naturally divided according to our expertise:
Josh:
• Fluid mechanics
• Objective function and constraint setup
Me:
• Optimization strategy
• Integrating engineering models into the optimization framework
Here are the 5 biggest lessons we learned along the way.
5 Hard Truths We Learned
1. Trust Is Earned
At the beginning of the project, we reviewed AI-generated code the same way we'd review a pull request from a junior engineer. Every function, every loop, every implementation.
After dozens of successful iterations, something changed. The generated code was consistently correct.
Eventually, we stopped reviewing syntax and started reviewing engineering behavior.
Instead of asking, "Is this Python code correct?" we started asking, "Does this produce meaningful results?"
That shift happened naturally. AI earned our trust through repeated success.
2. AI Writes Code. We Decided What the Code Should Do.
This became the biggest lesson of the project.
AI could explain ten optimization algorithms in seconds. It could generate clean implementations. It could even compare algorithms. But it couldn't reliably answer the question that mattered most: Which optimization strategy is actually the right one for this engineering problem?
Those decisions still depended on experience.
Even more interestingly, AI rarely challenged our engineering assumptions. For example, we replaced a simple constraint with a full physics-based curve because it better represented the underlying physics. AI never suggested that improvement. It never warned us that the simpler formulation might produce physically unrealistic designs.
It understood equations. It did not understand engineering judgment.
3. Traditional Debugging Isn't Dead in 2026
One result surprised me. For engineering calculations involving several physics equations, traditional debugging was still faster than AI in some cases. For example, if you know where heat rejection is calculated, you can often identify unrealistic results much faster than asking AI to search for the issue.
When investigating a difficult bug, setting breakpoints, stepping through execution, and inspecting variables inside VS Code frequently led us to the answer more quickly than prompting an AI assistant.
AI needed far more surrounding context before it could reason about deep mathematical logic. I expect this gap to shrink over time. Today, however, conventional debugging remains a good skill.
4. Local Context Is AI's Biggest Weakness
The hardest part of the project wasn't optimization. It was moving our workflow from local development to our company's HPC environment. The challenge wasn't Python. The challenge was enterprise context.
Internal cluster configurations, Conda environments, job schedulers, storage locations, and organization-specific infrastructure simply don't exist in public training data.
Even after experimenting with modern AI workflows and providing additional context, AI struggled to assemble a working solution. Eventually, I stopped prompting. I manually created the Conda environment. I wrote a minimal job submission script. I verified that everything worked. Only then did AI become incredibly useful.
Once a working baseline existed, it rapidly improved the scripts, automated repetitive tasks, cleaned up the workflow, and suggested better implementations.
5. The New Knowledge Gap
This project exposed something I didn't expect.
If you handed me a blank Python file today and asked me to rebuild our optimization framework entirely from memory... I'd struggle. Not because I don't understand optimization. I know the objective function. I know the constraints. I know why we selected our optimization algorithm. I know the engineering trade-offs.
What I no longer remember are the implementation details:
• The function signatures
• The keyword arguments
• The expected input formats
• Or how to parse input sheets as cleanly as our current implementation does
Throughout the project, AI handled those details while I focused on solving the engineering problem.
That realization made me wonder whether engineering education and technical interviews will need to evolve. Perhaps we should stop asking, "Can you implement this algorithm in Python?" and start asking, "Can you formulate the right optimization problem, select the appropriate method, and determine whether the results are physically meaningful?"
Because in an AI-assisted world, those may become the more valuable skills.
Final Thoughts
Perhaps the biggest lesson of all was this: The bottleneck is no longer writing software. The bottleneck is knowing what software should exist in the first place.
