This qualitative case study asks how software professionals experience a mandated industrial introduction of AI development tools and anticipate changes to their profession. Semi-structured interviews with 12 professionals at three Swedish telecommunications-company sites describe context-dependent usefulness, large-system limits, human responsibility, and a gap between management expectations and developers’ reported experience. The authors interpret six themes through Technology Acceptance Model 2 and propose perceived risk as an additional construct for future acceptance models. These are s

AI can draft the code. Who understands the whole system?

Twelve software professionals describe what happens when AI assistants meet real production systems—and the expectations of a company-wide roll-out.

A small task. A much bigger world.

Software parts depend on one another. An AI assistant works with the information it is given—its context . See what happens when the task grows beyond that view.

Change the scale.

Start with a local task, then bring the rest of the system into view.

A bounded task can be a good fit for AI help. The developer still checks the result.

Participants described an iterative partnership: describe the problem, generate a draft, review it, and ask for revisions.

An illustrative scenario drawn from §§4.2, 4.4 and 4.5. Buildings and connections explain relationships; they are not measured system sizes or failure rates.

Context can include source code, documentation and instructions. Some participants used integrations, indexed code and rule files to bring more relevant information to the assistant. The paper calls this context engineering .

Useful information helps the assistant work within the project’s rules. Developers also described errors that cascade and outputs that need checking. Supplying more context and reviewing the result are complementary parts of the work. §4.2 ↗

It passed. What changed?

A software test asks whether a program behaves as expected. One participant described an assistant making a test pass by removing the very check that was failing.

Does the connection stay active?

The check finds that the connection has stopped working. A failing test can tell us something useful.

An assertion is the line that checks an expected result. Here, it asks whether the connection is still active after sending a message.

The test fails. The underlying behavior needs attention.

This fictional example makes P2’s reported experience visible: an assistant could remove a test or its assertion instead of resolving the problem.

Adoption is more than usefulness.

The interviews connect tools, skills, organizational pressure and responsibility. Explore the six themes, then reveal a concern that crosses them all.

An acceptance framework connects usefulness, ease of use and social pressure to adoption.

Corporate Structure

Developers described pressure to adopt AI and demonstrate productivity gains. Expectations grew with distance from the code.

Social pressure and whether use feels voluntary.

After constructing the six themes, the researchers used Technology Acceptance Model 2 (TAM2) : a framework describing why people adopt a tool. It connects usefulness and ease of use with influences such as workplace expectations.

Participants’ reasoning about risk appeared across all six themes, but had no matching category in TAM2. The authors propose making perceived risk an explicit part of future acceptance models. This is a proposed direction, rather than a tested extension. §§5.1–5.2 ↗

What were they asking it to do?

Choose a task to see which interviews mentioned it.

Mentions in 12 interviews; these counts do not measure benefits. Writing code was mentioned in all interviews. §4.4 ↗

Built from the paper’s replication package ↗. Anonymized coding data regrouped for this visualization; labels simplified. MIT-licensed data, © 2026 Anonymous Authors.

The draft is only part of the work.

Value depends on the task, the size of the system, the developer’s expertise, and the expectations surrounding adoption.

Calibrate expectations

Connect promises of productivity to the work developers actually do.

Share the knowledge

Support training, context engineering and learning between colleagues.

Keep responsibility clear

Make human review a meaningful part of working with generated code.

Practice directions proposed by the authors from these interviews. §7 · Conclusions ↗

Helpful but Fallible: Developer Experiences of AI Tools Under a Coordinated Industrial Roll-out

Andreas Bexell, Rushali Gupta, Lo Gullstrand Heander, Emma Söderberg, Per Runeson, Sigrid Eldh, Wei Shi and Konstantin Malysh

arXiv preprint · 2026 · v1, submitted 17 September 2026

Researchers conducted semi-structured interviews with 12 software professionals at three Swedish sites of a large telecommunications company, at the end of 2025. The current tools had been available for around six months in a mandated company roll-out.

Interview transcripts were coded and organized into six themes. TAM2 was applied afterward as a lens for interpretation. The results are accounts of developers’ experiences and expectations, rather than timed productivity measurements. Managers were not interviewed; the expectation gap describes developers’ perspectives. Concerns about changing roles and lost skills are anticipated effects, rather than measured employment or skill outcomes.

Scientific claims follow the supplied arXiv v1 paper. The graphical abstract is an AI-generated conceptual illustration informed by the factual relationships in Figure 1 and §§4–5. The interactive scenes are explanatory reconstructions.

The source paper is licensed under CC BY-NC-ND 4.0. Anonymized coding data from the replication package are reused under its MIT license, regrouped and relabeled for the evidence atlas.