Sowing the Agentic Brownfield

In the near future, it’s entirely plausible that your entire codebase will be written, refactored, and evolved by AI agents. But the “brownfield” you’ll inherit won’t be legacy human code, it will be legacy AI decisions. And those decisions will stem from choices you make today. For example, whether and when to adopt an AI-first development paradigm, and how to prepare your stack to reach that point.

the sprawl has sprawled.

I believe this shift requires a revival of spec-driven development: a discipline that ensures an agentic brownfield can be safely maintained, evolved, and understood by multiple future generations of engineers and product leaders. The challenges were detailed at the beginning of this video on the c4model. I happen to be preferring this at the moment, but are there are others as widely supported as UML/PlantUML/Mermaid?

Continue reading “Sowing the Agentic Brownfield” →

Evolving what development means

The shift to agentic code isn’t about replacing developers. It’s about evolving what development means. There are valid concerns AND solvable problems. Leaving engineering efficiency on the table is not an option.

“I Don’t Trust AI-Generated Code”

  • When was the last time you yolo’d a review for by a co-worker?
  • Good possibility you have transitive dependencies that you a) don’t know about and/or b) haven’t audited.
  • Trust isn’t binary, it’s earned through verification. In the kernel performance work I used to do, we’d compile 40 different kernel versions to isolate an issue. Each build was an experiment, each test a verification. We didn’t trust without validation.

Agentic code works the same way. You don’t trust the code because an AI wrote it. You trust it because:

  • It passes comprehensive tests you defined
  • It meets specifications you controlled
  • It survived review by humans who understand the business context
  • It performs correctly in production (the ultimate judge)
Continue reading “Evolving what development means” →

The Path to Vibe Coding for the Enterprise

Hey folks,

I’ve been spending a lot of time thinking about how we write software. Actually, this was spurred on by a recent project: I thought, how can I drive inference workloads to llm-d? How can I keep vLLM “hot”? codegen is an inference-heavy workload, so let me look deeper.

What I found was a series of opportunities that we’ll need to tackle in order to make “vibe coding for the enterprise” possible… Opportunities that I feel uniquely positioned and experienced to effect 😉

First, we have to face the problem. The need for software…truly secure software is obvious and growing in urgency. The solution to this is to stop writing software entirely.

Like every other career path that transforms and evolves, often suddenly and without warning, your entire career is about to transform and evolve.

Continue reading “The Path to Vibe Coding for the Enterprise” →

Announcing Reliability Nightmares (the SRE coloring book)

“We often think of movements as starting with a call to action. But movement research suggests that they actually start with emotion — a diffuse dissatisfaction with the status quo and a broad sense that the current institutions and power structures of the society will not address the problem. This brewing discontent turns into a movement when a voice arises that provides a positive vision and a path forward that’s within the power of the crowd.” — Harvard Business Review

The idea behind SIG-SRE started just like that — with emotion, and knowledge that the status quo would not produce the outcomes that Red Hat needs, in the timeframe it needs them, to become competitive in the managed services business.

In addition to the fun video we created for the kickoff, the team has put together a coloring book to highlight how SREs think and how the practice of SRE impacts service using a Kitchen Nightmares restaurant analogy.

Continue reading “Announcing Reliability Nightmares (the SRE coloring book)” →

What it’s like to work at Red Hat for 8 years…

I wrote this post in July 2017, and I just found it (4 years later) in my Drafts folder.  What a great journey down memory lane it was to read this today.  Ask 2017 me if he knew what he’d be into 4 years on, and…yeah.  Life moves pretty fast.

We have been doing a lot of hiring lately — I am lucky to be at such a company.  It feels like that’s all we’ve done over the time that I’ve been at Red Hat.  In every interview I am routinely asked what is it like to work at Red Hat. Mostly I’d pass on a few relevant anecdotes, and move on.

As I’ve just come up on my 8 year anniversary at Red Hat, I thought I would write some of this stuff down to explain more broadly what it’s like to work at Red Hat, more specifically in the few groups I’ve been in, more specifically my personal experience in those groups…

Continue reading “What it’s like to work at Red Hat for 8 years…” →