Why I'm Building Toward AI/ML Engineering (Not Just Using AI Tools)

A lot of freelance work right now rewards being fast with AI tools — knowing which prompt gets a usable result, which model to reach for, which automation platform glues two services together. That’s a real, valuable skill, and I use it daily. But it’s not the same as understanding how the models underneath those tools actually work, and I don’t want to stop at the surface.

The ceiling of “tool-wiring”

Automations built entirely on top of someone else’s model API hit a ceiling fast. When the tool changes its pricing, deprecates a feature, or just doesn’t handle an edge case well, you’re stuck waiting on someone else’s roadmap. The freelancers and engineers who can actually reason about the models — what they’re good at, where they break, how to fine-tune or adapt them — aren’t stuck in that position.

Why now, and why me

I’m in a decent position to make this shift deliberately. I already have real client work that touches AI content generation, video tooling, and automation — so I’m not learning ML theory in a vacuum, I’m learning it against problems I’ve already run into in production. That context makes the math and the theory land differently than it would in a purely academic setting.

What “building toward it” actually looks like

Concretely: working through the fundamentals of machine learning alongside my CS coursework, rebuilding some of the automations I’ve shipped for clients using models I understand end-to-end rather than black-box APIs, and being honest with myself about what I don’t know yet instead of papering over gaps with confident prompting.

The point isn’t the label

I’m not trying to rebrand as an “AI/ML engineer” for the sake of a title. I’m trying to make sure that five years from now, the tools I’m fluent in are tools I actually understand — not just tools I’ve learned to operate.