AI is just the next tool

First, let me say what this post is not about.

I’m not here to argue whether a model was trained ethically, or whether the company behind it paid for the material it learned from. That’s a real conversation, it’s just not this one. I’m an engineer. I pick my tools based on what they can do, not on the politics of how they were built. So if you came for the ethics-of-training debate, this isn’t it. Consider that out of scope.

Here’s where I actually stand: AI is a tool. That’s the whole of it. One more tool among the tools I reach for to get a job done.

MoVox is the proof. This is an AI-native project, born with the help of AI. There’s a lot of AI involvement here, so let me break it down. First, let me define the buzzword “AI-native.” To me, it means this project simply doesn’t exist without AI. Not “AI helped speed it up.” Without AI, there is no MoVox; the entire pipeline runs on AI technologies: the novel analysis, the TTS, the image generation, the video editing, etc.

Next, the helpers that made it happen. I used AI research tools like Gemini, Claude, and NotebookLM for research, design, and coming up with ideas. And I use AI coding agents like Claude Code and Gemini to build the project, every day. Without these helpers, the project wouldn’t be where it is today; I’d still be trying to figure out the tech I’d need, learning everything as I go (more on that later).

So why am I so calm about this when a lot of people aren’t? Because as an engineer, I’ve seen this movie before. Let me draw the comparison I keep coming back to: AI coding agents are just programming languages.

Think about what a programming language actually does. It translates human intention into something a computer can run, all the way down to 0s and 1s. That’s the entire job. And the whole history of programming has been one long search for a better, faster, easier way to do that translation: to tell the computer what we want and have it actually listen.

I’m simplifying a bit, but bear with me. Start at the bottom: we had assembly, the raw instructions the processor runs. Back in the old days, you had to write those by hand. Hard to write, even harder to understand. Then came higher-level languages like C and C++, which read almost like English. When you compile a C++ program, the compiler takes that English-like code and turns it right back into the same assembly, the same machine code we used to write by hand. How a computer runs a program at the most basic level didn’t change; we humans just had a better way to convey our intentions. Programming got easier, and as far as I know, most people cheered the advancement and started adopting the new languages to make better applications faster.

What actually happened during this transition? Engineers adapted, just like they will now. They upskilled. They learned Fortran, then C and C++, then Java, then Rust and so on. Every one of those made it easier for a human to talk to a machine. That’s the thread running through all of it.

LLMs are the next step on that exact same line. They make programming easier again, this time by letting you use natural language. And not even just English. Is that a bad thing?

Yes, it lowered the barrier to entry. Yes, it gave us the vibe-coding era: building software by describing what you want in plain words and letting the model write the code. Again: is that such a bad thing? We can finally say what we mean to a computer, plainly, and be understood.

A lot of the complaints come from LLMs and agents producing bad code. Two things about that. One: the newer, more capable models keep chipping that problem down. Two, and this is the part I actually like: a lot of the people doing the vibe-coding are non-engineers learning on the job. They started without the training, sure. But many of them are genuinely passionate about what they’re building, and they ramp up fast on how an engineer thinks, how you break a problem down and solve it logically, one piece at a time. And AI-powered coding agents help them get there.

And honestly? That same path, learning on the job, is the one most of us “real programmers” walked. When I first joined a game company, I had no idea how to write a game in C++. The degree didn’t teach me that. What it taught me was how to learn on the job faster. That’s all it was.

So here’s my honest read: there’s nothing here to fear. This is natural progression. We’ve done it before, and we’ll do it again.

The one difference this time, and it’s a real one, is speed. Assembly to C to the modern languages played out over decades. Engineers had years to see it coming, to react, to pivot, to upskill. LLMs and agents didn’t give anyone years. They exploded onto the scene in months. A lot of people simply didn’t have time to react: to catch their breath, to reskill, to figure out where they fit. And I think that’s where most of the fear actually comes from. Not the tool. The speed.

There’s something even more basic underneath the speed, too. I’ll make a few claims here without stopping to prove each one, otherwise this turns into a research essay instead of a blog post.

Most people fear the unknown. A lot of people fear change. I think that’s the deeper root of the fear around AI.

Let me pick on my own family for a moment. My elderly parents are the ones who keep telling me AI is going to take my job. They’ve had no computer training, none at all. Everything they know about AI came from articles online about how it’s coming for our jobs, and that was the whole of their exposure to it. So of course they’re worried. It’s the only story they’ve been handed.

But they’re half right. The quick advance in AI will bring change. Huge change. Count on it.

And change has never waited for anyone to feel ready. Call it natural selection if you want. The people who adapt, who pick up the new tools and actually learn to use them, move forward. The ones who dig in and refuse get left behind. It sounds harsh, but it’s the same story every technological shift has told. The engineers who learned C didn’t lose their jobs to C. The ones who refused to learn it did.

So no, I’m not afraid of AI taking my job. I’d rather spend that energy learning to use it well, the same way I once had to learn C. The tools keep changing; adapting to them has always been the job.

Once we stop fearing AI and start using these tools, another major concern shows up: the so-called “AI slop”, whether it’s in code, art, or other areas. A lot of people complain that content produced by AI lacks creativity, has no soul, or is plainly wrong. I will again use the example of a programming language.

When we describe a problem to a compiler (by writing C code), the output is deterministic, meaning we can predict the exact output if we know the input. Thus there is this saying, “garbage in, garbage out.” When the input is wrong, don’t expect the right output. I always preach to others that computers don’t make mistakes (unless there’s a hardware failure, which is relatively rare); the software bug usually lies in the description provided by the human (the C code).

Because we are so used to this deterministic behavior when working with computers, we expect the same from the newcomer on the computer, the AI model. The problem is, AI models are non-deterministic. When giving a query to an AI model, such as asking it to write a program for us, the output cannot be easily predicted. I think this led to a majority of the complaints. The output is just not what we think it should be.

From where I stand, this non-deterministic behavior is actually desired. And here’s the part people miss: it’s a choice, not a flaw. You can pin a model down to be almost fully deterministic, set what’s called the temperature to zero, fix the random seed, and it will hand you back the same answer every time. We usually choose not to. That randomness is a knob we leave turned up on purpose, because it’s what lets the model explore instead of parroting one fixed reply.

So why do we want a model that explores? I will start with how AI learns. At the very basic level, our current AI models are powered by neural networks. Without going into the details of neural networks, they are loosely inspired by how a human brain processes and stores information (or however much our modern medical research understands about the way a brain works, which isn’t really a full understanding). Our AIs were designed to mimic a human’s intelligence, hence the word AI, artificial intelligence.

A human’s “training” is shaped by our experience all through our lives. We use our senses to collect information about the world around us (the training data), then our brain processes that collection, digesting it and boiling it down into our understanding (the training process). AI model training goes through a similar process at the very high level. To go a little further, both humans and AI models reinforce their learning through feedback. For the models, that even has a name: RLHF, or reinforcement learning from human feedback, and it’s a big part of how they get shaped after their initial training.

In this sense, an AI coding agent is more like a knowledgeable software engineer than a compiler. When we ask an AI model to solve a problem, we don’t know how it will solve it, but it will, in its own way. Just like humans, we all make mistakes. Sometimes we come up with the right answer, sometimes the wrong one, be it human or AI. If we don’t expect the AI to be an all-knowing god, but an entity with limited knowledge to base its answers on, then we will be more lenient in judging AI’s output.

So how do we ensure AI output is as close to accurate as possible? We first select the right model for the job (model evaluation and selection). Then we make our intentions crystal clear (prompt and context engineering). Once we receive the first round of output, we review it and send it back for rework if needed (a human-in-the-loop review cycle). I’ve leaned on all three building MoVox. Let me make it concrete with the voice work.

For picking the model, I didn’t want to go on gut feel, so on a separate branch I built a little A/B harness: feed the exact same line to several text-to-speech models, Qwen-TTS, MeloTTS, CosyVoice3, and a few others, then listen back to back and score each one. None of them were perfect, not one. But Qwen-TTS scored the highest for what we needed, so that’s what MoVox runs on. That’s model evaluation and selection, in plain terms.

Even the winner trips, though. Qwen-TTS will sometimes get stuck in a loop, usually on a very short line, and spit out a garbled clip. I could sit and listen to every file to catch them, but that doesn’t scale. So I wrote a small review agent that runs in its own process and just watches the output folder. Every time a new clip lands, it checks the audio’s length against how many characters the line has. If a clip runs way too long for what it’s saying, that’s the loop signature, and the agent quietly pulls that file into a review folder for me to check later. Generation keeps going, review keeps going, neither waits on the other. That’s the human-in-the-loop cycle: I don’t expect the model to be flawless, I expect it to slip, so I built something to catch the slips. (How I scored the models, and what that review agent keeps catching, are each worth their own post down the line.)

As for art creation, I’m not an artist, so I won’t go into a debate about whether the art created by AI has creativity or not. Again, out of scope. I just know humans also produce masterpieces and junk alike.

So let me bring the two halves together, back where I started.

Is AI slop? It can be. Point a model at a lazy prompt, grab the first thing it hands back, ship it without a second look, and yes, you’ll get slop. But that’s not the tool’s fault. That’s garbage in, garbage out, the same rule we’ve lived by since the first line of code. The tool didn’t lower the bar. The person did.

The other road is the one I’ve been walking with MoVox. Pick the right model for the job. Say what you mean, clearly. Review what comes back, catch the misses, send it around again. Direct it the way you’d direct a talented, occasionally sloppy collaborator, because that’s far closer to what it is than any compiler. Do that, and what comes out the other end isn’t slop. It’s craft.

That’s my whole stance, both halves of it. Don’t fear the tool: it’s the next step on a road engineers have been walking for the better part of a century, and adapting to the next tool was always the job. And don’t dismiss what it makes: the taste, the judgment, the thousand small corrections along the way, that was always where the craft lived, and it still is. The tool didn’t take the storyteller’s place. It handed one person a studio.

So no. Not slop. Craft.