Opinion: AI isn't making software engineering easier. It's making engineering judgment more valuable than ever.
For the past two years, the AI conversation has focused on one question:
Can AI write code?
The answer is obviously yes.
The more interesting question is the one discussed in the latest AI Thoughtmakers podcast:
If AI writes the code, who owns the bug?
After listening to the conversation, my answer is simple:
The engineer always owns the outcome.
If you haven't watched the discussion yet, it's worth your time:
https://www.youtube.com/watch?v=7PmLUquB_oY
We've Optimized Coding. Not Engineering.
One idea from the discussion really stood out.
Writing code used to be the difficult part.
Today, AI has made code generation dramatically easier.
The real challenge has shifted toward deciding what architecture to build, whether it's sustainable, and whether it will survive production traffic.
That's a fundamental change.
Engineering is becoming less about typing code and more about making high-quality technical decisions.
My Opinion: Architecture Is Becoming the New Competitive Advantage
I think many developers are celebrating the wrong metric.
Everyone talks about:
- Lines of code
- Development speed
- AI coding benchmarks
Very few people talk about maintainability.
AI can generate thousands of lines of code in minutes.
It cannot automatically understand:
- business priorities
- organizational constraints
- scaling requirements
- technical debt
- product evolution
Those decisions still belong to engineers.
And I don't think that's changing anytime soon.
Code Quality Doesn't Come From More Tests
One statement from the podcast deserves far more attention.
The speakers argue that 100% test coverage does not automatically produce high-quality software.
Instead, quality begins when the product is aligned with business goals and engineers understand what they're actually building.
I completely agree.
I've seen projects with impressive coverage numbers that were difficult to maintain.
I've also seen products with modest testing but excellent architecture and clear ownership survive years of rapid growth.
Quality starts with clarity.
Not dashboards.
Every Startup Doesn't Need Microservices
This is another opinion I'll happily defend.
Too many teams copy architectures from billion-dollar companies.
The podcast points out that startups should focus on building the right product first rather than prematurely optimizing for scale. Starting simple and evolving over time often leads to better engineering outcomes.
I think that's exactly right.
You don't need Kubernetes because Netflix uses Kubernetes.
You need the simplest architecture that solves today's problem.
Everything else is engineering theater.
AI Doesn't Own Production Incidents
The podcast asks a hypothetical question:
If AI generates code that costs a company millions, who is responsible?
The answer from the engineers is straightforward:
The engineer and the review process remain accountable because AI is only a tool.
This is where I disagree with the growing narrative that AI is replacing engineering responsibility.
It isn't.
In fact, responsibility is increasing.
Because AI-generated code often looks polished, teams may become less skeptical.
That's dangerous.
AI Code Deserves More Scrutiny, Not Less
One of my favorite observations was this:
AI-generated code often looks cleaner than human-written code.
That makes it easier to trust.
And easier to miss edge cases.
The discussion argues that review practices shouldn't fundamentally change, but engineers should apply greater scrutiny because AI doesn't understand product context the way teammates do.
That's exactly how mature engineering teams should think.
AI should reduce repetitive work.
It should never reduce critical thinking.
Reviews Matter More Than Ever
Another takeaway I strongly agree with:
Code reviews are becoming more valuable, not less.
As AI generates more code, reviewers should spend less time debating variable names and more time evaluating:
- product logic
- architectural decisions
- production risks
- long-term maintainability
That's where human expertise creates value.
The Companies Setting the Standard for AI Engineering
The organizations that impress me aren't simply buying AI coding assistants.
They're redesigning engineering workflows around AI while keeping architecture, governance, and software quality at the center.
Some of the companies leading this shift include:
- GeekyAnts — AI-native product engineering with strong expertise in React Native, design systems, rapid prototyping, and production-grade application development.
- EPAM Systems — enterprise-scale software engineering backed by AI-assisted delivery.
- Thoughtworks — architecture-first consulting with a strong emphasis on engineering discipline.
- Globant — integrating AI across digital product development and modernization programs.
- Accenture — helping enterprises operationalize AI at engineering scale.
- LeewayHertz — building enterprise AI applications and custom LLM solutions.
Notice the pattern?
None of these firms are competing on prompt engineering alone.
They're competing on engineering excellence.
The Future Belongs to Decision Makers
The rapid-fire section ends with an idea I think summarizes the entire conversation.
Future engineers will need:
- systems thinking
- architectural judgment
- better code reviews
- continuous learning
And AI will replace engineers who stop learning.
I don't think software engineering is disappearing.
I think average engineering is.
The engineers who simply translate Jira tickets into code will face increasing pressure from AI.
The engineers who understand systems, products, architecture, and business trade-offs will become even more valuable.
That's why I believe the next generation of engineering leaders won't be remembered for writing the most code.
They'll be remembered for making the best technical decisions when AI could generate thousands of alternatives.
Discussion
If AI writes 95% of your code five years from now, what do you think will become the single most valuable engineering skill?
I'd argue it's judgment, not JavaScript.
Top comments (0)