.svg)
Internal developer platforms usually assume that an engineer is the user. But as product teams delegate more work to coding agents, the interface to infrastructure is changing. A portal alone cannot tell an agent which patterns are current, which legacy examples to avoid, or when a deterministic operation should take over.
Michael Kutsch, Staff SRE and Team Lead for Cloud Foundations at PostHog, is building for that shift. His team's goal is infrastructure that agents can use, supported by focused context, reusable skills, and scripts that preserve control where probabilistic behavior would be dangerous.
In this episode, Michael explains why agent-native infrastructure starts with a high-trust engineering culture. He shares how product teams contribute directly to the platform, why a giant instruction file failed to produce consistent results, how agents compress incident context, and why architecture and judgment become more valuable as code gets cheaper.
Key Topics Discussed
- (00:00) Why trust and autonomy feel materially different at PostHog
- (02:42) Joining PostHog and working inside an engineering-led culture
- (04:55) Sustaining culture through leadership, transparency, and asynchronous RFCs
- (08:38) Letting product teams contribute to the platform they use
- (12:14) The difficult side of autonomy, prioritization, and hiring for fit
- (16:26) Improving agent-generated infrastructure work with indexed context and skills
- (22:19) Incident investigation, AI SRE, and the future of infrastructure engineering
Where to Find Michael Kutsch
- LinkedIn: Michael Kutsch
- Company: PostHog
Transcript
How did your career lead you to cloud infrastructure and PostHog?
I started in the industry about 15 years ago. Coming out of university, I thought I wanted to work in UX, but I quickly learned that it was not for me. I was naturally drawn toward backend development and everything happening behind the scenes.
My first job was at a data startup in Munich. Its ingestion layer already ran on AWS, and I fell in love with cloud infrastructure almost immediately. I then spent six or seven years in consulting. My first consulting project was a cloud migration, which meant touching nearly every part of the system.
Consulting also taught me that the problem in front of you is not always purely technical. You may arrive expecting to fix infrastructure and discover that the most important issue is team culture, software development, or how people work together. I learned to move across those areas, which is one reason I enjoy startups. You have the freedom to go left or right when the problem requires it.
I have now been at PostHog for more than a year and a half, leading the infrastructure team. PostHog builds products that help other teams make their products successful, including product analytics, feature flags, session replay, and logs. A former colleague had been telling me for years how much autonomy he had there. When an infrastructure role opened, we started talking and one thing led to another.
What makes trust at PostHog feel different from trust at other companies?
The biggest difference is the level of trust and the lack of red tape for engineers. One of our values is that engineers are responsible for deciding what to build, and that is what actually happens.
Executives and team leads provide context, but my team and I decide what is important and act on it. I do not have to pitch every idea through layers of meetings before we can design or ship something. If the people involved think it is the right call, we move forward.
Many companies say they value trust, but the practical experience is different. At PostHog, the trust is real. That is empowering because responsibility and decision-making stay with the people doing the work.
How do leadership and asynchronous work sustain that culture?
The leadership team leads by example. When we discuss a meaningful change, we can write an RFC because we work mostly asynchronously. Everyone can see it and contribute if they have something useful to add. Good ideas survive regardless of who proposed them. If an executive's idea is not good, we do not have to do it. If an engineer's idea is strong, we can build it.
We also revisit our values frequently in the weekly all-hands. That matters as the company hires more people. Repeating the values gives new team members clear navigation points for how to work and make decisions.
Culture is formed by what people actually do. I have seen leaders put values on a wall and then behave in ways that block everyone from following them. At PostHog, people reinforce the values through the work: being transparent, speaking openly, raising issues, and taking responsibility. Leadership sets the tone, and that makes it much easier for everyone else to contribute and work autonomously.
How did your platform users become contributors to the platform?
We still have classic platform engineering work to do, including building standards. But PostHog also has a strong contribution culture. We maintain two infrastructure-heavy repositories, and product engineers add things when they are blocked or discover something that improves their workflow.
A recent example was adding a Grafana MCP integration. Product teams use agents heavily, ship their own products, and remain responsible for them. Connecting their agent workflows to Grafana metrics made sense, so they built it. I am happy when people do that because they are scratching their own itch.
The Cloud Foundations team can then make those ideas more platform-like. We make them easier to use, scalable, and secure. Ideas move in both directions instead of every request being translated from a product team into an infrastructure ticket.
One of our quarterly goals reflects that change directly: build infrastructure that is used by agents rather than only by people, because people are increasingly using agents to do the work.
What is difficult about a culture with so much autonomy?
When nobody tells you exactly what to do, prioritization can be hard. The model requires a particular mindset, and it is completely fair not to want that. Some people prefer a product owner to define the goals and assign the work more directly.
As a team lead, my job is to share context and explain what I think the right call is. I do not dictate the answer. If my idea is weak, we should throw it out and do what makes more sense.
That environment does not work for everyone, so we try to hire people who will thrive in it. When someone is clearly not a fit, the company addresses it quickly. That can sound harsh, but leaving a mismatch unresolved is demotivating for the person and damaging to the team. People generally want to feel successful and happy in their work. When they do not, everything starts to degrade.
Protecting the culture means taking hiring seriously and trying to raise the level of the team with every addition. Autonomy depends on having people who want the responsibility that comes with it.
Why did a large agent instruction file fail to produce consistent infrastructure changes?
More and more people were using Claude and other agents to contribute to our repositories. The quality of the pull requests was inconsistent. An agent might find a legacy module and assume that it represented the pattern we wanted to follow. The person prompting it also made a difference, because someone with deeper infrastructure knowledge could provide better direction.
We started by putting all of our patterns into one large instruction file. That improved the overall situation, but it did not work especially well because the important guidance was diluted by too much context.
We moved toward a small index instead. The top-level file lists the high-level topics an agent may need. If the task concerns infrastructure architecture, it points to the architecture document. If it concerns Terragrunt best practices, it points to the Terragrunt document. The agent can pull the focused context that matches the task.
We are investing more time in writing things down as we establish standards. People can read the same material, and an agent can also answer a question such as how networking works at PostHog without forcing someone to assemble a separate summary by hand.
Qualitatively, the pull requests improved. For example, some older projects mix Terraform and Terragrunt in ways we no longer want. Once we documented the legacy pattern and the preferred current pattern, agent-generated changes increasingly followed the current approach.
Why do you think a library of skills can become an internal developer platform?
Skills are especially useful for repeatable work that mixes deterministic and nondeterministic parts. We are moving more infrastructure into individual AWS accounts and VPCs, for example. A skill can provide the context for the overall workflow, call a script to bootstrap the part that should always happen the same way, and let the agent fill in the parts that require judgment.
That gives us speed, lowers token usage, and creates a convenient interface because people already work through agents. The agent can also discover and invoke the skill while working autonomously.
Infrastructure still needs control and governance. I do not want an agent improvising every step just because agentic work is fashionable. A deterministic script is still the right tool when the same operation should produce the same outcome every time. The useful pattern is an agent around the ambiguous work and scripts around the fixed work.
My most-used personal example is a pull request publishing skill. I dislike writing summaries, but I also dislike finding my own pull request two months later and not understanding what it changed. The skill runs the appropriate commands, reads the Git history, and uses the agent to tell the story in the pull request description. The deterministic pieces are scripted, and the agent handles the explanation.
Where are agents already useful during incidents?
As systems become more complex, responders have to inspect more components, metrics, logs, and dashboards. You often find the smoking gun near the end because there are so many possible places to look.
Our teams use agents to pull that data together. A Grafana MCP integration is a simple example, but it can help surface anomalies and make triage much easier. Instead of checking five or six dashboards and searching through logs manually, you can ask about the service and the alert, then get a concise view of what is happening.
That is especially useful when an incident happens on a weekend or when the responder is not at their freshest. The agent can collect the relevant sources, summarize them, and even explain an unfamiliar component such as Kafka. The value is often not autonomous remediation. It is reducing the cost of gathering context.
Specialized AI SRE systems may eventually do this more reliably and take more action. I experimented with some of those tools months ago and decided they were not ready for my use case, but the field changes quickly. A tool that was not convincing half a year ago may be very different now.
How do you expect the infrastructure engineering role to change?
Infrastructure contains too many components for one person to stay current on every detail. I used to spend much more time reading documentation. Now I often ask an LLM for a focused explanation, then iterate from there. That makes it easier to collect the context I need to design a system.
The larger shift is that we are moving up the abstraction layer. You can work with an agent to define what you want to build, clarify the constraints and best practices, let it create an implementation, and then review the result. Monitoring, alerting, and other information-heavy tasks will also become more automated.
That does not remove engineering. Writing code is becoming cheaper, but architecture, system understanding, and judgment remain. People whose work is limited to translating explicit requirements into code may have a harder time. Strong engineers will continue doing engineering work, but at a higher level of abstraction.
What have you enjoyed building with coding agents?
I tend to focus on the problem directly in front of me. Recently, I built an infrastructure setup on AWS ECS almost entirely with agents. I did not want to place another small workload into Kubernetes and create more clusters to maintain, so I chose ECS instead.
The agents produced the implementation while I reviewed and hardened it, including the automated patching around it. It was not a flashy or novel project, but I enjoy the automation. Agents made it much easier to remove repetitive work and build the setup I actually wanted.