People hear "AI-native" and assume it means typing less code. That's the least interesting part. After fifteen years in data engineering and backend systems, the shift that actually matters isn't speed — it's where the engineering effort goes. When a model can produce a first draft of almost anything in seconds, the scarce skill stops being "can you write this" and becomes "can you design the system so the machine's output is reliable, and can you verify it." Generation gets cheap. Judgment, structure, and verification get expensive. AI-native engineering is the practice of moving your effort to the parts that stay hard.
This post is the hub for everything else I've written about the craft. Think of it as the method, with the proof linked alongside.
The method#
Five habits show up in every project I build this way.
Design in conversation, not in your head. I use Claude Code↗ as my default development environment, and the work starts as a dialogue — sketching the system in language, arguing with it, watching the shape emerge before any code is committed. It's closer to pairing than to autocomplete. The leverage isn't fewer keystrokes; it's that the cost of exploring a design dropped to near zero, so you explore more of them.
Draw the boundary between deterministic code and model judgment. This is the single most important decision in any AI system. Anything with a verifiable ground truth should be produced by code, not the model — the model's job is to interpret facts, not invent them. I made the whole argument, with a real skill as the example, in building agentic workflows with Claude Code. Get this boundary wrong and no amount of prompting saves you.
Put a validated contract in the middle. Free-form model output drifts. A structured, schema-validated artifact that everything downstream renders from does not. It also makes the model's job smaller and testable. This is why I think in systems, not scripts — the interface is where reliability lives.
Gate on evidence, not confidence. Models will tell you something is true because it pattern-matches as true. So acceptance has to depend on something external — a screenshot, a schema check, a test. The verify half of the loop does more work than the generate half, which is the whole point of delegate and verify.
Package the capability so it runs the same tomorrow. A clever afternoon isn't a workflow. Skills and MCP servers turn a one-off into infrastructure someone else can invoke identically. The packaging is the product.
None of these are about AI specifically. They're how you build reliable systems out of an unreliable component — which is most of engineering. The model just makes the unreliable component unusually capable, which raises the stakes on getting the structure right.
The proof#
Method is cheap to assert and expensive to demonstrate, so here's the demonstration. Each of these is a worked instance of the habits above:
- Data pipelines — dlt and DuckDB push the boring 80% (schema inference, normalization, idempotent loads) into the library, leaving only the decisions a human should make. Deterministic code where it belongs.
- Data lineage — column-level lineage is derived data, regenerated from the SQL on every commit, so it's never stale. A contract you can query.
- RAG backends — designing an embeddings backend is mostly about retrieval quality and the cheap-recall/expensive-precision shape, not about the model. Effort moved to where it pays.
- Analytics — SQL window functions keep logic in the query, close to the data, expressed once. The unglamorous fundamentals still matter.
- Agentic systems — Glasshouse audits any website for GDPR end to end: deterministic sensors, a JSON contract, mandatory evidence, packaged as a skill. The method, fully assembled.
And the meta-example: this entire site — the blog engine, the admin agent, the interactive artifacts, an AI music product — was built AI-natively, first prompt to deployment. The stack behind the blog is itself a build log of working this way.
Why it holds up#
The frontier moves fast, and a method tied to a specific model or tool ages badly. What's held up for me is that none of these habits depend on which model I'm using. Deterministic boundaries, validated contracts, evidence-based acceptance, reusable packaging — those are properties of systems, and they'll outlast any particular API. Staying useful is less about chasing the newest model and more about always evolving the practice around it.
That's what I mean by AI-native: not building with AI as a novelty, but building systems where a powerful, unreliable component does the generation and disciplined engineering makes the whole thing trustworthy. The model writes the draft. You build the machine that makes the draft correct, every time.
If you want to go deeper on any thread, the links above are the map. Or get in touch — I like talking about this stuff.