Challenges

Agents do follow context-file instructions, which means each mention of a tool or step gets acted on, every task. Extra instructions raise spend even when they don't help, and whether context files help at all is disputed: one source finds time saved, another no gain in success.

When a fact changes, agents often keep using the old version from memory or context files. Updated decisions need to replace, not sit beside, the old ones. Building the update into every task may keep notes current, but even its advocates still trim them by hand. A second pass that checks notes against session logs fixed a wrong note in one vendor test, but nobody has compared it with writing notes as you go.

Assistants tend to agree with the person asking and pick facts that support them. Each statement can be true while the overall picture is skewed, and people rate these answers as more objective.

Giving agents more tests up front helped only to a point, and agents that designed before coding did better, so heavy spec-first work risks repeating waterfall. Others argue the spec is the lasting artifact and should be executable; the evidence doesn't settle it.

One practitioner argues for goals-only planning prompts and fully detailed execution prompts. It is an opinion nobody has tested.

Letting an agent iterate against tests repairs edge cases and type errors, but if it misunderstood what was asked, it stays misunderstood. Only a person checking intent catches that.

The evidence that writing tests first helps agents comes from one language and from models that predate current ones, and nobody has re-checked it. Vague requirements, where test-first is said to help most as a way of thinking, haven't been tried with agents.

Coverage and mutation testing show whether code runs and whether a change would be noticed, but not whether the expected values are right, and model-written tests assert whatever the model expects the code to do. Some sources recommend mutation testing as a check on AI-written tests; another finds it barely tells good suites from bad ones on AI-written code.

Each agent change on top of earlier agent changes adds a little duplication and complexity. Better prompts set a better starting point but don't stop the slide; only refactoring and review do. Whether newer models maintain code better is disputed: one measure shows fast gains, another the same decay across model tiers.

Some loops reset the agent's context every iteration; one comparison on a single task found continuing did better for the cost. Nobody has compared them on real work.

Adding agents may run into the same coordination cost as adding people to a late project (Brooks's Law), and more agents on unclear requirements may only give the wrong answer faster. One team saw agents coordinate through shared plans, at the cost of CI load. No controlled comparison exists yet.

PR volume has grown several times over while reviewer numbers haven't, so the extra review falls on the few people trusted to approve. Some teams move trust into tests and production checks and auto-merge part of their changes instead; whether that holds up isn't known yet.

Even reviewers who spot a flaw in an AI recommendation often go along with it. Spotting a problem isn't enough; reviewers need the time and the authority to reject.

When agents push often, the build can sit red; people stop reading it, so a real failure gets lost and a green build stops reassuring. Teams are also moving from stories to epics, and nobody has shown a pipeline that takes that batch size at speed.

Some practitioners say agents make far larger builds worth attempting; others say most teams lack clear pass/fail checks and can't reason about large black boxes, so should aim smaller. Both say the checks decide. Neither side has numbers.

Leak rates are measured only under planted attacks, not in everyday use. Plan for it as a likely risk; keep secrets out of reach. (OWASP LLM02, LLM07)

The one architecture shown to block most injection attacks has only been tested by its own authors, who say the problem isn't solved, and a guardrail that stops most attacks still fails by security standards. Limit what an agent can do rather than hoping it can't be tricked; whether an agent should ever approve its own change is still open. (OWASP LLM01) In tests on coding agents with no approval step, injected instructions were acted on in a large share of runs, and agents rarely said they had noticed one.

When an agent works inside someone's session, the app's permissions and audit log see only the person. A rule like 'the agent may read but not delete' can't be enforced there, and actions can't be traced back to the agent. Drafts exist that name the agent or flag risky actions, but none yet links the agent to the person and narrows its access.

Agents fail on tasks unlike what they were trained on, not on tasks that look hard. A task that seems easy can fail and a hard one succeed, so judge from real results on your work.

One industry survey says good practices partly shield teams from AI's downsides; telemetry across many companies finds no outcome protected. Don't assume a mature process makes agent adoption safe; watch your own delivery numbers.

Checking agent code well takes hands-on coding skill, and relying on agents can wear that skill down. Without deliberate practice, a team loses the ability to review what it ships. Nobody knows yet whether the loss reverses or how to measure it.

Team context files, skills and memory stores can leak data, go stale, hide contradictions and lose track of who wrote what. Nobody has settled how conflicting writes should be handled.

With agents writing the code, practitioners disagree on whether verification, judgement, understanding or shared agreement on why a change exists becomes the constraint. Each position rests on one person's experience or opinion.

One view holds that a team's understanding of its system can't be rebuilt from documents once lost; another says most engineers work fine with a partial picture. With agents writing more of the code, the answer decides how much understanding a team has to keep.

Most of a junior engineer's questions now go to an assistant rather than a teammate, and entry-level hiring is shrinking. The quick answer replaces the conversation where they would have learned how the team works, and nobody yet knows how juniors will grow into seniors.

Results on pairing with an assistant disagree, and some show lower quality than a human pair. It also skips the knowledge sharing that pairing exists for. With a human partner, more knowledge changes hands and more of it is questioned; alone with an assistant, more is accepted on trust.