TLDR: Faster coding using AI simply moves the work elsewhere. Most problems surfacing around AI in engineering have familiar roots: weak specs, overloaded roadmaps, slow reviews, poor hand-offs, uneven ownership, and unfocused strategy.
AI adds another participant to that system and raises output, so weaknesses elsewhere get more expensive. Engineers spend less time writing changes and more time checking agent output; agents close tickets fast, then teams rewrite the results because the specs left hard questions open. If an agent produces three PRs in the time an engineer produced one, a review process that strained under one must now absorb three.
You can’t know whether AI improved anything until you measure the whole path from idea to production.
To see how technical leaders handle this in practice, I analysed twelve discussions from an international community of 12,500+ engineering and technology leaders, concentrated across North America, the UK, and Europe, spanning late May to mid-August 2026. The dataset holds 274 messages from 89 named participants. Around 58% came from AI-focused discussions; the rest covered prioritisation, incident response, delivery speed, work visibility, and executive responsibility. There’s a good spread of ideas: over 80% of contributors appeared in only one discussion, so the patterns aren’t one clique repeating itself.
I coded 82 themes across five areas: AI product design; AI engineering and measurement; delivery and operating process; people, capability, and accountability; and strategy and leadership. The sections below work through each finding, with anonymised practitioner comments where they highlight the point, plus practical guidance on how to bring AI into today’s engineering orgs.
AI product design
“Add AI” is backwards product thinking. Product teams report being asked to find AI features before anyone has identified the user problem. The default output is often a chatbot bolted beside the existing UI. Working the value ladder is a better solution: summarising information overload, surfacing anomalies users weren’t looking for, and supervised self-healing where AI moves from explaining problems to safely acting on them.
Every AI feature needs a falsifiable value hypothesis. Before you build, state what the feature makes a user faster at, more capable of, or better informed about, and how you’d know if it failed.
AI engineering and measurement
AI often moves cost instead of removing it. One engineering leader analysed his team’s git history and reported that AI “hasn’t made people more productive on my team; just rearranged what’s expensive.” Implementation accelerated while QA absorbed the difference, and bugs leaked through the models repeatedly. Measure end-to-end human effort from idea to production, not just generation time. A second practitioner added that “speeding up the easiest part isn’t the huge gain people want to believe.”
Task type predicts AI success. Delegation works for well-defined fixes, boilerplate, dependency conflicts, and common features; it fails for open-ended product work with unanswered questions. One other advantage: agents jump between small unrelated jobs cheaply, where your engineers pay heavily for context switching, so interrupt-heavy queues suit them well. Build a task taxonomy instead of assuming one adoption level across your org, and track human-assisted, human-steered, and unattended work as separate categories, because “used an assistant” says nothing about how much work the machine completed alone.
The newest model isn’t automatically the best economic choice. Just because you have access to Fable 5 doesn’t mean you should upgrade yet. Harness, context structure, tooling, latency, and feedback loops can count for as much as raw model capability, and one leader reported that a mid-tier model won on his team because “the faster feedback times combined with good tooling can often be more productive.” Evaluate the complete agent system, and optimise cost, latency, and success rate against human steering time, not benchmark scores.
Nobody has a control group. Everything changes at once, so measurement keeps failing. “Each engineer is frequently changing their models, context structure, harness, feedback loops,” said one engineering leader. Meanwhile, PMs feed AI-written specs directly into agents while review rules get renegotiated mid-experiment. Treat git metrics (churn, PR size, merge time) as diagnostics that trigger questions, never as performance judgements. Lock a few variables, log the rest, and favour longitudinal evidence over causal claims. “Code gen was never the bottleneck,”, said one member. “It’s specs on one end and build/test/deploy on the other.”
Workflow history is AI infrastructure. The one participant who could prove a gain ran an analytics programme with years of task data: work types, estimated versus delivered time, delay attribution, and vendor billing tied to hours, which made efficiency directly translatable into opex. Their result: “Double the impact, half the time, with a methodology raked over the coals by one of the smartest DS I know and trust.” What enabled it wasn’t the AI layer, but the constraint that no work started without documented, structured requirements. If you instrumented your workflow years ago, you can measure AI today. If you didn’t, you’re guessing.
Delivery and operating process
Requirement quality has become engineering infrastructure. The strongest single finding in the corpus is that ambiguous tickets produce agent steering, rewrites, and abandoned work, so specs now function as executable interfaces for humans and agents at once. An engineering leader who studied his team’s ticketing data found that “the PRs that often need to be scrapped or redone are the more open-ended, less well-defined exploratory tickets like new features with unanswered questions.” Well-bounded fixes and common patterns are better here. Grade specs before they reach an agent, and treat each spec as a hand-off contract with acceptance criteria.
Plans need to exist before generation begins. Technical leaders are adding pre-work checklists, code-owner conversations, and written plans that a senior approves before any agent writes code, because planning is much cheaper than PR review. One team lead said “we end up with less sloppy work because AI is being used with context, taste, and judgement.” A related practice commits the agent’s plan file into the PR beside the code, preserving intent across a stack of changes. Both moves relocate scrutiny to where a mistaken approach is still cheap to correct.
Review is the new constraint. Review now takes a larger share of delivery time, and some technical leaders now question the async PR queue itself. Options in circulation: pair programming for high-context or high-risk work, feature flags plus telemetry and fast rollback as a substitute for some pre-merge caution, and automated checks absorbing the mechanical share of review. There’s no single answer in the corpus, but the shared instruction is to decide deliberately which risks you control before merge, during rollout, and after deployment, instead of routing everything through a queue that predates agents.
Visibility of unfinished work is operational infrastructure. One discussion turned on an engineer who refused to push code until it reached a ready state, leaving a week of silence that senior leadership noticed. The room rejected commit-counting but defended visibility. As one engineering leader put it, “I’d phrase what you need in terms of outcomes instead of activities.” Another described a helpful alternative: “The team owns a ticket or piece of work, and a team member leads that ticket or piece of work,” meaning repo state, next steps, and blockers must survive any individual’s absence. Hidden work blocks your planning, hand-offs, and risk management. Week-long invisible branches also signal poor slicing, so use task size as a diagnostic.
Incident process turns into theatre unless you measure learning. Mandatory meetings and form-driven postmortems simply turn learning into compliance. Automate the mechanics instead (channel creation, participant routing, severity templates) so your people focus on diagnosis; tie severity to customer and financial impact instead of arbitrary labels; and map critical dependencies before the outage, not during it. The test of your incident process is whether the same class of failure recurs.
People, capability, and accountability
Comprehension debt is accumulating faster than tech debt. Your engineers can modify systems faster than they build durable mental models of them, and asking an agent questions creates a feeling of understanding without the knowledge sticking. Juniors can now generate code before they can judge it, so AI access needs the ability to validate output. A few suggestions included months of manual fundamentals before heavier AI use, pair programming with a senior, auto-maintained architecture artefacts (like adding an ARCHITECTURE.MD file to your repo), and having the model quiz the engineer after large changes. Decide which knowledge you can abstract away and which remains human-held.
You can’t delegate responsibility with generation. This was the bluntest consensus. When someone defends unsuitable work with “the model did it,” one engineer’s reply was “But Claude didn’t submit it, you did.” Keep your definition of done intact for generated output: review, verification, tests, docs, and a named owner, whether or not a model wrote the first draft.
“Slop” is an externalised-cost problem with asymmetric costs. One person generates output cheaply; your reviewers spend multiples of that time understanding and repairing it, and specific critique gets pasted back into the model, continuing the loop. The room’s answer: keep standards source-neutral and critique the content, not the tool, since “this is wrong” survives scrutiny that “this is AI slop” doesn’t in a pro-AI workplace. One reviewer’s calibration question: “how much of this is the LLM, and how much is you? So I can target my feedback appropriately.” Measure reviewer burden, and return low-quality work before its cost spreads.
Senior leverage is moving from correcting humans to configuring agents. Team leads are converting recurring review feedback into shared agent guidance: AGENT.md files, skills, and reusable rules that steer everyone’s tooling at once. One staff engineer realised that “my highest leverage is now teaching the robots instead of the humans.” Treat agent config as platform engineering, with owners and review, because it’s better to encode organisational corrections once than repeat individual corrections forever.
Psychological safety decides whether visibility norms work. Reluctance to show unfinished work often traces to environments where mistakes carried outsized consequences. One manager recalled a colleague “who came from a workplace where they were considered very… replaceable. Small mistakes, like bugs or ugly code, could lead to them getting fired,” and unlearning that took sustained effort. Early sharing only works when it’s safe to show unfinished work, and you help by distinguishing hard requirements from preferences and experiments.
Strategy, priorities, and leadership
Capacity problems dress up as process problems. Several discussions began with a team drowning and a leader reaching for a new ritual, tool, or cadence to fix it. Underneath, there was too much work for the people available; no process trick compensates for that indefinitely. One head of customer success in healthcare said: “We spend all of our time fighting fires and making quick fixes and there’s no time to consider edge cases or harden logic to ensure proper functionality.” Before you buy another productivity tool, map your WIP by stage, find where work’s stuck, and cut scope. With AI, an overload can look like a productivity problem when it’s a portfolio problem.
“AI-first” is too vague to manage. Execs are mandating AI adoption without defining what adoption means, and you can’t measure a slogan. Some of the pressure traces to fear that competitors will ship more, which produces activity instead of outcomes. If that mandate reaches you, translate it before it reaches your team: start from a blocked business outcome, ask whether AI removes the blocker, then define the use case, task, user, controls, and expected result. Your engineers shouldn’t inherit confusion.
Broken promises cost more than bugs. Your technical arguments lose to revenue pressure, so translate quality problems into commercial ones. Speaking about a churned account, one engineering leader concluded “we didn’t have a quality problem. We had a problem making promises that we could keep.” The customer tolerated defects, but not unreliable commitments. A CTO in the same discussion added that it’s “much much more productive to talk about things in terms of quality and avoid the phrase ‘slowing down.'” Track promise reliability alongside defect rates, and frame both as churn, lost revenue, and support load when you talk upward.
When everything is urgent, prioritisation has failed. Work becomes urgent because someone ignored it until the last moment, and many ‘hard’ deadlines began as arbitrary dates. Sort yours into three kinds—contractual, economic, and managerial—and reserve panic for the first two. Give stale work an explicit fate (promoted or killed) and make every new priority specify what it displaces. Fast, good, cheap: pick two (or reduce scope).
Final thoughts
Your team probably doesn’t need another coding assistant. It needs visibility into where AI creates leverage, where it relocates work downstream, and what has to change around it. So sort your own problems into three piles: what AI created, what it amplified, and what was already there. Then trace your chain from spec to customer outcome and ask where the human hours go.