From Coding to Context Switching: An AI Retrospective

On This Podcast

In this conversation, we examine how Fruition's ambitious push toward agentic coding produced real velocity gains but also unexpected burnout, forcing Elliott Beatty to send engineers home for a full week to recover. He explains that running multiple agentic coding sessions at once left developers doing so much context switching that review quality suffered and job satisfaction dropped, even though nobody feared losing their job to AI. We also discuss how the team deliberately pulled back from its most aggressive multi-agent workflows once it became clear that no single developer could sustainably supervise several projects at full throttle. Elliott describes settling into a sweet spot well above the team's original output but below the exhausting peak they briefly reached.

We also discuss why AI coding assistants have delivered far more value to Fruition's React frontend team than to its .NET Core backend or Flutter mobile teams. Elliott explains that frontend work is often a straightforward pattern of connecting to an API, fetching data and displaying it, something agents replicate well once shown existing code, whereas backend engineers are building interconnected microservices that require architectural judgement an agent cannot yet supply. The team's move from Jira to Linear, with its Figma integrations, has further smoothed frontend implementation by letting an agent pull designs directly from a ticket. Elliott concludes that at a professional level, production backend code still depends heavily on experienced engineers doing the genuine problem solving.

A further theme is how accelerated coding output simply moved the organisation's bottleneck downstream, overwhelming QA and then user acceptance testing even after Fruition hired an additional QA engineer and adopted LLM-assisted tools such as n8n and custom ChatGPT projects for building test cases. Elliott describes a backlog of work sitting in QA for weeks while business stakeholders struggled to review and approve everything engineering could now produce. We examine how the team prioritised shipping feature flags through LaunchDarkly specifically to relieve this logjam, letting mostly finished work merge into master and reach production behind a flag rather than clogging long-lived branches. He frames this as evidence that speeding up one stage of the SDLC simply exposes the next weakest link, echoing the value-stream-mapping lessons of the 2025 DORA report.