The Era of AI Won't Reward Better Prompts. It'll Reward Better Judgement.

I remember when getting stuck was part of becoming a better engineer. You would spend hours trying to understand why something was not working, reading documentation, tracing through unfamiliar code, searching through old discussions, and eventually the answer would reveal itself. It was frustrating, but that frustration was part of the process, because somewhere in those difficult moments you were building something that could not be gained from a tutorial or copied from an example: engineering intuition. You started recognising patterns, and you began to notice when an abstraction was becoming too complicated, when a solution was solving the wrong problem, or when something that looked elegant on paper would become painful six months later. The struggle was not just slowing you down; it was teaching you.

Then large language models arrived, and almost overnight the economics of software development started to change. The parts of engineering that once consumed hours could suddenly be completed in minutes: boilerplate code, repetitive tasks, unfamiliar APIs, and early prototypes could all be generated almost instantly, so a junior engineer could create the foundation of an application faster than ever before, while an experienced engineer could explore architectural possibilities before finishing their morning coffee. At first, this felt like a complete transformation of what it meant to be a software engineer, because if the machine could write the code, perhaps the advantage would belong to whoever knew how to operate the machine best, and maybe the engineers who spent years learning the craft were about to be overtaken by those who could write better prompts. But I think we are making the same mistake that Maverick warns against in Top Gun: "It's not the plane. It's the pilot." The plane has become extraordinary, but the pilot still matters.

"It's not the plane. It's the pilot."

The Pilot in the Box

One of the most interesting ideas from Top Gun: Maverick is that technology can make something possible without guaranteeing success. A more advanced aircraft gives a pilot greater capability, allowing them to move faster, respond quicker, and attempt things that were previously impossible, but when conditions change, when the situation becomes uncertain, and when there is no perfect answer available, the outcome still depends on the person controlling the machine. As Maverick says: "It's possible. That will come down to the pilot in the box." That line feels surprisingly relevant to the current moment in software engineering, because the question is no longer whether AI is capable—it clearly is. These tools can generate code, explain unfamiliar concepts, suggest architectures, and help engineers move faster than ever before, but the more important question is whether the person using the tool understands what to do with that capability. Can they recognise when the answer is good enough? Can they spot when a suggestion introduces unnecessary complexity? Can they tell the difference between an interesting idea and the right idea? The future of engineering will not be determined by who has access to the most powerful tools, because those tools will become increasingly available to everyone. The difference will come down to the pilot in the box.

"It's possible. That'll come down to the pilot in the box."

The Plane Does Not Win the Dogfight

One of the lessons from aviation is that having a more advanced machine does not automatically mean you win. In a dogfight, there is no opportunity to analyse every possible move or search for the perfect response; the pilot has to observe what is happening, understand the situation, make a decision, and act, and the advantage comes from recognising patterns quickly and making good decisions under uncertainty. Software engineering is entering a similar environment, because an LLM can generate ten possible solutions before an engineer has finished reviewing the first, and it can suggest different architectures, patterns, and approaches almost instantly. The challenge is no longer finding possible answers; the challenge is knowing which answer matters, which is a subtle but important shift. For a long time, engineers were limited by their ability to implement ideas, but today implementation is becoming cheaper, and the difficult part is deciding which ideas deserve to exist in the first place. A less experienced engineer may see the number of possibilities available and assume the goal is to explore as many as possible, but an experienced engineer understands that every option has a cost, that every abstraction creates a future maintenance burden, and that every new pattern introduces another concept the team has to understand. The goal was never to find every possible solution; the goal was to find the right one.

An F-14 against fifth gen fighters. It's not the plane, it's the pilot

The Bottleneck Has Moved

The biggest change AI has created is not that software engineers can write code faster; it is that writing code is no longer the biggest constraint. The bottleneck has moved, and when implementation becomes easier, decision-making becomes harder. The questions that separate good engineering from average engineering are no longer just about whether something can be built, but about whether it should be built at all. Should this feature exist? Is this abstraction solving a real problem or simply making the system more complicated? Are we improving the right part of the product? Will this decision still make sense when the system grows? These questions have always mattered, but they were often hidden underneath the amount of time engineers spent writing code, and AI has exposed them. An LLM can explain CQRS, event sourcing, dependency injection, and countless architectural approaches; it can help you understand concepts that once required hours of research. But it cannot understand your customers, your team, your constraints, or the trade-offs that exist inside your organisation. It can provide possibilities, but the engineer still has to provide judgement.

"Time is your greatest enemy."

The Danger of Drift

The biggest risk with LLMs is not that they will always give us bad answers; the more interesting risk is that they will give us too many good ones. I noticed this when working with AI tools: a simple problem that previously had a clear path suddenly became a conversation with endless possibilities, and a small piece of code could become an opportunity to improve the abstraction, introduce a new pattern, rethink the architecture, or redesign the surrounding system. The strange thing is that none of those suggestions are necessarily wrong, and that is exactly what makes them dangerous. A pilot rarely ends up far away from their destination because of one dramatic mistake; they drift, small changes in direction seeming insignificant at the time, but eventually they realise they are no longer heading where they intended. Software development can drift in exactly the same way: a bug fix becomes a refactor, the refactor becomes an architecture discussion, the architecture discussion becomes a redesign, and before long you are solving a completely different problem from the one you started with. The AI did not fail; it did exactly what it was designed to do, which was explore possibilities. The failure was forgetting the mission.

"The second you think, you're dead."

OODA Loops Instead of Prompt Loops

One concept from aviation that translates particularly well into engineering is the OODA loop: Observe, Orient, Decide, Act. The idea is simple, and the person who can move through this cycle effectively gains an advantage because they are able to adapt faster than the situation changes. I think this is where engineers need to be careful with LLMs, because it is easy to create a new kind of loop where we observe a problem, ask the model for a solution, review the response, ask another question, compare alternatives, and continue exploring. The conversation feels productive because we are constantly learning, but learning and progressing are not always the same thing, and at some point we need to leave the conversation and interact with reality. Build something, deploy it, measure it, and learn from what actually happens. The fastest way to discover whether an idea works is often not another question; it is feedback.

"Trust your instincts. Don't think, just do!"

The Mission Matters More Than The Machine

Perhaps the most important discipline a pilot develops is remembering the mission, because in training it is easy to become focused on the immediate challenge and forget the larger objective. Winning the engagement is not always the goal; sometimes the mission is something else entirely. Software engineers face the same temptation, because technical problems are interesting, architecture discussions are rewarding, and elegant solutions are satisfying, but the mission was never to build the most impressive system. The mission was to solve a problem for people. AI makes this harder because it makes every technical possibility more accessible, allowing us to explore deeper and move faster into complexity, but the best engineers understand that complexity is not the same as sophistication. Sometimes the most senior decision is knowing what not to build.

"The mission is all that matters."

The Enemy Gets a Vote

There is an old phrase from military strategy: "The enemy gets a vote." No matter how carefully you plan, reality will challenge your assumptions, and software works the same way. Users behave differently than expected, requirements change, production reveals problems that were invisible during development, and the solution that looked perfect in theory may fail when it meets the real world. This is why endless conversations with an LLM can become misleading: inside the conversation, every assumption remains true, but reality is where those assumptions are tested. Eventually, you have to stop talking to the copilot and fly the aircraft.

"No turning back now."

The Pilot Still Matters

The next generation of engineers will not be defined by how quickly they can generate code, because everyone will have access to powerful tools. The difference will come from the things those tools cannot replace: knowing which problems are worth solving, understanding when a simple solution is enough, recognising unnecessary complexity, and having the confidence to stop exploring and start building.

There is a moment in Top Gun: Maverick where Maverick says, "It's not what I am. It's who I am. How do I teach that?" It captures something every experienced engineer eventually discovers. You can teach someone a framework. You can explain an architecture. AI can generate code and answer technical questions in seconds. But judgement isn't a checklist, and intuition isn't something you download. They're earned through years of mistakes, trade-offs, production incidents, and learning from reality.

The aircraft will continue to improve. The models will become faster, smarter, and more capable. They will write better code, explain more concepts, and automate more of the work we perform today. But the responsibility in the cockpit remains unchanged. The tool does not choose the destination. The tool does not notice when you have drifted off course. The tool does not know when the mission is complete.

It's not what an engineer does. It's who they become.

"It's not the plane. It's the pilot."