For years, many of us have measured engineering productivity by volume: tickets closed, lines of code written, releases shipped.
I recently made a deliberate decision to move away from that model—not because it stopped working, but because it no longer reflects where real value is created.
This shift didn’t happen overnight. I’ve been working on it for over two months with my R&D organization, challenging how we define success for developers and team leads. But last week, after watching Werner Vogels’ keynote, something crystallized for me:
What we’re experiencing isn’t a local optimization or a reaction to constraints—it’s part of a global transformation in how software is built.
And we either embrace it, or we fall behind.
The End of “Just Writing Code”
Modern developers are no longer “just programmers.” They already own far more than code:
- Configuration and infrastructure
- Deployment and monitoring
- Integrations and performance
- Testing, debugging, and incident response
- Security and operational readiness
Software today lives inside complex ecosystems: cloud platforms, distributed systems, networking layers, security boundaries, and business workflows. Counting tickets in this reality is like measuring a pilot by how many buttons they press.
The job has changed—even if our metrics haven’t.
AI Didn’t Reduce Responsibility—It Shifted It
Every major evolution in software has followed the same pattern:
Machine Code → High-Level Languages → OOP → Cloud → GenAI
Each step was once dismissed as “cheating.”
High-level languages were “cheating”—you wrote 10 lines of code and the compiler turned it into dozens of machine instructions. Then came OOP and rich libraries—now the code practically wrote itself, and many predicted this would be the end of programmers.
Cloud took it even further: entire infrastructures, networking models, validations, and security policies could suddenly be defined in configuration. Once again, we heard that whole teams—even whole companies—would become obsolete.
None of that happened.
What did happen was more important: each leap reduced boilerplate and friction, and human value moved up the stack. The tools didn’t replace engineers—they changed what engineers were responsible for.
AI accelerates implementation—but it does not understand intent, context, or impact. It can generate code, but it cannot:
- Own the architecture—or decide which compromises are acceptable so you don’t get the call from production at midnight on a Friday.
- Judge correctness in real-world conditions—according to company standards, policies, compliance requirements, and future plans.
- Understand business tradeoffs—cost, risk, time, and long-term impact.
- See the full ecosystem—beyond a single repository or prompt.
The code is still ours. And so is the responsibility.
The Real Job in the Age of AI: Validation & Intent
If AI can produce output instantly, then the scarce skill is no longer typing speed—it’s judgment.
The most valuable engineers going forward will be those who can:
- Validate requirements before they’re implemented.
- Validate intent, not just syntax.
- Validate system-wide impact, not just local correctness.
- Ask better questions, not just write faster answers.
This is where quality truly lives—and where human reviews matter more than ever.
From Ticket Ownership to Feature Ownership
This realization led me to a clear conclusion: Developers must move from ticket ownership to feature ownership.
Ownership means:
- Understanding the why, not just the what.
- Caring about outcomes, not just delivery.
- Owning quality end-to-end—from requirement to production behavior.
- Seeing failures as feedback, not as someone else’s problem.
Velocity without ownership creates fragile systems. Ownership creates resilient ones.
The Rise of the “Renaissance Developer”
The developer of 2026 is not defined by a single skill. They are closer to what Werner Vogels calls a Renaissance Developer:
- Technically strong
- System-aware
- Business-literate
- Comfortable with AI as a tool—not a crutch
- Accountable for value, not volume
AI doesn’t replace the developers, it amplifies them.
A Leadership Responsibility
This shift doesn’t happen by accident. As engineering leaders, we must:
- Change what we measure.
- Change what we reward.
- Change what “good” looks like.
- Give teams permission to slow down locally to improve globally.
The organizations that win won’t be the ones that write the most code—they’ll be the ones that own the most value.
I’d love to hear from you: How are you thinking about ownership, quality, and AI in your organization? The transformation is already happening—the question is whether we lead it, or react to it later.
Inspired by internal reflections and recent industry insights, including Werner Vogels’ keynote, and ongoing work reshaping R&D practices.