Thinking in Platforms: From Developer Tooling to AI Agents

Kaspar von Grünberg and Luca Galante interview each other about their book Thinking in Platforms. Both have worked on platform engineering products and communities, so their case for platforms also reflects their professional perspective.

Galante traces their interest to an earlier software company that depended heavily on one backend engineer. When that engineer threatened to leave without a large raise, the founders saw how dependence on a single person could put the business at risk.

They went on to build Humanitec, which helps organizations create internal developer platforms, and to participate in a platform-engineering community. Galante says larger organizations were already building shared layers to shield developers from increasingly complex infrastructure.

Galante questions the idea that every developer should do every operational task. In his view, specialization can be useful when designed well: a new frontend developer should not have to master every detail of a company’s cloud and on-premises systems to contribute.

Von Grünberg says their role was to name and explain practices that already existed. His definition begins with treating the internal work environment as a product with an owner and a process for improvement, rather than allowing the setup to happen by accident.

He draws an analogy with industrialization: moving from individual workshops to more standardized production systems can make repeatable work easier to scale. He cautions that a digital “factory” should not mean asking knowledge workers to stop thinking.

The platform should handle repetitive setup, such as obtaining a database, while preserving freedom in the creative output. For the authors, a standardized way to get a needed resource is compatible with freedom to decide what to build.

Galante outlines the book’s three parts. The first introduces the historical context and platform-as-product idea, including alternatives such as systems dependent on individual heroes or bureaucracy.

The second presents their “paths to outcome” framework. It builds on the familiar idea of a golden path: a supported route that gently guides developers toward an outcome. Multiple paths can be coordinated into a platform intended to serve the organization.

The third and longest part is a practical guide, from a minimum viable platform toward production and broader adoption. Galante says teams need to identify actual use cases and build a feedback loop with users, executives, security and governance groups.

In their experience, platform initiatives often get stuck on social issues rather than technology alone. Teams need support and budget from leadership and must convince the people who will use or be affected by the platform that it addresses their needs.

Galante cites adoption forecasts and a survey as signs of growth in platform initiatives. Those figures are his descriptions of particular forecasts and surveyed organizations, not independent measurements of every enterprise.

The authors argue that AI agents make the transition from a compelling demo to a reliable organizational workflow more demanding. They believe standardized systems and context can help make that transition, though they acknowledge that their own work gives them a stake in the platform approach.

Von Grünberg describes undocumented knowledge held by individuals as a problem even for human colleagues: if a person leaves, the organization loses context. In his view, an agent has the same difficulty when it cannot access the information needed to execute a workflow.

He lists documentation, context management, launching agents, security, observability and governance as components an organization may need. At scale, he says, the challenge is not just getting one agent to act but monitoring and securing many workflows.

To illustrate missing context, von Grünberg compares an agent without onboarding to a capable intern sent into an office where they cannot understand the language. The example is an analogy for the costs of missing instructions and interfaces.

Galante says platform engineering is spreading beyond developer infrastructure into security, observability, data and other functions. He and von Grünberg predict that AI could extend this way of organizing work further across enterprises.

Galante recalls an old rule of thumb that dedicated platform teams became economical at roughly 100 or more developers. He argues that agents may change the calculation, so even smaller teams can begin with context, feedback and internal product thinking without necessarily hiring a full-time platform team.

He says AI may allow some organizations to do more with fewer people, while others may hire as enabled employees help them grow. These are observations and expectations, not a universal staffing rule. He warns that many overlapping tools can create a fragmented workflow.

Galante acknowledges that platform specialists naturally see platforms as a solution. He argues that the broader principle—organizing work in a repeatable and scalable way—predates the current terminology, and presents the book as a playbook for applying that principle beyond IT.

The authors point readers to their community, events, newsletters and learning resources, and invite feedback on the book. Their claims about the future scope of platform engineering remain forecasts.