What Actually Happens When You Put AI Inside an Engineering Team

A few months ago, I tested AI coding tools the same way I test any new technology: I gave them a real task; something we would actually ship.

‍

At first, it looked promising. The code compiled. It even solved part of the problem. Then we tried to integrate it. That’s when things started to break. It misunderstood context, added hallucinated logic, and solved one thing while quietly breaking another. What should have taken one hour turned into three.

‍

At that point, the tool was a liability. This experience reflects a broader trend in the industry. Research from GitClear, which analyzed a massive dataset of 153 million changed lines of code across both major open-source projects and enterprise commercial repositories, found a disconcerting trend: code churn (code that is reverted or updated within two weeks) is projected to double in 2024 compared to its pre-AI baseline.

‍

That was just a few months ago. Today, I ran a similar test. Same approach, but the output was different. It handled context better and made fewer unnecessary assumptions. It actually saved time.

‍

The divide in engineering is no longer about whether the tools work, but how different roles adapt to them.

‍

The Four Responses to the AI Shift

When people talk about AI in engineering, they usually speak in general terms. In reality, the impact is highly fragmented. We are seeing a divergence in how different roles internalize these tools, creating a new team dynamic that leaders have to manage carefully.

‍

Junior developers are often the most vocal early adopters because AI provides them with instant leverage. They can suddenly build complex features, test architectural ideas, and generate boilerplate that previously required years of rote practice to master.

‍

However, this creates a hidden risk of learning debt. By skipping the manual struggle of building systems from scratch, juniors may fail to develop the deep intuition that comes from making and manually fixing painful mistakes.

‍

On the other side of the spectrum, non-technical stakeholders are seeing a massive reduction in the barrier to execution. For basic tasks like simple scripts, data visualizations, or internal prototypes, the outcome matters more than the elegance of the code.

‍

AI removes the need to hire for basic execution in these cases. While this empowers the business, it risks creating a "shadow IT" layer of AI-generated code that lacks long-term maintainability or security oversight.

‍

Just like fellow seniors, I see these tools as an extension of my thinking: a way to automate the syntax tax so I can focus on system design and edge cases. In fact, the bottleneck has always been problem-solving. However, this shift introduces review fatigue. Senior engineers are getting buried under what we call "dark code."

‍

This is the extra, messy code that AI agents make when they do not fully understand the goal of a project. As highlighted by research from Uplevel, seniors are finding that auditing AI-generated code is often more mentally taxing than writing it from scratch, as it requires hyper-vigilance against subtle, confident-looking bugs.

‍

To stop this tired feeling, we need to make sure AI agents create clear and simple code that is easy for a human to check. We have been testing ways to cut down on this messy dark code and I will share those tips in a future post.

‍

Finally, there is a fourth group: the Purists who built their professional identity around the mastery of code. For those who take pride in the craft of a perfectly optimized function, the shift to AI can feel like a devaluation of their life's work. Some adapt quickly, moving their craftsmanship to a higher level of abstraction, while others resist. This resistance usually stems from the fact that the tool challenges the very definition of what makes a developer valuable in a post-generative world.

This Is Not the First Time

If you’ve been in this industry long enough, this pattern feels familiar. We have a history of abstraction. There was a time when writing efficient assembler code was a skill few people had. Then higher-level languages came. Then frameworks.

‍

The industry expanded rather than collapsed during those shifts. According to Jevons Paradox, as a resource like code generation becomes more efficient to produce, the demand for that resource actually increases. We will likely build bigger, more complex systems rather than writing less code. The difference now is the sheer speed of the transition.

Where AI Actually Breaks Things

There is a segment of the market where the impact is immediate and disruptive: Commoditized Engineering. Developers working on repeatable problems, such as standard CRUD apps, basic dashboards, and simple integrations, are seeing their value proposition shift.

‍

AI excels at pattern matching. If you are building something that has been done thousands of times before, the tool can get you 90% of the way there in seconds. From a business perspective, generating a solution in minutes is a significant change in the cost-to-value equation.

Where AI Becomes a Force Multiplier

In our work, we deal with problems that are not standard: performance constraints, edge cases, and systems that don’t exist yet. In those situations, thinking remains the bottleneck.

‍

Translating a solution from your head into code can take hours or days of writing, testing, and fixing. AI changes that. You can describe an idea and see it implemented quickly. The role is changing:

• Less time writing: The syntax tax is disappearing.
• More time deciding: You can test multiple approaches in the time it used to take to build one.

The Uncomfortable Question About Juniors

Junior developers face a unique challenge. If the system is more capable than the user, how does the user maintain control? Relying on tools from day one might skip the struggle that builds intuition. This creates a gap where experienced engineers benefit immediately, but juniors need to find a different path to mastery.

‍

Reviewing code requires a deeper level of understanding than writing it. Without the ability to write the code manually, a developer's ability to validate an AI's output is fundamentally limited.

What I Would Do if I Started Today

If I had to start again in this environment, I would not focus on writing code faster. I would focus on building real things. I would move past tutorials and solve real solutions to real problems.

‍

At the same time, I would invest in understanding systems deeply. How they connect, how they fail, and how they scale. Understanding concepts like the CAP Theorem or distributed systems is now more valuable than memorizing syntax. Execution is becoming easier; understanding remains difficult.

The Bigger Picture

Layoffs and job replacement are frequent topics of discussion, but the truth is nuanced. Some current changes reflect corrections from previous hiring cycles or increased efficiency. Underneath that, there is real progress in capability.

‍

In the future, senior engineers will likely move into a role called a product owner. Instead of spending all day typing out code, they will work closely with managers to solve big business problems. Their job will be to plan how a feature should work and why it matters rather than just doing the manual work of writing it.

‍

For engineers who love the deep technical side of things, there is a second path called the hard problem-solving track. This role is all about working on very fast systems and difficult math problems like the work done at big tech companies.

‍

We see both paths in our own team today. Some of our engineers focus on the product while others like Norbert on our SDK team work on the hardest technical challenges. Both paths show that humans provide a special kind of value that AI agents just cannot match.

‍

If you’re leading an engineering team today, the question is how to integrate these tools without creating more problems than you solve. Used incorrectly, they introduce noise and false confidence. Used correctly, they remove friction and accelerate execution.

‍

That balance is the real work now, and most teams are still figuring it out.

‍

Sources 

• GitClear (2024): Coding on Copilot: 2024 Data Shows AI’s Downward Pressure on Code Quality. A study of 153 million lines of code documenting the rise of code churn and the decline of code reuse.
• Uplevel (2024): AI Coding Assistant Impact on Developer Productivity and Burnout. Research indicates that while AI speed increases, developer burnout remains high due to increased cognitive load during code review.
• Gartner (2024): Hype Cycle for Software Engineering. Analysis on the rapid adoption of AI assistants and the shift toward "AI-Augmented" development roles.
• Economics: The Jevons Paradox. An economic principle explaining why increased efficiency in a resource leads to an increase in its overall consumption.
• Computer Science: The CAP Theorem. A fundamental principle of distributed systems that remains a critical bottleneck for human-led architectural decision-making.

‍