The debate over AI in software engineering has been framed almost entirely by the people writing deterministic code. That is a useful conversation, but it is incomplete. The engineers who build machine learning models live in a different reality, one where the tools themselves are probabilistic, where failure modes are not always visible in a pull request, and where the cost of a wrong assumption is not a bug fix but a model that quietly drifts. So when they talk about AI usage, they are not debating whether a code assistant saves ten minutes on a function. They are asking whether they can trust the output of a system that cannot fully explain itself. That is a different bar, and it deserves its own voice in this discussion.
Our take is simple: the mixed reactions from software engineers are valid, but they do not map cleanly onto the experience of ML engineers. For someone writing deterministic code, AI is a productivity lever. It can generate boilerplate, suggest patterns, and catch syntax errors. The time saved can be redirected toward design and architecture, which is why some engineers report a net positive. But for ML engineers, the stakes are not about speed. They are about correctness, reproducibility, and the ability to debug a model that is not just a function of inputs but a reflection of training data, hyperparameters, and the stochastic nature of gradient descent. Reviewing AI-generated code is one thing. Reviewing an AI-generated model pipeline is another, because the failure can be silent until it reaches production.
That is why the engineering community needs to stop treating this as a single conversation. The person who uses a code generator to scaffold a REST API is not having the same experience as the person who uses a large language model to write a data preprocessing step that will be fed into a training loop. The former can read the output line by line and verify it. The latter has to trust that the model has not introduced a subtle bias or a distribution shift that will only surface months later. The tools are the same in name, but the risk profiles are not. So when we hear that AI slows some engineers down, we should ask which engineers and what they are building. The answer will tell us more about the nature of the work than about the technology itself.
For our readers, the practical takeaway is this: do not let the loudest voices in the software engineering discourse define your relationship with AI. If you are building deterministic systems, use the tools to offload the mechanical parts of your work and spend the reclaimed time on the problems that require judgment. If you are building models, be more cautious. Treat AI as a junior collaborator who needs constant supervision, not as an oracle. And if you are somewhere in between, which most of us are, build your own criteria for when to trust the output. The conversation is not one-size-fits-all, and the sooner we stop pretending it is, the sooner we can have a realistic view of what these tools can and cannot do. The engineers who build ML models already know this. It is time the rest of us caught up.