When it comes to using AI to write code, I have been thinking a lot about porridge. Allow me to explain.
Too cold
Engineers who reject AI tooling may fear it will erode their skills or lead to sloppy output. There are legitimate reasons to be cautious: hallucinated code in safety-critical systems, security vulnerabilities introduced by generated code, the difficulty of reviewing code you didn't write. But the answer is not to bury your head in the sand.
Good software engineers have always been those willing to adopt better tools. Nobody argues that using an IDE with syntax highlighting makes you a worse programmer, or that automated linting is somehow cheating, despite the resistance these tools attracted on first appearance. AI coding is following the same trajectory.
The reality is that these tools, used well, are a genuine productivity multiplier for the mechanical aspects of software development. If I met an engineer in 2026 who told me they had never used an AI coding tool, I would not be impressed by their purity. I would be concerned about their adaptability.
Too hot
At the other end of the spectrum, there are the engineers who have gone full autopilot. Tab-complete everything. Accept every suggestion. Let the AI write the function, the test, the commit message. Ship it. Why think when the machine can think for you?
Because when you fall into the AI coding trap, and let AI do the thinking for you, something atrophies. You stop reasoning about architecture. You stop noticing when a suggestion is subtly wrong. You lose the instinct that tells you a particular abstraction is going to cause pain in three months. You are still shipping code, but you are not really coding any more. You are just a very expensive approve button.
When cloud infrastructure became widely available, the skillset for deploying and scaling a database did not disappear overnight. Instead, the bar was raised for what professional work was expected to deliver, and engineers who understood the underlying technology were better able to harness automated deployment to produce stable, fault-tolerant systems. AI coding tools are no different. The ability to generate working code is becoming commoditised, but the ability to design software is not.
If you are an experienced engineer whose workflow now consists entirely of prompting and approving, you are not building on your experience. You are discarding it. And you are leaving yourself entirely at the mercy of a tool that is available to everyone, including people with far less expertise than you.
Just right
Nobody has really figured this out yet. The tooling is too new, changing too fast, and too dependent on context for there to be a textbook answer on how to integrate AI into a team coding environment. What matters is the mindset: explore openly, but keep your critical faculties engaged.
The engineers getting the most out of AI are not the ones surrendering to it. They are the ones becoming more deliberate about where judgement actually matters. They let AI accelerate boilerplate, exploration, and low-risk implementation work, but stay close to core abstractions, interfaces, and architectural decisions. The workflow is not “AI everywhere” or “AI nowhere”. It is knowing where speed helps and where distance from the code becomes dangerous.
Finding the right temperature is important because the goal of AI tools is not just faster delivery: it is to free your time to be spent on harder problems. When the mechanical effort of writing code drops significantly, you have more time and energy available for the things that actually differentiate good engineering: system design, abstraction, trade-off analysis, and the kind of deep problem-solving that no amount of autocomplete can replicate.
The right temperature is not about how much AI you use. It is about whether you are still thinking.