Critical thinking in the age of AI and why it still matters

The art of the deal

Software engineering is the art of managing complexity in software systems. Good engineering strives to remove needless complexity from software so that it is easier to work with, has fewer defects and costs less to maintain over its lifetime.

At the heart of the fight against complexity is refactoring - the process of improving the design of existing code without changing its behaviour. Refactoring is as integral to software development as editing is to writing.

But its simple definition belies hidden complexity - knowing when, why and how to transform code for the better requires skill, insight and deep expertise.

Refactoring is thinking

A ‘refactoring’ draws a line between a single, well-defined code smell (an issue that may lead to deeper problems over time) and a corresponding fix. A refactoring is not a refactoring unless the code’s design is improved. Any change that updates the code’s behaviour is not a refactoring.

Developers refactor continuously when writing new code, typically as part of the process of first making code work and then making it right. A refactoring is not some random act of improvement but rather one step in a sequence of intentional changes that drive code towards a better place. This intention and the critical thinking that goes behind this process is an essential part of what it means to be a software engineer.

Thinking is learning

Refactoring helps developers maintain control of their code, but what happens when they are handed a legacy codebase? When the original authors have moved on, developers need to quickly acquire intellectual control of the software and the underlying domain before they can update or estimate change with any level of confidence. 

This learning phase can take months or even years depending on the state of the software or complexity of the domain. Assistants can undoubtedly help, but making sense of complex codebases requires a deeper contextual understanding and awareness beyond any tooling available today. Critical thinking is not something that can be handed off to an assistant.

Instead, developers need to work with the code, e.g. by adding a few much-needed tests or refactoring code smells thrown up by the IDE. Testing and refactoring force developers to ask questions about the code and its intent, both of which help further their understanding.

Assisted thinking

The AI-enabled IDE is an extremely powerful tool, capable of boosting developer productivity across many tasks, particularly for known problems.  For example, they are excellent at identifying issues across large codebases in seconds that would otherwise take developers hours or days to uncover (if ever).

But it is also flawed. According to one recent study, current AI tooling makes incorrect refactoring suggestions over 60% of the time, and not always in the most glaringly obvious way. Even the best models will introduce subtle bugs that may take weeks or months to surface.

This begs the question, what good is an assistant if it can’t be trusted? Even if this figure is overblown, any amount of misinformation is a huge distraction to an engineer. In the hands of an inexperienced engineer, it is a liability. 

We are nowhere near the point at which AI can think contextually. It might be brilliant at accelerating the known, exploring the possible, and automating the routine, but it is not a replacement for hard thinking. It will assist with your thinking, that is all. 

Crucially, this assistance must not overstep into reliance. Developers cannot swap ownership for convenience.

Informed caution

AI is now a fact of life. In amongst all the current hype and cynicism is a technology that will change how we live and work - maybe not at the speed and level the main protagonists claim, but it will change things dramatically nonetheless. 

However, today’s version of AI (i.e. Narrow AI) is not a replacement for good people and good engineering. If anything, it has only elevated the importance of good engineering at a time when fewer and better developers will increasingly be expected to deliver more with less.

In embracing AI, do so with your eyes wide open. Remember, it is only a tool. It will undoubtedly bring productivity gains but recognise that your mileage will vary depending on your context. To reiterate, it is not a replacement for people or good engineering. You must continue to:

• Keep human experience in the loop: AI is not a replacement for critical thinking or human-based peer reviews.

• Own your outputs: Developers must remain accountable for their decisions. This is non-negotiable.

• Learn how to use AI: Build a shared understanding across your teams on how to use AI optimally, focusing on where it brings most value. 

• Test and automate: CI/CD, DevSecOps and continuous integration practices must remain central to how you build software going forward. 

• Invest in learning and growth: AI is not a replacement for junior engineers and the next generation of experience needs to come from somewhere.

The more things change, the more they stay the same. AI is set to change almost every aspect of how we develop software, however, it will not remove the need for critical thinking or engineering know-how from the loop.

People, discipline and culture matter as much today as they have ever done. It’s just that we now have some additional and rather powerful assistance to help guide the way.