max heyer

going full ai engineer, not touching code anymore

Tue, 19 May 2026 00:00:00 +0000

I don’t write code anymore and I am not missing it.</p>

Not a function. Not a bug fix. Not a feature. From this blog to complex and ambitious work at enum</a>, things that should never break.</p>

And I love it.</p>

The part I thought was the fun part</a></h2>
I’ve been writing code for almost two decades. I was the kid running Linux and trying to create plugins for my Minecraft community. I remember the happiness I felt when things worked after hours of tinkering.</p>
Since then I worked on many projects, from simple websites as a teenager to highly scalable distributed systems at enum and Wunder Software. I optimized my whole workflow around coding. I use a split keyboard, I code in nvim and I touched a lot of programming languages. I love to create things and tinker around.</p>
It turns out I was wrong about which part I actually liked.</p>
The most fun was never in typing. The fun was in the deciding part of coding. What should this system do. How should it behave when things go wrong. What’s the right abstraction. Where does the complexity live. What is a solution for our problem.</p>
After many years into coding I found out that writing the code was the toll I paid to get those decisions into reality. Most of it was muscle memory: the same patterns, the same imports, the same retry loops, the same null checks, the same boilerplate I’d typed ten thousand times. The interesting part was over within seconds of opening the editor. The next six hours were translation.</p>
What I do now</a></h2>
I architect. I review. I push back. I argue. I read diffs carefully and reject the ones that solve the wrong problem. I write specifications and I watch multiple agents implement them. I notice when an agent has a pattern that doesn’t fit. I notice when test coverage is fake. I think about what should be a primitive and what should be composed.</p>
This is the work. The work was always this. The typing was overhead.</p>
The shift hasn’t made me lazier or sloppier - if anything, the opposite. I read more code now than I ever did before, because I’m reading the agent’s output instead of typing on my own. I think harder about the real problems, how we should implement a scalable reconciler pattern for the enum platform, where should data live, what is the real problem we should solve next? I have stronger opinions about the results and tests than ever before, because I’m the one who notices when they’re wrong.</p>
The skill that matters is taste. Whether you can tell when a design is bad. Whether you can spot the load-bearing assumption that’s about to break. Whether you know what to insist on and what to let go. None of that has changed. All of it matters more.</p>
I have a lot more time to focus on learning new things, figuring out how we scale our systems at enum, figuring out enum’s financing. Things that are much more important than seeing myself typing code 10 hours a day.</p>
The honest version</a></h2>
I should say the uncomfortable things.</p>
If AI coding disappeared tomorrow, if I had to go back to writing every line by hand - I think I would quit coding entirely.</p>
Not because I couldn’t. I still can. I’m probably sharper than I was a year ago just from staying current with the tooling. But I wouldn’t want to. It would almost feel like a waste of time. The years of muscle memory have already started fading and I’m not interested in rebuilding them. I have written enough software by hand to know what that feels like, and I am done with it.</p>
This is the part I struggle with when I think about it. Years of identity rests on “I am someone who writes code”. That identity is now contingent on a tool stack that’s three years old and could regress. If it breaks, the identity goes with it, and I’m fine with that.</p>
I think that’s the most honest signal I can give about what I actually valued. The thing I was doing all those years wasn’t writing code. I was making decisions and watching them become real. The agents make that loop shorter. Take the agents away and the loop becomes too long again. I’d rather do something else.</p>
This is not a vibe-coding manifesto</a></h2>
Vibe-coding without judgement is still dangerous. Letting an agent generate code you don’t read, into a system you don’t understand, is how production gets weird in ways you can’t debug at 3am. I’ve seen this. I’ve cleaned it up.</p>
What I’m describing is different. I read every diff. I reject a lot of ideas an agent has. I keep the agent on a short leash for anything load-bearing. The work has shifted from producing code to evaluating code, and evaluating is harder than producing - you have to be right about more things, faster, with less context.</p>
If you don’t have the taste, AI coding makes you worse. If you have the taste, it gives you back the time you were spending on translation.</p>
What comes next</a></h2>
I don’t know how this scales. I don’t know what it means for hiring, for juniors, for the next generation that will never type out a for loop the way I did a thousand times until it became reflex. There are real questions here that I don’t have good answers to.</p>
What I do know is what it feels like for me, right now, after a couple of months with this. The parts of the job I always loved got bigger. The parts I tolerated got smaller. I make more decisions per week than I used to make in a month. I ship more, think more clearly, and care more about what I’m building.</p>
This was always the job. The typing was just the toll.</p>
I’m done paying it.</p>

i personally paid for our cncf and linux foundation memberships and i'd do it again

Wed, 18 Mar 2026 00:00:00 +0000

I run a bootstrapped cloud company.</p>

Last year, we joined the Linux Foundation and the Cloud Native Computing Foundation as a Silver Member.</p>

I put my own money into enum</a> to make it happen. Because we’re self-funded and I wasn’t going to let cash flow be the reason we don’t invest in the ecosystem we depend on.</p>

There is no business case for this</a></h2>
Let me be clear: nobody is going to buy our Kubernetes platform because we have a CNCF logo on the website. No CTO will sign a contract because we’re on the Linux Foundation member page. It doesn’t move pipeline. It doesn’t close deals.</p>
So why do it?</p>
Because we’re not building a company that optimizes for the next quarter. We’re building for the long run.</p>
What we depend on</a></h2>
enum</a> runs on open source.</p>
Linux runs our servers. Kubernetes orchestrates our platform. The CNI, CSI, and CRI specifications define how our networking, storage, and container runtimes work. Every API we expose, every cluster we operate, every byte we store - all of that relies on projects that thousands of people built, mostly without getting paid for it.</p>
If we just take all of that and build a business on top without contributing anything back, we’re extracting value from a commons. That’s what most companies do. It’s legal. It’s normal. And it’s exactly what slowly kills the ecosystem everyone depends on.</p>
We don’t want to be that company.</p>
Cloud infrastructure in Europe</a></h2>
Here’s what bothers me about the European cloud market.</p>
Most European cloud providers ship products on top of open source but don’t participate in maintaining it. They don’t contribute upstream, don’t show up at CNCF meetings, don’t fund the foundations that maintain the software they profit from. Some of them claim sovereignty while migrating hundreds of thousands of employees from one US provider to another US provider.</p>
The US hyperscalers do invest. Google, Microsoft, Amazon, they employ hundreds of people who work full-time on open source. Say what you want about Big Tech, but they fund the commons.</p>
There are exceptions in Europe. SUSE has been a major open source contributor for decades. But these are the exceptions, not the norm. The gap is real.</p>
Most European cloud providers take the software, ship the product, and hope someone else maintains it. That’s not sovereignty.</p>
Why I care about this</a></h2>
I’ve been running Linux servers since I was twelve. I grew up with open source. Free software shaped how I think about technology, about collaboration, about trust.</p>
The internet was built on shared infrastructure. DNS, BGP, HTTP, TLS. None of these are proprietary. They exist because people agreed that some things should be open and maintained collectively.</p>
Cloud infrastructure should work the same way.</p>
I don’t think the answer to US cloud dominance is building European walled gardens. The answer is building European companies that participate in the global ecosystem as equals. Companies that contribute, not just consume.</p>
That’s what the Linux Foundation and the CNCF represent to me. Not a logo. A commitment.</p>
Being the good of the internet</a></h2>
There are companies that treat parts of the internet as shared infrastructure worth improving. Free TLS. Public standards. Upstream work. Making tools available that everyone benefits from, not just paying customers. That approach exists, but it’s not how most European providers operate.</p>
Most of them optimize for compliance, not contribution. They build on open source, sell managed services, and never look back. The foundations that maintain the software won’t hear from them. The working groups that define the standards won’t see them.</p>
I think there’s room for a European cloud company that does this differently. One that shows up. That funds what it depends on. That makes parts of its infrastructure free because some things should just be available. Not because it’s a clever funnel, but because that’s how the internet was supposed to work.</p>
I want enum</a> to be that. Yes, that sounds like a lot for a bootstrapped startup. I know. But the conviction doesn’t need an audience to be real.</p>
What this means in practice</a></h2>
Joining the foundations is step one. It’s the easiest step: Write a check, show up, participate.</p>
The harder stuff comes next. Contributing upstream. Publishing tools. Making parts of our platform free, not as a growth hack, but because some infrastructure should just be free. Building in public. Being transparent about how we operate, what we charge, and why.</p>
We’re a tiny team. We can’t mass-contribute to Kubernetes core or fund full-time maintainers. Not yet. But we can show up consistently, participate in the community, and build a company around the idea that open source isn’t a supply chain you exploit. It’s a community you invest in.</p>
The long game</a></h2>
I don’t know how big enum</a> will get. But I know what kind of company it is.</p>
If we keep showing up, contributing where we can, and building on top of what we help maintain, the company will either work or it won’t. But I’m convinced the business comes from doing it this way.</p>

kubernetes is not only about scalability

Tue, 14 Oct 2025 00:00:00 +0000

I use Kubernetes whenever possible - even for this blog.</p>

The problem with managing servers</a></h2>
I’ve been running Linux servers since I was twelve.</p>
And it’s always the same story:</p>

How do I run updates?</li>
What about networking?</li>
Backups?</li>
Security?</li>
Monitoring?</li>
And how the fuck do I configure all these services?</li> </ul>
Endless yak shaving before the code even runs.</p>
Even on VMs, I had to tinker with “hardware-level” details - network interfaces, storage, mounts, dependencies. So much overhead just to get a simple service online.</p>
Docker helped. But it also added complexity. We finally had containers, but no real consensus on monitoring, backups, or updates. Everyone solved these problems differently.</p>
Why standards without enforcements fail</a></h3>
Years ago I ran dozens of docker containers across Linux VMs on Proxmox hosts. I tried to standardize everything: Terraform, Ansible, Docker, GitOps.</p>
It worked until deadlines hit. Then people skipped steps, changed patterns, pushed quick fixes. Standards without structure die quietly, one exception at a time.</p>
And it wasn’t just us. Talking to others in the industry - customers, competitors, partners - everyone struggled with the same thing. Most didn’t even have GitOps. Everyone was building their own unique mess.</p>
Why Kubernetes is different</a></h2>
Kubernetes was built for Google-scale systems. 65,000-node clusters. That scale forces discipline. You can’t paper over inconsistency at that level.</p>
So I started experimenting with K8s on some VMs and immediately saw the difference. Networking, security, deployments, load balancing, configuration management - all built in with sensible defaults, all defined as code. Kubernetes made infrastructure problems disappear behind APIs.</p>
But here’s what really matters: K8s enforces standards. You can’t just configure networking however you want. You configure a Service resource. You don’t invent your own deployment pattern. You write a Deployment manifest. The API itself forces you into standardized patterns.</p>
With Ansible or Docker Compose, nothing stops you from doing it differently in every project. With K8s, the system only accepts resources that follow its specification. That’s why the standards actually work.</p>
Helm and Operators changed everything</a></h3>
Helm charts are blueprints for entire environments. You define services, dependencies, and configuration in a standardized format. You can publish them, reuse them, and deploy identical stacks anywhere in minutes.</p>
Yes, they can get complex. But it’s much simpler to read a complex Helm chart than reverse-engineering a landscape of half-documented Linux servers.</p>
Operators</a></h4>
K8s Operators take this even further. They make infrastructure self-managing. They are a software pattern to implement software-defined infrastucture.</p>
Take CloudNativePG: it runs PostgreSQL from single instances to full HA clusters with autoscaling, failover, and backups - all declaratively.</p>
`apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: cluster-example spec: instances: 3 storage: size: 1Gi </code></pre> Backups? Just another YAML config:</p>`apiVersion: postgresql.cnpg.io/v1 kind: ScheduledBackup metadata: name: backup-example spec: schedule: "0 0 0 * * *" # At midnight every day backupOwnerReference: self cluster: name: cluster-example </code></pre> That’s it. Networking, HA, storage, recovery - done.</p> Running everything on K8s</a></h3> Today I run as much as possible on K8s. From simple homelab stuff like Home Assistant to high available storage clusters. At enum</a> almost every service runs on K8s clusters. Each cluster shares the same defaults for networking, monitoring, storage, and backups. It’s predictable. Boring in the best possible way</strong>.</p> No SSH-ing into random servers. No debugging why NGINX is configured differently “just here”. Every deployment follows the same process. Every config lives in Git.</p> Yes, K8s does not enforce everything and people can still mess around and give a shit on any standards. But in reality K8s enforces a lot already and the community follows the standards, just because they see the benefits from it.</p> Use Managed Kubernetes</a></h4> You can run Kubernetes clusters yourself. But most teams shouldn’t.</p> Operating the control plane is its own craft - scaling, updates, disaster recovery, networking quirks. Most teams don’t need to care about any of that. They need to ship products, not clusters.</p> We operate a large-scale platform</a>. You don’t and you should not care about it. I’ve seen how easily people lose control of their systems once they start mixing automation with improvisation. Use a managed platform. It’s not less “real”. It’s just less painful.</p> Yes, K8s is not for everything</a></h3> Kubernetes isn’t the holy grail for every problem. But it’s holy for me.</p> Some workloads don’t belong there and that’s fine. The cluster overhead isn’t worth it for everything. I still run game servers and some monitoring tools on plain VMs - even a GitLab instance that breaks now and then. It’s fine. Some entropy is healthy.</p> But Kubernetes changed how I think about infrastructure. It turned chaos into code. It made systems boring - and boring is what reliability feels like.</p> If you’re thinking about trying Kubernetes, do it. You won’t regret it.</p>