Alex Kaserbacher

Platform teams shouldn't predict the future but observe the present.
When multiple teams build similar solutions, commoditize the pattern. Make it the default, keep escape hatches.
Good ideas spread upwards through platforms, not downwards through rules and mandates.

Teams anchored to solutions defend them even when their context changes. Teams anchored to problems evolve.
'We manage Jenkins' (rigidity)
'We enable continuous delivery' (adaptability)
When your identity is the solution, you protect it. When it's the problem, you solve it.

Internal platforms aren't infrastructure tools. They're organizational memory. Each capability encodes a problem multiple teams already solved. Platform teams aren't only service providers, but curators of collective learning.

YouTube video by Modern Software Engineering Does Your Software Development Prioritize Business? #agile

My latest YouTube short for the Modern Software Engineering channel, "Does Your Software Development Prioritize Business?": www.youtube.com/watch?v=cRut...

The rise of "context engineering" Header image from Dex Horthy on Twitter. Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the…

Don't focus on engineering prompts, focus on engineering context instead.

"[...] as applications grow more complex, it’s becoming clear that providing complete and structured context to the AI is far more important than any magic wording.

blog.langchain.com/the-rise-of-...

I remember Adrian Colyer publishing a post about David Parnas’s work in the context of modern microservice architectures a few years ago. Unfortunately, his blog is no longer online, but thanks to the Wayback Machine, I was able to dig it up.

web.archive.org/web/20240424...

I already enjoyed his absolute masterpiece "The Creative Act," (which I highly recommend - get the hardcover, the binding is great) and am very much looking forward to his work on AI and engineering. Check it out here: www.thewayofcode.com

Seriously? How awesome is this? Rick Rubin, the legendary producer of artists like Neil Young, U2, Metallica, Adele, System of a Down (and many more), wrote a book with Anthropic on Vibe Coding!

Productivity Through Play: Why Messing Around Makes Better Software Engineers In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to Holly Cummins about productivity in creative knowledge work like software engineering. She talks about how "messing around…

@hollycummins.com 's discussion in the Engineering Culture podcast about developer productivity reminds me a lot of Cal Newport's notion of "seudo productivity" vs "slow productivity" in his newest book (buff.ly/VBBEZBi)

Btw, give the podcast episode a listen, it's great:

Embedding a deep understanding within organizations about the fact that architecture, organizational structure, and (human) communication are interlinked.

I like how you show services as enablers for team autonomy. I often think of "teams that own them can work independently" as a north star for improving flow, since full independence is hard to reach (there will always be _some_ things stream-aligned teams need to work together on and collaborate).

From the article: "everybody tests in production, whether they admit it or not; good teams are aware of this and build tools to do it safely"

Deploys Are The ✨WRONG✨ Way To Change User Experience This piece was first published on the honeycomb.io blog on 2023-03-08. …. I’m no stranger to ranting about deploys. But there’s one thing I haven’t sufficiently ranted about…

This is actually one of the best-structured arguments for using feature flags that I've seen in a long time: buff.ly/dgOdKlV

Separate deployments (continuously delivering code to production) from releases (switching code "live" for users).

When I vibe code, I often intervene in the process with something like "hey, you might try X instead of Y."

For me, the process of coding with AI is a very active one. Like Pardis said in her post, reviewing code is essential. Use the tools to reason about the code and utilize the gain in iteration speed to actively contrast different approaches to solve the problem.

I myself have experienced accelerated learning, but on a different level. Instead of reasoning about code details, I am able to focus much more on architectural concepts and ideas as well as iterate on them much faster and compare different approaches.

What I found to be particularly interesting is the question about learning: "When I vibe code, especially in a domain I’m not familiar with, am I actually learning anything? This is where I’d recommend reviewing every change before every commit."

Vibe coding a data room app Building an intuitive data room app to streamline investor access to startup information

Great advice and best practices for AI-assisted coding by @djpardis.com djpardis.com/blog/2025/06...

I myself have experienced accelerated learning, but on a different level. Instead of reasoning about code details, I am able to focus much more on architectural concepts and ideas as well as iterate on them much faster and compare different approaches.

What I found to be particularly interesting is the question about learning: "When I vibe code, especially in a domain I’m not familiar with, am I actually learning anything? This is where I’d recommend reviewing every change before every commit."

YouTube video by The Pragmatic Engineer Things you didn't know about GitHub - with CEO Thomas Dohmke

Check out the full interview here: www.youtube.com/watch?v=2oq_...

He also mentioned some independent services that have different scaling needs from the platform itself, such as the Copilot API and Actions. This is pragmatic. Use deployment boundaries where they really matter: supporting varying load patterns or improving team independence.

I listened to @gergely.pragmaticengineer.com interview with GitHub's CEO @ashtom.bsky.social today. What amazes me is that GitHub is mostly still a monolithic Ruby on Rails application and that it works so reliably at that scale.

I'm also wondering: what about generated code? Does it have the same effect on teams and their perceived ownership of their (generated) artifacts? Might be an interesting area for research.

While I'm bullish about LLMs and use them widely myself, this issue is something I've been worried about for a long time. Now, some empirical evidence seems to be emerging about this.
arxiv.org/pdf/2506.08872

Network Communication And Leaky Abstractions Synchronous communication in distributed systems is a leaky abstraction. Discover how asynchronous messaging builds resilient systems that decouple services from unpredictable network failures.

Synchronous communication in distributed systems is a leaky abstraction. My new article shows how asynchronous design helps in building resilient, decoupled systems. Discover more: www.shapingshifts.com/p/network-co... #SoftwareArchitecture #DistributedSystems

Designing Effective Cross-Team Dynamics For Platform Teams Discover how to transform platform teams from bottlenecks into powerful enablers.

I just published a new article on the dynamics between platform and application teams. Discover how to build platform teams which enable teams instead of becoming a bottleneck. Read the full article here: www.shapingshifts.com/p/designing-...

UnConference "Software-Entwicklung und Menschen - Team-Topologies, sozio-technische Systeme, Conway's Law und mehr"
Montag 2024-02-26 17:30
Kostenlos!
Registrierung: zoom.us/meeting/regi...

Danke an alle, die beim Vortrag von Stefan Toth und mir auf der @OOP Konferenz dabei waren. Wir haben über Herausforderungen im Microservices-Umfeld gesprochen und diskutiert, wie evolutionäre Architektur dabei hilft. 👉 Folien-Download: www.embarc.de/microservice... #oop2024 #OOPMuc

Freue mich riesig auf meinen Vortrag heute um 14:30 auf der OOP gemeinsam mit Stefan Toth. Lasst uns gemeinsam diskutieren, wie evolutionäre Architektur bei modernen Herausforderungen im Microservices-Umfeld hilft. Seid dabei! #oop2024 #OOPMuc