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”

weArIng a different hat (still Red)

Earlier in August 2023 I changed roles within Red Hat. My new role is “Chief AI/ML Platform Strategist”, and organizationally is part of Red Hat’s OpenShift AI product group.

I’d been in my previous role for ~5 years, and celebrated my 14th anniversary at Red Hat last month đŸ«¶ . My previous team (Red Hat Service Delivery) afforded me endless technical challenges, opportunities to launch new services, present, help define technical strategy and build cross-org engineering teams to support that strategy, from the ground up. Equally important to me was the opportunity to mentor as many Red Hatters as I possibly could.

And now, on to the next chapter. Red Hat’s CEO Matt Hicks did an interview recently that describes how Red Hat will participate in the AI/ML ecosystem as a platform company, specializing in machine learning operations (MLOps). My role involves working with engineering and product leaders to devise a strategy that will deliver a sustainable open source, enterprise software business around artificial intelligence and machine learning.

Continue reading “weArIng a different hat (still Red)”

If you’re totally comfortable to launch, you’ve waited too long.

It’s both exciting and nerve-wracking to develop highly visible production service platforms. Exciting, in that the ideation phase of creating a differentiated offering inspires “creatives” in the software engineering space to do their best work. Nerve-wracking, in that knowing the details of implementation, and what hit the editing room floor during planning/prioritization exercises, carries with it a certain sense of responsibility — especially if you end up being caught-out on any of those areas as “real usage” begins.

There was a fantastic paper written last year on the topic of creativity in software engineering. Highly encouraged reading, especially for software engineering managers, technical team leads, those involved in hiring/promotions and so forth.

In order to solve today’s complex problems in the world of software development, technical knowledge is no longer enough. Previous studies investigating and identifying nontechnical skills of software engineers show that creative skills also play an important role in tackling difficult problems.

Exploring the Role of Creativity in Software Engineering, Jan 2021, https://arxiv.org/pdf/2101.00837.pdf

For this blog, I’ll focus on the experience the team I led went through during the bring-up of a highly visible service launch scheduled for March, 2021 called Red Hat OpenShift on AWS (ROSA).

The ROSA service was a first-of-its-kind, first-party offering (transacted through Amazon) that would be added to the AWS console. That set the high bar for the team to deliver on what the business partnership between Red Hat and AWS had negotiated. Shortly thereafter additional first party services from partners were added to AWS console (Grafana has one at least). But indeed ROSA was the first 🙂

Continue reading “If you’re totally comfortable to launch, you’ve waited too long.”

What it’s like to be “how constrained” and becoming a free thinker

I think it’s most folks (engineers especially) default approach, when being introduced to a new system, product or idea, to immediately want to understand “how” something works. This blog is to specifically challenge that default, turn it around, and pose that we default to “why” something works. Why it has to exist, and why it is the way it is.

Continue reading “What it’s like to be “how constrained” and becoming a free thinker”