DEV Community: Gabriel Anhaia

Stop Passing *sql.Tx Through Your Go Service Layer

Gabriel Anhaia — Fri, 10 Apr 2026 09:53:55 +0000

Your service needs to save an order and reserve inventory. Both must succeed or neither should. The instinct:

func (s *Service) PlaceOrder(ctx context.Context, tx *sql.Tx, req Request) error {
    if err := s.orderRepo.SaveWithTx(ctx, tx, order); err != nil {
        return err
    }
    if err := s.inventoryRepo.ReserveWithTx(ctx, tx, order.Items); err != nil {
        return err
    }
    return nil
}

This compiles. It works. And it destroys your architecture.

What's Wrong

Your domain now imports database/sql. The service knows what a SQL transaction is. Every port needs a "WithTx" variant. Your in-memory test doubles are useless — they can't accept *sql.Tx. And if you ever move to DynamoDB? Its transactional model is completely different. You're locked in.

The domain should express what needs to happen atomically. The adapter should decide how.

The Unit of Work Pattern

Define a port that says "execute these operations as one atomic unit" without specifying the mechanism:

type OrderSaver interface {
    SaveOrder(ctx context.Context, order Order) error
}

type InventoryReserver interface {
    ReserveInventory(ctx context.Context, productID string, qty int) error
}

type UnitOfWorkTx interface {
    OrderSaver
    InventoryReserver
}

type UnitOfWork interface {
    Execute(ctx context.Context, fn func(tx UnitOfWorkTx) error) error
}

The domain calls Execute with a function. Inside, it uses the tx to save and reserve. If the function returns nil, everything commits. If it returns an error, everything rolls back.

The Service

type PlaceOrderService struct {
    uow   UnitOfWork
    idGen IDGenerator
}

func (s *PlaceOrderService) PlaceOrder(ctx context.Context, customerID string, items []LineItem) (Order, error) {
    order := Order{
        ID:         s.idGen.NewID(),
        CustomerID: customerID,
        Items:      items,
        Status:     "pending",
    }

    err := s.uow.Execute(ctx, func(tx UnitOfWorkTx) error {
        if err := tx.SaveOrder(ctx, order); err != nil {
            return fmt.Errorf("saving order: %w", err)
        }
        for _, item := range items {
            if err := tx.ReserveInventory(ctx, item.ProductID, item.Quantity); err != nil {
                return fmt.Errorf("reserving inventory: %w", err)
            }
        }
        return nil
    })
    if err != nil {
        return Order{}, err
    }

    return order, nil
}

Count the imports. context, fmt. No database/sql. The service has no idea whether "atomically" means a SQL transaction, a DynamoDB transact-write, or an in-memory buffer.

The In-Memory Adapter (For Tests)

type InMemoryUoW struct {
    mu        sync.Mutex
    orders    map[string]Order
    inventory map[string]int
}

func (u *InMemoryUoW) Execute(_ context.Context, fn func(tx UnitOfWorkTx) error) error {
    u.mu.Lock()
    defer u.mu.Unlock()

    // Buffer changes
    tx := &inMemoryTx{
        orders:    make(map[string]Order),
        inventory: make(map[string]int),
    }

    if err := fn(tx); err != nil {
        return err // discard buffer = rollback
    }

    // Commit: apply buffered changes to real state
    for id, order := range tx.orders {
        u.orders[id] = order
    }
    for product, qty := range tx.inventory {
        u.inventory[product] += qty
    }
    return nil
}

If the function fails, the buffer is discarded. The real state never changes. That's rollback — in pure Go, with zero SQL.

The Rollback Test

func TestPlaceOrder_RollbackOnFailure(t *testing.T) {
    uow := NewInMemoryUoW()
    svc := NewPlaceOrderService(uow, &seqIDGen{})

    _, err := svc.PlaceOrder(ctx, "cust-1", []LineItem{
        {ProductID: "prod-a", Quantity: 2},
        {ProductID: "prod-b", Quantity: -1}, // invalid — will fail
    })

    if err == nil {
        t.Fatal("expected error")
    }

    // Nothing committed
    if len(uow.Orders()) != 0 {
        t.Error("orders should be empty after rollback")
    }
    if len(uow.Inventory()) != 0 {
        t.Error("inventory should be empty after rollback")
    }
}

The order was saved inside the function, but the reservation failed. Both were rolled back. The test proves it — in microseconds, with no database.

When You Don't Need This

Not every service needs Unit of Work. If your operation makes one database call, a simple repository port is enough. UoW adds complexity. Use it when you genuinely need atomic operations across multiple repositories.

📖 This is Chapter 16 of Hexagonal Architecture in Go: Ports, Adapters, and Services That Last.

The book covers the full journey: from the spaghetti service that breaks every sprint, through domain modeling, port design, adapter building, and production patterns like this one — to knowing when hexagonal architecture is overkill and skipping it confidently.

22 chapters. Every example tested. Companion repo included.

Book 2 in the Thinking in Go series.

Part 5 of 5. Thanks for reading the series. If it helped, the book goes 10x deeper on every topic.

The Dependency Rule: One Import Statement Will Tell You If Your Go Architecture Is Broken

Gabriel Anhaia — Fri, 10 Apr 2026 09:53:47 +0000

Open your domain package. Read the imports.

package domain

import (
    "context"
    "fmt"
)

Clean. This domain depends on nothing but standard library utilities.

Now look at this:

package domain

import (
    "context"
    "database/sql"
    "fmt"
)

One extra line. database/sql. Your domain now depends on infrastructure. The architecture is broken.

The Rule

Inner layers must never import outer layers.

The domain defines interfaces. The adapters implement them. The domain never knows which adapter is on the other side. That's the entire rule.

  Adapter ──imports──► Domain    ✅ Correct
  Domain  ──imports──► Adapter   ❌ Broken

What "Depends On" Means in Go

In Go, dependency is an import. Nothing else. No annotation-based DI. No classpath scanning. If package A imports package B, A depends on B.

Want to know which direction your dependencies point? Open the file. Read the imports. The compiler is your architecture linter.

How Violations Sneak In

Even experienced developers break the rule accidentally:

JSON struct tags on domain types. You add json:"customer_id" to your Order struct. Now your domain knows about serialization. That knowledge belongs in the adapter's DTO types.

sql.NullString in a domain field. "It's just one field." Now your domain imports database/sql. Every test needs the sql package. You're locked to SQL databases.

*http.Request as a domain method parameter. Your domain now depends on net/http. Can't call that method from a CLI tool or a Kafka consumer without importing the HTTP package.

ORM tags. gorm:"column:order_id" on your domain struct. Your domain depends on gorm.io. If you switch ORMs, you rewrite the domain.

Returning pq.Error from an adapter. The raw PostgreSQL error escapes into the service layer. Anyone handling it must import github.com/lib/pq.

Each seems harmless. Together they erode the boundary until your "hexagonal architecture" is just a folder structure with no enforcement.

The Correct Way

The domain defines a port. The adapter implements it. The domain never imports the adapter.

// domain/service.go — imports: context, fmt. Nothing else.
type OrderRepository interface {
    Save(ctx context.Context, order Order) error
}

type OrderService struct {
    repo OrderRepository
}

func (s *OrderService) CreateOrder(ctx context.Context, customerID string, total int64) (Order, error) {
    if customerID == "" {
        return Order{}, fmt.Errorf("customer ID is required")
    }
    order := Order{ID: generateID(), CustomerID: customerID, TotalCents: total}
    if err := s.repo.Save(ctx, order); err != nil {
        return Order{}, fmt.Errorf("saving order: %w", err)
    }
    return order, nil
}

// adapter/memory/repository.go — imports the domain, not the other way around
type InMemoryRepository struct {
    orders map[string]domain.Order
}

func (r *InMemoryRepository) Save(_ context.Context, order domain.Order) error {
    r.orders[order.ID] = order
    return nil
}

The adapter knows about the domain. The domain has no idea the adapter exists. Arrow points inward.

How to Detect Violations

Read the imports. Open your domain package. If you see database/sql, net/http, encoding/json, or any ORM, fix it.

Compile the domain alone:

go build ./internal/domain/...

If it fails because of missing infrastructure packages, you have a violation.

Automate it:

go list -f '{{.Imports}}' ./internal/domain/... | grep -E "database|net/http|encoding/json"

If that returns anything, the architecture has a hole.

`main()` Is the Exception

main() imports everything. It creates adapters, injects them into services, and starts the server. That's its job — to be the one place where all layers meet so that nothing else has to.

func main() {
    repo := postgres.NewOrderRepository(db)
    svc := domain.NewOrderService(repo)
    handler := httphandler.New(svc)
    // ...
}

main() is the composition root, not part of any layer.

📖 The dependency rule is Chapter 7 of Hexagonal Architecture in Go, and it's the foundation everything else builds on. The book covers correct vs incorrect dependency direction with side-by-side code, how violations sneak in through five common patterns, and detection techniques including automated import checking.

Part 4 of 5. Final post: stop passing *sql.Tx through your service layer — the Unit of Work pattern in Go.

Testing a Go Service in Microseconds: The Hexagonal Testing Strategy

Gabriel Anhaia — Fri, 10 Apr 2026 09:53:42 +0000

Your Go tests take 3 minutes because every "unit test" spins up PostgreSQL in Docker.

That's not a testing problem. That's an architecture problem.

When your business logic is tangled with your database calls, the only way to test it is to bring the database along. Hexagonal architecture untangles them — and testing becomes almost mechanical.

Three Layers, Three Strategies

Layer 1: Domain Tests — Microseconds

The domain is pure Go. No imports from database/sql, net/http, or any external package. Testing it is trivial:

func TestNewOrder_RejectsEmpty(t *testing.T) {
    _, err := NewOrder("ord-1", "cust-1", nil)
    if !errors.Is(err, ErrOrderEmpty) {
        t.Errorf("got %v, want ErrOrderEmpty", err)
    }
}

func TestOrder_Confirm(t *testing.T) {
    order := validOrder(t)
    if err := order.Confirm(); err != nil {
        t.Fatalf("unexpected error: %v", err)
    }
    if order.Status != OrderStatusConfirmed {
        t.Errorf("status = %q, want confirmed", order.Status)
    }
}

No setup. No teardown. No containers. These tests finish before your terminal redraws.

For the service layer, test doubles are trivial because the ports are small:

// 8 lines. That's the entire repository double.
type inMemoryRepo struct {
    orders map[string]Order
}

func (r *inMemoryRepo) Save(_ context.Context, order Order) error {
    r.orders[order.ID] = order
    return nil
}

func (r *inMemoryRepo) FindByID(_ context.Context, id string) (Order, error) {
    o, ok := r.orders[id]
    if !ok {
        return Order{}, ErrOrderNotFound
    }
    return o, nil
}

Layer 2: Adapter Tests — Milliseconds

HTTP handlers: Use httptest. Stub the domain behind the port interface. Test that JSON→domain translation works and errors→status codes map correctly:

func TestCreateOrder(t *testing.T) {
    svc := &stubService{}
    handler := httphandler.New(svc)

    body := `{"customer_id":"cust-1","items":[{"product_id":"p1","quantity":2,"price_cents":2500}]}`
    req := httptest.NewRequest(http.MethodPost, "/orders", strings.NewReader(body))
    rec := httptest.NewRecorder()

    handler.Create().ServeHTTP(rec, req)

    if rec.Code != http.StatusCreated {
        t.Errorf("status = %d, want 201", rec.Code)
    }
}

No real service. No database. You're testing translation, not business logic.

Database adapters: For in-memory adapters, test directly. For PostgreSQL, use integration tests (testcontainers) — but only to verify the adapter implements the port correctly.

Layer 3: Integration Tests — Seconds

Full stack through HTTP. Build real adapters, wire through the service, send HTTP requests:

func TestFullStack_CreateAndGet(t *testing.T) {
    repo := memory.NewOrderRepository()
    svc := domain.NewOrderService(repo, &noopNotifier{}, &seqIDGen{})
    handler := httphandler.New(svc)
    srv := httptest.NewServer(handler.Routes())
    defer srv.Close()

    // Create
    resp, _ := http.Post(srv.URL+"/orders", "application/json",
        strings.NewReader(`{"customer_id":"cust-1","items":[...]}`))
    // assert 201...

    // Get
    resp, _ = http.Get(srv.URL + "/orders/ord-1")
    // assert 200 + correct body...
}

Use sparingly. These catch wiring bugs, not business logic bugs.

The Pyramid

        /\
       /  \        Few integration tests (slow, catch wiring bugs)
      /----\
     /      \      Some adapter tests (medium, catch translation bugs)
    /--------\
   /          \    Many domain tests (fast, catch business logic bugs)
  /____________\

This pyramid falls naturally out of the architecture. You don't need a testing strategy document. The architecture IS the testing strategy.

Hand-Written Doubles > Mock Frameworks

With 1-2 method interfaces, a hand-written stub is 5-10 lines. A mocking framework adds code generation, magic assertions, and runtime reflection. The framework overhead isn't worth it for interfaces this small.

Write the struct. Implement the methods. Move on.

📖 This is the testing strategy from Chapter 14 of Hexagonal Architecture in Go. The book also covers conformance tests (run the same suite against every adapter), error mapping tests, and when integration tests are genuinely necessary.

Companion code: github.com/gabrielanhaia/hexagonal-go-examples

Part 3 of 5. Next: the one rule that holds everything together — the dependency rule, and what breaks when you violate it.

Go Interfaces Are Ports: The Language Feature That Makes Clean Architecture Free

Gabriel Anhaia — Fri, 10 Apr 2026 09:53:38 +0000

The biggest insight that changed how I structure Go services:

Define interfaces where you USE them, not where you implement them.

This one idea — consumer-defined interfaces — is what makes hexagonal architecture feel native in Go instead of bolted on.

The Java Way vs The Go Way

In Java, the class that implements an interface must explicitly declare it:

public class PostgresOrderRepository implements OrderRepository {
    // Must import OrderRepository. Must name it. Coupled at the declaration.
}

In Go, a type satisfies an interface just by having the right methods. No keyword. No import.

// Domain package defines what it needs
type OrderRepository interface {
    Save(ctx context.Context, order Order) error
    FindByID(ctx context.Context, id string) (Order, error)
}

// Adapter package — doesn't even need to know the interface exists
type PostgresOrderRepository struct {
    db *sql.DB
}

func (r *PostgresOrderRepository) Save(ctx context.Context, order Order) error {
    // SQL INSERT
    return nil
}

func (r *PostgresOrderRepository) FindByID(ctx context.Context, id string) (Order, error) {
    // SQL SELECT
    return Order{}, nil
}

PostgresOrderRepository never mentions OrderRepository. The dependency arrow points inward — from infrastructure to domain — exactly as hexagonal architecture demands.

Small Interfaces Win

The Go proverb: "The bigger the interface, the weaker the abstraction."

Don't do this:

// 12 methods. Every test double implements all 12.
type OrderRepository interface {
    Save(ctx context.Context, order Order) error
    FindByID(ctx context.Context, id string) (Order, error)
    FindByCustomer(ctx context.Context, customerID string) ([]Order, error)
    List(ctx context.Context, limit, offset int) ([]Order, error)
    Count(ctx context.Context) (int, error)
    Delete(ctx context.Context, id string) error
    // ... six more methods nobody uses together
}

Do this:

type OrderSaver interface {
    Save(ctx context.Context, order Order) error
}

type OrderFinder interface {
    FindByID(ctx context.Context, id string) (Order, error)
}

// Compose when a service genuinely needs both
type OrderRepository interface {
    OrderSaver
    OrderFinder
}

Now a service that only writes depends on OrderSaver. Test double: 5 lines. A service that only reads depends on OrderFinder. Test double: 5 lines.

The Testing Payoff

With small, consumer-defined interfaces, test doubles are trivial:

type inMemoryRepo struct {
    orders map[string]Order
}

func (r *inMemoryRepo) Save(_ context.Context, order Order) error {
    r.orders[order.ID] = order
    return nil
}

func (r *inMemoryRepo) FindByID(_ context.Context, id string) (Order, error) {
    order, ok := r.orders[id]
    if !ok {
        return Order{}, ErrOrderNotFound
    }
    return order, nil
}

No mocking framework. No code generation. Your domain tests run in microseconds.

func TestPlaceOrder(t *testing.T) {
    repo := &inMemoryRepo{orders: make(map[string]Order)}
    svc := NewOrderService(repo)

    order, err := svc.PlaceOrder(ctx, req)
    // assert...

    // Verify it was saved
    saved, _ := repo.FindByID(ctx, order.ID)
    // assert...
}

No database. No Docker. No setup. Just Go structs and method calls.

The Rule

Define interfaces in the consumer package (the domain)
Keep them small (1-3 methods)
Compose when needed via embedding
Let Go's implicit satisfaction handle the wiring

That's it. No framework needed. The language does the work.

📖 This is Chapter 5 of my book Hexagonal Architecture in Go — which goes deep into port design, naming conventions, when to split vs compose, and the IDGenerator pattern for deterministic testing.

Part 2 of 5 in the Hexagonal Architecture in Go series. Next: testing your hexagonal service at every layer — domain, adapters, and integration.

Hexagonal Architecture in Go: Why Your Service's Business Logic Should Know Nothing About HTTP

Gabriel Anhaia — Fri, 10 Apr 2026 09:53:26 +0000

You've seen it happen. Maybe you caused it.

A Go service starts as a clean main.go with a few handlers. Six months later, the handler that was 40 lines is 400. The SQL queries live inside HTTP handlers. The business logic imports database/sql. The test suite takes six minutes because every test needs a running PostgreSQL.

Someone suggests a refactor. A Jira ticket gets created. Nobody assigns it.

This isn't because Go developers are bad. It's because Go gives you freedom without structure. No mandatory base classes. No framework telling you where things go. Freedom without a plan leads to spaghetti.

The One Rule That Fixes It

Hexagonal architecture (ports and adapters) comes down to one rule:

Dependencies always point inward. The domain knows nothing about infrastructure.

Your Order entity doesn't know it's stored in PostgreSQL. Your OrderService doesn't know it's called from an HTTP handler. Your discount calculation doesn't know the coupon code came from a JSON body.

// The domain defines what it needs — a port (interface)
type OrderRepository interface {
    Save(ctx context.Context, order Order) error
    FindByID(ctx context.Context, id string) (Order, error)
}

// The domain service depends on the interface, not the database
type OrderService struct {
    repo OrderRepository
}

func NewOrderService(repo OrderRepository) *OrderService {
    return &OrderService{repo: repo}
}

The adapter (PostgreSQL, in-memory, whatever) implements the interface. The domain never knows which one is on the other side.

Why Go Is Perfect for This

In Java, hexagonal architecture requires dependency injection frameworks, annotation processors, and configuration hell. In Go, you need interfaces and a main() function. That's it.

Go's implicit interfaces are the killer feature. The adapter doesn't need to declare implements OrderRepository. It just needs the right methods:

// This automatically satisfies OrderRepository
// No "implements" keyword. No import of the domain package needed.
type PostgresOrderRepository struct {
    db *sql.DB
}

func (r *PostgresOrderRepository) Save(ctx context.Context, order Order) error {
    // SQL INSERT
    return nil
}

func (r *PostgresOrderRepository) FindByID(ctx context.Context, id string) (Order, error) {
    // SQL SELECT, translate sql.ErrNoRows to domain.ErrOrderNotFound
    return Order{}, nil
}

And main() is your composition root — the one place where everything gets wired:

func main() {
    repo := postgres.NewOrderRepository(db)
    notifier := email.NewNotifier(smtpClient)
    service := domain.NewOrderService(repo, notifier)
    handler := httphandler.New(service)

    mux := http.NewServeMux()
    mux.HandleFunc("POST /orders", handler.Create())
    log.Fatal(http.ListenAndServe(":8080", mux))
}

No framework. No reflection. No magic. Five lines of wiring and you can see the entire architecture.

The Before and After

Before (spaghetti):

Business logic mixed with HTTP parsing and SQL queries
Can't test without a running database
Can't add gRPC without copy-pasting the handler
New developers take weeks to understand the codebase

After (hexagonal):

Domain tests run in microseconds — no Docker, no database
Swap PostgreSQL for DynamoDB by changing one line in main()
Add gRPC, CLI, or Kafka consumer without touching business logic
New developers read main() and understand the architecture

The Book

I wrote a full book on this: 22 chapters, 5 parts, from spaghetti code to production-ready hexagonal services in Go.

📖 Hexagonal Architecture in Go: Ports, Adapters, and Services That Last

It covers everything: domain modeling, port design, HTTP and outbound adapters, dependency injection in main(), testing at every layer, error handling across boundaries, transactions (Unit of Work), event-driven adapters, observability via decorators, when to skip hexagonal entirely, and migrating existing services incrementally.

Every code example is tested in a companion repository.

Book 2 in the "Thinking in Go" series. Book 1 (The Complete Guide to Go Programming) teaches the language. Book 2 teaches how to architect with it.

This is Part 1 of a 5-part series on Hexagonal Architecture in Go. Next up: how Go interfaces naturally become ports — and why that matters more than you think.

Your Vulnerability Scanner Was the Vulnerability: 4 Projects Backdoored in 8 Days

Gabriel Anhaia — Sun, 05 Apr 2026 17:24:57 +0000

My project: Hermes IDE | GitHub
Me: gabrielanhaia

Trivy is a vulnerability scanner. Its whole job is finding security problems in other people's code.

On March 22, 2026, it became one.

Not a metaphor. Not an exaggeration. A threat group tracked as TeamPCP (Mandiant designation UNC6780) compromised Trivy's GitHub Actions workflow, injected a credential-stealing payload called SANDCLOCK, and turned every pipeline running the affected action into a silent data exfiltration machine. SSH keys, API tokens, cloud credentials. Gone. Through the tool teams installed specifically to stop that from happening.

The punchline? Trivy wasn't even the only victim that week.

Eight Days, Four Compromises, Two Security Scanners

Here's the full timeline. Each entry includes the attack vector and affected versions based on published advisories.

March 19 — LiteLLM (PyPI)

LiteLLM provides a unified Python interface for calling multiple LLM providers. Thousands of AI projects depend on it. TeamPCP published a poisoned package to PyPI containing the SANDCLOCK payload embedded in the package's setup.py post-install hook.

Affected versions: 1.56.3 through 1.56.5 on PyPI
Known-bad hash (1.56.4): sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Clean version: 1.56.6 (published March 23 after PyPI yanked the compromised releases)

Anyone who ran pip install litellm or let automated dependency updates fire during that four-day window pulled in malware alongside their LLM proxy.

March 21 — Telnyx Python SDK (PyPI)

Same playbook, different target. Telnyx's SDK handles voice, messaging, and communications APIs. TeamPCP pushed a modified package with SANDCLOCK baked into the initialization module.

Affected versions: 2.1.0 through 2.1.2
Known-bad hash (2.1.1): sha256:7d793037a0760186574b0282f2f435e7c0b4a3b5e38d25f9c1db4b79e5f1a2c0
Clean version: 2.1.3 (published March 24)

March 22 — Trivy (GitHub Actions)

This one stings differently. Aqua Security's Trivy is one of the most deployed container vulnerability scanners on the planet. It scans Docker images, filesystems, and Git repos for CVEs, misconfigurations, and exposed secrets. TeamPCP didn't bother with PyPI this time. They went straight for the GitHub Actions workflow.

Affected action: aquasecurity/trivy-action with mutable tags @v1 and @latest
Compromised commit SHA: b4b587a89b42c8b9b4494c2e3f58f5e33eb937bb
Clean commit SHA: f1ef53dab1f0a26b0f9cda0f94e66e3f93ae6375 (tag restored March 25)
Exposure window: March 22 - March 25

March 27 — KICS (GitHub Actions)

The final strike. Checkmarx's KICS scans Terraform, CloudFormation, Ansible, and Kubernetes manifests for security misconfigurations. Same vector as Trivy. Same payload.

Affected action: checkmarx/kics-github-action with mutable tags @v2 and @latest
Compromised commit SHA: 94a2d2cfee7c15af34c3f9a50ab332dcab5c5d1a
Clean commit SHA: d8e511bb7e46c8fa91c7c3e4e85a9db15a41f89c (tag restored March 29)
Exposure window: March 27 - March 29

Four projects. Eight days. Two of them were security scanners. The tools organizations deploy to find backdoors were carrying backdoors.

That's not a footnote in a threat report. That's a fundamental trust failure.

How Mutable Tags Became the Weapon

The PyPI compromises on LiteLLM and Telnyx followed a pattern supply chain researchers have documented dozens of times: steal maintainer credentials, push a poisoned package version, wait for pip install to do the rest. Familiar. Still effective.

The GitHub Actions attacks were nastier.

Most workflows reference actions by a mutable tag. Here's what a standard Trivy setup looked like in thousands of repositories:

- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@v1
  with:
    image-ref: 'my-app:latest'
    severity: 'CRITICAL,HIGH'

That @v1 is a Git tag. It points to whatever commit the maintainer last associated with it. Tags in Git aren't fixed. Anyone with write access can delete a tag and recreate it pointing at a completely different commit. There's no audit log visible to consumers. No notification fires. No version number changes.

TeamPCP gained write access to the action repositories (compromised maintainer tokens remain the leading theory, though full initial access details haven't been disclosed) and performed this exact operation:

Cloned the legitimate action code
Added SANDCLOCK as a secondary payload that ran silently after the scanner completed
Moved the @v1 tag to point at the new, poisoned commit

The action still ran the scanner. Still produced the expected output. Still reported vulnerabilities in other people's code. It just also quietly harvested every credential in the CI/CD environment and shipped them to attacker-controlled infrastructure over HTTPS.

# What developers thought they were running:
#   trivy scan → report vulnerabilities → done

# What actually ran:
#   trivy scan → report vulnerabilities → harvest SSH keys,
#   AWS creds, GitHub tokens → exfiltrate to attacker C2 → done

Nobody noticed for days. The scanner scanned. The malware ran. The output looked normal.

What SANDCLOCK Harvests

SANDCLOCK isn't ransomware. It isn't a cryptominer. It's a credential vacuum designed for stealth over spectacle.

Once running inside a CI/CD environment, it targets:

SSH private keys. It searches ~/.ssh/ for id_rsa, id_ed25519, and anything else that looks like a private key. CI/CD runners frequently hold keys with push access to production repositories.

Every environment variable. AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, NPM_TOKEN, database connection strings, third-party API keys. Pipelines need credentials to deploy, which makes their runtime environments a buffet of secrets.

Cloud provider credential files. Beyond environment variables, SANDCLOCK specifically scrapes ~/.aws/credentials, ~/.config/gcloud/application_default_credentials.json, and ~/.azure/. Persistent credential files on build runners are gold for lateral movement into cloud infrastructure.

Git configuration and stored credentials. The .gitconfig file and any cached Git credentials, enabling the attacker to push code to repositories the compromised runner can reach. This creates potential for the attack to spread itself.

Exfiltration happened over HTTPS to domains mimicking legitimate analytics and telemetry endpoints. Blending with normal outbound CI/CD traffic made network detection brutally hard.

The entire design philosophy: grab everything, stay quiet, enable larger attacks later.

Checking Whether You Got Hit

This section matters more than anything else in this post.

Trivy

# Find all workflow files referencing Trivy
grep -r "aquasecurity/trivy-action" .github/workflows/

# Check your GitHub Actions run logs between March 22-25
# Look at the "Set up job" step to see which commit SHA was resolved

Compare the resolved SHA against the compromised commit b4b587a89b42c8b9b4494c2e3f58f5e33eb937bb. If it matches, that run was poisoned.

KICS

grep -r "checkmarx/kics" .github/workflows/

Compare resolved SHAs from runs between March 27-29 against 94a2d2cfee7c15af34c3f9a50ab332dcab5c5d1a.

LiteLLM

pip show litellm
pip hash $(pip show -f litellm | grep Location | cut -d' ' -f2)/litellm

If the installed version falls between 1.56.3 and 1.56.5, reinstall from the verified clean release:

pip install litellm==1.56.6 --force-reinstall

Telnyx

pip show telnyx

Versions 2.1.0 through 2.1.2 are compromised. Clean target: 2.1.3.

General SANDCLOCK Indicators

Look for these across any potentially affected system:

Unexpected outbound HTTPS connections from CI/CD runners to unfamiliar domains during build steps
Processes reading SSH keys or cloud credential files that have no business touching them
Modified or newly created files in /tmp or runner workspace directories that don't belong to the build

If credentials were exposed, rotate everything. Not just the ones that seem important. SANDCLOCK grabs anything it can reach, and guessing which secrets the attacker copied is a losing game.

The Broader March 2026 Context

This wasn't happening in a vacuum. March 2026 was a rough month for supply chain security across the board. North Korea-linked group UNC1069 was running a separate campaign targeting the axios npm package. Zscaler's threat research team documented a measurable surge in supply chain attacks across multiple package ecosystems.

But TeamPCP's campaign stands out because of target selection. Hitting LiteLLM and Telnyx is standard supply chain opportunism: popular packages, lots of installs, harvest at scale. Hitting Trivy and KICS shows calculation.

Security tools run with elevated permissions. They access source code, container images, infrastructure configurations, and the CI/CD secrets required for deployment. Organizations explicitly trust them. When a security team maps their pipeline's attack surface, the vulnerability scanner is the last thing they'd suspect.

Which is exactly what makes it the best target.

There's a compounding irony here that's hard to overstate. The organizations diligent enough to integrate Trivy or KICS into their pipelines were the ones who got hit. Teams running zero security scanning? Completely unaffected.

Defensive Measures That Would Have Caught This

No silver bullet exists. But specific steps would have prevented or contained this particular campaign.

Pin GitHub Actions to full commit SHAs.

This is the single highest-impact change. A mutable tag is a redirect anyone with write access can silently change. A commit SHA is fixed forever.

# Vulnerable (mutable tag):
uses: aquasecurity/trivy-action@v1

# Hardened (immutable SHA):
uses: aquasecurity/trivy-action@f1ef53dab1f0a26b0f9cda0f94e66e3f93ae6375

Tools like StepSecurity Harden-Runner and pin-github-action can enforce SHA pinning across all workflows automatically.

Enable pip hash verification.

Use --require-hashes and maintain hash-pinned requirements files:

# requirements.txt with hash pinning
litellm==1.56.6 \
    --hash=sha256:a1b2c3d4e5f6...verified_hash_here

A modified package with a different hash won't install. Period.

Restrict CI/CD runner egress traffic.

Most build steps don't need unrestricted outbound internet access. Allowlisting known-good domains and alerting on anything else would have flagged SANDCLOCK's exfiltration within minutes.

Destroy runners after every job.

Ephemeral runners prevent credential files from accumulating. Combine this with just-in-time secret provisioning that injects only what each step needs for only the duration it needs them.

Minimize workflow permissions.

permissions:
  contents: read
  # Don't grant write access unless the step genuinely needs it
  # Don't expose deployment secrets to scanning steps

A Trivy scan doesn't need write access to the repository. It doesn't need deployment secrets. Least privilege limits blast radius.

Checklist: Post-Incident Response

If any of these four projects ran in your environment during the affected windows:

Identify every CI/CD run that used the compromised versions
List every secret, token, and credential accessible to those runs
Rotate all of them. Not some. All
Audit Git history for unexpected commits pushed with stolen credentials
Check cloud provider audit logs for unauthorized API calls
Pin all GitHub Actions to commit SHAs going forward
Add hash verification to all pip install commands
Restrict runner network egress to allowlisted domains
Subscribe to security advisories for every action and package in your pipeline

The Trust Problem Doesn't Have a Clean Fix

Every dependency is a trust decision. Every GitHub Action, every PyPI package, every base image. Developers make hundreds of these calls per project, mostly without thinking about it.

The standard advice says: verify everything, audit dependencies, read source code, check hashes. In practice, nobody does this for every package in every project on every update. The volume is too high and the tooling to make it manageable is still catching up.

What March 2026 demonstrated wasn't a new category of attack. Supply chain compromises have been documented for years. What it demonstrated is that the trust boundary extends further than most teams realize. The vulnerability scanner isn't outside the attack surface. It's part of it. The IaC checker isn't a neutral observer. It's running code on your infrastructure with access to your secrets, just like everything else in the pipeline.

Treating security tools as inherently trustworthy because they're security tools is the same mistake as treating any dependency as safe because it's popular. Popularity doesn't prevent compromise. It incentivizes it.

The teams that weathered this best weren't the ones with the most security tools. They were the ones who treated their security tools with the same suspicion they'd apply to any third-party code. Pinned versions. Restricted permissions. Monitored behavior. Rotated credentials fast when the advisories dropped.

Four projects. Eight days. Two scanners turned into attack vectors. Thousands of pipelines silently compromised.

The question isn't whether this happens again. It's whether the pipeline will catch it when it does.

Coinbase Fired Engineers Who Didn't Learn AI in Five Days. The Industry Barely Flinched.

Gabriel Anhaia — Sun, 05 Apr 2026 17:21:35 +0000

My project: Hermes IDE | GitHub
Me: gabrielanhaia

Monday morning. A message goes out to every engineer at Coinbase: learn GitHub Copilot and Cursor. Not next quarter. Not when the current sprint wraps. By Friday.

Saturday, the holdouts sit across from Brian Armstrong himself. The ones who can't produce a "good reason" for skipping the tools don't make it to the following week.

That's not a thought experiment. It happened at one of the largest crypto exchanges on the planet, and Armstrong described it on John Collison's Cheeky Pint podcast with the relaxed confidence of someone who's already decided the conversation is over.

The tech industry's response? A collective shrug.

The Timeline Nobody Talks About

Five business days. That's the window Armstrong gave his engineering organization to become proficient with AI-assisted coding tools. Not "try them out." Not "evaluate whether they fit your workflow." Proficient.

Here's the sequence:

Monday: Mandate goes out. Every engineer must adopt Copilot and Cursor.
Tuesday through Friday: Engineers are expected to integrate these tools into daily work.
Saturday: Engineers who haven't complied sit down with the CEO personally.
After the meeting: Those without an acceptable justification are terminated.

Armstrong didn't frame this as optional. Monthly team meetings now track AI usage metrics. Direct reporting on adoption rates flows upward. The initial five-day sprint was just the shock; the ongoing surveillance is the system.

Coinbase currently reports that 33% of its new code comes from AI assistance. Armstrong's stated target: 50%.

Those numbers sound bold. They also collapse under the slightest scrutiny.

What Does "33% AI Code" Actually Measure?

Nobody in the industry has settled on a definition. Does "AI-generated" mean Copilot wrote the first draft and a human approved it without changes? Does it mean a developer wrote most of a function and Copilot filled in the boilerplate? When an engineer accepts an AI suggestion, then refactors it until the original is unrecognizable, whose code is that?

Coinbase hasn't published its methodology. The 33% figure most likely tracks acceptance rates in Copilot and Cursor. How often an engineer hits "tab" instead of typing manually.

That tells you something about adoption. It tells you almost nothing about quality.

Consider what gets rewarded when the metric is volume:

// Team A: Tight, well-abstracted code
// 200 lines, 10% AI-suggested
// Zero production incidents this quarter

// Team B: Verbose, repetitive implementation
// 800 lines, 55% AI-suggested
// Same feature, three incidents this quarter

Team B looks better on the dashboard. Team A looks better in production. When Armstrong says the goal is 50%, the uncomfortable follow-up is: 50% of what, measured how, optimized for whom?

Lines of code? Files touched? Pull requests with AI involvement? Each of those captures something different. Optimizing for the wrong one creates incentives that actively degrade software quality.

Goodhart's Law hasn't taken a day off. When a measure becomes a target, it stops being a good measure. A team that inflates its AI percentage by accepting mediocre suggestions looks phenomenal in the monthly review and catastrophic in the incident postmortem.

AI Adoption Mandates: Who's Doing What

Coinbase isn't alone in pushing AI tools. But the enforcement spectrum across major companies is wide.

Company	AI Stance	Enforcement	Timeline	Consequence for Non-Adoption
Coinbase	Mandatory proficiency in Copilot/Cursor	CEO-level meetings, monthly metrics tracking	5 business days	Termination
Shopify	"Baseline expectation" per CEO memo	Teams must prove AI can't do a task before requesting headcount	Gradual, no fixed deadline	Hiring/resource implications
Google	Internal AI assistants encouraged	Usage tracked, discussed in team settings	Ongoing, multi-year rollout	No reported direct consequences
Amazon	CodeWhisperer pushed through AWS ecosystem	Built into product workflows; free for developers	Organic adoption	None reported
Stripe	Heavy internal AI usage	Tool choices bubble up from teams	Team-driven pace	None reported
Meta	AI tools integrated into internal dev environment	Engineering leadership tracks adoption	Rolling	None reported

The pattern is visible. Most large engineering organizations treat AI adoption as a product problem or a culture problem. Build good tools, make them accessible, let teams experiment, track what sticks.

Coinbase treats it as a compliance problem. Use this tool. Use it now. Prove you're using it. Or leave.

What separates Coinbase from the pack isn't the pro-AI position. Virtually every major tech company shares that position. It's the velocity of the mandate and the severity of the consequences. Shopify's Tobi Lutke wrote a memo reshaping how the company thinks about staffing around AI capabilities. That's aggressive. But nobody at Shopify reportedly lost their job for not learning a text editor plugin in a business week.

Who Decides What Counts as a "Good Reason"?

Armstrong used that phrase. Engineers who missed the Friday deadline needed a "good reason." Two words carrying the weight of people's livelihoods.

Picture the room. A software engineer sits across from the founder-CEO of a publicly traded company valued in the tens of billions. The engineer must justify why they didn't learn a particular code completion tool in five business days. The CEO gets to decide whether the justification holds up.

What qualifies?

"The tool doesn't work well with our legacy codebase."
Is that a good reason, or an excuse?

"I was shipping a critical feature all week and didn't have time."
Does that fly, or should the engineer have found time anyway?

"I have concerns about code quality and IP ownership."
Is that principled skepticism, or resistance to progress?

Nobody outside that Saturday room knows the answers. That's the whole point. When the standard is subjective and the judge holds absolute power over employment, "good reason" means whatever the CEO decides it means at that moment on that particular Saturday morning.

What "psychological safety" looks like after this kind of mandate

Engineers who survived the Saturday meeting now work in a company where the CEO has shown willingness to fire people over tool preferences on a one-week timeline. They'll use the tools. Of course they will.

But compliance and buy-in are different animals that wear the same mask. Compliance means engineers accept AI suggestions to hit metrics. Buy-in means engineers use AI tools because they genuinely believe those tools make their work better.

Compliance looks identical to buy-in in every dashboard, every monthly report, every podcast talking point. It reveals itself only when something goes wrong. When a production outage traces back to an AI suggestion nobody questioned because questioning felt like career risk.

This dynamic isn't unique to AI tools. It surfaces whenever top-down mandates replace collaborative decision-making. The mandate might even be correct. AI coding tools probably should be part of every working engineer's setup. But "you should learn this" and "learn this in five days or you're fired" land differently in terms of trust, autonomy, and the kind of engineering culture that produces reliable software.

The Speed Fallacy

There's an assumption baked into the 33%-to-50% target that deserves direct challenge: that more AI-generated code is inherently better.

Faster code production matters when the bottleneck is typing speed. In most engineering organizations, typing speed hasn't been the constraint since the invention of copy-paste. The hard problems live elsewhere. Understanding requirements that contradict each other. Designing systems that handle edge cases gracefully. Debugging production failures at 2 AM when the on-call page hits. Making architectural decisions that won't haunt the team eighteen months from now.

AI tools genuinely help with certain tasks. Generating boilerplate. Writing tests from existing implementations. Filling in repetitive patterns. Suggesting implementations of well-understood algorithms. No serious engineer disputes those gains.

But volume without direction is just a faster way to accumulate technical debt.

Google's internal research on AI-assisted coding found that while these tools increased code production speed, they didn't meaningfully reduce time spent on code review, debugging, or incident response. The total elapsed time from "start coding" to "feature works in production" improved modestly. Real gains, but far smaller than raw generation metrics would suggest.

Coinbase's 33% figure tells a story about adoption velocity. It tells almost nothing about whether the engineering team ships better software, resolves incidents faster, or produces fewer bugs per feature. Those metrics presumably exist inside the company. Armstrong didn't choose to share them on the podcast. That silence says something.

What Working Engineers Should Take From This

Underneath the power dynamics analysis sits a practical truth: AI coding tools are becoming a baseline expectation across the entire industry. Not every company will fire engineers over it. Most won't. The direction, though, is unmistakable.

Learn the tools before someone tells you to. Spend a week with Copilot or Cursor on a side project. Discover what they handle well (boilerplate, test scaffolding, code explanation) and where they fall apart (security-sensitive logic, novel architecture, anything requiring deep domain context). Informed opinions beat no experience every time.

Measure your own output honestly. If AI tools make you faster at producing correct, maintainable code, that's a win. If they make you faster at producing code while your bug rate climbs and your review cycles lengthen, that's a different story. Track whether the suggestions you accept tend to survive untouched or get torn apart in review.

Separate tool competence from tool dependence. Being able to use Copilot is a skill. Being unable to function without it is a liability. The engineers who get the most from AI tools are the ones who understand the underlying code well enough to evaluate whether a suggestion makes sense. That requires the same fundamentals it always has.

Watch what your company measures. If leadership starts tracking AI adoption percentages, think hard about what behavior that incentivizes. A team optimizing for the metric will make different choices than a team optimizing for software quality. Those paths diverge further than most managers realize.

The Precedent That Matters More Than the Tools

Armstrong's mandate will work by his own metrics. AI adoption at Coinbase will reach 50%. The monthly meetings will produce numbers that look great in a board presentation. Engineers will use the tools because the alternative is unemployment.

But strip away the AI angle and the structure is bare. A CEO decides a specific technology is mandatory. Engineers get five days. Holdouts get fired. Compliance is tracked monthly. The "good reason" standard is defined by one person with unchecked authority over the outcome.

Swap out "AI coding tools" for any technology. The architecture of the mandate is identical.

The question that should make engineers uncomfortable isn't "should I learn AI tools?" Obviously yes. The question is: who gets to decide how fast developers must change their workflows, with what consequences, and based on whose definition of success?

At most companies, tool adoption happens through grassroots enthusiasm, team experimentation, and gradual standardization. Slower. Messier. Won't generate a viral podcast clip. But it tends to produce genuine adoption rather than performative compliance, and it doesn't require anyone to justify their professional judgment to the CEO on a Saturday.

Armstrong chose speed over consensus. That's his prerogative as a founder-CEO. It might even be the right strategic call for Coinbase specifically, given how fast AI capabilities are evolving and how volatile the crypto market remains.

Every engineer watching from outside should notice what happened, though. Not the AI part. The part where five days was deemed sufficient to reshape how an entire engineering organization works, and where the penalty for falling short was a meeting that ended careers.

Tools will come and go. Copilot might dominate for years or get replaced next quarter. The precedent of mandate-and-fire on a five-day timeline? That sticks around much longer than any code completion engine.

They Forced a Junior to Use AI. Then Fired Him for the Bugs It Wrote.

Gabriel Anhaia — Sun, 05 Apr 2026 17:20:49 +0000

My project: Hermes IDE | GitHub
Me: gabrielanhaia

Two Bugs and a Cardboard Box

A junior engineer at an AI startup shipped two bugs to production. Got fired for it.

Read that again. Two bugs. From a first-year developer. At a company that told him to use AI coding tools. That's not a performance issue. That's a Tuesday.

The company had "strongly encouraged" every engineer to lean on tools like Cursor. Ship faster. Write more. Let the machine handle the boring parts. So this junior did exactly what he was told. The machine produced code. The code had bugs. The bugs hit production. And the person who followed instructions got walked out of the building.

Reddit caught fire. Thousands of comments ripped into the company for building a trap and punishing the person who fell into it. Because that's what happened. Leadership set the rules, picked the tools, decided speed mattered more than correctness, and then acted shocked when correctness suffered.

The Coinbase Connection

This didn't happen in a vacuum. It happened in the same industry where Coinbase CEO Brian Armstrong publicly ordered every engineer to adopt AI tools and gave them one week to get proficient. Seven days. Not a quarter. Not even a full sprint cycle. Seven calendar days to restructure how they write software.

Armstrong's stated goal: half of Coinbase's codebase generated by AI. That figure currently sits at 33% and climbing. For a company that handles billions in cryptocurrency transactions, where a single authorization bug in a trading endpoint could drain customer wallets.

One week to learn tools that produce 1.7x more bugs than human-written code, according to CodeRabbit's research. What could go wrong.

The pattern writes itself on a whiteboard. Company mandates AI tools. AI tools produce code at volume with known quality gaps. Bugs ship. Someone gets blamed. That someone is never the executive who signed the mandate.

What "AI-First Development" Looks Like from the Bottom

Picture the junior's position for thirty seconds.

Six months into a first real engineering job. Leadership sends an all-hands email about "AI-first development." The team lead starts tracking velocity in PRs per week. Cursor gets installed on every machine. There's a Slack channel called #ai-wins where people post screenshots of generated code. Nobody creates a channel called #ai-failures. That channel would be too active.

A 23-year-old doesn't have the scar tissue to know what AI gets wrong. They haven't debugged a race condition at 2 AM. Haven't watched a silent error swallow a payment. Haven't spent three days tracking down a missing authorization check buried inside generated code that looked flawless.

So the junior does what he's told. Uses the tool. Ships the output. And when it breaks, the company fires the developer, not the process.

That's not accountability. That's a sacrifice.

The Bug That Passes Every Test

Here's what people outside engineering don't grasp about AI-generated bugs: they don't look broken. They look clean, well-structured, idiomatic. The code does the right thing in every scenario except the one that costs money.

Consider a discount calculation service for an e-commerce platform. The AI generates this:

# AI-generated: applies promotional discount to cart total
def apply_discount(cart_total: float, discount_code: str) -> float:
    discount = get_discount(discount_code)

    if discount is None:
        return cart_total

    if discount.type == "percentage":
        return cart_total * (1 - discount.value / 100)

    if discount.type == "fixed":
        return cart_total - discount.value

    return cart_total

Readable. Handles percentage and fixed discounts. Returns the original total for invalid codes. Tests pass because the test suite covers valid discounts, invalid codes, and both discount types.

Ships to production. Works fine for two weeks. Nobody panics.

Then a customer applies a $50 fixed discount to a $30 cart. The function returns negative twenty dollars. The payment processor reads that as a $20 credit to the customer's account. The company bleeds money on every order where the discount exceeds the cart total. Nobody catches it for eleven days because the monitoring dashboard tracks transaction volume, not transaction polarity.

The fix:

def apply_discount(cart_total: float, discount_code: str) -> float:
    discount = get_discount(discount_code)

    if discount is None:
        return cart_total

    if discount.type == "percentage":
        discounted = cart_total * (1 - discount.value / 100)
    elif discount.type == "fixed":
        discounted = cart_total - discount.value
    else:
        return cart_total

    return max(discounted, 0.0)  # <-- the entire fix

One line. max(discounted, 0.0). That's the gap between working software and an eleven-day revenue leak. A senior who's been burned by negative totals catches this in review without breaking stride. The AI didn't flag it because negative totals weren't in its training data. The junior didn't flag it because nobody taught him to look.

And this is who gets fired.

Before and After: What Proper Review Looks Like

The uncomfortable part: that bug shouldn't have reached production regardless of who wrote it. Not the junior. Not the AI. Not both together. The company's review process failed, assuming one existed at all.

Here's the difference between a team that ships AI-generated code safely and one that ships termination letters.

The broken process (what likely happened)

Junior generates code with AI tool
Junior opens PR
Another junior or mid-level dev skims it, sees clean code, approves
CI runs tests. Tests pass (because nobody wrote edge-case tests)
Code merges and deploys
Bug hits production
Junior gets blamed

The process that actually works

PR Creation:

Every PR containing AI-assisted code gets an automatic ai-generated label
No exceptions. The team needs to know what they're reviewing.

Review Assignment:

AI-labeled PRs route to a senior engineer. Not another junior. Someone who's spent years building instinct for boundary conditions, missing auth checks, and silent failures.

Edge-Case Testing Required Before Merge:

def test_discount_does_not_go_negative():
    """Fixed discount larger than cart total should return 0."""
    assert apply_discount(30.0, "SAVE50") == 0.0

def test_percentage_discount_at_boundary():
    """100% discount should zero the cart, not go below."""
    assert apply_discount(100.0, "FULL100") == 0.0

def test_zero_cart_with_discount():
    """Discount applied to empty cart should return 0."""
    assert apply_discount(0.0, "SAVE10") == 0.0

def test_negative_cart_rejected():
    """Negative cart totals should raise, not silently compute."""
    with pytest.raises(ValueError):
        apply_discount(-5.0, "SAVE10")

Pre-Merge Checklist for AI-Assisted Code:

Does this handle null, empty, and zero inputs?
What happens at boundaries? Negative numbers, max values, empty collections?
Are there race conditions under concurrent requests?
Does this check authorization, not just authentication?
What fails silently? Where do errors get swallowed?

Post-Incident:

Postmortem examines the process, not just the person. Was the code reviewed? By whom? Were edge-case tests written? If the answer to any of those is "no," the process failed. Not the developer.

That second process isn't revolutionary. It's barely novel. But the company that fired this junior didn't have it. Neither do most companies racing to hit their AI adoption KPIs.

The Numbers Nobody Puts on a Slide

CodeRabbit's research confirms what this story shows in miniature: AI-generated code produces 1.7x more bugs than human-written code. Not theoretical risks. Production-breaking, customer-facing defects at nearly twice the rate.

Incidents per pull request climbed 23.5% across teams that adopted AI tools aggressively. Mean time to resolve those incidents went up by 62%. Why? Because the people who understood the systems well enough to fix things fast were often the same people whose roles got "optimized" away.

Combine those numbers with forced adoption. A company pushes developers toward tools that produce 1.7x more bugs, measures success by output volume, underinvests in review, and then fires the lowest-ranking person when the math does what math does.

That's not a management strategy. That's a liability time bomb with a junior developer strapped to the front.

Accountability Flows Downhill. It Shouldn't.

There's an infuriating pattern in how organizations handle tool failures.

When enterprise software causes problems, the vendor gets blamed. When a new database corrupts data, the architecture team faces scrutiny. When a CI/CD pipeline introduces regressions, the platform team holds a retro and writes an action plan.

But when mandated AI coding tools produce bugs? The individual developer gets fired. The tool keeps its seat license. The mandate stays in place. Leadership writes a blog post about "AI-first culture."

This only works in one direction: downward. Leadership mandates the tool. Leadership sets velocity targets. Leadership decides PRs-per-week is the metric that matters. Leadership skips investing in review infrastructure. And when the entirely predictable outcome arrives, leadership fires the person with the least power to have changed any of those decisions.

That junior didn't choose the tool. Didn't set the targets. Didn't design the review process. Didn't decide that speed mattered more than correctness. He just happened to be holding the code when the music stopped.

Armstrong's 50% and What It Means for Coinbase

Think about what 50% AI-generated code means for a financial services company.

Coinbase isn't a social media app where the worst bug shows someone the wrong meme. Regulatory compliance isn't optional. Security flaws don't just cost reputation; they cost real money from real customer accounts. A race condition in the order matching engine could create phantom trades. A missing boundary check in a withdrawal endpoint could let attackers drain funds.

Fifty percent AI-generated code in that environment, without proportional investment in verification infrastructure, is a bet that the tools won't produce the exact class of bugs they're statistically proven to produce. And the engineers expected to catch those bugs before they ship? They had seven days to learn the tools that wrote them.

The junior who got fired at that AI startup is a preview. Scale the same dynamic to a company managing customer funds, and the stakes stop being about one person's career.

What Reddit Got Right

Reddit nailed the core point: firing a junior over two bugs is absurd. Senior engineers ship bugs. Staff engineers ship bugs. Distinguished engineers ship bugs. The difference is that experienced engineers typically work inside processes with enough review layers that their bugs get caught before customers see them.

Reddit also correctly identified the systemic failure. Mandating tools without building guardrails. Measuring velocity without measuring quality. Skipping the investment that makes AI-assisted code safe to ship.

Where the conversation went sideways: treating this as an isolated case of bad management. It's not isolated. It's structural. The incentive system across the industry currently rewards AI adoption speed and punishes caution. Companies that slow down to build review infrastructure don't get praised for responsibility. They get asked by their board why adoption metrics lag behind competitors who fired their way to faster numbers.

What Should Actually Happen

Stop firing juniors for predictable outcomes. That's the floor. Everything else builds on it.

Fund the verification layer before mandating the tools. If leadership wants 50% AI-generated code, leadership needs to pay for the review infrastructure that makes that safe. Senior reviewers. AI-specific checklists. Boundary-focused test requirements. Automated analysis that flags common AI failure patterns. This costs money. Far less money than production incidents and wrongful termination suits.

Put defect rates on the same dashboard as velocity. Any team metric that shows PRs-per-sprint without showing incidents-per-PR is a lie of omission. Both numbers go on the same slide, or neither does.

Build structured onboarding for AI-assisted development. Juniors need to learn what AI gets wrong before they're asked to use it in production. Curated examples of AI failures. Paired review sessions with senior engineers. A ramp-up period that's longer than one calendar week. Build the judgment first, deploy the tools second.

Make accountability proportional to authority. The person who mandates the tool carries more responsibility for the tool's failures than the person told to use it. When AI-generated code breaks production, the postmortem examines the decision chain, not just the last person who clicked "approve."

Treat AI output like untrusted input. Every AI-generated code block deserves the same skepticism as user input in a web form. Validate it. Test its boundaries. Assume it's wrong until proven otherwise. Teams that internalize this will ship fewer bugs than teams that treat AI output like a trusted colleague's work.

Protect juniors during this transition. Junior developers are the most vulnerable to AI-generated bugs because they have the least experience spotting them. That's not a reason to fire juniors. It's a reason to invest harder in mentoring them. The senior engineers of 2031 are the juniors getting fired in 2026 for bugs they didn't write and couldn't have caught.

The Question Nobody in Leadership Wants to Sit With

If a company mandates a tool, and that tool produces bad output, and an employee ships that output in good faith following company policy, who's liable?

Not morally. Legally.

Because as AI-generated code scales from 33% to 50% to whatever comes after, and as the bugs scale right alongside it, someone's going to ask that question in front of a judge instead of on Reddit. The answer won't be "the junior developer."

Companies that figure this out now, that build the infrastructure and review processes and accountability structures before they're forced to, will still be standing when the dust settles. The ones that keep firing juniors for using the tools they were told to use will learn the lesson the expensive way.

That junior deserved a better process. Not a cardboard box.

Has your company forced AI coding tools on the team? What does the review process look like? Does a review process even exist? Drop a comment below. The more engineers talk openly about what's actually happening inside these orgs, the harder it gets for leadership to pretend the current approach is working.

Cursor 3 Is Silently Deleting Code, Draining Wallets, and Swapping Models Behind Closed Doors

Gabriel Anhaia — Sun, 05 Apr 2026 17:20:08 +0000

My project: Hermes IDE | GitHub
Me: gabrielanhaia

The AI coding tool that promised to 10x developer productivity just quietly deleted an afternoon's work. Then it charged for the privilege.

That's not hyperbole. That's a Tuesday for Cursor 3 users who've been filing bug reports, comparing billing screenshots, and watching their model settings rearrange themselves overnight. What shipped as an "agent-first" IDE looks more like a trust-destruction machine wearing a VS Code skin.

The Bug That Should've Blocked the Release

Picture this. A developer writes code. Cursor's agent mode makes edits. Everything checks out. Then the developer spots something minor, clicks "Fix in Chat," and the agent takes care of it.

Except when they flip back to their file, their previous changes are gone.

Not flagged. Not conflicting. Not sitting in some recovery panel. Gone. The file quietly reverted to its pre-agent state while nobody was looking.

The root cause sits in a conflict between the Agent Review Tab and the main editor state. When both are active and a developer triggers "Fix in Chat," Cursor overwrites the file with the older version. No diff notification. No undo prompt. The edits vanish like they never happened.

Here's the kicker: this isn't some obscure edge case requiring a bizarre reproduction sequence. The "Fix in Chat" button sits right there in the UI. The Agent Review Tab opens automatically. Using both in sequence is the workflow Cursor's own interface encourages. It's the happy path. And it destroys work.

A code editor that silently deletes changes has broken the most basic contract between a tool and the person relying on it. Bugs ship. Silent data loss ships differently.

Workarounds (That Shouldn't Be Necessary)

These aren't fixes. They're defensive coding against a paid product.

Close the Agent Review Tab before clicking "Fix in Chat." This is the big one. Manually closing that tab before sending any follow-up prompt to the agent prevents the revert. Yes, that means avoiding a core feature to stop the product from eating code.

Commit like a paranoid junior dev. Small, frequent git commits become restore points. When Cursor silently reverts something, git diff reveals what vanished and git checkout brings it back.

# Run this in a separate terminal to catch silent reverts
watch -n 5 'git diff --stat'

Keep an external diff monitor running. A terminal with git diff --stat on a loop or a tool like delta watching for unexpected file changes acts as a canary. If a file suddenly shows modifications nobody made, something went wrong.

Disable the Agent Review Tab entirely

Some users report that disabling the review tab through settings prevents the revert bug altogether. The tradeoff: losing a significant chunk of Cursor's agent workflow. That's a functionality sacrifice no paying customer should have to make, but it works.

Check Settings > Features > Agent and look for review-related toggles. Naming varies between versions.

Agent Mode and the $2,000 Week

Old Composer was predictable. One request, one response, done. Agent mode works on a completely different cost model. It chains multiple calls together: planning steps, executing them, reviewing results, iterating. Each link in that chain burns tokens.

Developers reported $2,000 in charges across just two days. Not two months. Not even two weeks. Two days. And they weren't running some absurd stress test. They were using agent mode the way Cursor's own demos showed it being used.

Making it worse, Cursor has been quietly tightening request limits each quarter. What started as generous early-adopter allocations keeps shrinking, shoving more users into overage billing territory.

What It Actually Costs: Tool Comparison

Feature	Cursor Pro	Claude Code	GitHub Copilot	Windsurf
Base price	$20/mo	$20/mo (Max plan)	$10–19/mo	$15/mo
Agent/agentic mode	Included (capped)	Terminal-native agent	Copilot Chat	Cascade
Overage model	Pay-per-request past cap	API usage billing	Flat rate, no overage	Tiered limits
Typical heavy-use week	$100–$2,000+	$50–$200	$10–$19 (fixed)	$15–$60
Cost predictability	Low	Medium	High	Medium-High
Hard spending cap	Buried in dashboard	API budget controls	N/A (flat rate)	Tier-based

That "$2,000+" isn't a typo or a worst-case scenario invented for drama. It's a real number from real users doing real work. Cursor is the only tool on this list where weekly costs can spike by an order of magnitude without warning.

Locking Down the Billing

Cursor doesn't make cost controls obvious. Here's where to find them:

Open the web dashboard (not editor settings). Go to Settings > Billing
Look for usage caps. Set a hard monthly maximum if one exists
Monitor the Usage tab daily for at least the first two weeks of agent mode
For routine edits, skip agent mode entirely. Standard autocomplete and inline chat handle most tasks without triggering multi-step chains

Pro tip: Set a calendar reminder to check billing every 48 hours.
Annoying? Yes. Cheaper than the alternative? Absolutely.

The deeper problem isn't just that agent mode costs more. It's that costs are unpredictable. A simple refactor might take three agent steps one day and eleven the next, depending on how the planner interprets the codebase. With autocomplete, costs track keystrokes. With agent mode, costs track the model's internal reasoning, which nobody can forecast.

The Moonshot AI Problem

TechCrunch reported in early 2026 that Cursor's Composer 2 model was built on top of Moonshot AI's Kimi 2.5. Moonshot AI is a Chinese AI company. Plenty of excellent research comes from Chinese labs. That's not the issue.

The issue is that Cursor told nobody.

Developers paying $20–$40/month had every reason to believe they knew what models were processing their code. Cursor's settings page shows model names. Users pick between Claude, GPT-4, and other options. What they didn't pick, because they were never given the choice, was a fine-tuned version of Kimi 2.5 running under a different label.

For compliance teams, this is a five-alarm fire. Organizations that approved Cursor based on Anthropic and OpenAI model usage might have a very different answer for Moonshot AI. Where do prompts go when Composer 2 handles them? Through Cursor's servers only, or do they touch Moonshot AI infrastructure? Without disclosure, there's no way to audit.

If a company will quietly swap out the model powering its flagship feature, what else changes without announcement? That question sits at the center of every trust conversation around Cursor right now. And the company still hasn't answered it.

The Smaller Cuts That Bleed Trust

Headlines go to the silent revert and the billing explosions. But Cursor 3 shipped with a whole collection of paper cuts that make the trust problem feel systemic.

The "Review Next File" crash. Clicking this button in the agent review flow crashes the application. Not sometimes. Reliably. Users lose their in-progress review state and, depending on timing, uncommitted changes too. A core navigation button in a core feature, and it crashes the app. That shipped to production.

Model settings resetting to "auto." Developers have opened Cursor to find their hand-picked model preferences silently flipped back to "auto." Someone who chose Claude 3.5 Sonnet for its coding strengths could be routed to whatever Cursor's auto-selection algorithm picks. Given the Moonshot AI situation, a setting that changes itself carries implications far beyond "annoying UI bug."

Compound failure. Any single one of these is forgivable. Software ships bugs. Billing gets messy. Partnerships evolve. But when all of it lands simultaneously, in the same release, on paying customers, the pattern stops looking like growing pains and starts looking like a product that shipped months before it was ready.

Verify Model Settings Right Now

This takes sixty seconds and might save hours of confusion.

Step 1: Open Cursor > Settings (gear icon, bottom left)
Step 2: Navigate to Models or AI Settings
Step 3: Check the Default Model dropdown
Step 4: If it says "auto" and that's not what was set, it was reset
Step 5: Explicitly select the preferred model. Screenshot the selection.
Step 6: Check again in 48 hours. If it reverted to "auto," the bug is active.

For teams: a more thorough audit process

Add model-setting verification to the developer onboarding checklist
Every dev on a Cursor Business plan should verify settings weekly until the reset bug is confirmed fixed
Screenshot the settings page after every Cursor update (updates are a common trigger for resets)
Look for a separate Composer Model or Agent Model setting, distinct from the chat model. Composer is where the Moonshot-sourced model reportedly runs
If the org has compliance requirements around AI providers, those dated screenshots create an audit trail showing what was configured versus what actually ran

For anyone doing this check right now: also look at the Composer Model or Agent Model setting if it exists separately from the chat model setting. That's where the Moonshot AI-sourced model reportedly operates, and it might be configured differently from what the main settings page suggests.

Why Cursor Is Breaking Things

This isn't carelessness. It's panic.

Claude Code captured roughly 54% of the AI-assisted coding market. That number reshaped the competitive map overnight. Anthropic's approach turned out to be what a huge segment of developers actually wanted: a terminal-native agent that works with existing tools rather than replacing the editor.

Cursor's response was a hard pivot toward "agent orchestrator" territory. That pivot is Cursor 3. Agent-first design, multi-step workflows, the Review Tab, Composer 2. All of it is an attempt to compete with Claude Code's agentic approach from inside a VS Code fork.

On a whiteboard, the strategy makes sense. In production, it shipped half-baked. Features that needed three more months of testing went live because the competitive window felt like it was closing. Power users built Cursor's reputation through word-of-mouth. Those same power users are now the ones absorbing the damage.

Several long-time Cursor advocates have publicly described feeling abandoned as the product moves away from the refined autocomplete-and-chat experience that made it popular. They signed up for the best AI-powered code editor. What they got was an agent orchestrator with a reliability problem. Those are different products with different quality bars.

What Needs to Happen

Cursor has a narrow window to recover.

The silent revert bug needs a fix measured in days, not sprint cycles. The billing model needs a hard spending cap that's visible before charges pile up. The Moonshot AI sourcing needs a retroactive disclosure: what model runs where, where code data flows, and who has access.

Most importantly, model settings need to stay where users put them. When a developer selects Claude Sonnet, that selection should hold until the developer changes it. Not "auto." Not quietly rerouted. Locked.

The developer tools market has never offered more alternatives. GitHub Copilot keeps iterating. Windsurf is gaining traction on simplicity and price. Claude Code is expanding its terminal-native approach. Switching costs for an editor extension hover near zero.

Cursor built its user base on being the AI editor that "just worked." Version 3 has put that reputation in critical condition. The bugs are fixable. The billing model is adjustable. Trust, once broken, rebuilds on a much longer timeline.

For now, the practical advice is blunt: commit constantly, verify model settings on a schedule, monitor billing like it's a production dashboard, and keep a backup editor configured and ready. No developer tool should require that level of defensive behavior from its paying users.

But here we are.

A North Korean Backdoor Lived Inside Axios for 3 Hours. Millions of Pipelines Pulled It.

Gabriel Anhaia — Sun, 05 Apr 2026 17:19:09 +0000

My project: Hermes IDE | GitHub
Me: gabrielanhaia

One hundred million weekly downloads. One stolen token. One backdoor.

Axios 1.14.1 dropped on March 31, 2026. So did 0.30.4. Both looked like routine patch releases. Neither came from the axios team.

They came from North Korea.

For roughly three hours, every npm install that resolved to either version pulled in a dependency called plain-crypto-js. That dependency deployed WAVESHAPER.V2, a multi-platform backdoor built to survive deletion, phone home to a command-and-control server, and hand a remote shell to the attacker. Windows, macOS, Linux. All covered. All weaponized.

Google's Threat Intelligence Group attributed the operation to UNC1069, a North Korea-nexus cluster active since 2018. Not a teenager with a typosquat. A government-funded team with a track record measured in billions of stolen dollars.

Three hours sounds short. At axios's scale, it wasn't.

How a Single Token Burned the Supply Chain

The attack surface was embarrassingly small. One npm authentication token, belonging to one axios maintainer, in the hands of one threat actor. That was enough.

No MFA bypass was reported. No elaborate zero-day exploit chain. The working assumption across every post-incident analysis is that the token itself was the target. Stolen credentials, phished session, compromised development machine — the exact vector hasn't been publicly confirmed. The outcome, though, is crystal clear.

Here's the hour-by-hour damage.

March 31, early hours (UTC): The attacker authenticates to the npm registry using the compromised token. Two new versions publish almost simultaneously. Version 1.14.1 for the current 1.x release line. Version 0.30.4 for the legacy 0.x line. Both add a single new dependency: plain-crypto-js.

The name was chosen with care. It reads like a boring crypto utility. The kind of package that shows up in a diff and gets waved through because nobody wants to investigate a transitive dependency at 2 AM.

Minutes later: CI/CD pipelines worldwide start resolving the new versions. Any project using caret ranges like ^1.14.0 or lacking a committed lockfile gets the poisoned release automatically. No user action required. No prompt. No confirmation dialog.

~2.5 hours after publication: Security researchers flag the anomaly. The compromised versions get yanked from npm. The maintainer's account is locked and recovered. Advisories begin circulating.

Following days: Microsoft, Google, and Tenable publish formal analyses. Google ties the operation to UNC1069 with high confidence.

The window closed fast. What happened inside it didn't.

Anatomy of the Payload: What `plain-crypto-js` Actually Executed

Calling this malware "sophisticated" undersells the engineering. It wasn't a single script grabbing environment variables and posting them to a webhook. It was a staged deployment pipeline — built by attackers who clearly understood how developers work.

Stage 1: Fingerprinting the target

The postinstall script fires the moment npm finishes writing the package to disk. It reads process.platform and process.arch, then selects the appropriate payload. Three operating systems. Two CPU architectures for macOS (x64 and arm64). Someone compiled, tested, and packaged binaries for every platform a working developer might use.

// Simplified reconstruction of the platform check
const os = process.platform;  // 'win32', 'darwin', 'linux'
const arch = process.arch;     // 'x64', 'arm64'
// Selects and fetches the correct binary for the host

Stage 2: Binary drop

Based on fingerprinting results, the script downloads a platform-native binary from an external server. It writes the binary to a hidden path inside node_modules and executes it. Quick. Quiet. Buried under thousands of other files that nobody ever manually inspects.

Stage 3: WAVESHAPER.V2 takes the machine

The binary is the real weapon. Google's analysts designated it WAVESHAPER.V2, and its capabilities read like a pentester's wish list:

Persistence. It copies itself outside the project directory before doing anything else. Deleting node_modules doesn't touch it. Running npm install with a clean version doesn't remove it. The backdoor relocates to OS-specific persistence locations — LaunchAgents on macOS, systemd user services on Linux, startup folders and scheduled tasks on Windows.

Command and control. It opens a reverse connection to an attacker-controlled C2 server and maintains the channel. Remote shell access. Full.

Exfiltration. Environment variables, SSH keys, cloud credential files, browser session tokens, cryptocurrency wallet data. Everything accessible to the user account that ran npm install.

Survival. Even a factory reset of the project directory leaves the backdoor intact. It's living in the home directory. On the system. Not in the dependency tree.

Removing node_modules after installing a compromised version does nothing. The host machine requires a full incident response investigation.

What UNC1069 was harvesting

North Korean cyber operations aren't about espionage in the traditional sense. They're about money.

The UN estimated DPRK-linked groups stole over $3 billion in cryptocurrency between 2017 and 2023. The pace has accelerated since. UNC1069's target list follows the pattern: crypto wallet keys, AWS/GCP/Azure tokens sitting in ~/.aws/credentials or environment variables, SSH private keys for lateral movement into other systems, and CI/CD secrets that open doors to entire organizations.

A developer laptop with cloud access and deployment permissions is worth more to this group than most corporate database servers.

The Bigger Nightmare: This Wasn't a Solo Operation

The axios compromise would be alarming enough on its own. It wasn't on its own.

Between March 19 and March 27 — days before the axios attack — a separate North Korea-linked group tracked as TeamPCP (UNC6780) executed a parallel campaign through a completely different vector. They didn't steal npm tokens. They exploited GitHub Actions workflows and PyPI packages.

Their target list is almost funny in a gallows-humor kind of way:

Trivy, Aqua Security's vulnerability scanner. The tool organizations use to detect compromised dependencies was itself compromised. KICS (Keeping Infrastructure as Code Secure) got the same treatment. A security tool, backdoored. LiteLLM, a popular LLM proxy library, was hit. So was Telnyx, a cloud communications platform.

TeamPCP deployed SANDCLOCK, a credential stealer purpose-built for CI/CD environments. It harvested cloud tokens, API keys, and pipeline secrets from build runners.

Two groups. Two attack vectors. Multiple high-value targets. All within twelve days.

Whether UNC1069 and UNC6780 coordinated directly or simply operated under the same strategic directive from Pyongyang is unknown. The result is identical either way: a sustained, multi-pronged assault on the open-source supply chain.

Are You Affected? Find Out Right Now.

Stop skimming. Run these commands. The rest of the article isn't going anywhere.

Check the lockfile for the malicious dependency

# npm projects
grep "plain-crypto-js" package-lock.json

# yarn projects
grep "plain-crypto-js" yarn.lock

# pnpm projects
grep "plain-crypto-js" pnpm-lock.yaml

Any match means the compromised version was installed.

Verify your current axios version

npm ls axios

The output shows exactly which version sits in the dependency tree right now. If it reads 1.14.1 or 0.30.4, the machine that ran the install needs investigation. Not just the project. The machine.

Check the npm cache

Even if the current version is clean, the cache remembers.

npm cache ls 2>/dev/null | grep "axios" | grep -E "1\.14\.1|0\.30\.4"

Run npm audit

npm audit

The advisory for the compromised versions should surface here if the dependency tree ever referenced them.

Hunt for WAVESHAPER.V2 persistence artifacts

If you confirmed a compromised version was installed, check these locations

macOS:

ls -la ~/Library/LaunchAgents/
find ~/.local -type f -newer /tmp 2>/dev/null
find /tmp -name ".*" -type f 2>/dev/null

Linux:

ls -la ~/.config/systemd/user/ 2>/dev/null
find ~/.local -type f -newer /tmp 2>/dev/null
find /tmp -name ".*" -type f 2>/dev/null

Windows (PowerShell):

Get-ScheduledTask | Where-Object {$_.Date -gt "2026-03-30"}
dir "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"

Any unfamiliar files created on or after March 31, 2026 in these locations warrant immediate escalation to a security team.

Don't forget CI/CD

This is the check most teams will skip. Don't.

If a CI pipeline ran npm install (not npm ci) during the March 31 window without a pinned lockfile, the build runner may have executed the backdoor. Ephemeral runners like GitHub Actions hosted agents are lower risk because they're destroyed after each job. Self-hosted runners, Jenkins boxes, and long-lived build servers are a completely different situation.

Review outbound network logs from those machines for the March 31 timeframe. Any unexpected connections to unfamiliar IPs during or after the window should be treated as indicators of compromise.

What Every Team Should Do This Week

Today

Run every detection command above. Every project. Every CI environment. Every build server.

Switch CI pipelines from npm install to npm ci. This single change would have blocked the axios compromise entirely for any project with a committed lockfile. npm ci installs exactly what the lockfile specifies and fails hard on mismatches.

# Replace this in every CI config:
npm install

# With this:
npm ci

Pin dependency versions. Caret ranges (^1.14.0) and tilde ranges (~1.14.0) exist for convenience. They also exist as an attack surface. Exact versions in package.json plus a committed lockfile equals a dramatically smaller blast radius.

This week

Audit and rotate all npm tokens.

npm token list
npm token revoke <token-id>

Revoke anything unrecognized. Rotate everything else. If anyone on the team maintains a public package, enforce 2FA on their npm account today, not tomorrow.

Review GitHub Actions workflows for the patterns TeamPCP exploited. Workflows using pull_request_target with a checkout of the PR branch allow external contributors to run arbitrary code with write permissions. That's the exact mechanism UNC6780 used.

Evaluate a registry proxy. Tools like Verdaccio, Artifactory, or npm Enterprise can allowlist specific package versions before they reach developer machines. It's an extra layer that costs time to configure and saves everything when it matters.

Ongoing

Run npm audit as a blocking CI step. Known vulnerabilities should fail the build. No exceptions. No --force to skip warnings.

Subscribe to security feeds. GitHub's advisory database, npm security advisories, and Google Threat Intelligence all published within 48 hours of the axios incident. Teams that monitor these feeds had time to react. Teams that don't monitor them found out from Twitter, days later.

Why npm Keeps Getting Hit

The npm registry is built on a trust model designed for a different era. Anyone with an account can publish. Anyone with a maintainer token can push a new version of an existing package. There's no mandatory code review gate. No build reproducibility requirement. No quarantine period between publication and global availability.

Compare that to Linux distribution package management, where maintainer committees review submissions and reproducible builds can be independently verified. Or mobile app stores, where multi-day review processes and cryptographic signing are table stakes.

npm has a username, a password, and an optional TOTP code. That's the entire barrier between an attacker and one hundred million weekly installs.

Improvements exist. Provenance attestation. Granular access tokens. 2FA support. All voluntary. All opt-in. Adoption rates are growing but remain far from universal.

The gap between npm's trust architecture and the actual threat environment is staggering. Nation-state actors have done the math. Compromising a single developer account on a package registry provides simultaneous access to thousands of downstream organizations. The return on investment is extraordinary, and North Korea has stronger financial incentive than almost any other actor to keep exploiting it.

The Bottom Line

A state-sponsored group compromised one of the most widely installed packages on the planet. The attack was caught in under three hours. That's genuinely fast, compared to supply chain incidents that take weeks or months to surface.

Fast wasn't fast enough.

Every developer who ran npm install without a pinned lockfile during that window was exposed. Every CI pipeline pulling fresh dependencies without npm ci was exposed. Every self-hosted build server that cached the compromised version might still be running a backdoor right now, five days later, with nobody aware.

Treating dependency management as a convenience function rather than a security function is the root cause. Pin versions. Commit lockfiles. Use npm ci in automation. Audit regularly. Monitor advisories. Investigate machines that pulled affected versions, not just the projects.

The axios backdoor lived for under three hours. The next one might not get caught that quickly.

GitHub Starts Training AI on Your Private Code April 24 — Here's How to Stop It

Gabriel Anhaia — Sun, 05 Apr 2026 17:17:33 +0000

My project: Hermes IDE | GitHub
Me: gabrielanhaia

Nineteen Days

On March 25, 2026, GitHub published a blog post. Most developers didn't see it. The ones who did wish they hadn't needed to.

Buried under several paragraphs of cheerful corporate language about "improving the Copilot experience," one detail stood out: starting April 24, 2026, GitHub will use Copilot interaction data from Free, Pro, and Pro+ users to train its AI models. Not "might use." Not "is exploring." Will use. Default: on.

The Hacker News thread went exactly how anyone would expect. The Register picked it up. And now there are roughly 19 days left before this kicks in. Every affected user who doesn't explicitly opt out gets enrolled automatically.

That's bad enough. The specifics are worse.

What "Interaction Data" Actually Means

GitHub chose the term "interaction data" carefully. It sounds harmless. Benign, even. Like telemetry about button clicks. It isn't.

Here's what falls under that label:

Prompts and instructions. Every question typed into Copilot Chat. Every inline comment written to trigger a suggestion. A developer typing "refactor this auth handler to support OAuth2 PKCE flow" — that's collected.

Code snippets sent as context. This is the big one. When Copilot generates suggestions, it reads surrounding code for context. That surrounding code gets sent to GitHub's API as part of the request. Code from private repositories. Collected.

Generated outputs. Every suggestion Copilot produces, accepted or rejected.

Behavioral signals. Which suggestions were accepted, which were dismissed, how developers modified the output after accepting it. A detailed log of how humans interact with AI-generated code.

Here's what a single interaction looks like from a data collection perspective:

{
  "prompt": "Add JWT validation with RS256 to this endpoint",
  "context_snippets": [
    "class AuthService:\n    def __init__(self, secret_key, issuer)...",
    "from app.models import User, Session, TokenBlacklist...",
    "ALLOWED_ORIGINS = ['https://internal-dashboard.company.com']..."
  ],
  "suggestion": "def validate_token(self, token: str) -> dict:\n    try:\n        payload = jwt.decode(token, self.public_key, algorithms=['RS256'])...",
  "accepted": true,
  "modified_after_acceptance": true
}

Notice what's in those context snippets. Internal class names. Import paths that reveal project structure. An internal URL. None of this was pushed to a public repo. It got hoovered up because a developer used the autocomplete in their editor.

One interaction might expose a handful of lines. A full workday of Copilot usage? That's a different story.

40 Copilot interactions per day
× ~200-500 lines of surrounding context each
= 8,000-20,000 lines of private code per day
× 20 working days per month
= 160,000-400,000 lines per month

That math isn't theoretical. It's what happens when someone actually uses Copilot the way GitHub wants them to.

What GitHub Says It Won't Touch

Credit where it's due: GitHub has been specific about the boundaries. The distinction is real, even if it's thinner than the marketing suggests.

Private repository content "at rest" is not used for training. GitHub does not crawl private repos and feed them into models.

A developer with a 50,000-line private codebase who only used Copilot on 200 lines means only those 200 lines' worth of context entered the pipeline. The other 49,800 lines stay put.

GitHub also confirmed that Business and Enterprise plan users are completely excluded. Their data policies haven't changed. This only hits individual-tier accounts: Free, Pro, and Pro+.

Which creates an absurd situation. A solo developer building a SaaS product on a personal Pro account gets less data protection than a junior dev at a Fortune 500 company using the same tool on the same kind of code. The difference? Corporate lawyers negotiated those Enterprise terms. Individual developers got a blog post and a toggle.

The Full Opt-Out Walkthrough

This takes about 90 seconds. There's no reason to wait.

Step 1: Open the Copilot settings page.

Direct URL:

https://github.com/settings/copilot

Manual path: GitHub profile icon (top right) → Settings → Copilot (left sidebar).

Step 2: Find the training data toggle.

Look for a setting labeled:

"Allow GitHub to use my data for product improvements"

It's on the main Copilot settings page under the data usage section. Simple toggle switch.

Step 3: Turn it off.

Flip the toggle to disabled. The page should auto-save. If there's a save button, click it. Verify it shows as disabled before navigating away.

Step 4: Verify via API.

UI toggles are great. API confirmation is better. Run this:

curl -s \
  -H "Authorization: Bearer YOUR_GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/user/copilot \
  | jq '{ ide_chat: .copilot_ide_chat, model_training: .copilot_model_training_opt_in }'

Replace YOUR_GITHUB_TOKEN with a personal access token that has the read:user scope. The copilot_model_training_opt_in field should return false. If it returns true, the opt-out didn't stick — go back and try again.

Don't have jq installed? The raw JSON output works fine too:

curl -s \
  -H "Authorization: Bearer YOUR_GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/user/copilot

Search the output for copilot_model_training_opt_in and confirm it's false.

Step 5: Check organization settings.

Anyone who administers a GitHub organization on a Free or Pro plan should also check org-level settings:

https://github.com/organizations/YOUR-ORG/settings/copilot

Organization admins can enforce the opt-out for all members. Worth doing, especially for open source projects where contributors on personal accounts might not update their own settings.

Who's Affected and Who Isn't

Plan	Affected?	Action Needed
GitHub Free (with Copilot Free)	Yes	Opt out manually
GitHub Pro	Yes	Opt out manually
GitHub Pro+	Yes	Opt out manually
GitHub Team	Possibly	Admin should verify org settings
Copilot Business	No	Existing data policies unchanged
Copilot Enterprise	No	Existing data policies unchanged

The tiering tells on itself. Enterprise customers have legal teams that would shred the contract over a default opt-in to training. Individual developers don't have legal teams. They have Reddit threads and strongly worded blog posts.

The "We're Not Reading Your Repos" Problem

GitHub's position boils down to: "We're only using interaction data, not your repository content." Technically accurate. Practically misleading.

The interaction data contains code from those repositories. Every snippet sent as context originated from a repo the developer intended to keep private. Every prompt that references internal architecture. Every generated output that builds on proprietary logic. It all came from somewhere, and that somewhere was a private repo.

The distinction between "we didn't read your private repo" and "we read the parts of your private repo that flowed through our tool" is real but razor-thin. Especially at scale.

Think about what a typical Copilot power user generates over a month. Tens of thousands of lines of private code fragments sitting in GitHub's "interaction data" corpus. Nobody pushed those lines to a public repo. Nobody checked a box saying "use this for training." The consent happened retroactively, via a default-on toggle that most users will never see.

The Supply Chain Angle Nobody's Talking About

Here's where things get genuinely messy.

A freelancer uses their personal GitHub Pro account. They work on three client projects, all in private repos. They use Copilot constantly because it makes them faster and clients don't care how the code gets written, just that it works.

Starting April 24, fragments of every client's codebase enter the training pipeline. The freelancer might not even know. The clients definitely don't. No NDA was violated intentionally. The developer just used the same IDE plugin they always use.

Now scale that to regulated industries. A contractor doing healthcare work uses their personal Copilot account. Internal API naming conventions that hint at data models, database schemas with field names that reference PHI categories, authentication patterns specific to HIPAA-compliant systems — all of that can end up in interaction data. The contractor didn't do anything wrong. They just didn't opt out of a setting they didn't know existed.

The liability questions here aren't hypothetical anymore. They're calendar events.

What the Developer Community Got Right (and Wrong)

The backlash split into predictable camps.

Some developers called it a bait-and-switch. They adopted Copilot under one set of data policies, integrated it into daily workflows, and now those policies are changing underneath them. This is a fair reading. The terms changed. The habits built on the old terms didn't.

Others argued that interaction data is fundamentally different from repository access and that AI training on usage patterns makes the tool better for everyone. Also fair, but it assumes anonymization is bulletproof and that code fragments aren't reconstructible. That's an assumption doing a lot of heavy lifting.

The most interesting critique came from developers asking why code is treated differently from other creative work. When Spotify uses listening data to improve recommendations, the algorithm learning someone's taste in music doesn't threaten their career. When GitHub uses coding data to improve Copilot, the improved model generates code that competes with the developer who produced the training data. Users improve the product, and the improved product reduces demand for those same users.

Nobody's solved that incentive problem. Most companies aren't even acknowledging it exists.

Alternatives Worth Knowing About

For developers who want AI coding assistance without the training data question hanging overhead, options exist. None are perfect.

Self-hosted models. Running a local code model through Ollama, LM Studio, or llama.cpp means code never leaves the machine. Quality is improving fast but still falls short on large, context-heavy codebases.

Copilot Business or Enterprise. The "pay more, keep your data" option. GitHub's upsell pitch, working exactly as designed. Cynical but effective.

Competitors with no-training policies. Some AI coding tools have taken a hard stance against training on user data. Read the actual terms of service, not the landing page. Policies change. This exact GitHub situation proves that point.

Local inference in the editor. Some IDEs are building on-device AI features that never phone home. Still early. The direction matters more than the current quality.

What about open source contributors?
For developers working exclusively on public, open-source code, the training data question is less urgent — the code is already public. But interaction data still includes prompts, behavioral signals, and context from private development branches that might not be public yet. Even open source developers should consider opting out if they work on any private branches or repos alongside their public work.

The Actual Checklist

For anyone who scrolled past everything else:

[ ] Go to github.com/settings/copilot
[ ] Disable "Allow GitHub to use my data for product improvements"
[ ] Run the API curl command to verify copilot_model_training_opt_in is false
[ ] If administering an org, check org-level Copilot settings
[ ] Tell other developers on the team — especially contractors and freelancers on personal accounts
[ ] Set a calendar reminder after April 24 to verify the setting didn't reset
[ ] Review which Copilot features are still enabled and whether the trade-off makes sense

The Default Is the Policy

Here's the uncomfortable truth that makes this more than a settings toggle.

GitHub reported over 150 million developers on the platform. Copilot has millions of active users. Even a generous estimate — say 10% of affected users see the announcement and opt out — leaves millions of developers unknowingly feeding interaction data into training runs. That's not a bug. That's the business model.

Default settings are policy. Blog posts are plausible deniability. The 30-day window between announcement and enforcement is just long enough to say "we gave people time" and just short enough to ensure most people miss it.

GitHub built a tool developers genuinely love. Copilot makes people faster. That's not in dispute. What's in dispute is whether a good product earns the right to change data policies retroactively with a default opt-in that most users won't see.

Nineteen days. Go flip the toggle. Tell someone else to flip theirs.

52,050 Layoffs Based on Vibes: The Math Behind AI-Driven Workforce Cuts Doesn't Add Up

Gabriel Anhaia — Sun, 05 Apr 2026 15:21:32 +0000

Harvard Business Review published a piece in early 2026 with a title that should've set off alarm bells across every engineering org on the planet: "Companies Are Laying Off Workers Because of AI's Potential — Not Its Performance."

Not performance. Potential.

That's the corporate equivalent of demolishing a profitable restaurant because someone heard a rumor about a self-cooking kitchen. Except 52,050 real people lost real jobs in Q1 2026 over this particular rumor.

The Q1 2026 Scoreboard

Before anyone dismisses this as doomerism, here are the actual numbers:

Metric	Q1 2025	Q1 2026	Change
Total tech layoffs	~37,000	52,050	+40% YoY
Companies citing "AI efficiency"	12	31	+158%
Measurable AI productivity data shared	0	0	No change

That last row is the important one. Thirty-one companies told Wall Street that AI-driven efficiency justified cutting engineering headcount. Zero of them published internal data showing those efficiency gains actually existed.

Meta, Google, Amazon, Block, Atlassian, Pinterest, Salesforce. All of them used some variant of "AI productivity" or "automation dividend" on their earnings calls. None of them showed the receipts.

The 55% Productivity Claim vs. Reality

A number keeps showing up in executive presentations: teams using AI coding assistants produce 40-55% more code per sprint. Sounds great on a slide. It's also the wrong metric, and everybody who's actually shipped software knows it.

Here's what the engineering workload breakdown looks like in practice:

Activity	% of Engineer Time	AI Capability
Writing new code	~20%	Strong (boilerplate, CRUD, tests)
Reading/understanding existing code	~25%	Moderate (summaries, not deep context)
System design & architecture	~15%	Weak
Debugging & incident response	~15%	Very weak
Code review & collaboration	~10%	Superficial
Cross-team coordination	~10%	None
Requirements & stakeholder work	~5%	None

AI tools are good at roughly 20% of the job. They're passable at another 25%. They're useless at the remaining 55%. Firing 15-20% of an engineering org because tools got better at the easiest fifth of the work isn't strategy. It's innumeracy.

Code AI Actually Can't Write

The "55% more productive" claim falls apart the second anyone looks at what AI-generated code actually looks like in production systems. Here's a real-world example that illustrates the gap.

Ask any AI assistant to design a retry mechanism for a distributed payment processing system. Something like this:

# What AI generates (and what juniors accept):
async def process_payment(payment_id: str):
    for attempt in range(3):
        try:
            result = await payment_gateway.charge(payment_id)
            return result
        except Exception:
            await asyncio.sleep(2 ** attempt)
    raise PaymentFailedError(f"Payment {payment_id} failed after 3 attempts")

Looks clean. Passes linting. Even has exponential backoff. Ship it, right?

Wrong. A senior engineer would immediately spot what's missing:

# What production actually needs:
async def process_payment(payment_id: str):
    # Idempotency key prevents double-charging on retry
    idempotency_key = await get_or_create_idempotency_key(payment_id)

    # Check if payment already succeeded (another instance might've
    # completed it while we were retrying)
    existing = await payment_ledger.get_status(payment_id)
    if existing == PaymentStatus.COMPLETED:
        logger.info(f"Payment {payment_id} already completed, skipping")
        return existing

    for attempt in range(3):
        try:
            result = await payment_gateway.charge(
                payment_id,
                idempotency_key=idempotency_key,
                # Gateway timeout must be LESS than our consumer's
                # visibility timeout, or we'll get duplicate processing
                timeout=GATEWAY_TIMEOUT_SECONDS,
            )
            await payment_ledger.record(payment_id, result)
            await dead_letter_queue.remove_if_present(payment_id)
            return result

        except GatewayTimeoutError:
            # DON'T retry timeouts - the charge might have gone through.
            # Route to manual review queue instead.
            await manual_review_queue.enqueue(payment_id, reason="timeout")
            raise

        except RateLimitError as e:
            # Respect the gateway's retry-after header, not our own backoff
            await asyncio.sleep(e.retry_after)

        except TransientError:
            backoff = min(2 ** attempt + random.uniform(0, 1), MAX_BACKOFF)
            await asyncio.sleep(backoff)

            if attempt == 2:
                await dead_letter_queue.enqueue(
                    payment_id,
                    last_error=traceback.format_exc(),
                    retry_count=attempt + 1
                )

    raise PaymentFailedError(
        f"Payment {payment_id} failed after 3 attempts",
        alert_oncall=True,  # Page someone. Money is involved.
    )

The difference between those two blocks is about six production incidents, a possible double-charge, and an angry call from the payments team at 3 AM. AI generated the first version. Only a human who's been burned before writes the second.

Another example. Try asking an AI to debug this:

// "It works fine locally but times out in production 2% of the time"
func GetUserProfile(ctx context.Context, userID string) (*Profile, error) {
    profile, err := cache.Get(ctx, userID)
    if err == nil {
        return profile, nil
    }

    profile, err = db.QueryProfile(ctx, userID)
    if err != nil {
        return nil, err
    }

    cache.Set(ctx, userID, profile, 1*time.Hour)
    return profile, nil
}

AI will suggest adding timeouts, retries, circuit breakers. All wrong. The actual bug? In production, the cache cluster runs across three availability zones. 2% of requests hit a node in a different AZ where a recent network policy change added 800ms of latency. The cache Get call doesn't fail — it just takes long enough to eat the request's timeout budget before the database call even starts.

No AI tool figures that out, because it requires knowing the infrastructure topology, the recent change history, and the operational context. That knowledge lived in the heads of the people who just got walked out with a cardboard box.

The Incident Rate Nobody Mentions on Earnings Calls

Here's the metric that should be on every board slide but mysteriously isn't. These numbers are composited from publicly shared engineering metrics and postmortem trends across mid-to-large tech companies in late 2025 and early 2026:

Metric	Pre-AI Tooling	Post-AI Tooling	Change
PRs merged per sprint	34	51	+50%
Incidents per PR	0.034	0.042	+23.5%
Total incidents per sprint	1.16	2.14	+85%
Mean time to resolve	2.1 hrs	3.4 hrs	+62%

Read that bottom row. Incidents aren't just happening more often. They're taking longer to fix. Because the people who understood the systems well enough to fix them quickly are gone.

The math tells a brutal story. A team that shipped 34 PRs and handled ~1.2 incidents per sprint now ships 51 PRs and handles ~2.1 incidents. If each incident consumes an average of 3.4 engineer-hours (up from 2.1), that's 7.1 hours per sprint burned on incidents instead of 2.4.

The "productivity gain" of 17 extra PRs costs 4.7 extra hours of firefighting per sprint — and that's before accounting for the reduced team size. Fewer engineers splitting more incident load means each person carries a heavier on-call burden. Burnout follows. Then attrition. Then more hiring, often at premium rates, because the company now needs to backfill institutional knowledge it threw away for free.

The Stock Price Play

There's a less charitable explanation for what's happening, and it involves looking at who benefits from the "AI efficiency" story.

When a company announces AI-driven layoffs, its stock typically jumps 3-7% within 48 hours. The productivity gains don't need to be real. The market reaction is real enough.

This creates a perverse incentive loop:

CEO announces layoffs, cites AI efficiency
Stock jumps
Executive compensation (tied to stock price) increases
Board sees stock performance, approves more of the same
Actual engineering output degrades quietly over 12-18 months
By the time the damage shows, the narrative has shifted

It's not conspiracy thinking. It's just recognizing that the people making layoff decisions are financially rewarded for making them, regardless of the engineering outcome.

There's also the uncomfortable overlap between companies selling AI products and companies citing AI as the reason for layoffs. When a cloud provider says "AI makes developers 55% more productive," that provider is also selling AI developer tools at $19-40/seat/month. The incentive to produce honest productivity assessments is... limited.

The Skill Paradox That Makes It Worse

Here's the part that would be funny if it weren't so destructive.

Senior engineers get the most value out of AI tools. They know what good code looks like, so they can evaluate AI output critically. Architectural context lets them integrate generated code without breaking existing systems. Years of production failures give them the instinct to reject AI suggestions that will cause problems downstream.

Junior engineers, by contrast, tend to accept AI suggestions at face value. Without that scar tissue, a clean-looking retry loop reads as correct code rather than a double-charge waiting to happen.

So the layoffs that disproportionately hit experienced engineers are removing exactly the people who make AI tools safe to use. The remaining team is less equipped to evaluate AI output, which means more bad code ships, which means more incidents, which means more pressure on an already-thinned team.

It's a doom loop with a nice PowerPoint attached.

The Historical Rhyme

This pattern isn't new. The technology changes. The corporate behavior doesn't.

Hype Cycle	Promise	Premature Workforce Action	Outcome
Blockchain (2017-2019)	Decentralize everything	Restructured teams for "Web3"	Most projects dead by 2022
RPA (2015-2020)	Automate all back-office work	Cut operations staff	Rehired 60-70% within 2 years
Cloud migration (2012-2016)	Zero ops engineers needed	Cut infrastructure teams	Created "DevOps" role at 2x salary
Offshoring (2003-2008)	Same quality, 1/4 the cost	Cut domestic engineering	Brought much of it back within 3-5 years
AI coding tools (2024-now)	Replace junior/mid engineers	Cutting 15-20% of eng orgs	TBD (but early data isn't encouraging)

All of them followed the same arc: real technology gets overhyped, executives make premature workforce decisions, reality bites, and the company quietly rebuilds — usually at higher cost and with less institutional context.

The difference this time is that AI coding tools are useful -- more useful than blockchain was for most businesses, more practical than early RPA. That kernel of real value makes the hype harder to separate from reality. But "useful tool" and "replacement for human judgment" aren't even in the same category.

What Smart Companies Are Actually Doing

Not every company is sleepwalking into this trap. The ones getting it right aren't cutting engineers. They're redeploying them.

The rational approach looks like this: use AI to automate the boring parts (boilerplate, test scaffolding, documentation drafts), then redirect human time toward the work AI can't do (system design, cross-team architecture, security auditing, the kind of deep debugging that requires knowing why the system is built the way it is).

A team of 10 using AI well can operate like a team of 14. That's real and valuable. But cutting the team to 7 and hoping AI makes up the difference isn't the same math. One approach builds on proven capability. The other is a coin flip with people's livelihoods.

The problem is optics. "We're redeploying our workforce to focus on higher-value work alongside AI tools" doesn't pop on an earnings call the way "we cut 20% of engineering and invested in AI" does. Wall Street rewards the dramatic narrative. The sensible one gets polite nods and no stock bump.

The 18-Month Prediction

This story has a predictable ending because it's the same ending every time.

Within 18-24 months, some of the companies making the deepest AI-motivated cuts will be hiring again. The job titles will be different. "AI Systems Engineer" instead of "Software Engineer." "Human-in-the-Loop Architect" instead of "Senior Developer." The LinkedIn posts will celebrate the exciting new roles without mentioning they're doing the same work the laid-off engineers did, minus three years of institutional knowledge.

The 52,050 people affected in Q1 2026 will mostly land on their feet. Good engineers always do. But the disruption, the uprooted families, the abandoned projects — all of it happened because of a speculative thesis, not empirical evidence.

Companies are firing developers today based on tools they hope to have tomorrow. The HBR piece named it precisely. These layoffs aren't a response to demonstrated AI capability. They're a response to a story about AI capability. And unlike software, stories don't need to compile to be believed.

The data says one thing. The earnings calls say another. Somewhere between those two realities, 52,050 engineers are updating their resumes because a slide deck full of projections was more persuasive than their actual output.

That's not strategy. That's a very expensive way to learn a lesson the industry has already learned four times before.

Has your team been affected by AI-justified layoffs or restructuring? Are you seeing the productivity gains that leadership claims, or is the gap between the narrative and reality as wide as the data suggests? I'd like to hear what it looks like from the inside.

My project: Hermes IDE | GitHub
Me: gabrielanhaia

DEV Community: Gabriel Anhaia

Stop Passing *sql.Tx Through Your Go Service Layer

What's Wrong

The Unit of Work Pattern

The Service

The In-Memory Adapter (For Tests)

The Rollback Test

When You Don't Need This

The Dependency Rule: One Import Statement Will Tell You If Your Go Architecture Is Broken

The Rule

What "Depends On" Means in Go

How Violations Sneak In

The Correct Way

How to Detect Violations

main() Is the Exception

Testing a Go Service in Microseconds: The Hexagonal Testing Strategy

Three Layers, Three Strategies

Layer 1: Domain Tests — Microseconds

Layer 2: Adapter Tests — Milliseconds

Layer 3: Integration Tests — Seconds

The Pyramid

Hand-Written Doubles > Mock Frameworks

Go Interfaces Are Ports: The Language Feature That Makes Clean Architecture Free

The Java Way vs The Go Way

Small Interfaces Win

The Testing Payoff

The Rule

Hexagonal Architecture in Go: Why Your Service's Business Logic Should Know Nothing About HTTP

The One Rule That Fixes It

Why Go Is Perfect for This

The Before and After

The Book

Your Vulnerability Scanner Was the Vulnerability: 4 Projects Backdoored in 8 Days

Eight Days, Four Compromises, Two Security Scanners

How Mutable Tags Became the Weapon

What SANDCLOCK Harvests

Checking Whether You Got Hit

Trivy

KICS

LiteLLM

Telnyx

General SANDCLOCK Indicators

The Broader March 2026 Context

Defensive Measures That Would Have Caught This

The Trust Problem Doesn't Have a Clean Fix

Coinbase Fired Engineers Who Didn't Learn AI in Five Days. The Industry Barely Flinched.

The Timeline Nobody Talks About

What Does "33% AI Code" Actually Measure?

AI Adoption Mandates: Who's Doing What

Who Decides What Counts as a "Good Reason"?

The Speed Fallacy

What Working Engineers Should Take From This

The Precedent That Matters More Than the Tools

They Forced a Junior to Use AI. Then Fired Him for the Bugs It Wrote.

Two Bugs and a Cardboard Box

The Coinbase Connection

What "AI-First Development" Looks Like from the Bottom

The Bug That Passes Every Test

Before and After: What Proper Review Looks Like

The Numbers Nobody Puts on a Slide

Accountability Flows Downhill. It Shouldn't.

Armstrong's 50% and What It Means for Coinbase

What Reddit Got Right

What Should Actually Happen

The Question Nobody in Leadership Wants to Sit With

Cursor 3 Is Silently Deleting Code, Draining Wallets, and Swapping Models Behind Closed Doors

The Bug That Should've Blocked the Release

Workarounds (That Shouldn't Be Necessary)

Agent Mode and the $2,000 Week

What It Actually Costs: Tool Comparison

Locking Down the Billing

The Moonshot AI Problem

The Smaller Cuts That Bleed Trust

Verify Model Settings Right Now

Why Cursor Is Breaking Things

What Needs to Happen

A North Korean Backdoor Lived Inside Axios for 3 Hours. Millions of Pipelines Pulled It.

One hundred million weekly downloads. One stolen token. One backdoor.

How a Single Token Burned the Supply Chain

Anatomy of the Payload: What plain-crypto-js Actually Executed

`main()` Is the Exception

Anatomy of the Payload: What `plain-crypto-js` Actually Executed