AI is changing software development. That isn't speculation, and it isn't something that we should fear or resist. However, we need to learn, embrace, and work with organizations that understand exactly what this advancement enables.
For years, I've talked about the difference between someone doing the same thing every year for 10 years and someone with only 5 years of experience, but who learned something new every year. I'm always a fan of the person growing rather than the person staying. AI is going to accelerate this gap and make the learning/adapting/morphing process that much more critical.
I use AI regularly. I've used AI to help research items, fix bugs, write code, write requirements, plan releases, and develop entire solutions for my clients. I've used AI to reduce repetition in my day-to-day and improve standardization and quality within existing codebases. Used well, it can make a capable developer dramatically more effective.
But there is a dangerous leap between using AI to increase a team's capabilities and assuming AI makes the team unnecessary.
I have recently watched that leap play out multiple times: enthusiasm for AI turning into blind faith, with pressure to replace large portions of experienced teams before establishing meaningful checks, balances, ownership, or quality controls.
That is not an AI strategy. It is a cost-cutting strategy wearing an AI label.
The distinction matters because AI can generate an extraordinary amount of output. What it cannot do is make an organization immune to the consequences of that output.
Output Is Not The Same as an Outcome
AI makes it trivial to produce more code, documentation, tests, plans, and analysis. That increased production can create the appearance of equally dramatic productivity gains.
However, lines of code are not business value. Neither are completed prompts, generated pull requests, or the number of tasks an agent marked as finished. This is the same for human contributors as well.
Software creates value when it solves the right problem, works correctly, remains secure, performs under real-world conditions, can be supported, and continues to evolve with the business.
Achieving those outcomes requires context and judgment, but not blind trust.
The 2025 DORA state of AI-assisted Software Development report describes AI primarily as an amplifier; it magnified an organization's existing strengths and weaknesses. Strong platforms, clear workflows, reliable testing, and fast feedback can make AI enormously valuable. Weak or nonexistent processes, fragmented knowledge, and fragile infrastructure can enable a team to create technical debt at speeds you could only imagine.
That is the central issue. AI does not automatically fix the system around software delivery. It accelerates whatever system already exists.
The Rise of AI Slop
The term "AI Slop" is often used for low-value content produced rapidly and at scale. In software, slop may look more convincing.
It compiles. The formatting is clean. The naming looks reasonable. Tests may even pass.
Yet the implementation may duplicate an existing capability, ignore an architectural boundary, mishandle an edge case, introduce a subtle security issue, or solve the request without solving the business problem.
The risk is not simply that AI occasionally produces bad code. Humans do that as well.
The risk is the combination of volume, confidence, and reduced understanding. AI can produce questionable work far faster than people can meaningfully inspect it. When organizations optimize for generation while treating review as overhead, the review queue grows, changes get larger, and superficially credible work moves into production without anyone fully understanding it. Compare the size of an AI contribution to review and the way that you managed your own teams, would you accept something with 1,000 modified files from a developer? Most likely not, but with AI people are!
Addy Osmani describes this as "comprehension debt": a codebase can appear healthy while the team's understanding of it quietly erodes. Tests and automation remain essential, but they cannot validate requirements nobody expressed, assumptions nobody recognized, or consequences nobody considered.
Technical debt is hard enough when someone remembers why a decision was made, or maybe even left a little nugget in a code comment as to why something silly was done. Comprehension debt is worse: the system continues growing while fewer people can explain why it behaves as it does.
This could get even worse as AI progresses, since AI is now writing human-readable code with variable names, etc., that make sense. In the future, that could change without controls, making comprehension almost impossible.
Software Engineers Still Matter, but the Role is Changing
Saying that software engineers remain essential is not an argument for preserving every old process or pretending the technology is less capable than it is.
The role must change.
When AI can implement a well-scoped request quickly, the value of an engineer moves further toward:
- Understanding the business and identifying the right problem
- Designing systems instead of merely completing isolated tasks
- Supplying the context, constraints, and acceptance criteria AI lacks. (Skills, guidance, etc)
- Evaluating tradeoffs across security, performance, cost, accessibility, and maintainability.
- Reviewing generated work for intent, not only syntax
- Testing the behavior nobody remembered to request
- Monitoring production and connecting technical feedback to customer impact
- Teaching others how to use AI without surrendering their own understanding.
The future engineer may type fewer lines manually. However, it makes the engineer's experience the control surface through which increasingly powerful tools are directed. Retaining knowledge of concepts such as the above becomes critical.
Do Not Remove the People Who Know What "Good" Looks Like
One of the most dangerous AI adoption patterns I've witnessed is removing experienced people first and expecting the tool to preserve their institutional knowledge afterward.
Documentation can capture facts. A model can search repositories, tickets, and internal knowledge bases. It can use MCPs and tooling to query your environments, logs, and details. However, none of these automatically capture every exception, customer expectation, regulatory concern, architecture compromise, or lesson learned during an incident.
Experienced team members often carry the organization's definition of quality:
- They know which "temporary" integration is business-critical.
- They recognize when a technically valid change conflicts with a customer's workflow.
- They remember why an obvious-looking simplification failed three years ago.
- They know when a passing test suite is not good enough evidence for that customer-reported issue.
- They can distinguish a plausible answer from the right answer.
If an organization removes that judgment, it also removes its ability to evaluate the AI intended to replace it.
You cannot outsource judgment to a system whose output still requires judgment to trust.
What to Do: Elevate the Team Instead of Hollowing it Out
Ok, so where do we go from here? A responsible AI strategy should make the team more capable, not merely smaller. That means treating adoption as an organizational capability, not a software-license rollout.
1. Define where AI may act - and who remains accountable
Separate low-risk assistance from high-impact decisions. Generating a test-data builder is not the same as changing authorization logic, billing rules, patient data workflows, or production infrastructure.
AI may do the work, but a named person must remain accountable for the result and understand what was done.
2. Require human review based on risk
Not every change requires the same ceremony. Establish review levels based on data sensitivity, security exposure, financial impact, user reach, reversibility, and architectural significance.
Human review should not be a ceremonial approval of an oversized generated diff. Keep changes small enough that a reviewer can actually understand them, review them, and give a true review.
3. Strengthen automated controls
Use compilation, tests, static analysis, dependency scanning, security checks, performance benchmarks, accessibility validation, and deployment safeguards aggressively. AI can also help create and operate these controls, or you may need to acquire additional tooling/licensing.
But remember: automation is evidence, not absolution. A green pipeline proves only what the pipeline was designed to check.
4. Preserve intent with the implementation
Require AI-generated changes to explain the problem, approach, alternatives considered, assumptions, risks, and validation performed. The goal is not more AI-generated prose. The goal is to give reviewers enough context to reconstruct why the change should exist.
It also serves as documentation for future reviewers, and even future AI changes, to reflect on the history.
5. Train everyone, not only the enthusiasts
Terms more than prompt tips. They need training in context management, decomposition, verification, secure usage, privacy, model limitations, and when to stop using the tool.
Junior developers still need opportunities to build fundamental skills. Senior developers need to develop stronger orchestration and review practices. Leaders need to understand that adoption metrics are not outcome metrics.
This depends on task types, models selected, and other factors. Comparing usage metrics between team members can be a dangerous and incomplete story.
6. Measure what reaches the customer
When hunting for metrics, focus on the customer. Measure lead time, change failure rate, escaped defects, security findings, operational incidents, rework, support demand, and customer outcomes. Compare the entire delivery system, not mearly how quickly code was initially produced or the date that it was delivered.
The more output AI creates, the more important these quality signals become. They can be the modern-day canary in the coal mine, warning of changes in direction.
7. Create fast feedback and a path to stop
Introduce AI in bounded areas, observe the results, and expand based on evidence. Teams must be able to report poor outcomes without being labeled resistant to change.
A strategy that cannot tolerate negative feedback is not experimentation. It is predetermined advocacy.
Be sure to also include feedback cycles to revisit as AI continues to progress; what failed 3 months ago may work well today.
AI Can Review AI but Cannot Own the Consequences
AI-assisted review is valuable. It can find common defects, examine test coverage, flag inconsistencies, and give human reviewers a useful first pass. It can even help balance AI costs by using different skill types for implementation vs. review. I believe these tools should be a part of any modern delivery pipeline, for AI- or non-AI-created content.
But using a second AI system to review the first does not eliminate the need for ownership.
When something fails in production, a customer is harmed, or sensitive data is exposed, "the agent approved it" will not be an acceptable explanation to those asking.
Accountability remains human and organizational, whether leaders acknowledge it before or after the incident.
The Goal is Leverage, Not Replacement
I am optimistic about AI. It has substantially improved my productivity, and I expect its capabilities to continue improving. It's role within development to continue to expand, and the work of software teams to change significantly.
This is exactly why organizations need thoughtful adoption now.
The companies that benefit most will not be the ones that replace people the fastest. They will be the ones that deliberately combine machine speed with human context, experience, creativity, empathy, and accountability.
They will use AI to remove drudgery while giving people room to solve harder problems. They will train their teams rather than hollow them out. They will increase delivery speed without pretending that generated volume equals customer value. And they will strengthen quality controls as their ability to produce change accelerates.
AI should challenge every team to evolve.
It should not give leadership permission to stop thinking.
What has your experience been with AI, AI Adoption, or corporate expectations to date?