Fighting the Tools (So I Can Maybe Write Some Code)

Why Model-Based Development Still Feels Manual

There’s a special kind of exhaustion that comes from spending hours wrangling tools—not to build something brilliant, but just to get through the day without breaking the workflow.

That’s been my experience lately in automotive embedded software development, especially in model-based design using MATLAB/Simulink. The code generation part is fine—honestly, Simulink does a great job producing production-ready C code. It’s everything that comes after that feels broken.

The grind starts with testing frameworks that don’t integrate cleanly with the models. Then come the traceability tools, which throw errors if the folder structure changes or if a requirement gets reworded. And don’t get me started on software delivery pipelines that still depend on manually moving files around, or chasing mismatches in artifact metadata.

Then there’s the long, slow battle with functional safety requirements—especially ISO 26262. Yes, they’re essential. No, they’re not straightforward. Each requirement needs to trace to a test. Each test needs to tie back to an autogenerated report. Every piece of metadata needs to be formatted just so—or a downstream tool breaks and doesn’t tell you why.

On top of that, the application and service tools—the ones meant to simplify calibration or configuration—often require so much customization that they add more overhead than they save. Every project has its own flavor, and every team seems to have their own internal tool that almost works. Almost.

It’s not the modeling or code that drains your time. It’s the constant glue work: trying to convince six tools to speak the same dialect, trying to prove where the code came from, trying to explain to someone in review why a test result disappeared from the report.

And the worst part? I’ve gotten good at it. Not because I want to—but because I have to. You start keeping a spreadsheet of manual post-processing steps and calling it “automation.” It’s not elegant, but it passes review.

Sure, there are bright spots. A test environment that finally runs without manual prep. A delivery package that builds clean. But the actual software development—the thinking, the designing, the building—gets squeezed between the seams of too many tools that don’t quite fit together.

I’m not asking for miracles. Just a workflow where model-based development doesn’t mean spending more time documenting what happened than actually making it happen.

Until then, it’s back to the post-build scripts.