AI began as something many engineers experimented with on the edges of their work. You could ask it to explain a concept, generate a small piece of code, or help debug an error. It was useful, occasionally impressive, and still relatively limited in scope.
That capability evolved quickly.
Engineers can now ask AI to explain a codebase, plan a feature, generate an implementation, write tests, propose fixes when those tests fail, and review PRs. Some are managing multiple agents at once, with each one producing code, questions, and decisions that require attention.
This can create extraordinary leverage—and it can also leave engineers feeling fragmented, overwhelmed, and, strangely, less confident in their own competence.
It has been a frequent topic in coaching conversations. Engineers describe feeling deeply tired by the pace of change and worried about whether they will be able to keep up over the long arc of their careers.
The prevailing narrative says AI is making us dramatically more productive. Yet producing more work means reviewing more work, making more decisions, and moving across more technical terrain quickly. The volume of output has increased much faster than our ability to understand all of it.
If you have felt unsettled by this mismatch, you may be evaluating yourself against a standard of competence that no longer fits the nature of the work.
The old standard of competence is breaking
For a long time, engineers developed confidence by gradually expanding the boundaries of what they knew.
We learned to read and write code, became proficient in a language or stack, and built increasingly complex systems with help from tech leads. Over time, we accumulated enough experience to recognize patterns, anticipate failure modes, and debug problems that once would have confounded us.
Even before AI, that path was becoming harder to follow. Distributed systems and microservice architectures required engineers to understand a growing collection of services, infrastructure, dependencies, deployment systems, and organizational history. Few people could hold the entire system in their heads.
AI has widened the accessible surface area even further. An engineer can now make progress in a language they barely know, modify unfamiliar infrastructure, or enter a part of the software development lifecycle where they have little prior experience.
But the internal standard many of us carry has not caught up.
We may still believe that a genuinely competent engineer should deeply understand everything they produce. When AI enables us to move beyond the boundaries of our knowledge, the resulting discomfort can feel like evidence that we are becoming less capable or that everyone else has adapted more successfully.
This is one reason imposter syndrome can intensify: we are measuring ourselves against an expectation of mastery that the work itself has made increasingly impossible.
Comprehensive mastery is becoming an impossible standard.
Yet letting go of that expectation leaves us with a difficult question: What level of understanding do we need when AI helps us work beyond our existing expertise?
The gap between capability and responsibility
AI expands what we can attempt. Our understanding may not expand at the same speed, and our ability to verify the work may lag even further behind. Yet accountability for what happens remains with us.
Knowledge gaps are inevitable. In the age of AI, responsible engineering depends even more on how we respond to them.
The level of understanding required depends on what is at stake. Limited familiarity may be acceptable when AI helps update a low-risk internal script. The same approach becomes dangerous when a change affects authentication, data integrity, concurrency, critical business behavior, or infrastructure that the team does not know how to operate.
As AI expands the range of work available to us, competence includes deciding where incomplete understanding is tolerable, where deeper verification is required, and when to involve someone with greater expertise.
You do not need to know everything you can now attempt. But you do need to know where your understanding ends and how much risk that creates.
What competence requires now
Knowledge remains essential. It gives us facts, concepts, patterns, explanations, and accumulated understanding that help us interpret a problem. Deep technical knowledge shapes the questions we ask, the assumptions we challenge, and the errors we are capable of noticing.
As AI makes knowledge easier to access, three other capabilities become more consequential.
Discernment is the ability to read a situation accurately by recognizing what is relevant, trustworthy, missing, or easily overlooked. An AI-generated solution may be technically plausible while failing to account for an undocumented constraint, a downstream dependency, or the reason an unusual design decision exists.
Judgment is the ability to choose a course of action after reading the situation. It weighs evidence, risks, constraints, and tradeoffs so that you can decide what to verify, when to prototype, when to involve someone with deeper expertise, and when to choose a more reversible path.
Wisdom is the ability to know what is worth doing and toward what end. It considers people, consequences, uncertainty, ethics, and what will matter over time. A technically effective decision can still leave a system more fragile, impose an unreasonable burden on another team, or solve a problem that was never important enough to justify the cost.
Discernment reads the situation. Judgment decides what to do. Wisdom asks what is worth doing and toward what end.
These capabilities build on one another. Knowledge without discernment can produce a technically plausible solution that does not fit the actual system.
Discernment without judgment allows an engineer to recognize missing context or meaningful risk but leaves them unsure how to proceed.
Judgment without wisdom can produce a defensible decision that solves the immediate problem while creating longer-term costs for the system, the team, or the people affected by it.
AI can help us uncover risks, generate options, compare tradeoffs, and reason through possible decisions. It may not have access to undocumented organizational history, team dynamics, or the reasons behind earlier decisions, and it cannot assume responsibility for the consequences of the choice.
That responsibility should change how we use AI throughout the engineering process. Here are two examples.
De-risk the plan before you build
During planning, AI gives us an opportunity to investigate uncertainty much earlier. Prototypes, experiments, and explorations that were previously too expensive may now take a fraction of the time.
Before committing to a plan, identify the assumption with the greatest uncertainty or the highest consequence if it proves wrong. Test it while changing direction is still inexpensive.
AI can help us discover where the plan itself may be wrong before we invest deeply in executing it.
This is discernment and judgment in practice. Discernment identifies the relevant uncertainty. Judgment determines what evidence you need before proceeding.
Preserve understanding of the systems you own
When AI writes code for a service you are responsible for, read the code.
Trace the important control and data flows, and understand how errors are handled. Pay particular attention to changes involving security, data integrity, and concurrency. Review more deeply where the consequences of being wrong are higher and where your existing knowledge is weakest.
Ask yourself whether you could explain how the change works to another engineer without asking AI to reconstruct the explanation for you. If you cannot, keep investigating, reduce the scope of the change, or involve someone with deeper expertise before shipping it.
This, too, is discernment, judgment, and wisdom in practice. Discernment identifies where incomplete understanding creates meaningful risk. Judgment determines whether you understand enough to proceed or need to investigate further, reduce the scope, or seek help. Wisdom considers whether the speed gained today is worth leaving your team with a system it cannot confidently operate, debug, or evolve over time.
Reduce uncertainty before you build. Preserve understanding after you build.
A more mature relationship with not knowing
It’s important to accept that AI has made it possible for engineers to operate across a surface area that no individual can reasonably master.
Continuing to interpret every knowledge gap as evidence of inadequacy will likely worsen the imposter syndrome many engineers already feel.
The alternative requires a more honest relationship with what we do and do not know.
It also asks us to become more discerning about what fits the situation, thoughtful about risk, and accountable for the expanded capability we now possess.
I see this as one way AI is asking the engineering profession to grow up. Our competence will be reflected less in whether we understand everything we attempt and more in how responsibly we proceed when we do not.
[This is the first of a two-part exploration of how AI is reshaping engineering careers. In the next edition, I’ll explore what happens to career growth when familiar sources of guidance and support become less reliable, and what engineers can do to keep developing.]