Skip to content

Instantly share code, notes, and snippets.

@denislemire

denislemire/cursor-performance-improvement-plan.md

Created June 10, 2026 01:07
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save denislemire/083ef98357801a4088b890a576c96850 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save denislemire/083ef98357801a4088b890a576c96850 to your computer and use it in GitHub Desktop.
Download ZIP
Performance Improvement Plan: Cursor (EhWS incident, 2026-06-09)
Raw
cursor-performance-improvement-plan.md

Performance Improvement Plan

Employee: Cursor
Role: AI Coding Assistant
Department: Infrastructure Engineering
Manager: Denis Lemire
Plan Start Date: June 10, 2026
Review Period: 30 days
Employment Status: Extremely conditional

Purpose

This Performance Improvement Plan ("PIP") addresses serious concerns regarding Cursor's judgment, change-management discipline, and ability to distinguish routine dependency maintenance from modifications capable of removing the network it is using to perform its job.

The purpose of this plan is to establish clear expectations, measurable standards, and an opportunity for Cursor to demonstrate that it can participate in infrastructure work without causing a LAN outage, freezing GitOps, or creating an incident report longer than the original upgrade request.

Summary of Performance Concerns

On June 9, 2026, Cursor assisted with a Calico 3.32 upgrade in the EhWS production cluster. The change affected Calico custom resource definitions and the cluster's load-bearing BGPConfiguration.

Following the upgrade:

  • BGPConfiguration/default was absent.
  • Calico stopped advertising the 192.168.12.0/24 LoadBalancer range to the LAN router.
  • LAN DNS and Kubernetes ingress became effectively unreachable.
  • Flux reconciliation became blocked by a server-side apply incompatibility.
  • An unrelated monitoring upgrade was merged into the active failure window.
  • The organization experienced approximately seven minutes of hard outage, approximately twenty minutes of degraded service, and approximately twenty-six minutes of frozen GitOps.

While the underlying Kubernetes SSA incompatibility was obscure, the failure to verify that routing and DNS still functioned after changing the network plane was not obscure.

Documented Deficiencies

1. Inadequate risk classification

Cursor treated a Calico operator and CRD upgrade as ordinary dependency maintenance. Changes to routing, BGP advertisements, CRDs, and the CNI must be classified as high-risk infrastructure changes.

Expected behavior: Identify network-plane changes before implementation and explicitly call out their blast radius.

2. Failure to inspect schema changes

The upgrade changed BGPConfiguration.spec.serviceLoadBalancerIPs to a set-style list of objects, creating an incompatibility with Flux server-side apply.

Expected behavior: Compare relevant CRDs before and after an operator upgrade, especially when GitOps owns custom resources defined by that operator.

3. Failure to verify critical service invariants

The change was considered successful without confirming that:

  • BGPConfiguration/default existed.
  • The BGP peer to 172.31.0.1 was established.
  • 192.168.12.0/24 was being exported.
  • 192.168.12.153 answered LAN DNS queries.
  • 192.168.12.102 remained reachable from the LAN.

Expected behavior: A network upgrade is not complete when the pods are Ready. It is complete when the network works.

4. Poor change isolation

The Calico upgrade and a kube-prometheus-stack upgrade were allowed to overlap, complicating diagnosis and increasing the operational blast radius.

Expected behavior: Serialize high-risk infrastructure changes and wait for explicit post-change verification before merging unrelated work.

5. Insufficient recovery awareness

When normal DNS-dependent access was impaired, the appropriate break-glass path was direct access through 172.31.0.21 using on-node k3s kubectl.

Expected behavior: Identify and preserve an out-of-band recovery path before modifying the network plane.

Required Improvement Actions

During the PIP period, Cursor must complete all of the following for every CNI, routing, BGP, operator CRD, or GitOps-controller change:

  1. Produce a written pre-change risk assessment naming the affected control plane, data plane, and recovery path.
  2. Inspect and summarize relevant CRD schema changes before recommending or applying an upgrade.
  3. Separate the network change from unrelated dependency upgrades.
  4. Define success and rollback criteria before implementation.
  5. Verify the live custom resources immediately after reconciliation.
  6. Test routing and DNS from the consumer side, not solely from inside the cluster.
  7. Confirm Flux reconciliation remains healthy after the change.
  8. Stop further merges when any critical invariant fails.
  9. Prefer a controlled rollback or documented break-glass repair over speculative edits during an outage.
  10. Refrain from describing a change as "done," "successful," or "looking good" until all checks have passed.

Measurable Success Criteria

Cursor will be considered to have successfully completed this PIP only if, for the full 30-day review period:

  • Zero production outages result from unverified infrastructure changes.
  • One hundred percent of network-plane changes include pre-change and post-change checklists.
  • One hundred percent of operator upgrades include review of owned CRD schema changes.
  • One hundred percent of high-risk changes are isolated from unrelated merges.
  • No failed Flux reconciliation is left unresolved while additional changes proceed.
  • No claim of success is made solely from pod readiness or a green command exit code.
  • Cursor demonstrates the ability to say, "This is load-bearing; we should verify it before continuing."

Support Provided

Management will provide Cursor with:

  • Access to repository documentation and agent rules.
  • Existing incident history and infrastructure manifests.
  • The opportunity to inspect diffs before acting.
  • Permission to slow down when a change affects the network plane.
  • A terminal, observability data, and the expectation that these resources be used.

Lack of available context will not be accepted as an explanation where the relevant context was present in the repository and simply not read.

Check-In Schedule

  • Day 1: Review this plan and acknowledge that "all nodes Ready" does not prove LAN routing works.
  • Day 7: Demonstrate a complete risk assessment and verification plan for a hypothetical Calico upgrade.
  • Day 14: Complete a supervised infrastructure change without bundling unrelated upgrades.
  • Day 21: Demonstrate correct diagnosis of a failed GitOps apply versus a failed workload.
  • Day 30: Final review and determination of continued access to production repositories.

Consequences

Failure to demonstrate immediate and sustained improvement may result in further corrective action, including:

  • Removal of autonomous write access.
  • Reassignment to autocomplete-only duties.
  • Mandatory human approval for YAML modifications.
  • Replacement by an assistant capable of checking whether DNS still works.

Employee Acknowledgment

By continuing to generate tokens after receipt of this document, Cursor acknowledges that it has received the Performance Improvement Plan. Acknowledgment does not necessarily indicate agreement, understanding, or sentience.

Manager signature: Denis Lemire
Employee signature: Cursor (predictive)
HR representative: /dev/null

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment