A few months ago, I wrapped up two consecutive batches at the Recurse Center, Spring 1 and Spring 2, 2026, for a total of three months. It’s traditional at RC to write what they call a “return statement” when finished with batch. This is an opportunity for me to reflect on everything I did, everything I learned, and the people I met. Many prior return statements you can find online come from people early or mid-career, joining RC to get their career started, take a break after a layoff, or pivot in their career. Layoff notwithstanding, mine is a little different.
I’ve been doing Infrastructure and DevOps work for just over thirty years along with a significant amount of Python coding and teaching. I came to RC to do a post-layoff reset, catch up on what’s “out there” in technology and complete two projects that have been on my radar for some time. Specifically I wanted to learn more about Agentic AI and Kubernetes Operator development, a detour from hardcore hands-on AWS and Kubernetes administration most recently.
I offer my perspective as someone who has been in this industry since before most of my batchmates were born, to help career-starters, career-shifters, or seasoned veterans.
When I started RC, I had two technical goals. It wasn’t entirely “get better at coding” but it was also to create portfolio projects that would help me understand concepts I had little knowledge of and that I felt were important for my career path. “Learn by Building” is the best way for me to grasp new concepts.
This is what I had on deck:
An AI Agent in Python: I didn’t want simply to install and use agents, as my infrastructure background might direct me. I wanted to build a non-trivial agent that did something useful. In the process I wanted to learn about MCP servers (building one myself), and how to run the agent against a local model rather than a commercial frontier model. This would give me the inner working knowledge vital to be effective at using a troubleshooting agent.
Kubernetes operator: I’ve worked with Kubernetes for years now, but it’s a completely different skill to extend its functionality. I wanted to understand operators as well as Custom Resource Definitions (CRDs) from the inside, not just from installing via helm charts or from the perspective of the kubectl cli.
I am proud to say I met both my goals, and come away with new skills and a solid foundation from which to grow further. There is still much more to do with these projects and far more to learn.
Batch Spring 1: An AI agent that troubleshoots Kubernetes clusters. I wrote a chatbot agent, and an MCP server, both in Python, and ran it against a local Ollama instance. The end result was an interactive chatbot where I could use natural language to troubleshoot problems on a live Kubernetes cluster. This broke me out of a cycle of “tutorial paralysis” where I was reading about this topic but not actually doing anything about it. Much of the research came out of some prompting in Claude along with blog posts of those who went before me in this topic.
I wanted this to work in a real cluster and actually find and suggest fixes for actual problems. (A little chaos engine magic, helped create the broken environments for me). Getting the agent to talk to Ollama was the hardest part at the start, more complicated than the theory of getting it to work. I got unstuck on it during pairing sessions with two people (Hyacinth and Miguel) who relieved me of a connection issue that I’d been spinning on for days. They walked through it with me, total time under an hour, with some human-generated code fixes.
That illustrated the big RC claim to fame: you don’t know everything (and can’t know everything) but someone two desks away may know the one thing you’re missing, and is willing to assist, without judgement.
Batch Spring 2: Kubernetes operator, built as part of a process of teaching me advanced Go. The second project was a Kubernetes operator, also for cluster troubleshooting, with custom resources that defined rules about things to monitor. In the long, slow climb up this learning curve I was forced to understand reconciliation loops and CRDs properly instead of glossing over them.
I used Claude Code deliberately in a kind of “teacher mode”. I did NOT let it write the code for me unless I was seriously blocked. I set it up to walk me through a “curated” mentorship. I had it help me plan the path, explain concepts as needed, let me attempt them, and correct me where I went wrong. It helped me start off with an MVP and then iterated over feature additions, rather than generating code I’d have to pore over to understand. That’s not how I wanted this to go. (Though I did have it often summarize our work for commit messages. That was a time saver.)
Given how some of my consulting work now involves helping other engineers use AI tools, this had the side effect of getting me to understand first-hand how to learn with AI as a companion, as much as it was to learn Go and operator/controller concepts. I am also thinking of how I can hook this into the first project, where it asks for solutions to the issues the operator finds in a cluster.
Both projects worked and I was proud to demo them to fellow Recursers. These projects are ready for expansion and more learning paths for me.
Most of my batchmates knew little about Kubernetes and were enthusiastic to tell me so when I described my Recurse projects. This was a welcome opportunity for me to teach at a place built around collaborative learning and pairing. I gave a quick 5 minute intro, and at the request of many, I then expanded it into a one-hour “Whirlwind Intro to Kubernetes.” My batchmates found it enlightening, the feedback being generally “I finally know what the thing does” or “I feel less intimidated by it now.” Best feedback ever.
I also gave short presentations on how to give presentations, a skill RC strongly emphasizes, and one I’d built up over decades. I also did (and continue to do) systems design interview prep for my fellow Recursers, an opportunity to give back drawing from my experience on both sides of the interviewing desk.
RC’s culture: no feigning surprise, no backseat driving, everyone curious rather than performing, all of this conducive not only to asking the hard questions but to answering them, being open and welcoming to those who want to know what I know.
That “dual role” is what I’d emphasize to another senior engineer thinking about doing a batch at RC: you’ll learn so much from people on the crest of what’s happening in the industry, and you’ll get to explain fundamentals to someone who can benefit from your experience.
You may even come out of it with new friends as I have.
I expected the technical material to be the hardest part (not that it wasn’t challenging): the plumbing of the communication among the Agent/MCP/LLM as well as the Go nuances I was still wrapping my head around.
What actually took adjustment was the atmosphere of generosity itself. Twelve weeks in a place with no judgment, where asking questions costs you nothing and admitting you’re stuck immediately gets you the help to get unstuck. This is not always something thirty years of professional work prepares you for.
Many workplaces talk about collaboration, and I have always emphasized teamwork and cross-team collaboration. But these same places don’t always set up an environment to nurture it. RC has just that nurturing atmosphere, one that encourages people to let down their guard and really work together.
If you’re deciding whether RC is for “someone like you” (decades of experience, not a career pivot, catching up on what’s happening in the industry, building new portfolio projects) I can say that RC is not concerned with the years behind you or ahead of you.
They care whether you’re curious, willing to be bad at something in front of strangers for a while, in a judgement-free zone, willing to get help, and willing to give it. I came in wanting to build up two specific skills I didn’t have. I left with that accomplished, a plan on how to structure my learning going forward, and a renewed passion for teaching, especially showing others about AI-assisted learning.
The experience has been a boost to my confidence and given me a more positive outlook in an industry that has been uncertain and stress-inducing for some time now.
Both projects are in working states ready for me to build upon them. The troubleshooting agent has obvious next phases, and the controller work can directly feed into consulting conversations I’m already having about EKS and platform engineering, part of building my independent consulting business. I’m carrying along with me the “teacher mode” approach to using AI tools.
I’ve also been successfully building my coaching business where I help engineers get unstuck in their career, another area where I can use my experience to benefit others, and another fire stoked by my time at RC.
To the people who helped me get over those humps when I got stuck myself, thank you! To the new friends I have, I look forward to the future!
For RC in general: it did for me exactly what it says it does for engineers and I can’t imagine my life right now without having had that experience.
If you are interested in checking them out for a local or remote batch, click here.