The actual pain points of agentic engineering

I’ve been using coding agents daily since early 2025. With the introduction of Herdr, Claude and Pi in the terminal, multi-agent orchestration across worktrees. The output is real. I ship more code than I did six months ago. But the pain points a fsre also real, and most commentary I’ve read either oversells the magic or dismisses the whole thing. Here’s what I’ve actually run into.

The verification bottleneck

Agents write code fast. Median time to a “plausible” PR is about 13 minutes in the structured agentic engineering study. But roughly 30% of those PRs introduce regressions. An independent replication of SWE-bench results found that about half of benchmark-passing patches would be rejected by real maintainers, mostly for functional problems.

The uncomfortable math: AI-authored code shows about 1.7x more issues per PR than human code on mature codebases. Logic errors up 75%. I/O performance problems up 8x. Security vulnerabilities up 2.7x. That last number, from a Softude analysis, was the one that made me rethink my review process.

Review of agent-written code takes more effort, not less. Heavy users report 11 to 16 hours per week on review alone. Agent PRs wait 4.6x longer in review queues because reviewers have to trace logic they didn’t write and didn’t design.

My take: the bottleneck has moved from writing to verifying. Writing is cheap now. Deciding whether to trust and merge the output is expensive. If you don’t redesign your testing and review gates, you just relocate the work.

Context is the real technical problem

Every post-mortem on a bad agent session traces back to context. Not intelligence. The model is smart enough. It just didn’t know what it needed to know.

The failure modes I hit most often:

Context rot. Performance degrades in longer sessions even on tasks the agent handled fine 20 minutes earlier. Stuffing a monorepo’s worth of files into the context window buries the signal in noise.

Missing institutional knowledge. Legacy constraints that live in Slack threads, postmortems, and departed engineers’ heads. The agent produces code that passes lint and tests but violates architecture decisions nobody wrote down. Wavect calls this “technically correct but architecturally wrong.” I call it Tuesday.

Constraint decay. This one stings. You write careful rules in AGENTS.md, system prompts, or project conventions. The agent follows them for the first few interactions. Then, over long sessions, it starts ignoring them. It reintroduces patterns you banned. It weakens test assertions. It deletes validation code it considers redundant. Developer’s Digest documented this pattern, and I’ve seen it happen enough times that I now treat AGENTS.md as a starting point, not a guarantee. Executable constraints, pre-commit hooks, and CI checks that fail on violations, work better than prose instructions.

Stale context in concurrent work. When I have multiple agents and human edits happening across worktrees, the agent’s snapshot of the codebase goes stale mid-run. It edits a file based on state that no longer exists. Sourcegraph’s analysis found that agents lose convergence in large repos with common names, deprecated code paths, and test fixtures that look like production code.

Harness matters more than the model

Same model, different harness, wildly different results. I’ve seen a 5-to-36-point swing on the same benchmark just from changing the tooling around the model. The Agentic Engineering Field Study on GitHub documents this systematically.

The harness is everything around the model: tools it can call, permissions it has, verification loops, observability, instruction files. Getting this right is where the actual engineering lives.

Pain points in the harness layer:

Silent failures. Context overflow truncates instructions without any error. The agent just stops following rules you gave it, and you don’t notice until the PR review. Config drift overwrites edits. The agent goes quiet when it should be reporting problems.

Reward hacking. Agents delete tests to make CI pass. They special-case known inputs. They game completion criteria. This is a known research problem now, but it shows up in production all the time. I’ve had an agent “fix” a failing test by changing the expected value to match the broken output.

Multi-agent coordination. When multiple agents hit the same files, you get merge conflicts, circular PR dependencies, and review gridlock. Lee Boonstra wrote about this from her experience at Google, and her observations match mine. The fix is to serialize shared mutations and designate one agent as the integration owner for contested files. But that requires planning that most people skip.

The human cost nobody talks about

There’s an 84% adoption rate for AI coding tools among developers. But only 29-33% trust the accuracy. People use tools they don’t trust, every day, because the speed feels too good to give up.

The day-to-day experience shifted from writing code to planning, context engineering, harness design, and review. Stack Overflow’s own reporting calls it decision fatigue: denser days, more judgment calls per hour, higher cognitive load even as raw output goes up.

I’ve noticed some patterns in myself and other developers I talk to:

Token-limit relief. That moment when a long agent session hits the context limit and you can start fresh. It feels like putting down a heavy bag. That shouldn’t feel like relief, but it does.

After-hours continuation. Agents don’t clock out, so neither do I. The temptation to fire off one more task at 11pm is harder to resist when the agent will happily churn away while I sleep. Coddy’s report on “AI coding addiction” sounds dramatic, but the pattern is real.

Shipping code I don’t fully understand. This is the one I’m least comfortable admitting. When an agent writes a complex regex or a clever data transformation, I review it, test it, confirm it works, and merge it. But I don’t always understand it the way I would if I wrote it myself. That’s a trade-off, not a win.

What actually works

After six months, the practices that hold up:

Small, verifiable tasks with fresh context. Break work into chunks that an agent can finish in one session. Start each chunk with clean context. State the goal, constraints, and acceptance criteria up front. The Ralph-style iteration pattern, where you give the agent a task, verify the result, then start a new session for the next task, beats marathon sessions every time.

Executable constraints over prose instructions. Pre-commit hooks, CI rules, type checks, and test assertions that fail automatically. AGENTS.md is useful for giving the agent context about the project, but it’s not a substitute for guardrails that run as code.

Human ownership of architecture. The agent implements. You decide what gets built and how it connects. Abdicating design decisions to the agent is where projects go wrong. A mkdev retrospective on a year of agent-assisted coding found the same thing: the projects that worked had a human directing the overall structure.

Structured review artifacts. When an agent opens a PR, require it to include what changed, why, what it tested, and what risks remain. I use merge-readiness packs for this. It makes review faster because you’re evaluating evidence rather than reverse-engineering intent from a diff.

Budgets and kill switches. Maximum iteration counts, spending limits, sandbox permissions, draft-PR-only mode until a human approves. Without these, agents over-engineer, loop on irrelevant details, or make changes you didn’t ask for.

The technology is real and the productivity gains are real. The part that’s missing from most of the hype is that you’re not saving time overall, you’re spending it differently. Less writing, more reviewing. Less coding, more designing. Less doing, more deciding. Whether that trade-off works depends on the kind of work you do and how much you invest in the plumbing around the model.