Technology Radar: An opinionated guide to today's technology landscape (Volume 30)
Thoughtworks (Technology Advisory Board) · pdf · 2024-04-03 source ↗ Reader 🖥️
Agentic AICoding AgentsFrontier-Lab HypeMulti-Agent OrchestrationPull Requests & Async Code ReviewRetrieval & RAGStacked Diffs / Stacked Pull Requests
As AI assistance shifts from an individual developer's tool to something that must be engineered at the team level, organizations need deliberate, disciplined practices (team-shared prompts and RAG-grounded knowledge over ad hoc fine-tuning, and reformed PR/CI practices to absorb AI-increased throughput) rather than either overenthusiastic LLM adoption or business-as-usual team process.
practical · expository — A twice-yearly opinionated-guide format: short, graded recommendations (Adopt/Trial/Assess/Hold) on named techniques, tools, platforms and languages, bundled with longer prose on four cross-cutting themes. Practical throughout — every item is ultimately advice on what to do.
Structure
| Part | Role |
|---|---|
| Four cross-cutting themes (open-ish source licenses, AI-assisted software development teams, emerging architecture patterns for LLMs, dragging PRs closer to proper CI) | context and synthesis |
| Graded technique/tool/platform blips (Adopt/Trial/Assess/Hold), roughly one-third concerning AI | evidence/examples instantiating the themes |
Key terms
- AI team assistants
AI tooling engineered for a whole team's shared practice — standardized prompts plus RAG-backed organizational/industry knowledge sources that spread best practices, upskilling and alignment across team members — as distinct from individually-adopted developer tools like GitHub Copilot. - 10x team
The goal state the TAB wants AI team assistants to produce: aggregate team capability lifted by shared AI tooling, contrasted explicitly with a team of individually AI-boosted but siloed '10x engineers' whose gains don't aggregate. - Tracking health over debt
Treating a system's 'health' rating as a tracked SLO-equivalent metric that organizations allocate resources against, instead of (or alongside) tracking technical debt as a separate, harder-to-operationalize concept.
Propositions
- explicitAI coding assistance tools (e.g. GitHub Copilot) are currently framed around enhancing an individual's work, but software delivery is team work, so the next frontier is AI tooling built for the team rather than for the individual developer.conf: high
- explicitStandardized prompts (encoding agreed-upon best practices and templates) plus RAG-delivered organizational/industry knowledge sources can produce team-wide knowledge amplification, upskilling and alignment in a way individual AI tool adoption does not.conf: medium
- explicitWith AI coding assistants increasing individual coding throughput, teams tend to produce larger pull requests, which puts more pressure on the already-strained batch-and-wait async code review process that substitutes for true continuous integration.conf: highsupports2024_final_dora_report · p3 — This April 2024 practitioner observation (AI throughput -> larger PRs -> strained review) predates and independently corroborates the same mechanism DORA's October 2024 report could only infer from survey data.supportsGitHub Brings Stacked Pull Requests to Public Preview · p1 — Names the same AI-generated-code-volume-strains-review dynamic that the later stacked-PRs extraction treats as the central, binding bottleneck of AI-accelerated development.
- explicitRetrieval-augmented generation (RAG) is the preferred pattern for grounding LLM output in enterprise contexts, and is usually a better cost-benefit choice than fine-tuning for making an LLM aware of organization-specific knowledge or codebases.conf: high
- explicitFine-tuning requires more compute/expertise and introduces more sensitive/proprietary-data risk than RAG, and risks under- or over-fitting; most 'make the LLM know about us' use cases are retrieval problems, not behavior-shaping problems.conf: high
- explicitMany problems organizations reach for LLMs to solve (e.g. sentiment analysis, content classification) can be solved more cheaply and simply with traditional NLP; rolling out an LLM solution as soon as it minimally works, without checking whether an LLM is the right end-state solution, is an overenthusiasm risk worth holding off on.conf: high
- explicitLLM-powered autonomous agent frameworks (Autogen, CrewAI) are evolving past single-agent and static multi-agent systems toward agents with defined roles that collaborate via delegation or conversation to complete tasks, but the area is still early-stage.conf: highextendsTechnology Radar, Volume 34 · p4 — Vol 30's early, single-case 'AI team assistants' idea (team-shared prompts/knowledge beyond individual tool adoption) is the direct ancestor of Vol 34's broader claim that teams must rethink collaboration structure and agent topologies for the agentic era.
- explicitA security champion is a responsibility assigned to an existing team member (not a separate role or hire), trained by security practitioners, who raises security considerations across technical and nontechnical delivery decisions and bridges development and security teams.conf: high
- explicitThe commercial pressure to monetize AI tools is intensifying 'open-ish' source licensing — tools marketed as open source whose fundamental capabilities only appear after a paid subscription, with the fine print often obscuring this more aggressively than in prior open-core business models.conf: medium
- explicitGenAI/LLM-based codebase-understanding tools (e.g. Driver AI, bloop) using RAG over code search are starting to help developers navigate undocumented or outdated legacy codebases, though in practice this is so far mostly limited to smaller code snippets rather than whole-system understanding.conf: medium
Arguments
Teams should deliberately build AI team assistants rather than rely on the aggregate effect of individually-adopted AI coding tools. strength: medium
Explicit premises:
- Current AI coding tools are framed around individual-developer enhancement.
- Software delivery is team work, not individual work.
- Standardized prompts plus RAG-delivered shared knowledge sources can amplify knowledge, upskilling and alignment across a team.
Implicit premises:
- Individual-level AI productivity gains do not automatically aggregate into team-level gains — a team of siloed '10x engineers' is not the same as a '10x team.'
- Knowledge amplification requires explicit shared tooling (prompts, retrieval sources), not merely giving every team member access to the same underlying LLM.
Inferences:
- Team-level AI tooling could become as significant an investment area as individual developer tooling over the following Radar cycles.
Organizations should default to RAG over fine-tuning when they want an LLM to incorporate organization-specific knowledge. strength: high
Explicit premises:
- Fine-tuning requires considerable compute and expertise.
- Fine-tuning introduces more exposure risk for sensitive/proprietary data than RAG.
- Fine-tuning risks under- or over-fitting depending on available data volume.
- RAG offers a better cost-benefit ratio for the common case of making an LLM aware of specific facts or codebases.
Implicit premises:
- Most 'teach the LLM about us' requests are really retrieval/grounding problems, not problems requiring the model's underlying behavior to change.
Inferences:
- Teams reaching for fine-tuning as a first move likely haven't correctly diagnosed which kind of problem they have.
Narratives
- The TAB frames its own practice of building AI team assistants ('we've started using a team assistance approach...') as a working example, contrasting it with a hypothetical team of siloed, individually AI-assisted '10x engineers.'
→ Implicitly argues that aggregate team capability, not individual tool adoption, is the right unit of measurement for AI's organizational payoff.
Questions addressed
- ⭕ How should software delivery teams move AI adoption beyond individual developer productivity to team-level capability?
Proposed as a direction (standardized prompts + RAG-delivered shared knowledge) with one early internal case, not a resolved or evaluated practice. - ⭕ Is pull-request-based async review sustainable as AI coding assistants increase individual throughput and PR size?
Named as a growing strain; the TAB surveys mitigations (gitStream, GitHub merge queue, stacked diffs, PR-derived metrics) without endorsing a specific fix, and still prefers true CI where teams are free to adopt it. - ✅ When should a team fine-tune an LLM versus use RAG?
RAG is recommended as the default; fine-tuning is reserved for cases needing genuine task-specificity beyond what retrieval-based grounding can provide.
Gaps
- incompleteThe theme on dragging PRs closer to proper CI names AI-increased throughput and larger PRs as a growing strain on async review, and surveys several mitigations (gitStream, merge queues, stacked diffs, PR metrics) in the same breath — but does not analyze which of these actually addresses the AI-specific mechanism (more code per unit time) versus merely repackaging the same total review burden into more numerous smaller transactions.
Read next: Later corpus material on stacked pull requests and on DORA's AI/changelist-size findings examines this mechanism more directly. - incompleteThe 'AI team assistants' blip offers no account of adoption barriers, measured outcomes, or how a team-shared-prompt-and-RAG approach differs in practice from a team that already had strong individual tool adoption plus good informal knowledge-sharing habits — it is reported as a promising direction from a single internal case, not evaluated.
Read next: Later Radar volumes or practitioner reports that follow up on team-level AI tooling outcomes specifically (as opposed to individual-developer AI productivity studies).
Closes gaps elsewhere
- 2024_final_dora_report · g1 — Thoughtworks's TAB reports, from direct observation across many client engagements in a document published six months before the DORA 2024 report, the same mechanism DORA could only infer (AI-assisted coding raises throughput, which tends to produce larger PRs, straining review). This is practitioner testimony, not a controlled measurement, but it is independent, dated-earlier corroboration of the hypothesized causal chain rather than a mere plausibility argument.
Related documents
- Technology Radar, Volume 34
- 2024_final_dora_report
- Agentic AI and Code Reviews
- GitHub Brings Stacked Pull Requests to Public Preview
- Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE
- Transcript for Cursor Team: Future of Programming with AI | Lex Fridman Podcast #447
- Does GitHub still merit "top git platform for AI-native development" status?
- SpaceXAI Launches Grok Bot for Autonomous AI Agents
- Have your agent record video demos of its work with shot-scraper video
- Accelerating Delivery: How AI Agents Can Own the Initial Code Draft