In a Snowflake medallion architecture, raw data lands in Bronze, which dbt cleans into Silver and shapes
into Gold. dbt owns the two upper layers completely. Every dbt run recreates the tables and views its
models define, from code that is versioned, reviewed, and tested.
The bronze layer those models stand on has no such owner. This post is about that layer, and giving Bronze
a proper owner without disrupting your dbt project.
Anthropic recently published The AI-Native SDLC playbook, and
it's the most concrete writeup I've seen discussing the effects of cheaper code generation on a delivery process,
written by a company where AI authors 80% of merged code.
If you run engineering at any scale, I suggest you read it.
It consists of six stages from Plan to Maintain that work in a loop rather than a linear chain of handoffs. Each
stage commits an artifact that the next stage reads. The chain of commits is the audit trail. Humans stop reading
every line and start judging intent and risk.
GitLab's CEO responded with the line that will likely outlive
the playbook itself: "when implementation becomes abundant, trust becomes scarce."
Code is abundant now. Your data is not. An agent can regenerate your code in an afternoon, but it cannot regenerate the
production state your company accumulated over years. The playbook's recovery model quietly assumes otherwise, which
leads to our claim: the loop does not close at the database.
The database is the one stateful component in your infrastructure. It's where the history lives, and you cannot roll
back history by redeploying an older version of it.
As of April 2026, MySQL 8.0 has reached End of Life (EOL), marking a critical security and operational milestone. When a
database reaches EOL, the safety net is pulled away. Oracle will no longer release security patches, bug fixes, or
performance improvements for the community edition. If a vulnerability is discovered tomorrow, your 8.0 instances will
remain exposed.
In this post, we’ll explore what this means and how cloud platforms are responding to it.
Platform engineering is rapidly emerging as a discipline aimed at reducing cognitive load for developers, enabling
self-service infrastructure, and establishing best practices for building and operating software at scale. While much
of the conversation focuses on CI/CD, Kubernetes, and internal developer platforms, one crucial aspect often remains
overlooked: database schema management.
Despite being at the heart of nearly every application, schema changes are still a major source of friction, outages,
and bottlenecks. In this post, we'll explore why database schema management deserves a dedicated chapter in the
platform engineering playbook and how organizations can integrate it into their platform strategies.
Let me tell you a not-so-fictional story about a developer named Alice. Alice is a backend engineer at a fast-growing
startup. One day, her manager asked her to make a small change to the database. The data engineering team was
complaining that they were seeing duplicate emails in the user table, and they suspected that the email column did
not have a unique constraint.
