Alexandru Paraschiv – Leading Adobe Firefly Romania
Here’s what’s happening right now:
→ Armin Ronacher polled 5,000 developers: 44% now write less than 10% of their code manually.
→ Addy Osmani described the shift: engineers are moving from conductors (guiding one agent) to orchestrators (managing fleets working in parallel).
→ Harness is building infrastructure where AI agents observe failures, reason about root causes, and remediate – no human paged at 3 AM.
Boris Cherny, creator of Claude Code, put it: “Once the plan is good, the code is good.”
That framing is powerful – but incomplete. Because execution was never just typing. Execution is where you discover what the plan missed. Every engineer knows this: you don’t fully understand a problem until you’re knee-deep in solving it.
So the real shift isn’t that execution stopped mattering. It’s that the nature of execution changed. You’re no longer writing code – you’re reviewing it, directing it, catching what the agent assumed wrong. The reps are different now.
And most engineering orgs are running on metrics built for a different world.
When we measured velocity in story points, engineers gamed the system by making stories smaller. When we measured PRs merged, engineers split work into trivial commits. Now add agents to those same incentive systems: an engineer can generate infinite PRs, close infinite tickets, ship infinite story points – and the codebase gets worse with every one. We built our metrics for a world where output was hard. In a world where output is free, those same metrics reward the exact behavior that kills you.
If agents handle the typing, what separates a good engineer from a great one?
→ System thinking – can you decompose a problem so an agent can solve it, not just yourself?
→ Judgment – can you catch what AI-generated code got wrong? Sonar’s research shows only 48% of developers consistently review AI code before committing.
→ Taste – do you know what good looks like when you didn’t build it?
These aren’t new skills. Good engineering leaders have always hired for them. AI just made them the only skills that matter.
Here’s what worries me most, though. When agents ship fast, and the code looks right and the tests pass – you move on. Ship after ship after ship. And slowly, you understand less of your own codebase. I’ve caught myself doing it.
Some call it comprehension debt. Unlike tech debt, you can’t refactor your way out of it. And it’s invisible until the worst possible moment – when something breaks and nobody understands why.
That’s a leadership challenge.
How do you measure productivity when output is infinite but understanding isn’t?
How do you grow juniors when the hands-on reps that built your own intuition are absorbed by machines?
How do you lead a team where the bottleneck isn’t writing code – it’s understanding it?
These aren’t future problems. They’re Monday morning problems.
And here’s the tension I can’t resolve: the companies that move fast with AI will learn faster, even if they accumulate comprehension debt. The companies that insist on full understanding before shipping might simply fall behind. There may not be a clean answer here – just a trade-off that leaders need to make with eyes open.
But I’ll say this: the engineers and leaders who spend the time upfront – who insist on clarity, who ask the hard questions before the agent starts writing, who treat AI output as a draft and not a deliverable – they’re the ones building things that hold together.
The rest will ship fast and understand nothing. And for a while, it might even look like winning.
Want to leave a comment? Here’s Alex’s LinkedIn article: https://tinyurl.com/bdcwfpvk
