Engineering judgment is becoming the work

Software engineering is changing faster than most career frameworks can keep up with. A few years ago, being a strong engineer was still heavily associated with the ability to write good code, understand systems deeply, debug difficult problems and deliver reliably. Those things still matter, but AI is rapidly changing the economics of implementation. Code that once took hours to produce can now appear in seconds, while tests, migrations, documentation, refactors and even fairly sophisticated architectural proposals can increasingly be generated on demand.

This does not make engineering less important. It changes where the value of the engineer sits. As implementation becomes cheaper, the difficult part shifts toward deciding what should be built, what should be trusted, what should be changed, which risks matter, when to move quickly and when not to. Engineering judgment is moving closer to the centre of the job.

That creates an interesting problem. AI can make an experienced engineer dramatically more productive because that engineer already has enough context and judgment to challenge the output. They can recognize when a proposed solution is elegant but unnecessary, when a generated abstraction is premature, when a migration is riskier than it looks, or when the model has confidently optimized for the wrong thing. For engineers who are still developing those instincts, the situation is more complicated. If AI removes too much of the struggle through which those instincts traditionally formed, the industry may end up making engineers faster without necessarily making them better at engineering.

This is one of the problems Engineering GPS is designed to work on: not how to make engineers produce more code, but how to help them become better at the decisions around the code.

Engineering judgment is not a set of rules

Ask an experienced engineer why they made a particular decision and the answer is rarely a clean rule. You are more likely to hear something like, “I’d ship this because we can reverse it quickly,” or “I would normally prefer the cleaner architecture, but the business does not need it yet,” or “I’m uncomfortable with this because we will not know quickly enough if it fails.” Those answers are interesting because the engineer is not applying a universal best practice. They are interpreting the situation.

That is what engineering judgment means in Engineering GPS. It is the ability to look at incomplete information, identify the variables that actually matter, understand the trade-offs, and make a decision that can be defended even when there is no obviously correct answer.

This is also why judgment is difficult to teach. Patterns, architectures, processes and principles can be documented relatively easily. What is much harder is learning when one principle should outweigh another. “Move fast” and “protect reliability” can both be good advice. “Keep things simple” and “design for the future” can both be good advice. “Own the problem” and “escalate early” can both be good advice. Seniority often shows up in knowing which one matters now.

A technically better solution is not always the better engineering decision

Consider another common situation. A team is about to add a new capability to an existing service. One engineer proposes extending the current implementation, which would be relatively quick but adds another exception to a design that is already becoming difficult to maintain. Another proposes extracting the capability into a cleaner service boundary. The second option is architecturally more attractive, but it requires more work, introduces another operational dependency and delays something customers are waiting for.

Which option is better?

There is no useful answer without understanding the situation around the decision. How likely is this part of the product to continue changing? What concrete problems is the current design already causing? How expensive would it be to separate the capability later? How much operational complexity would the new service introduce? What is the cost of delaying the customer outcome, and what would the team actually learn by waiting?

A technically cleaner architecture can still be the wrong engineering decision if it solves a future problem that may never arrive. Equally, repeatedly choosing the quickest implementation can gradually create a system in which every subsequent change becomes harder. The important question is not simply which design is cleaner, but which trade-offs matter most given the evidence available today.

That distinction is central to how Engineering GPS thinks about judgment. Strong engineers increasingly distinguish themselves not by knowing more rules, but by recognizing what matters in a particular situation.

The lenses behind a decision

This is where the methodology behind Engineering GPS starts. When the system looks at an engineering situation, it does not simply ask a language model to decide what a senior engineer would do. The aim is to decompose the decision and make the reasoning underneath it more explicit.

One useful lens is reversibility: if the decision turns out to be wrong, how difficult is it to undo? This matters because reversible decisions allow more experimentation. If a team can make a small move, observe what happens and cheaply retreat, it often needs less certainty upfront. Engineers sometimes spend far too long trying to eliminate uncertainty from decisions that could instead be tested.

Another lens is consequence: if the decision is wrong, what actually happens? A failed internal experiment and corrupted customer data are not equivalent risks. Good judgment means matching the amount of rigor to the real consequence of failure rather than treating every engineering change with the same level of caution.

Then there is observability: would the team know that something had gone wrong? Engineering conversations often focus on the probability of failure while underestimating the importance of detection. A moderately risky change with excellent monitoring and a clear rollback path may be safer than a seemingly simple change whose effects are difficult to observe.

Domain familiarity matters as well. A team making a change in a system it has operated for years is in a different position from one touching an unfamiliar domain with hidden assumptions and weak operational knowledge. The methodology also considers other lenses depending on the situation, including blast radius, time pressure, dependencies, architectural consequences, operational readiness, product value, ownership, learning value and the cost of delay.

The point is not to turn every engineering decision into a spreadsheet with twenty scores. That would simply be another way of avoiding judgment. The skill is knowing which variables matter most in the situation in front of you.

Strong engineers often change the question

One of the clearest signals of mature engineering judgment is reframing. Less experienced engineers often try to answer the question they were given. More experienced engineers are more likely to challenge whether it is the right question in the first place.

“Should we build A or B?” may become “What assumption makes A better than B?” “Can this architecture scale?” may become “What scale do we actually expect, and when?” “Should we delay the release?” may become “What risk are we hoping the delay will remove?” “Should we refactor this?” may become “What concrete problem does the current design create?”

This sounds simple, but it changes the quality of the decision dramatically. Engineering teams can spend enormous amounts of time answering technically interesting questions that do not matter enough. Judgment is partly the ability to notice that before the team invests significant time solving the wrong problem.

This is why AI changes engineering careers

The industry sometimes talks about AI and software engineering too narrowly. The conversation quickly becomes whether AI will replace developers, how much faster engineers can code, or which model produces the best pull request. The more consequential change may be that implementation itself is becoming less scarce.

If almost every engineer can generate competent code quickly, producing code stops being as strong a differentiator as it once was. The engineer who stands out is the one who can look at five plausible solutions and understand which one fits the situation; who recognizes when the AI has solved the wrong problem; who understands that the technically impressive answer is not necessarily the useful one; who knows when to move with 70 percent certainty and when the downside demands 99 percent; and who can connect a technical choice to operations, product impact, organizational constraints and customer consequences.

Those are judgment problems, and engineers who want to remain highly valuable will increasingly need to invest deliberately in those capabilities.

This applies to experienced engineers, but it may matter even more for people entering the profession now. Earlier generations of engineers accumulated judgment through thousands of small struggles: debugging things they did not understand, writing bad abstractions, recovering from incidents, reading unfamiliar code, arguing through designs, making decisions and seeing the consequences. A junior engineer working with a capable AI assistant can bypass some of those struggles.

That can be a very good thing. There is little value in romanticizing the hours engineers once spent searching for trivial syntax errors or reproducing boilerplate by hand. But some of that friction was doing useful work. If an AI immediately explains the bug, chooses the architecture, writes the tests and recommends the trade-off, the engineer may complete the task successfully while learning surprisingly little about how to make the decision independently next time.

The answer cannot be to stop using AI. The more interesting challenge is how engineers can use AI without outsourcing the development of judgment to it.

What Engineering GPS is trying to do differently

Most AI engineering tools are optimized to help engineers complete the task in front of them, and that makes sense. They should be. Engineering GPS has a different objective: it is designed to help the engineer improve the reasoning they bring to the next task.

That means the system evaluates not only whether the engineer chose a reasonable option, but also how they arrived at that choice. It looks at what they noticed, which trade-offs they considered, how they handled uncertainty, what assumptions they made and which important variables were missing from their reasoning. If an engineer reaches a good answer for weak reasons, that matters. If they choose an imperfect answer but demonstrate strong reasoning, that matters too.

The most useful feedback is therefore not “The correct answer was B.” It is closer to: “Your instinct to move quickly makes sense, but you treated this mainly as a delivery-speed decision. The more important variable was reversibility. Because the change was cheap to undo and easy to observe, you could safely create information instead of debating the decision longer.”

That type of feedback is useful because it can travel. The engineer can apply the same principle the following week to a completely different decision. Engineering GPS is designed to build not scenario knowledge, but reusable judgment.

The intelligence layer behind Engineering GPS

Engineering GPS uses AI, but the product is not designed as a general-purpose model with a system prompt instructing it to behave like an experienced engineering manager. That would be relatively easy to build and, more importantly, too easy to mistake for genuine engineering intelligence.

The intelligence layer behind Engineering GPS is structured around different forms of engineering reasoning. Technical decisions may require thinking about architecture, maintainability or failure modes. Operational situations bring in observability, blast radius, recovery and operational ownership. Product decisions introduce user value, opportunity cost and the cost of delay. Cross-team situations bring different questions around ownership, dependencies and influence, while AI-generated code raises another set of questions around verification, hidden assumptions and how much scrutiny should depend on consequence.

The broader engineering judgment framework therefore spans areas such as technical excellence, architecture, operational judgment, systems thinking, product thinking, business impact, ownership, professional effectiveness, mentoring and AI-era engineering judgment. Different situations activate different parts of that intelligence because engineering judgment is contextual. A framework that gives the same advice regardless of the situation is not really a judgment framework; it is a checklist.

The methodology should be visible

An important principle has become clearer as Engineering GPS has developed: the methodology should not disappear completely behind the experience. It is not enough for a user simply to receive feedback that sounds intelligent.

Engineers are right to be skeptical of AI-generated advice. If a product challenges someone's reasoning, the user should be able to understand what that challenge is grounded in. When Engineering GPS says that reversibility mattered, or that an engineer failed to consider observability, those concepts should be explicit rather than hidden behind a generic assessment.

This does not mean engineers need to memorize a framework before using the product. It means good feedback should be inspectable. The product should be able to explain why a particular piece of reasoning matters and which engineering principle sits behind the observation.

That is also an important distinction between a judgment system and the vague experience of “AI says this is good.” There should be a methodology underneath the opinion.

The goal is not to remove the difficult part

There is a slightly uncomfortable product-design implication here. Most software products are designed to remove friction. Engineering GPS sometimes needs to preserve it.

If an engineer brings a real decision to the Situation Clinic, the most helpful thing the system can do may be to avoid giving an immediate answer. Instead, it might ask what would make the engineer change their mind, which assumption carries the most risk, what information could be gathered cheaply before making the larger decision, or which part of the choice is actually irreversible.

That is slower than simply asking an AI, “What should I do?”, but there is a reason for it. If AI always performs the reasoning on behalf of the engineer, the profession may become extremely efficient at producing work while gradually becoming less practiced at making the decisions that define good engineering.

That outcome is not inevitable. In fact, AI could do the opposite. It can give engineers access to an almost unlimited supply of realistic situations, counterarguments, changing constraints, alternative perspectives and immediate feedback. Used differently, the same technology that can remove opportunities to think can create many more opportunities to practice thinking.

That is the bet behind Engineering GPS. The role of the software engineer is changing. Code will continue to matter, but the relative value of simply producing it is likely to decline as machines become better at doing that part. Knowing what to build, what to trust, what to question, what to optimize for and when to change direction will matter more.

Those are not secondary skills around engineering. Increasingly, they are the engineering.