Around nine months ago, something that was shifting around the industry reached my team. The major coding tools were undergoing mainstream adoption, the first truly capable models were hitting general availability, and leadership at our company made it official: AI was no longer something to watch from a distance. It was time to lean in.

What that actually meant, nobody could fully define yet. But the experiments started, and the results were hard to ignore.

I remember one of my first real moments with it. I was diagnosing a production issue, the kind that used to mean hours of pulling logs, cross-referencing symptoms, second-guessing syntax on commands I half-remembered. I gave the tooling access to the resources, described the symptoms, and watched it work through the problem with a logic that felt uncomfortably familiar. It wasn't just fast. It was inferring the next step the way I would, except without the detours, the syntax mistakes, the time spent looking things up. I could see, maybe for the first time, not how this technology would replace me, but how it would let me focus on the parts of the problem where I could actually produce value. The thinking. The judgment. The decisions that couldn't just be executed.

My team started having the same experience. Velocity went up. Throughput increased. Documentation, context-gathering, implementation cycles, all of it compressed. By every measure we had, adoption and its results were encouraging.

But then something started feeling off.

It was subtle at first. I noticed it in the language people were using. Engineers would describe their work differently.

I told the agent to do this. AI helped me build this.

It wasn't how you'd talk about pair programming with a teammate. There was a distance in it. A quiet disconnection from the output. The code was shipping, but the ownership felt diffuse, like the accountability had been distributed to something that couldn't actually hold it.

And that made me start asking harder questions. Not about the tools, the tools were clearly working. But about what we were measuring, what we were assuming was still intact, and whether the practices we'd built our engineering culture on were keeping pace with the velocity we were so proud of.

We were moving fast. But were we moving well?

That question is what this article is about. Because I think most engineering teams navigating AI adoption right now are doing what we did, picking up the tools quickly, seeing the gains immediately, and only later realizing that the mindset, the culture, and the practices needed to use them well are still catching up. And in that gap, quietly, some important things are getting lost.

Wisdom takes time, but the tools won't wait

For those unfamiliar with how engineering careers actually develop, let me walk you through something that I think is easy to overlook from the outside.

Becoming a well-rounded engineer is slow by nature. Not because engineers aren't smart or aren't working hard, but because the kind of expertise that makes someone genuinely capable of architecting complex systems for specific industries, whether that's finance, healthcare, messaging, banking, each with their own constraints and nuances, can only be built through accumulation. It starts before you write a single line of code. It happens in the process of trying to articulate a solution, mapping your ideas against what's actually buildable, watching the gap between theory and reality reveal itself through iteration. Then it continues through implementation, where technologies turn out to be incompatible, costs shift, configurations break assumptions, and what you sketched out gets reshaped by contact with the real world. And then there are the production incidents, the moments where you have to stop the bleeding, navigate risks you specifically tried to avoid when building the system, and find your way to stability through areas you've never been before.

All of that, the good decisions and the bad ones, the pressure, the failures you learned from and the wins you built on, that's what we mean when we talk about engineering wisdom. It travels with you. It informs how you read a problem, what you pay attention to, when you push back and when you trust the plan. It's not something you can acquire from a book. Like most professions, practice teaches you things that theory simply can't, or the theory was completely wrong and needed rethinking.

And now we are building machines trained on all of it.

That's the part that's hard to sit with. What took you years to earn, these tools can access almost immediately. They can move across languages, technologies, and domains with a fluency that is genuinely difficult not to read as expertise. When someone in a conversation demonstrates knowledge far beyond your own, you assume they're better at the craft. The same instinct applies here, and it's not entirely wrong, but it's not entirely right either. These tools aren't deriving solutions from lived experience. They're inferring from patterns at a scale and speed that human learning was never designed to match.

So the question becomes: how do you catch up with something built to move that fast? And more importantly, should catching up even be the goal?

The reference points that used to give engineering teams their orientation, their sense of what good looks like, what to trust, what to question, are becoming moving targets. And they're moving faster than our ability to recalibrate around them. That's not a failure of intelligence or effort. The engineers I work with are experienced, adaptable, and genuinely engaged with learning how to use these tools well. The gap isn't about capability. It's structural. Building solid fundamentals has always required time, and for the first time, time is the one thing the pace of this technology isn't giving us.

As a leader, that's what keeps me up at night. Not just how do I help my team move faster, but how do I guide them through a shift where some of the skills they've built are being transferred to a different system, and they find themselves managing that system rather than building from end to end. What does career growth look like in that world? What does it mean to develop as an engineer when the hard parts are increasingly handled for you?

Those aren't questions I have fully resolved. But I think they're the right ones to be asking.

When processes become fossils

The practices that engineering teams built around quality, ownership, and maintainability didn't appear out of nowhere. They evolved organically, as responses to real problems that teams had lived through. Pull requests exist because code written in isolation misses things, not because engineers aren't capable, but because when you've been looking at the same problem long enough, you stop seeing the details. Having another set of eyes isn't about opinion, it's about catching what proximity blinds you to. Documentation standards exist because as teams scale, the cost of rediscovering the same pitfalls, the same design decisions, the same reasoning behind a particular implementation, becomes unsustainable. Definition of done exists because without it, done means something different to everyone.

These weren't arbitrary rules. They were a living system, shaped by the accumulated experience of teams that learned what happens when they're absent.

Then AI changed the scale.

What used to take days or weeks can now arrive in hours. A team that was managing a handful of pull requests daily can suddenly be looking at dozens, sometimes hundreds. In my team's case, a review that used to take anywhere from fifteen minutes to half a day now has to compete with a volume that no human process was designed to absorb. Deployments that happened once or twice a week now happen multiple times a day. Test cycles that were built to validate changes at a certain cadence are now being asked to run continuously against a queue that never empties.

The processes didn't disappear. They got distorted.

Nobody made a deliberate decision to lower the bar. What happened was quieter than that. The momentum of the work simply outpaced the speed at which the process was designed to operate, and the standard became a checkbox. Reviews got glanced at rather than read. Documentation got generated rather than written. The right things appeared to be happening, but not in the right way. And when a process is distorted like that, the failure is silent. It doesn't announce itself. It creeps into the system slowly, invisibly, until one day you look around and realize that all of the engineering qualities you thought were intact have been quietly hollowed out.

That's when the accountability question gets serious. When code is arriving faster than it can be genuinely understood, who can explain why something was built a particular way? Who owns the full end to end design, especially when the design evolves during implementation and AI is making adjustments underneath you? Who is going to answer the 2am call with a clear and solid understanding of what's happening in the system?

It almost feels like being a mechanic who has spent their whole career on gas engines, and one day a car rolls into the shop and you don't realize until you pop the hood that everything underneath has changed. The vehicle looked familiar from the outside. But the internals are something else entirely. That's what it can feel like to work in a codebase where the implementation was delegated to AI, even when the design was completely yours.

The recalibration needed here isn't about slowing down. The speed is real, and the productivity gains that come with it are real. The failure is that the foundations were never rebuilt to match the new reality. Keeping the old checklist while moving ten times faster is not the same thing as having a process that works at scale. It just looks like one, until it doesn't.

This pressure isn't only felt at the leadership level. Individual engineers feel it too, the sense that their knowledge is going stale, that their best practices are being outpaced, that the standards they built their professional identity around are losing their shape. The question for engineering teams isn't whether to move fast. It's whether the foundation underneath the speed is strong enough to hold.

Artifacts of the past vs. foundations for the future

Let's step back and look at what the craft of software engineering was actually about, because I think this is where the most important distinction lives.

It was never about writing code. The code was always the medium. The real craft was identifying solutions to complex problems, translating them into a series of trade-offs and decisions that solved for the needs of the moment, while leaving enough room to accommodate the future without a complete rewrite. That's what separated a good engineer from a great one. Not how fast they typed or how many languages they knew, but how clearly they could think through a problem and how soundly they could encode that thinking into something that would outlast the moment it was built.

Think about a painter. The canvas, the brushes, the paint itself were never the point. Mixing colors and executing strokes were skills in service of something larger, which was conveying a message. Being able to use those tools to communicate something true and lasting is what made a great painter. Software engineering works the same way. The languages, the syntax, the patterns, the boilerplate, those were always tools in service of the actual work, which was building bridges between human needs and the systems that serve them.

So when we ask what AI can and can't absorb, the answer starts to come into focus. The instrumental skills, syntactic fluency, API familiarity, pattern recognition, boilerplate construction, those were always means to an end. They built intuition as a side effect, but they were never the point in themselves. Automating them doesn't hollow out the craft. It clears the path to what the craft was always really about.

What can't be automated is the engineering intuition underneath. The judgment about which trade-off is right for this moment. The instinct for where complexity is hiding in a system before it becomes a problem. The ability to read code not just for what it does but for what it was trying to do, and whether those two things are the same. That deeper understanding is why AI still needs very specific context from us. It can make educated guesses, but it is trained on existing data, existing codebases, existing solutions. It can recombine what has already been discovered. What it can't do is generate the spark that precedes discovery.

Nobody invented the wheel because they knew the wheel was the answer. They got there through experimentation, through dead ends, through the slow process of elimination that eventually revealed the most elegant solution. That moment of insight, the eureka that translates a signal into something genuinely new, is something that lives in human experience in a way that can't be reduced to a training set.

This matters enormously for how we think about developing engineers right now. The friction of hard problems was never the enemy. It was where the learning happened. Engineers grew by struggling, by hitting walls, by making decisions that didn't work out and understanding why. When AI absorbs that formative work before an engineer has done enough of it to build real intuition, you get engineers who are fast but underdeveloped. Capable with the tools, effective in familiar territory, but underprepared for the moments the tools can't handle and pressure is highest.

As leaders, we can't let skill development happen as a passive byproduct of using AI tools. We have to be deliberate about what engineers still need to struggle with and why. Not out of nostalgia for how things used to be done, but because depth under pressure is exactly what the new pace demands more of, not less. Someone who can maintain the right focus when velocity is high, who can make sound decisions when the stakes are real and the answers aren't obvious, that's who becomes an effective engineer as this transition evolves.

There is also a career identity question here that's worth naming honestly. For a long time, the craft and the professional identity of an engineer have been deeply connected. When the parts of the job that felt most like engineering get automated, it raises a real question about what the role means now. But this isn't the first time technology has forced that question. The Industrial Revolution automated work that had defined entire professions, and the people who thrived weren't the ones who resisted the change. They were the ones who understood that the tools had changed, but the underlying human judgment those tools were in service of had not. We may be living through something similar now, just at a different stage of technological history.

The engineers who will define this era won't be the ones who used AI the most. They'll be the ones who understood clearly what it couldn't do, and made sure they could still do it themselves.

Trust, stakes, and the new shape of judgment

Now that we understand how we got here, the question becomes how we move forward. And I think the answer starts with understanding how trust actually works, because almost everything we need to rebuild depends on calibrating it correctly.

In engineering, trust has always been proportional to what we call the blast radius. How much are we willing to put at risk given the decision we're making? We give junior engineers autonomy in low-stakes areas first, not only to protect the product, but to protect them. To make sure they're developing their skills and instincts in a space where mistakes are recoverable. You would never put a child in a situation where they could be seriously harmed before they've had the chance to build the abilities to navigate it. The same logic applies. As expertise and intuition grow, the scope of trust expands. Eventually you reach a place where bigger risks are acceptable, because the consequences are either well understood, well contained, or there's a reliable path back to stability when things go wrong.

The problem is that most teams haven't applied that same thinking to AI.

It's easy to understand why. AI displays many of the same surface attributes we associate with expertise. It's fluent, confident, fast, and broad. At first glance, it looks like it has earned the trust we'd give a senior engineer. So we extended that trust, uniformly, without mapping where the variance lives or what it costs when the tool gets it wrong in the moments that matter most.

What we didn't account for is the confidence problem. When a junior engineer is unsure, they usually show it. In the way they frame a question, the tone of a pull request description, the hesitation in how they present a design. Those signals exist because humans tend to externalize uncertainty in ways that others can read. AI doesn't work that way. It produces fluent, confident output regardless of whether it's standing on solid ground. There's no hesitation, no hedge, no signal that something might be worth questioning. That shifts the entire burden of skepticism onto the engineer reviewing the output. And for engineers whose skills are not where they need to be, that's a burden they can't fully carry yet.

Some cultures have a specific answer to this problem. In certain decision-making forums, there is a designated skeptic, someone whose explicit role is to ask the questions that must be justified, to push until the reasoning is airtight, to make sure that collective judgment converges on something defensible rather than something that just sounded right. That role is largely missing from AI-driven engineering flows. We assumed engineers were doing it themselves, and up to a point they were. But AI changed the equation in ways that made that assumption quietly incorrect.

Building that skeptical mindset into the team is part of the answer. But the other part is that judgment alone cannot be the policy. You can't measure it, you can't enforce it, and you can't build a culture around something that isn't defined. Leaders have a responsibility to give it structure. To identify the areas where human understanding is non-negotiable, where the ability to look at a system and explain what it does, why it was built that way, and how it behaves under pressure is a requirement, not an assumption. The code can be AI-generated. The accountability cannot be.

That means writing the assumptions down. Effective communicators in any field know that shared understanding requires making assumptions explicit and getting alignment on them. The same applies to AI-driven development flows. The automation can drive the execution, but the assumptions it's operating on need to be defined, visible, and treated as criteria that must be met, not defaults that are taken for granted.

Think about a map. A map doesn't tell you which route to take. It shows you the risks, the detours, the landmarks, the areas to avoid. It gives you the information you need to make a sound decision for the moment you're in. That's how guardrails for AI should work. Not as restrictions that slow teams down, but as a map that shows where the stakes are high, where scrutiny is non-negotiable, and where flexibility is earned because the consequences are small, recoverable, or well understood.

That principle shows up across every domain where trust matters. Raising a child. Managing a team. Designing a complex system. Flexibility works when failure is survivable. The same conscious approach needs to be applied here.

So the question I want to leave you with is this. Do you know what success looks like in your engineering team when it has to be concretely measured? What are the areas where you've defined clear outcomes, not just velocity, not just throughput, but actual evidence that the things being built are sound, understood, and owned? And are you building that clarity alongside your team, or are you assuming it's already there?

The adoption is done. The work is just starting.

Let me be direct about something. This article has not been an argument against AI. The tools are here, they are embedded, and the ground has shifted underneath us in ways that are permanent. The world that existed before this level of AI capability is not coming back, and it shouldn't. Fighting that reality is not where energy belongs. The wave is real, and the question was never whether to ride it, but how.

What this has been about is the intention that should have traveled alongside the tools. Whether we are building engineers who can lead AI with wisdom and experience, or ones who are becoming dependent on it without fully realizing the gaps that dependency is creating. That distinction is everything. And it doesn't resolve itself on its own.

These questions are not unique to engineering. The same reckoning is happening in medicine, in accounting, in research, in writing, in data analysis. Across every field where AI is becoming the main driver of impact, the same questions are surfacing. How is wisdom preserved when the tools evolve faster than experience can accumulate? Which processes need to be recalibrated rather than just outpaced? How do people develop the right judgment for the right situation? How do we build the maps that show where a tool is effective and where a human being is non-negotiable?

Engineering is just one lens into a much broader shift. This is one of those moments that steers the world into a genuinely new era, and we are living inside it while it is still being shaped.

I won't sit here and claim I have all the answers. I don't think anyone does yet. The challenges ahead haven't even been fully formulated. What we're seeing right now is a glimpse into the types of questions this era is going to keep asking. And figuring out how to ask the right ones, how to focus the lens in a way that generates real progress, is itself a form of evolution.

So I'll leave you with this. What kind of progress are you looking to build with your team, with your people, in the area where you work? And what does that progress look like when we, as humans, are playing the role of orchestrator and director rather than executor?

Because that shift, from doing to directing, from executing to judging, is not just the future of software engineering. It may be the defining challenge of our generation.