Podcast Summary
Podcast: Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Episode: Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't | Guest: Tudor Girba
Host: Vasco Duarte
Release Date: October 6, 2025
Main Theme
This episode dives into the concept of "Moldable Development" with Tudor Girba—CEO of fink.com, creator of the Glamorous Toolkit IDE, and co-author of the forthcoming book Rewilding Software Engineering. The discussion centers around how moldable development enables developers to create contextual, custom tools—on-demand, in the course of their real work—to answer system-specific questions that AI-driven code assistants struggle with today. The approach offers profound shifts in how teams understand, navigate, and modernize complex or legacy systems, potentially outpacing even the latest AI-based tooling.
Key Discussion Points & Insights
1. What Is Moldable Development?
[02:26 - 03:32]
- Moldable development is a new way of programming, akin to approaches like TDD or DevOps, but focused on building thousands of contextual tools—per system—to speed up developers’ ability to comprehend complex codebases.
- Unlike standard IDEs with a handful of generic plugins, moldable development encourages teams to make and use bespoke tools that give system- and business-context-specific views.
Quote:
"When I say contextual tools, I mean potentially thousands of contextual tools. ... they give us different perspectives on the system. And the goal is to help us figure systems out faster."
—Tudor Girba [02:26]
2. Why “Moldable”?
[03:32 - 03:52]
- The term reflects the process: continuously shaping the development environment to answer evolving, system-specific questions—whether about functionality, performance, or hidden structures.
3. Case Study: The Telco Data Pipeline
[04:41 - 10:16]
- A real telecom company spent years (and significant resources) trying to speed up a vital data pipeline, only to discover after three years that nothing had changed in terms of throughput.
- The core insight: there was a “missing box” (component) in their architectural understanding—teams had drawn four boxes, but the real system had five. All their planning and efforts missed this unseen component.
Quote:
"Whenever somebody draws ... a picture of the system on the whiteboard, they don't document the system. They document what they believe the system to be."
—Tudor Girba [07:30]
[Key Segment: 07:02 - 10:16]
- Even high-functioning, well-funded teams can be blind to key elements in their own systems because of how software’s complexity and constant evolution outpace human memory and documentation.
4. Why Can’t We Just Read All the Code?
[12:05 - 14:08]
- Reading code or documentation is the main way developers try to understand systems. But with even “small” codebases, reading every line is unscalable and outdated as soon as reading is complete (due to constant changes).
- This creates a cycle where understanding always lags behind reality.
Quote:
"The main source of information that we gather from systems is reading. ... even if you try to read ... it takes about one person month to read the whole [250k LOC] thing. ... Everything you know from yesterday ... is only a useful source of hypothesis. It's not a useful source of answers."
—Tudor Girba [12:05]
5. The Hidden Cost: Reading Code
[14:09 - 17:28]
- Over 50% of developer time goes to reading code, but few teams talk about or optimize this. Most reading is unstructured and ad hoc, the least productive way to extract actionable information.
Quote:
"The amount of time that developers spend on reading accounts for more than half of the total time of development. ... But, when was the last time you talked about how you read code?"
—Tudor Girba [14:12]
6. AI Code Assistants: Limitations & Comparison
[18:00 - 20:25]
- AI tools can quickly answer a narrow question, but the “why” or the context behind those answers (and their accuracy) remains opaque and potentially misleading.
- Real investigation is iterative, contextual, and involves multiple layers of abstraction and follow-up questions—something not well-served by a “one-and-done” answer from a codebot.
Quote:
"When you ask the AI ... you get exactly the same kind of ... answers back. The answer is going to come quickly, but you will not know whether this is accurate. ... You definitely do not have an explanation as to why the answer is the way it is."
—Tudor Girba [18:00]
7. Moldable Development’s Approach: Micro-tools for Questions
[20:25 - 27:54]
- Complex systems (like the telco pipeline, with custom Excel transformations and 22,000 scripts) require tooling that adapts to every unique stack and context—out-of-the-box static or generic tools don’t work.
- Moldable development treats every decision or question as deserving a micro-tool—mirroring the “write a test for every requirement” idea of TDD.
- Glamorous Toolkit is an open-source IDE built for this, making it low-cost (time-wise) to generate custom, highly contextual micro-tools.
Quote:
"We are saying that the only deterministic tool that will work will be those that are built to match the context."
—Tudor Girba [27:54]
8. Case for Continuous Tooling (Parallel to TDD)
[29:26 - 32:25]
- Just as TDD democratized test-writing by making it quick and cheap to add tests, moldable development’s value is in making it fast and cheap to build contextual tools for any imaginable system question.
Quote:
"We are essentially approaching every single development problem as a little tiny empirical scientific discovery problem. ... We can take the testing lessons and simply generalize it to everything else."
—Tudor Girba [29:42]
9. Software Engineering’s Uniqueness and Knowledge Work
[33:39 - 35:29]
- Unlike other engineering, software’s internal “shape” is totally invisible except through tools. Developers must build tools to perceive, comprehend, and reason about their own work.
- The convergence of subject (code) and tool (development environment) is unique to software. Thus, tool-building becomes a core competency, not an optional extra.
Quote:
"The object of our work is invisible, it's not perceivable except through tools. ... In software they are the same. This presents itself with a unique opportunity and ... a different kind of lesson."
—Tudor Girba [33:39]
Notable Quotes & Memorable Moments
-
"Software doesn't have a shape because it's just data. But we as humans, we need some sort of a shape, some representation in order for us to perceive so that we can reason."
—Tudor Girba [03:52] -
"Reading is the most manual possible way to extract information in other systems."
—Tudor Girba [17:28] -
"We can optimize decision making in software engineering with at least an order of magnitude. And if this is correct, this can be directly transformed into a competitive advantage."
—Tudor Girba [36:00]
Timestamps for Key Segments
- [02:26] — What is Moldable Development?
- [04:41] — Telco story: Real-World Case Study
- [12:05] — Why code reading is an intractable bottleneck
- [14:12] — Hidden costs of code reading
- [18:00] — The limits of AI code assistants
- [20:25] — How Glamorous Toolkit enables micro-tools for every question
- [27:54] — Contextualization necessity and parallels to TDD
- [29:42] — Moldable development as scientific discovery
- [33:39] — Software’s uniqueness: invisibility and tool dependence
- [36:00] — Where to learn more: multipledevelopment.com, gtoolkit.com, fink.com
Resources and Links
- Book: multipledevelopment.com (Rewilding Software Engineering)
- Glamorous Toolkit: gtoolkit.com (open source; micro-tools IDE)
- Company: fink.com (consulting on legacy/competitive projects)
- Tudor’s LinkedIn: [Link in show notes]
Conclusion
The episode delivers a compelling case for moving beyond generic, static development environments (and even beyond current AI codebots) to a paradigm where the ability to quickly create and evolve context-specific tools is foundational. Tudor Girba’s experiences and research (embodied in the free Glamorous Toolkit and the upcoming book) show that this way of working is not only possible but crucial for tackling complexity and creating real competitive advantage in modern software engineering.
Perfect For:
- Agile/Scrum Masters, architects, tech leads, and senior developers dealing with legacy systems, complex code bases, or seeking next-generation developer productivity methods.
"You need a new kind of a development experience that should be focused not on what exists out of the box, but on how quickly you can create a contextual tool."
—Tudor Girba [32:25]