Why Companies Can't Get Agentic AI Off the Ground: It's Not a Technology Problem — It's Four Organizational Walls

Over the past year, I've put agentic AI into a real development workflow, and I gave a talk on the topic at COSCUP. Seen from the tech community, agentic AI looks like the next productivity revolution. Seen from inside a company, most rollouts stall — and where they stall almost never has anything to do with the technology.

What actually kills a proposal to "let an AI agent take over the development of some module" is a handful of very human things: management feels it can't be controlled, no one knows who's responsible when something breaks, and colleagues fear being replaced. And even once it does ship, there's one more wall that fewer people talk about but that sits closest to the engineering floor — an agent dismantles a person's role and quietly relocates responsibility to code review, a place no one prepared for. I've watched all of this happen firsthand, and as it turns out, academia has already written it all up.

Wall #1: Management Feels It "Can't Be Controlled"

When you propose letting an agent autonomously take over a stretch of development work, a manager's first reaction usually isn't "how accurate is it?" — it's "how do I control this thing?"

That's not conservatism; it's a reasonable instinct. When traditional code breaks, I have logs, stack traces, and tests to localize the problem. But an agent's reasoning process is a black box — when it makes a wrong decision, you often can't say which step broke. A system that can't be observed and can't be debugged is, for anyone accountable for outcomes, a system you don't dare put into a production flow.

This is precisely one of the core barriers the research identifies. A 2026 interview study of software engineering practitioners (16 interviewees across 12 companies) [1] found these companies stuck at a "capability-deployment verification gap": they can build experimental higher-level AI capabilities but can't move them into production because adequate output verification is missing, leaving humans as the only trusted check. Four recurring barriers shape this gap: LLM context-window limits, underperformance on proprietary languages and protocols, non-determinism incompatible with qualification standards, and data-confidentiality concerns. In other words, management's hesitation isn't emotional; it's a normal risk response to a system whose behavior can't be predicted and whose output can't be verified. A separate study spanning engineering and manufacturing (30+ interviews) [10] adds that adoption is constrained less by model capability than by fragmented data, stringent security and regulatory requirements, and legacy toolchains without API access — governance structures that haven't caught up with agentic capabilities.

Wall #2: When Something Breaks, No One Knows Who's Responsible

This is the most lethal of the walls — industry and governance discussions have even given it a fixed name: the accountability gap. IBM uses exactly that framing [13], noting enterprises often lack the ability to monitor agent behavior, review automated decisions, and attribute responsibility when the system causes harm.

An agent can be deployed, monitored, even audited, yet none of that answers the most basic question: when it does something wrong and causes a loss, who's responsible? When responsibility is implicit rather than explicitly assigned to a person, governance fails. Discussions around the NIST AI Risk Management Framework therefore argue [14] that before an agent is allowed to act, a named business and technical owner must be assigned.

Industry framing puts it even more bluntly [15]: AI agents lack the legal accountability, moral responsibility, and reputational incentives that ordinary employees inherently carry, so the consequences don't naturally land on anyone — governance has to actively fill that gap.

Economics, as it happens, gave this dilemma a precise name long ago — and it's a perfect pun: the principal-agent problem. The theory goes: you (the principal) delegate work to an agent, but you face two built-in obstacles — you can't fully observe what it actually did (information asymmetry), and its goals may not align with yours. Economics' classic fix is the incentive contract: use bonuses, performance reviews, and reputation to tie the agent's interests to yours, so that "acting in its own interest" also means getting your work right.

Here's the catch. An AI agent is, literally, an agent — but it knocks out both pillars of that mechanism at once. Its reasoning is a black box, so you can't observe it (that's Wall #1); it has no interests of its own, no performance review, no reputation, so you can't bind it with incentives. So management's inarticulate unease has a textbook name: you've hired an agent you can neither monitor nor contract with. This isn't a new problem — it's a classic one in economics, pushed to its extreme by AI. And "assigning a named owner" is, at bottom, tethering an agent that can't be incentivized back onto a person who can — grounding that broken contract mechanism through a human.

My own take: people are willing to answer for their own judgment because they can't escape it — they'll be reviewed, it'll affect their performance rating, it'll have career consequences. An agent has none of that. So when a process shifts from "this engineer is responsible" to "this agent is responsible," responsibility isn't transferred — it evaporates. That's what managers are truly afraid of.

And it gets worse: even if you want to assign an owner, you find responsibility isn't a point — it's a chain. The person who wrote the agent, the person who reviewed its output, the person who hit merge, the person who configured the automated checks — every link touched that code. When something breaks, each of them can reasonably say "it wasn't only me." Applied ethics has a long-standing name for this — the "problem of many hands": when an outcome is brought about by many people together, no single individual can be cleanly held to account for it.

Let me head off a common objection here: why not just have another agent review this agent's output? Indeed, in real-world loop implementations the "find the error" step (verification) is increasingly handed to a second agent acting as reviewer. But that doesn't solve the accountability problem — it demonstrates it more clearly. Because even in those highly automated setups, the one who hits merge is still a human. In other words: an agent can automate "finding the error," but not "answering for the release." Verification is the causal side, and it can be outsourced layer by layer to agents; accountability is the answering-for-it side, and it doesn't disappear — it just gets pushed onto whoever decides whether to trust that layer of agent review. Stack as many agent reviewers as you like; the accountability anchor doesn't vanish, it moves up one notch, and still comes to rest on a person.

I think you have to be honest about this: there's no clean right answer, and anyone who says "it should just be person X" is oversimplifying. But it can be decomposed. The key is to separate two things that get conflated: causal responsibility (whose lapse produced the bug) — usually multi-causal, established after the fact — and accountability (who answers for it) — which the system assigns in advance, and shouldn't be argued about only after something breaks. Most organizational pain comes from thinking they're looking for the first (whose fault) when what they actually lack is the second (who's accountable) — and the second never had to equal the person who erred. Like aviation safety: the captain is accountable for the whole aircraft, which doesn't mean they tightened every screw.

The pragmatic move isn't to elect "the one person responsible" — it's to make each link accountable for its own decision: whoever designs the agent and its automated checks owns the capability boundary (what the agent is authorized to do, what the checks cover, whether that's reasonable); whoever reviews owns that particular judgment (given the information they had, should this change pass); whoever hits merge owns the release decision — the final gate. That's fairer than anointing a single super-owner, and far more auditable. Which is exactly why "merge authority exclusive to humans + immutable audit logs" matters so much: rather than argue about fault after the fact, make every decision leave a named trail beforehand. When something breaks, you don't argue — you read the log and trace each layer back.

Worth adding: a plane has a captain, but an agent pipeline has none by default — it's missing exactly that role that's accountable for the release as a whole. So merge authority isn't something that pre-exists and we assign; it's a captain we deliberately manufacture. That's also why "let the agent auto-merge" is so dangerous in accountability terms: it's a plane with no captain. Incidentally, the hardest link to trace is "the check nobody set up" — an absence doesn't throw an error, so you may never notice it's missing; the fix is the same layering: make required checks org-level enforced with any bypass leaving a named trail, turning "there's no check here" from an ownerless vacuum into a decision with someone's name on it.

Wall #3: Colleagues Fear Being Replaced

After the technical conversation and the governance conversation, this last wall is the quietest — and the hardest to take down.

When you ask a team to "use AI to take on part of the work," you think you're talking about efficiency. But what a frontline engineer may hear is a signal that the organization is preparing to replace this role. That feeling turns into silent resistance — nominal compliance, but in practice they route around it, treat it as a showpiece, and adoption never climbs.

There's a large body of empirical work on this in organizational behavior. The most-cited framework, STARA awareness [2], found that the more aware employees are of "smart technology, artificial intelligence, robotics, and algorithms," the lower their organizational commitment and career satisfaction, and the higher their turnover intentions. And a multilevel systematic review (Bankins et al., 2024) [3] notes that employees who fear AI worry not just about their jobs but about damage to their skills and careers, which drives down engagement and commitment and raises resistance and turnover — the threat is often less about unemployment than about a professional identity under threat. AI disrupts not just tasks, but the psychological contract that gives the work meaning.

And there's an ironic mechanism playing out daily here: when you "ask" a senior engineer to train or calibrate the very agent meant to take over their work, you're asking them to hand-accelerate their own marginalization. They know it, so the resistance shows up in the hardest-to-detect form — not refusal, but "compliance without investment": training data one layer too shallow, agent errors quietly not reported, the most critical tacit knowledge kept in their head and never written into a skill. What you see is adoption stalling; what's actually happening is that the very expert judgment most worth digitizing is being silently withheld.

For a profession with as strong an identity as engineering, this gets amplified. What you're touching isn't their working hours — it's the thing that makes them who they are. That's why Wall #3 can't be forced down with "communication" or a raise — it requires letting the engineer win a new position in the transition, not just be soothed. Which connects straight to the solutions later: turning them from "the person the agent replaces" into "the person who defines the agent's boundaries."

But here's something managers easily misjudge: employees aren't a monolith of "collective resistance." Teams have always split into factions — this isn't new. Rogers' diffusion of innovations theory sorted adopters back in 1962 into innovators, early adopters, early majority, late majority, and laggards [18]. A recent empirical study of developers using AI tools goes further [19], clustering engineers into three groups — Enthusiasts, Pragmatists, and Cautious — that differ markedly in usage breadth, perceived productivity and quality, and future adoption intent. In other words, your team already contains both reformers and conservatives, and the agent won't flatten that fault line — it will surface it, and may deepen it.

For leadership, that's a lever, not a headache. The real mistake is spending all your energy "soothing the conservatives"; the more effective move is to identify and empower the reformers first — they're often the team's opinion leaders, and peer-to-peer, lateral diffusion from them is far more persuasive than top-down mandates from a manager. Pragmatists will follow once they see proof of success and organizational support; the cautious need more time and reassurance. Your job isn't to get everyone on board the same day — it's to let the reformers run first and blaze the trail for the rest to see.

Wall #4: When the Agent Dismantles Your Role, Who's Approving That PR?

The first three walls are about "whether to adopt." But once it's actually live, there's a finer and less-discussed wall: an agent doesn't cleanly replace a person — it takes a role apart and reassembles it — and that reassembly quietly moves responsibility to a spot no one was ready for.

Research describes this more precisely than I'd expected. One line of work [4] argues that reducing AI's impact to "replace vs. augment" isn't enough; what actually happens is task chaining: on one hand, AI pulls previously manual steps "under the hood" of a single task, narrowing the span of activity a human directly handles and shifting responsibility within a role; on the other, it lowers the cost of chaining steps across a job boundary, making it rational to redraw that boundary and reassign activities between roles. A separate line [5] decomposes a role into execution, search, coordination, judgment, and accountability, arguing agents take the front end (execution, search, drafting) while humans should retain context, judgment, and accountability. Both point to the same thing: an engineer's job gets split, the agent takes the first few pieces, but "accountability" doesn't disappear with them — it just gets pushed downstream.

And where does it get pushed to? Code review.

This is my deepest takeaway from the past year, and the research happens to back it up. When an agent generates code at volume, the bottleneck shifts from writing code to reviewing AI-generated code — and every AI suggestion has to be read with suspicion until proven correct. Studies call this the oversight burden [8] and note it's the most underestimated hidden cost of adopting AI in software engineering, sometimes consuming more effort than it saves.

More critically, where responsibility lands. A survey study on the future of code review (100 developers across 5 companies) [6] found developers broadly expect code review not to disappear — they anticipate similar or greater effort and a broader range of artifacts under review, and nearly all expect LLMs to become active participants in the process. Building on that trajectory, a paper proposing an agentic code review architecture (Kamalı et al., 2026) [7] envisions a future in which reviewers shift from manual inspectors into supervisory operators of agents. Put the two together and the direction is clear: review doesn't get replaced by the agent — it gets pushed up a level, where a human no longer reads every line but supervises the agents that do.

To put it plainly for leadership: when a module the agent wrote breaks, responsibility doesn't stop at the agent — it slides all the way down and stops at the reviewer who hit approve. That means two things. First, code review is upgraded from a hygiene habit into the accountability anchor of the entire pipeline — it's more important after agents ship, not less. Second, if a company hasn't thought this through, it's effectively letting one engineer silently bear the full consequences of an AI output they may not even be equipped to fully review. That's unfair to the reviewer, and an undefended risk to the company.

This isn't just theory. Stripe has published a representative case [17]: its internal autonomous coding agent (codenamed Minions) produces over 1,300 PRs a week containing zero human-written code — yet every one is still reviewed by a human before it merges. People haven't left the process; their seat changed, from writing code to reviewing it. More telling still, a counterintuitive point runs through the case: what makes it scale has almost nothing to do with model power, and everything to do with the developer infrastructure Stripe built years earlier for humans — sandboxed devboxes, comprehensive test suites, CI and deterministic gates. In their engineers' words, if your dev environment, test infrastructure, and feedback loops are solid, agents benefit from them; if they're not, no model will save you. The lesson matters especially for leadership — for loop-based work, one solid verification gate matters more than raw model power. In other words, what decides whether this scales isn't how smart the AI is, but how well you've designed your accountability gates.

There's another economic mechanism hiding here that managers must grasp: moral hazard. It describes what happens when someone doesn't bear the consequences of their own actions — they quietly take on too much risk, or slack off on diligence. Auto-merging agent output, or letting review become a rubber stamp, is a textbook breeding ground for it: when the person hitting approve knows "responsibility is diffuse anyway, and it won't trace back to me," the honesty of their review erodes systematically — not because they're bad, but because the incentive structure permits them to coast. This is the real organizational consequence of "evaporating responsibility": once accountability is diluted, oversight quality declines with it. Conversely, this is exactly why "named ownership + an immutable audit trail" isn't bureaucratic red tape but a repair to incentives — it ties consequences back onto the person making the decision, giving them a reason to review in earnest.

And moral hazard has a more upstream version that managers often manufacture with their own hands: turning "use AI to go faster" directly into a performance KPI. The intent is usually good — a manager wants to drive adoption, so they reward visible numbers like "AI suggestion acceptance rate," PR count, or delivery speed. But that walks straight into Goodhart's law: when a measure becomes a target, it stops being a good measure. As one commentary puts it bluntly [16], if "AI suggestion acceptance rate" becomes a KPI, you're rewarding engineers for blindly accepting low-quality AI code — in effect, measuring their willingness to switch off critical thinking. A speed metric systematically manufactures speed-driven lapses.

And this top-down incentive distortion has a harder-to-admit extreme: sometimes a manager's real motive for pushing agents isn't efficiency — it's to route around people. A manager who has lost faith in their team, or has had enough of certain hard-to-manage senior engineers, may treat the agent as the solution that "finally lets me not depend on these people" — rather than repair a team they believe can't be fixed, bring in an outside force to reorganize an order they can no longer control. This is more dangerous than foot-dragging from below, because it comes from the end that holds decision-making power, and it quietly turns the agent from "a tool that helps the team" into "a pretext to replace it." So before designing any KPI or rollout plan, leadership owes itself an honest question: am I pushing this agent to make the team stronger, or to avoid having to face this team at all?

And there's no free lunch here. Research points out [9] that "review everything" causes velocity collapse — review overhead eats the entire productivity gain the agent brought — while "review nothing" produces unauditable, non-compliant code. So the answer isn't either/or; it's risk-graduated human oversight — high-risk changes bound tightly to human review and named responsibility, low-risk ones let through. Which loops right back to the first three walls: observable, named ownership, humans kept in the loop.

An Old Fault Line, Amplified by Agents: Security vs. RD

One subplot worth flagging. The layered accountability, capability boundaries, and enforced gates from Wall #2 all land on a long-standing fault line inside companies: security wants gates and control, RD wants speed and autonomy. This tension is empirically documented — a systematic review of DevSecOps [11] found the biggest "people" problem is exactly the conflict between development and security teams, with developers feeling judged and stripped of autonomy; another study [12] locates the root in differing objective functions — RD wants to ship fast, security wants a thorough assessment, and both are doing the "right" thing by different definitions. So it's structural, not a communication problem.

And agents move where that fault line sits. Security used to gate "code RD was confident in," so RD felt nitpicked; now both sides face "AI output not even RD is sure of." It's the first time RD and security share an enemy — and that gate flips from "policing RD" to "protecting RD," shielding the engineer who'd otherwise carry the AI's consequences alone. That's why my solutions below hold up: on the surface they're security's demands; underneath, they're spreading responsibility off of RD. Whoever can make the team see that shift turns the deepest resistance into a driving force.

So What Do You Do? — Four Handholds, Not Answers

I won't pretend to have a complete solution, but after this year, here are the directions I think are worth pursuing:

First, make the agent observable before you talk about autonomy. The concrete bar: every action the agent takes — which tool it called, which file it changed, on what basis it decided — must map to a traceable log line, the kind you'd read when debugging a normal bug. Be honest here: traceable isn't the same as understandable — a log line tells you what the agent did, not why it decided that way, and the reasoning black box won't vanish soon. But that's exactly the point: if you can't fully see its "thinking," you must at least be able to fully reconstruct its "behavior." Until you can do that, don't talk about autonomy. A human review checkpoint at this stage isn't the enemy of autonomy — it's the entry ticket that gives the agent a chance to be accepted. Make it reconstructable first, then loosen the reins.

Second, treat "layered, named accountability" as a precondition for deployment, not an afterthought. Stop asking "who's the one person responsible" — there isn't one. Make every decision in the chain named and logged: who authorized the agent, who approved, who merged, which checks passed at the time. The accountability gap isn't something technology can patch — it's something the system has to design for by distributing responsibility across layers up front. When something breaks, you should be able to read the log and trace it back, not argue about it in a meeting room.

Third, have engineers write the agent's capability boundary list by hand. "Involve employees" sounds like a slogan; the concrete handhold is an actual artifact: let the engineer who owned that area define this agent's allowlist / denylist — which files it can touch, which APIs it can call, which operations always require human review. This isn't a format I invented; in real loop implementations, people already encode it as a fixed "Stop" section in the agent's config file, spelling out in black and white "never merge, never delete, never push to main, send anything uncertain to a human" — and their experience is blunt: the red line you don't write down is one the agent will eventually cross for you. It loops right back to the layered accountability from Wall #2: the engineer who owned that area is already the person best placed to define that "capability boundary" layer. Their role is upgraded from "the person who writes the code" to "the person who defines how the agent should write code" — that's not consolation, it's a real step up in scope. Resistance loosens not because they were invited to a meeting to speak, but because they actually hold a set of rules that can say stop.

Fourth, treat code review as the accountability anchor, and graduate it with an explicit line. Admit one thing: when an agent dismantles a role, the person hitting approve is where responsibility lands. Rather than let that happen silently, say it out loud — and make "risk" concrete: changes that touch production data, alter permissions or security logic, or modify external interfaces always get a named human reviewer; only purely internal tooling, tests, and docs auto-merge. Where exactly to draw the line is debatable, but there has to be an explicit line, not a gut feeling. And keep an auditable decision trail throughout. This doesn't slow AI down; it keeps speed from bypassing responsibility.

Back to First Principles: None of These Walls Were Built by the Agent

Having gotten this far, I want to step back and make one thing clear, so this piece doesn't get read as "and therefore the agent is a troublemaker."

Look back at these five obstacles — management can't control it, no one's accountable when it breaks, employees fear replacement, roles get taken apart and reassembled, security versus RD — and not one of them was invented by the agent.

Management was never good at governing what it can't see through; it's just that the black box used to be "the tacit know-how inside some senior engineer's head," and now it's a model's reasoning. Responsibility attribution was always a tangle of "many hands"; it just limped along on implicit understandings ("this module is yours") and nobody forced you to make it explicit. Fear of replacement has shown up in every technological wave, from the Industrial Revolution to ERP rollouts to offshoring. The boundaries of roles and R&R were always going to be redrawn as tools change. And the goal conflict between security and RD existed for decades before the word "DevSecOps" was coined.

In other words, the agent isn't the cause of these ailments — it's the contrast dye. What it actually does is illuminate, all at once and mercilessly, the cracks a company normally papers over with interpersonal trust, seniority, and gray areas. Introduce an agent into a well-governed organization and it reveals a few hairline cracks; introduce it into one that was already running on tacit understanding, and it reveals an entire wall of fractures.

For leadership, that's good news, not bad. Because it means: every single thing you're forced to do to make the agent operate safely — spelling out layered accountability, writing the red lines into a list, making checks mandatory, pulling security and RD to the same table — none of it is useful for the agent alone. These are the fundamentals your organization should have had all along but never had the impetus to build. The agent just finally gave you a reason you can't refuse.

So the real question was never "should we adopt agents." It's the harder, worthier one: are we willing to use this occasion to close, one by one, the holes that tacit understanding has been hiding.

Agentic AI often fails to get off the ground not because it isn't capable enough, but because it exposes the holes that already existed in a company's governance, accountability, people, and division of labor. The technology will keep improving — but these walls were never built by the agent, and only the organization can take them down.

---

References

Academic papers (peer-reviewed / preprints)

1. Apostolou, S. A., Bosch, J., & Holmström Olsson, H. (2026). Agentic AI in Industry: Adoption Level and Deployment Barriers. arXiv:2605.14675. https://arxiv.org/abs/2605.14675 — Interview study across 16 practitioners at 12 companies; introduces a "capability–deployment verification gap." The four barriers are: LLM context-window limits, underperformance on proprietary languages/protocols, non-determinism, and data confidentiality. (Wall #1)

2. Brougham, D., & Haar, J. (2018). Smart Technology, Artificial Intelligence, Robotics, and Algorithms (STARA): Employees' perceptions of our future workplace. Journal of Management & Organization, 24(2), 239–257. https://doi.org/10.1017/jmo.2016.55 — The original STARA awareness paper. Greater awareness correlates with lower organizational commitment and career satisfaction, and higher turnover intentions, cynicism, and depression. (Wall #3)

3. Bankins, S., Ocampo, A. C., Marrone, M., Restubog, S. L. D., & Woo, S. E. (2024). A multilevel review of artificial intelligence in organizations: Implications for organizational behavior research and practice. Journal of Organizational Behavior. https://doi.org/10.1002/job.2735 — Multilevel systematic review; employees who fear AI worry about replacement and damage to skills/careers, driving down engagement and commitment and raising resistance and turnover. (Wall #3)

4. Chaining Tasks, Redefining Work: A Theory of AI Automation. (2026). arXiv:2606.15960. https://arxiv.org/abs/2606.15960 — Argues the "replace vs. augment" dichotomy is insufficient; AI shifts responsibility within roles and redraws job boundaries through task chaining. (Wall #4: role reconfiguration)

5. The Integrator Advantage: Controlled Agentic AI for Small and Medium-Sized Companies. (2026). arXiv:2606.16649. https://arxiv.org/abs/2606.16649 — Decomposes a role into execution, search, coordination, judgment, accountability, etc.; argues agents take the front end while humans retain context and responsibility. The right question is "which human time can be multiplied," not "who can be replaced." (Wall #4)

6. Dorner, M., Bauer, A., Šmite, D., Thode, L., Mendez, D., Britto, R., Lukasczyk, S., Zabardast, E., & Kormann, M. (2025). Quo Vadis, Code Review? Exploring the Future of Code Review. arXiv:2508.06879. https://arxiv.org/abs/2508.06879 — Survey of 100 developers across 5 companies. Developers expect code review not to disappear — anticipating similar or greater effort and a broader range of reviewed artifacts, with nearly all expecting LLMs to become active participants. (Wall #4)

7. Kamalı, H. Ö., Tuna, E., Haratian, V., & Tüzün, E. (2026). Rethinking Code Review in the Age of AI: A Vision for Agentic Code Review. arXiv:2605.17548. https://arxiv.org/abs/2605.17548 — A vision paper arguing reviewers shift from manual inspectors into supervisory operators of agents, with a framework carrying context across review stages. (Wall #4)

8. Garousi, V. (2026). Human Oversight and Overload: Two Hidden and Costly Burdens of AI-Assisted Software Engineering. arXiv:2606.05770. https://arxiv.org/abs/2606.05770 — Characterizes two underestimated burdens: the constant need for human oversight of AI-generated artifacts, and cognitive overload from the flood of AI suggestions. (Wall #4)

9. Governed AI-Assisted Engineering: Graduated Human Oversight for Agentic Code Generation in Regulated Domains. (2026). arXiv:2606.22484. https://arxiv.org/abs/2606.22484 — Presents the GAIE framework and Oversight Classification Model (OCM), routing tasks by regulatory impact, customer proximity, reversibility, and data sensitivity into three oversight tiers (human-in-the-loop / human-over-the-loop / automated-with-monitoring). (Wall #4 and the closing directions)

10. Agentic AI in Engineering and Manufacturing: Industry Perspectives on Utility, Adoption, Challenges, and Opportunities. (2026). arXiv:2604.09633. https://arxiv.org/abs/2604.09633 — Exploratory study grounded in 30+ interviews; finds adoption is constrained less by model capability than by fragmented data, security/regulatory requirements, and legacy toolchains lacking API access. (Wall #1)

11. Rajapakse, R. N., Zahedi, M., Babar, M. A., & Shen, H. (2021). Challenges and Solutions When Adopting DevSecOps: A Systematic Review. arXiv:2103.08266. https://arxiv.org/abs/2103.08266 — Systematic review finding that the largest "people" challenge is conflict between development and security teams: developers feel judged and stripped of autonomy. (Security vs. RD fault line)

12. Collaborative Application Security Testing for DevSecOps: An Empirical Analysis of Challenges, Best Practices and Tool Support. (2022). arXiv:2211.06953. https://arxiv.org/abs/2211.06953 — Empirical analysis documenting how development and security teams take an adversarial stance because their objective functions differ (delivery speed vs. thorough security assessment). (Security vs. RD fault line)

Industry reports & governance frameworks (not peer-reviewed; for further reading)

13. IBM (2026). The accountability gap in autonomous AI. https://www.ibm.com/think/insights/accountability-gap-autonomous-ai — Notes enterprises often lack the ability to monitor agent behavior, review automated decisions, and attribute responsibility after the fact. (Wall #2)

14. SPHERE / NHIMG (2026). AI Agent Ownership — An Underlying NIST AI RMF Control. https://nhimg.org/community/agentic-ai-and-nhis/ai-agent-ownership-and-accountability-gaps-in-ai-governance/ — Argues a named business and technical owner should be assigned before an agent is allowed to act, treating ownership as a prerequisite control for governance. (Wall #2)

15. World Economic Forum (2026). Why autonomous AI demands a new model of organizational authority. https://www.weforum.org/stories/2026/05/autonomous-ai-new-model-organizational-authority/ — Notes AI agents lack the legal accountability, moral responsibility, and reputational incentives of regular employees; consequences aren't intrinsic, so governance must compensate for the gaps. (Wall #2)

16. Hamade, J. (2025). Beyond the Hype: A Leader's Guide to Software Development Metrics in the Age of AI. Medium. https://medium.com/@justhamade/beyond-the-hype-a-leaders-guide-to-software-development-metrics-in-the-age-of-ai-129cd6d2fa7b — Industry commentary. Argues that making "AI suggestion acceptance rate" a KPI incentivizes blindly accepting low-quality AI code — measuring willingness to switch off critical thinking; any speed metric must be counter-balanced by a quality metric. (Wall #4: KPI incentives)

17. Stripe Engineering (2026), via InfoQ. Stripe Engineers Deploy Minions, Autonomous Agents Producing Thousands of Pull Requests Weekly. https://www.infoq.com/news/2026/03/stripe-autonomous-coding-agents/ — Stripe's autonomous coding agents ("Minions") produce 1,300+ PRs/week with zero human-written code, yet all changes are human-reviewed before merge; scaling hinges on existing developer infrastructure (sandboxed devboxes, tests, CI and deterministic gates), not model power. (Wall #4: humans relocated to reviewers)

Organizational behavior & technology adoption (academic)

18. Rogers, E. M. (1962/2003). Diffusion of Innovations. Free Press. — Classic theory sorting adopters into innovators, early adopters, early majority, late majority, and laggards; early adopters hold the highest opinion leadership and are key to peer diffusion. (Wall #3: employee factions)

19. AI Tools in Software Development: Developer Perceptions and Usage Patterns. (2026). arXiv:2601.21305. https://arxiv.org/abs/2601.21305 — Empirical clustering study sorting developers into Enthusiasts, Pragmatists, and Cautious groups that differ in usage breadth, perceived productivity/quality, and future adoption intent, mapping onto Rogers' adopter categories. (Wall #3: employee factions)

Verification & citation status:

1. Independently verified (arXiv ID/DOI, title, authors, year all match): items 1, 2, 3, 6, 7, 8, 9, 10, 11, 19; items 13, 14, 15, 16, 17 (IBM, SPHERE, World Economic Forum, Hamade, Stripe/InfoQ) all exist and are confirmed; item 18 (Rogers, Diffusion of Innovations) is a classic text. Stripe Minions' "1,300+ PRs/week, all human-reviewed" is corroborated by Stripe's engineering blog and multiple primary write-ups (including InfoQ quoting a Stripe engineering manager's public post).
2. Items 4 (Chaining Tasks, Redefining Work) and 5 (The Integrator Advantage) have not been independently re-verified for their exact arXiv IDs; Wall #4 therefore attributes them softly ("one line of work argues"). Check arXiv for the correct ID/authors before citing, or substitute a confirmed source.
3. The "problem of many hands" is an established concept in applied ethics (traceable to D. Thompson and others); this piece uses it as a standalone concept and does not claim any of the code-review papers above originated it.
4. "Principal-agent problem," "moral hazard," "sin of omission," "Coasean transaction costs," and "Goodhart's law" are textbook economics/management concepts not tied to a specific paper here; for formal attribution, add primary sources such as Jensen & Meckling (1976), Holmström (1979), and Goodhart (1975)/Strathern (1997).
5. The "Stop section in an agent config" description (in solution 3) comes from a secondary industry piece on Loop Engineering whose details couldn't be fully independently verified, so the text says "in real loop implementations"; find a primary source before formal use.
6. Items 13–14 are industry/governance pieces; items 15, 16, 17 are industry reports, an engineering blog, or individual commentary rather than academic papers. The governance arguments ("named owner," "human-in-the-loop checkpoint," "speed metrics need a quality counter-metric") are echoed across BCG, MIT Sloan Management Review, OECD, and the EU AI Act (Articles 12–14).