How AI Bridged a Tooling Gap: Extending InSpec for Kubernetes CRDs

#platformengineering #devops #ai #kubernetes

The Problem: Trailing Ecosystems in Infrastructure-as-Code

As infrastructure and platform engineers, we spend a lot of time dealing with libraries that are just feature-complete enough to be useful, but still have rough edges.

Recently, I was writing compliance tests using InSpec to validate some Kubernetes infrastructure. While InSpec provides solid compliance-as-code capabilities, its Kubernetes resource pack hasn't evolved much in recent years. If you are working with modern cloud-native architectures, like testing the newer Gateway API standards, you quickly realize it's missing foundational building blocks.

In my case, I needed to validate Custom Resource Definitions (CRDs).

The Mirage: A Confident Hallucination

When I first paired with an AI model to spin up the compliance tests, it spit out exactly what I wanted to see. The loop looked clean, intuitive, and natural:

expected_standard_crds.each do |crd_name|
  describe k8s_custom_resource_definition(name: crd_name) do
    it { should exist }
    its('spec.group') { should cmp 'gateway.networking.k8s.io' }
  end
end

There was just one issue: k8s_custom_resource_definition does not exist in the InSpec Kubernetes resource pack. The model had completely hallucinated the API wrapper.

Normally, this is the point where you sigh and prepare to write a messy workaround. In InSpec, that usually means dropping into raw Ruby, shelling out to kubectl via command resources, or parsing raw JSON strings, completely destroying the clean, expressive nature of compliance-as-code.

The Twist: Engineering the Abstraction with Claude

When I brought this problem to Claude, it didn't just apologize and rewrite the test using a messy workaround. Instead, it spotted the framework's gap and pivoted to an engineering mindset.

It realized that to make that ideal test code work, it just needed to build the missing abstraction.

By dropping into InSpec's underlying K8s client backend, Claude generated a custom resource implementation and placed it right into the profile's libraries/ directory:

# libraries/k8s_custom_resource_definition.rb

class K8sCustomResourceDefinition < Inspec.resource(1)
  name "k8s_custom_resource_definition"
  desc "Verifies a Kubernetes CustomResourceDefinition exists."

  example "
    describe k8s_custom_resource_definition(name: 'gateways.gateway.networking.k8s.io') do
      it { should exist }
      its('group') { should cmp 'gateway.networking.k8s.io' }
    end
  "

  def initialize(opts = {})
    @crd_name = opts.fetch(:name)

    begin
      @crd = inspec.backend.client.api("apiextensions.k8s.io/v1")
        .resource("customresourcedefinitions")
        .get(@crd_name)
    rescue ::K8s::Error::NotFound
      @crd = nil
    end
  end

  def exists?
    !@crd.nil?
  end

  def group
    @crd&.spec&.group
  end

  def resource_id
    @crd_name
  end

  def to_s
    "Kubernetes CustomResourceDefinition #{@crd_name}"
  end
end

Because Claude correctly mapped the apiextensions.k8s.io/v1 resource endpoint, the original, elegant test loop now worked flawlessly.

The Real Leverage of AI in Platform Engineering

We often talk about AI in the context of writing boilerplate application code or scaffolding quick utility scripts. But for infrastructure engineers wrestling with fragmenting or trailing open-source ecosystems, the real leverage might be ecosystem expansion.

When open-source tools are 80% complete, we usually inherit the technical debt of bridging the final 20% ourselves. If LLMs can shift from "writing code within the strict constraints of a tool" to "dynamically rewriting and extending the tool itself," it completely changes how we maintain our platform tooling stack.

Have you experienced a similar workflow where one model's hallucination became the blueprint for another model to extend a framework?

Let's discuss in the comments!