A reflection on AI and professional judgment
“Do it and deploy it.”
It is not always phrased that way. Sometimes it is disguised as urgency: it has to be ready tomorrow, we will review it later, AI can solve it, there is no need to overthink it. But when urgency replaces review and judgment, the outcome is the same: a production decision made without sufficiently understanding what we are putting into production.
A sentence I heard last week made me pause: “Let AI do it and deploy it; there is no value in a developer reviewing the code.”
There are situations where an exhaustive review may add little value. Small, repetitive, contained, and reversible tasks can benefit enormously from automation. Denying that would be dogmatic.
But turning that idea into a general rule means something deeper: assuming implementation is all that matters, and that professional judgment can disappear from the process.
I am not writing this from a rejection of artificial intelligence. I use it every day, and I believe it can expand our ability to build software in extraordinary ways. It can solve repetitive tasks, accelerate exploration, unblock problems, and allow small teams to validate ideas that would otherwise have required unattainable resources.
That is valuable. And precisely because it is valuable, it deserves to be used responsibly.
The problem is not that AI writes code. The problem begins when we confuse its ability to generate a solution with certainty that the solution is suitable for production. A tool can propose an implementation; it cannot bear the consequences of accepting it.
Someone still decides what to ask for, what data the system can access, which permissions it receives, what tests are sufficient, which risks are accepted, and when to deploy. Even if they did not write every line, that person or team remains responsible.
Professionalism does not mean writing everything by hand. Nor does it mean reviewing every change with the same level of scrutiny. A personal landing page does not have the same criticality as a system that processes payments, personal data, or sensitive infrastructure. A small, repetitive, and contained task can be an excellent situation for delegating extensively to AI.
Demanding maximum control in every case would be inefficient. But removing control altogether is not efficiency: it is giving up judgment.
The autonomy we give a tool should depend less on how much we trust it and more on three questions: how much harm can an error cause, which controls exist to detect it, and how capable are we of limiting or reversing it?
That is where guardrails matter. Prior configuration, suitable models for each task, limited permissions, automated validations, tests, isolated environments, observability, the ability to roll back changes, and reviews when the impact warrants them. They are not a declaration of distrust in AI; they are a declaration of responsibility toward the people affected by our software.
The preparation of the person using the tool matters too. Professional judgment does not disappear because an interface can produce results quickly. On the contrary, it becomes more important. We need to distinguish a plausible solution from a safe one, recognize when we do not understand a change sufficiently, and know when to ask for help or raise a risk.
But responsibility cannot rest entirely on one person either. Teams need agreements: non-negotiable minimums for sensitive areas and practices that evolve through experience. We do not need to anticipate every situation from day one; trying to do so can lead to paralysis. We do need to learn from what happens, turn that learning into better controls, and avoid repeating the same risks out of convenience.
When we normalize “prompt and production” without judgment, the harm is not limited to a single failure. It can become security breaches, hidden costs, technical debt, lost trust, and decisions that are difficult to reverse. It also damages the perception of our profession: it suggests that software development is about asking for results and pressing a button, rather than making responsible decisions under uncertainty.
AI multiplies our capacity to act. It can improve what we already do well. But it can also dangerously amplify a lack of care, knowledge, or responsibility.
This is not about reviewing for the sake of reviewing, nor about distrusting AI by default. It is about not confusing speed with responsibility.
Before deploying, ask yourself: what could a reasonable review detect or prevent? What would the impact of being wrong be? Which controls exist to detect, limit, or reverse the consequences?
If you cannot answer, perhaps it is not time to deploy yet.
AI can write code. Responsibility for putting it into production remains ours.