Giving engineers access to AI is easy.
Improving what the team delivers takes more work.
I’ve seen organizations buy tools, encourage experimentation, and expect faster delivery, better quality, and eventually the same results with fewer people. There was plenty of activity: prototypes, new workflows, and people finding ways to use AI throughout the day. In the early days, people were trying to consume enough tokens to meet usage expectations.
That activity didn’t consistently turn into useful software reaching customers.
That’s because investment in AI adoption is moving faster than investment in the engineering skills needed to use it well. Generating code doesn’t eliminate the need to understand its function through exposure to object-oriented design patterns, SOLID principles, and system design, just to name a few. There are still many organizations that aren’t employing test-driven development (TDD), continuous integration and delivery (CI/CD), or incremental delivery. We don’t need to be experts in all of those things anymore, but we need to know SOMETHING about them. Making implementation faster helps, but a team needs to understand the rest of that work too.
Code is one part of delivery
An engineer rarely starts with a perfectly defined problem and finishes when the code compiles.
They need to resolve unclear requirements, understand what product and design are trying to accomplish, and fit a change into an existing system. They need to decide how much to build before getting customer feedback. Then there is review, testing, deployment, and supporting what happens afterward.
AI can help throughout that process. The engineer still needs to recognize which questions matter and whether the answers make sense.
That is where differences in experience become visible. Someone who understands how a system fits together can give an AI useful context, examine its proposal, and direct the next step. Someone missing that foundation may complete individual tasks faster while struggling to turn them into a working product.
The team can end up producing more code without resolving the problems that were slowing delivery in the first place.
Fundamentals give you something to reason from
When I talk about engineering fundamentals, I mean knowledge that helps someone make decisions about the system they are building.
At the system level, that includes understanding when a short-lived function makes sense, when a long-running service is more appropriate, and when work should move through a queue. It includes knowing what belongs in object storage, what a CDN does, and where rate limits or other protections are needed.
At the code level, it includes how responsibilities are separated, what should be hidden behind an interface, and which operations need to succeed or fail together.
An AI can explain these concepts and propose an implementation. Understanding them gives an engineer a basis for evaluating that proposal.
Consider a workflow that updates a database and calls an external service. The happy path may look straightforward. What happens if the database update succeeds and the external call fails? What happens when the request is retried? Could the same action happen twice?
An engineer needs to recognize those questions before accepting a solution. If they don’t understand the failure modes, a plausible implementation can look complete.
The same applies to testing. A team can ask AI to write tests, but someone needs to decide what those tests should establish. Defining expected behavior, checking failures, and knowing when a passing test leaves an important assumption unexamined all require engineering judgment.
AI makes those skills useful in more places. It doesn’t remove the need to develop them.
More generated code puts more weight on judgment
As AI handles more implementation, a larger share of an engineer’s contribution may come from deciding what to ask for and evaluating what comes back.
Does the proposed solution address the actual problem? Does it fit the existing system? Is a quick fix appropriate, or will it create work the team has to undo? Should this feature be built at all?
I’ve joked that AI could turn software engineers into QA analysts: the AI writes the code, and the engineer spends the day figuring out whether it works. That exaggerates the shift, but it points to a real responsibility. Someone has to challenge the assumptions in generated work and understand the consequences of accepting it.
If AI writes the code and the engineer spends the day testing it, are we resurrecting the QA department under the SWE job title?
— Matt Viteri (@mattviteri_) November 2, 2026
That review can go well beyond reading the code. A change may be internally consistent and still solve the wrong problem. It may pass its tests while relying on an assumption that fails in production. It may work today while adding an operational burden the team cannot support.
Judgment needs opportunities to develop
Engineering judgment develops through real work and feedback.
A code review helps when someone explains why a design is difficult to maintain. Investigating a failure helps an engineer connect an implementation choice to its consequences. Supporting a service gives them a reason to care about deployment, observability, and recovery. Working with experienced colleagues helps them understand tradeoffs they haven’t encountered themselves.
AI can support that learning. An engineer can ask for an explanation, explore alternatives, or work through an unfamiliar part of the stack. I think that is one of its most useful applications. It lowers the barrier to getting started and gives people a way to keep asking questions.
The team still needs to check understanding. Can the engineer explain why the approach fits? Can they identify where it might fail? Can they investigate when the result differs from what they expected?
I talk about this a little more in a separate post where I express some concern over the dwindling number of entry-level positions in tech. If companies reduce junior opportunities while expecting engineers to exercise more judgment over AI-generated work, they need to think carefully about how that judgment will develop.
The work available to an early-career engineer may change. They still need opportunities to take responsibility, receive feedback, and learn what happens after a change reaches production.
Learning plans need to cover the whole job
Training people to use AI tools is a reasonable investment. Teams need time to understand the tools, experiment with workflows, and find applications that help their work.
That training should sit alongside continued development in software engineering.
An engineer learning to build an AI workflow will benefit from evaluation techniques. They also need to understand how to define expected behavior and investigate a failed test. Someone using an agent to deploy a change needs to understand the deployment process, how to limit exposure, and how to recover if something goes wrong.
A team’s learning plan should reflect where its people are starting. Engineers have different levels of experience and are at different stages of adopting AI. Giving everyone the same tool and the same adoption target won’t address those differences.
Leaders need to make room for coaching, reviews that explain reasoning, and work that gradually expands someone’s responsibility. That takes capacity from experienced engineers, so it needs to be accounted for in delivery plans.
Look for better outcomes
When I evaluate an engineering organization, hearing that the team has adopted AI (everyone has) tells me something about its tools. I still want to understand the team’s capabilities.
Who can explain and challenge the assumptions in generated work? Does one person remain the only one who understands a critical system? Who is helping other engineers grow? Is there time for learning, and does that learning show up in how the team works?
I would assess the results through similar questions. Are useful changes reaching customers sooner? Is the team spending less time correcting recurring mistakes? How much effort goes into reviewing and repairing generated work? What is happening to reliability and the support burden? Can engineers take on more meaningful responsibility?
Those outcomes give leaders a better basis for judging their investment than usage alone.
AI can help an engineer work beyond their current experience, and it can make learning something unfamiliar much easier. Getting lasting value from that assistance requires people who can understand, evaluate, and take responsibility for the result.
Companies should invest in AI. They should also invest in the engineering fundamentals that allow their teams to turn it into quality software.