I used to spend most of my time writing code. Now I spend most of it deciding what the model should know before it writes a single line. The shift happened gradually and then all at once — one day I realized the thing I was actually getting good at wasn't TypeScript or Python, it was assembling the right information at the right time for a model to do its job.

I've been calling this context engineering, and I think it's genuinely a new skill. Not prompt engineering — that's writing a clever sentence. This is more like building the information architecture around every model call. Which files go in the context? What documentation matters right now? How do you structure the system prompt so the model has the right mental model of your codebase? What tools does it need access to, and what memory should it surface from past sessions?

At MAIA this is everything. Our natural-language-to-map pipeline lives or dies by the context we assemble before the model even starts reasoning. The model doesn't need to know everything about geospatial analysis. It needs to know exactly the right things for this specific query. A well-scoped context turns a mediocre prompt into a perfect map. A sloppy one produces garbage regardless of how smart the model is.

Claude Code is where this really clicked for me. The CLAUDE.md file, hooks, MCP servers — it's all context engineering. You're not configuring a text editor. You're building a workspace that shapes how an intelligence interacts with your code. And the compounding effect is real. Better context produces better output, which teaches you what context matters, which produces even better output next time. The feedback loop is tighter than anything I've experienced in traditional programming.

I think in a few years we'll look back and realize the people who got really good at this early had a massive advantage. Not because they were better programmers, but because they understood that the new bottleneck isn't writing code — it's shaping what the model knows.

Everything I run sits on a Dell OptiPlex micro in my apartment in the Outer Sunset. Ubuntu, 32 gigs of RAM, a 1TB NVMe. It draws maybe 15 watts at idle. My cloud bill is zero.

I know the obvious question is why not just use Vercel or Railway or whatever. And the honest answer is that I want to understand every layer. When something breaks I want to know exactly where to look. Not in some abstract "it's good to understand things" way — I mean I've been burned enough times by managed services hiding complexity that I'd rather just own it. Running your own infrastructure teaches you things that platforms deliberately abstract away, and those things matter when you're debugging at 2am.

The stack is simple. Cloudflare Tunnel exposes public stuff — this site, MAIA staging. Tailscale handles everything private — dashboards, dev tools, SSH from my phone. systemd manages all the services. No Docker, no Kubernetes, no orchestration layer pretending to be simple. Just unit files and timers.

The real unlock was Tailscale and Cloudflare Tunnel together. Tailscale gives me a private mesh network across every device I own. Cloudflare Tunnel gives me public ingress without opening a single port. Between the two I have zero exposed ports on the machine but can reach anything from anywhere. My morning news digest, tech release monitor, concert ticket scraper, this website — all running on the same box, all accessible exactly where they need to be and nowhere else.

There's a specific feeling I'm chasing here. Typing a URL and knowing exactly which process on which machine on which port will handle that request, because I set all of it up myself. That's the feeling.

I type on a Corne. 42 keys, split in half, no number row. When people see it they usually ask if it's a joke. It's not a joke but I understand the reaction.

It took three weeks of genuine suffering to learn. My typing speed dropped from around 100 WPM to maybe 30. I couldn't type a URL without stopping to think about where the colon was. Every missing key lives on a layer — you hold a thumb key and the whole board transforms. Numbers on one layer, symbols on another, navigation on a third. It sounds insane and it felt insane for those first three weeks.

But by week four something clicked. The split layout means my shoulders stay open instead of hunching inward. The columnar stagger means my fingers move straight up and down, not diagonally like on a normal staggered board. And the thumb clusters — I use my thumbs for space, enter, backspace, and layer switches now, instead of destroying my pinkies on modifiers. After a month I tried going back to a regular keyboard and my wrists immediately started hurting. That was the end of that debate.

The real revelation was the layers though. On a normal keyboard your hands are constantly leaving home row — reaching for backspace, stretching for brackets, moving to arrow keys. On the Corne everything is within one key of where your fingers already are. I have numbers, symbols, navigation, media controls, all accessible without moving my hands. The firmware is QMK and I've iterated on the layout for months. Every key does exactly what I want because I defined every single mapping.

I soldered this one myself. Mill-Max hot-swap sockets, Gateron silent switches, custom caps. I solder things that don't need to exist — LED gauntlets, lightning clouds, keyboards. 42 keys sounds like a constraint. It's actually a design principle: every key should earn its place.

We're past the point of needing to directly watch a single thread of LLM work. That level of babysitting isn't necessary anymore. But I've been noticing something about where we've landed instead.

Right now I'm comfortable letting a model run for about ten minutes — that's roughly the amount of work I can review thoroughly and catch mistakes in. To stay efficient I'll have three to five active sessions going, plus another five to ten waiting for responses or in various stages of progress. Which means I'm context-switching every one to three minutes.

The thing is, human brains don't really multitask. We just context-switch and process things incrementally. And when the time between switches is this short, the overhead of loading working memory for each task starts to feel significant relative to the actual focused work being done. It's this weird middle state of feeling inefficient even though things are technically getting done.

I've noticed it bleeding into other parts of my life too — personal tasks get interleaved with agent work, things partially complete before something else needs attention. The first-person experience is honestly a bit dissociative. Scattered. Lack of continuity. Multiple workstreams are moving forward but the felt sense is fragmented.

I think this gets better over time. As models can do more work per stretch, the context-switching frequency goes down, and the ratio of overhead to actual work improves. But right now we're in the awkward middle. One thing that helps: keeping each piece of review atomic — treating it as a complete unit rather than something I'll come back to.

The pitch for MAIA is simple: ask a question, get a map. "Show me all parcels in downtown SF that sold for over 2M in the last year and are zoned for mixed-use development." You type that in natural language, and MAIA produces a map with the parcels highlighted, the data attached, ready to explore. No GIS expertise, no SQL, no manual layer stacking.

That's the pitch. The reality of building it is a different story. The hard part is not the AI — the LLM orchestration and the agentic pipeline, while nontrivial, are at least tractable engineering problems. The hard part is the data underneath. Geospatial data is messy and inconsistent and siloed across dozens of county, state, and federal databases. Parcel boundaries don't match across jurisdictions. Zoning codes mean different things in different cities. Property records use different schemas everywhere. It's a nightmare.

Our actual job most days is normalizing all of that into a unified layer that the AI can query intelligently. The LLM is the interface. The data pipeline is the product. And every new city we add is its own special flavor of data chaos that has to be wrangled into the same schema as everything else.

I love this kind of problem though. One of the things that drew me to startups is you get to do a little of everything — I'm doing LLM orchestration and database optimization and infrastructure and product thinking all in the same week. You have to move fast and resist the urge to optimize. The discipline is always asking: is this moving the business forward? Not is this the most elegant solution, not is this the most interesting technical problem, but is this the thing a customer needs right now.

We're building for analysts who know what questions to ask but don't want to learn PostGIS. The bet is that natural language is a better interface for geospatial analysis than any tool that exists today. I think we're right.

There are always a bunch of good-sounding ideas. The hard part is killing them. I learned this at MAIA and it took a while — the urge to build something elegant instead of something useful is strong, especially when you're technical enough to see all the possibilities.

The rule I keep coming back to: don't build before you need it. Don't add a cache until you've measured latency. Don't add a message queue until you actually need async processing. Don't add a service layer until the monolith is genuinely struggling. Every abstraction is a bet that the pattern will repeat, and most of those bets lose.

This is hard because building things feels like progress. Refactoring feels productive. Setting up elaborate infrastructure for a feature that doesn't exist yet feels responsible. But it's not — it's avoidance. The actual work is figuring out what the customer needs and pushing that through, ugly or not. A lot of resisting the urge to optimize. You have to move quickly and leave things ugly sometimes, and that's genuinely uncomfortable.

You gotta beat the shit out of your ideas. The ones that survive are worth building. The rest were just interesting — and interesting is not the same as valuable. Constantly prioritizing is the hard part. Not the coding, not the architecture, not the tooling. The prioritizing.

Write the obvious thing. Ship it. If it needs to change, change it then. The codebase that's easy to change beats the codebase that anticipated every change but is impossible to understand.