Engineering Productivity in the Age of AI

Andrea Caldera, Co-founder13 May 2026 · 9 min read

Artificial intelligence is transforming how software is built. Code can be generated in minutes, prototypes appear faster than ever, and development cycles continue to compress. These capabilities unlock enormous productivity potential, but they also introduce new challenges: maintaining quality, ensuring architectural integrity, and sustaining predictable delivery.

For engineering leaders, the central question is no longer whether AI will change software development. It already has. The real challenge is how to harness AI-driven productivity while preserving the engineering discipline that makes teams scalable and reliable.

The old framing of engineering productivity focused on the individual: the engineer who shipped the most code, solved the hardest problems, or moved the fastest in isolation. That model was always incomplete, but it became increasingly misleading as software systems grew more interconnected and delivery became more collaborative.

AI changes the unit of leverage. In an agentic workflow, productivity is not about how much code one person types. It is about how well a team directs intent, evaluates output, and turns agent-assisted implementation into reliable delivery. The effective engineer is no longer the one who does everything manually, but the one who can define the right problem, set constraints, and keep the system coherent as more of the work is automated.

That is where the ELEVATE Framework becomes useful. Its six pillars describe the full system that AI can speed up but not replace. Agentic engineering should strengthen those pillars, not obscure them: faster delivery still needs quality gates, more automation still needs resilience, and higher output still depends on collaboration and craft.

AI can generate code, suggest architectures, and automate decisions. But understanding cannot be delegated. Teams still need to know why a system works, what trade-offs were made, where complexity is accumulating, and which assumptions might fail in production.

In practice, this means pairing AI speed with engineering judgment: deliberate design decisions, clear ownership, and frequent review of generated changes against architectural intent. The teams that scale AI well are not the ones that accept every suggestion quickly; they are the ones that preserve shared understanding as implementation gets faster.

When teams outsource understanding to AI, the cost is rarely visible at first. Engineers lose intimacy with the code they ostensibly own. Architectural intent fades because no one is forced to articulate it. Junior engineers stop building the mental models that come from working through a problem manually, and senior engineers stop transferring tacit knowledge during review because the review surface is now a generated diff rather than a colleague's reasoning. In the worst cases, a team can find itself unable to maintain, debug, or safely evolve a feature that someone — or something — built six months ago.

AI-assisted development tools dramatically accelerate individual output. Engineers can generate code faster, explore alternative implementations instantly, reduce time on repetitive tasks, and prototype ideas in minutes rather than days. But individual acceleration does not automatically translate into organisational productivity. That gap between the speed at which a single engineer can produce code and the speed at which a team can actually deliver working software is the AI productivity paradox.13 Without strong engineering practices, faster code generation reliably leads to:

• Architectural drift as generated code bypasses established patterns
• Increased technical debt from accepted suggestions that solve the immediate problem but create long-term maintenance burden
• Reduced visibility into engineering work as more happens inside AI tools
• Lower predictability in delivery as individual speed masks systemic bottlenecks
• Quality regressions that surface later in the lifecycle

AI amplifies both good and bad engineering practices. Organisations that rely solely on speed gains risk accumulating complexity faster than they can manage it, and the 2025 to 2026 industry data is starting to bear this out at scale.

The 2025 DORA State of AI-Assisted Software Development report surveyed teams at a moment when AI adoption among software professionals had reached 90%, with a median of two hours per day spent working with AI tools. Its headline finding is that AI is not a free productivity boost: it acts as a multiplier of existing engineering conditions, strengthening high-performing teams and exposing the weaknesses of teams with fragmented processes. AI adoption is now correlated with higher throughput — a meaningful reversal from the 2024 report, which had found AI correlated with lower throughput and stability — but it continues to show a negative relationship with delivery stability. More change is shipping, and a larger share of it is breaking something downstream.

A large-scale empirical study published in early 2026, Debt Behind the AI Boom, mined 302,600 AI-authored commits from 6,299 GitHub repositories across five widely-used AI coding assistants. It identified 484,366 distinct issues, with code smells accounting for 89.3% of them, and found that 22.7% of those issues still survived in the latest version of the surveyed codebases — persistent technical debt, not transient noise. Separately, METR's July 2025 randomized controlled trial of experienced open-source developers found that allowing AI tooling actually increased task completion time by 19%, even though the same developers predicted, going in, that AI would save them roughly 20%. Perceived speed and real cycle time are not the same number.

What we tend to see when teams adopt AI without adjusting their engineering practices follows a recognisable pattern:

• PR volume goes up, PR size goes up with it. Authors produce more code per change because generation is cheap, but reviewers do not gain equivalent leverage. Review becomes the new bottleneck.
• Lead time for changes flattens or regresses. Time-to-first-commit drops, but time-from-PR-open-to-merge grows as reviewers work through larger, less familiar diffs.
• Change failure rate creeps up. Generated code that looks correct passes review more easily than it should, and defects surface later — often in production rather than in CI.
• Rework ratio increases. A growing share of commits touch code written in the previous one to two weeks, a signal that initial implementations are not converging on the right design.

The teams that avoid this trap are the ones that treat AI as a forcing function for the practices they already knew mattered: smaller changes, tighter review loops, clear ownership, and continuous measurement. The teams that struggle are the ones that measure only the inputs — lines generated, PRs opened, suggestions accepted — and miss the downstream cost.

The ELEVATE Framework provides a structured approach to improving engineering productivity and quality. Rather than focusing purely on output metrics, it emphasises systemic improvements across the engineering organisation, with a guide built around velocity and throughput, code quality, resilience, collaboration & flow, onboarding & enablement, and progression by craft.

In an AI-assisted environment, those pillars act as both guardrails and accelerators. Velocity and throughput help teams measure whether AI is actually improving time-to-market. Code quality and resilience ensure generated work does not create faster failures. Collaboration & flow keeps human review, shared context, and hand-offs healthy as more implementation is delegated to agents. Onboarding & enablement become more important because new engineers need clear patterns and tools to work effectively with AI. Progression by craft matters because seniority shifts from typing speed to judgment, system design, and the ability to guide agents well.

The framework helps teams align around practices that enable sustainable delivery, continuous improvement, cross-team visibility, and operational excellence, while still using AI to remove repetitive work.

For engineering leaders, it acts as both a diagnostic tool to understand how teams operate today, and a roadmap for evolving engineering maturity over time. The focus is on practical, measurable improvements rather than abstract ideals.

Frameworks provide guidance, but many organisations struggle with practical implementation. Leaders consistently ask the same questions:

• How do we measure whether teams are improving?
• How do we maintain visibility across multiple teams?
• How do we identify bottlenecks early?
• How do we ensure best practices are consistently applied, not just documented?

Without the right tooling, applying a framework across an organisation becomes manual and fragmented. Spreadsheets, surveys, and periodic reviews cannot keep pace with teams shipping multiple times per day, which is what led us to build Poggle.

Poggle integrates with the tools engineering teams already use to provide visibility, alignment, and actionable insights. Rather than adding another layer of process, it operationalises the ELEVATE Framework in a measurable, scalable way.

Visibility across teams. Engineering organisations often struggle with fragmented information across GitHub, project management tools, and internal workflows. Poggle consolidates these signals into a clear view of activity, progress, and delivery patterns.

Early bottleneck identification. High-performing teams continuously identify and remove obstacles that slow delivery. The platform surfaces patterns that reveal workflow inefficiencies, overloaded teams, slow feedback loops, and delivery risks before they impact outcomes.

Reinforcing engineering practices. Frameworks like ELEVATE emphasise iterative delivery, transparency, and measurable improvement. Making those practices visible and trackable is what lets teams see where they are strong and where they are drifting.

Data-driven leadership. Engineering leaders need to balance developer productivity, delivery predictability, quality and reliability, and organisational scalability. The right data layer is what makes those decisions informed rather than anecdotal.

AI is not replacing engineering discipline; it is making the absence of discipline visible. Frameworks like ELEVATE provide the principles. Platforms like Poggle make those principles measurable. The opportunity for engineering leaders is to build systems that let their teams move fast while still building software the right way — and to scale productivity without losing control of complexity.

If there is one thing engineering leaders should do this week to prepare their teams for agentic development, it is this: pick a small set of metrics that reflects end-to-end delivery health (e.g. cycle time, change failure rate, or rework ratio) and establish their current baseline before AI adoption deepens further. You cannot manage what you have not measured, and the teams that will pull ahead over the next twelve months are not the ones with the most AI tooling. They are the ones who know, with evidence rather than intuition, whether that tooling is making their system better or just faster at producing work that someone else will have to fix.

Agentic development rewards engineering organisations that already know themselves. The work of becoming that kind of organisation starts now.

Andrea CalderaCo-founder at Poggle