TBM 434: How Maps Can Hide Problems
If what you are mapping is incoherent, don’t fall in love with the map (or your personal ability to navigate with it).
Reading Radar
Fresh ideas.
Better ways to work.
Explore Agile, ways of working and practical AI for teams. Find recent articles from six sources, then follow an idea back to its author.
Read our perspectiveOn our radar
Updated dailyThe Conductor Developer
TL;DRWhy I think software development is starting to feel a little more like conducting an orchestra. There’s a shift happening in software development that I don’t think we’re talking about clearly enough. For the last couple of years we’ve framed AI as a productivity tool. How much faster can it write code? How many more features can we ship? How much cheaper can we build software? I think that’s the wrong question, but I understand why. The first thing AI became good at was writing code, so naturally that’s where we focused. As AI got better at coding, I expected the bottlenecks to move thr
The Economic Benefit of Refactoring
Giles Edwards-Alexander does an experiment to see if decomposing a large function helps reduce token costs, suggesting that is may now be possible to measure the economic benefit of refactoring more…
TBM 433: The Border Collie Faustian Bargain
(I have a question at the end, if you get there)
The Orchestrator's Tax
Subagents get justified by time saved and parallel execution, but Rahul Garg explains that's not what matters most. Every token in the orchestrator's context is competing for its attention, and the real value of a subagent is what it keeps out of that context. Subagents should be treated as a tool for protecting the orchestrator's working memory, offloading reasoning it doesn't need to hold onto. Doing this well means giving the orchestrator explicit ground rules for when and how to delegate. more…
Why I’m Writing Rachel’s Ramblings
TL;DRI have ideas. I haven’t been writing them. That’s about to change. I promise… myself. I’ve been thinking a lot about talent. Actually, I’ve been thinking a lot about thinking. And writing. Or more specifically, not writing. This really hit me earlier this year at the Future of Software conference. I was surrounded by people sharing their latest ideas and I had a slightly uncomfortable realization: I have my own. Not just opinions. Actual patterns. Hypotheses. Things I’m seeing across clients, across teams, across the industry that feel new or at least not well articulated yet in a way tha
TBM 432: Bundling & Unbundling Capabilities (and AI)
Early in my product career, I wore many hats.
Fragments: July 21
With this post, I’ll wrap up my notes from the second Future of Software Development Retreat. But before I do, I should note that the full Thoughtworks report on the retreat is now available. They have five headline findings: Code generation is no longer the bottleneck — verification is. ‘Harness engineering’ is emerging as a distinct, ownable discipline. Organizations are colliding with a real apprenticeship crisis. The executive/engineer expectation gap is a bigger risk than any technical limitation. Legacy modernization is the clearest, most defensible near-term value pool. ❄ ❄ A session co
TBM 431: The Denominator That Matters
Here’s a simple model for thinking about AI success in organizations.
The Archaeologist’s Copilot
When people think of legacy modernization, most folks aren't imagining the target environment will be Java 8. But this was the challenge facing Nik Malykhin when he needed to run a Java 1.5 codebase on today's hardware. His early use of LLMs gave plausible answers that did not hold up in the codebase. Progress came when he grounded the process in evidence, using AI to support analysis, validation in a stable Docker environment, and gradual refactoring protected by tests. The main takeaway is practical: AI was most useful when constrained by evidence, clear roles, and a step-by-step modernizati
DSLs Enable Reliable Use of LLMs
LLMs generate code incredibly fast, but to ensure they generate exactly what is intended, they need clear boundaries. Abstractions and Domain-Specific Languages (DSLs) provide a strong harness that guides LLMs right from the start. Unmesh Joshi describes how the example of Tickloom - a domain model and DSL for illustrating distributed system behavior - shows how we can use an LLM as a partner to iteratively build a DSL and as a natural language interface to use it. Such a DSL can act as the key source of truth for software systems in the world of LLMs. more…
Follow the ideas
Meet the sources.
These articles belong to their original authors. Summaries help you choose what to read; visit the original for the full context.
COME TAKE A LOOK
A little less busy.
A lot more together.
Curious? Join the waitlist and see how we welcome your team.
Tell us a little about your team. We’ll explain the next steps and invite you when we have capacity for your workspace.
Join waitlist Start with your email. No payment needed to join.