We (Tech) spent the last three years obsessing over how we interact with language models - chatbots, agents, AI-powered workflows. Meanwhile, a more fundamental shift has taken place: prompting is giving way to context engineering and how you interface matters very little. When you need a problem solved with AI, asking a chatbot out-of-the-blue might give you the occasional good result. But for exceptional results, models need information about you, your problem space, and your expectations. Do it well and every thread feels like chatting with a partner that’s just as deep-in-the-weeds as you are.
Evolution Below the Surface
It's ironic how we obsessed over the interface while the real breakthrough was happening in the background. It wasn't about how we talk to AI. It was about what the AI knows before we even start talking.
Since ChatGPT's breakout in 2021, the scope of context we can engineer into these systems has expanded in three distinct stages:
Stage 1: Prompt-only context. "Hey, create this file for me based on some examples. Here's good, what's bad." The AI only knows what you tell it in that moment. Success meant obsessing over every word in your prompt.
Stage 2: Document-level context. Suddenly you could infuse entire files - product requirements, tech specs, data schemas, research insights, and even designs - into the working environment. The prompt started to matter less because AI already understood your domain.
Stage 3: System-level context with deterministic triggers. Where we are today. You engineer systems that retrieve context only when it's relevant - pulling business-specific data for product decisions, industry-agnostic knowledge for technical problems. You’re not just throwing everything at the model and hoping for the best. You build guardrails, triggers, and deterministic workflows so the model can operate within the constraints you engineered. The system knows exactly when to think freely and when to follow strict rules. From commands to autonomous loops. From 'build this' to 'keep building better.’
That's the real story. The interface discussion is a distraction. Context engineering is what unlocked AI’s real utility.
Context Is King
Context engineering is the practice of designing the environment in which AI operates - the documents, code snippets, file trees, configuration details, and tool access - then taking a step back to let the model decide how to use it all.
The world's written knowledge, as it turns out, is pretty distracting for models to think about with every answer to a question. Context engineering is effective because of how it keeps AI focused and reliable using a technique called RAG (Retrieval-Augmented Generation). It's your way of saying "Among everything ever created, this bit of information is the most relevant to how we solve problems." Even a single, well-written document can fine-tune a model to think, brainstorm, evaluate outcomes, and prototype like an expert. You create the context within which AI can be successful, and wow does it shine.
"Simple example of the difference a little context makes."
Comparing the responses of a model operating within a well-engineered system versus not is night and day. The difference is genuinely impressive.
But here’s where it breaks down: even models operating within the best engineered context fail to give accurate answers every time. Language models are inconsistent (non-deterministic). They like to hallucinate facts. Model makers push updates at an insane rate. A question answered one way on Monday gets answered completely differently on Friday with the same inputs.
It’s Hard to Deploy AI at Scale
This isn't a minor annoyance. It kills the tool for boring, repetitive work that actually fills your day. That "summarize this customer call and update our CRM" task needs to work identically 40 times a week. If call #17 randomly formats data differently, or misses a critical field, or invents a priority level, your automation is worthless. You're back to manual review.
Workplace AI demos look incredible. The day-to-day reliability isn't there yet. You can’t delegate work that’s only going to be done right some of the time.
And this isn’t an isolated problem. A McKinsey study found that nearly half of all had businesses have already had negative, unreliable consequences of their AI use.
The disconnect between AI’s technical capabilities and its practical reliability can hit hard. Poorly managed expectations and misapplied tooling means broken optimism and future plans already being cancelled. But this is a problem even with the most cutting edge systems - decisions still require human oversight 71% of the time.
So where is the path to reliable AI? It starts small. Solve problems where you control the most context - deeply personal systems designed to specifically work with your domain, your data, and your workflows. Build what works for you, then scale from there. Resist the urge to throw universal solutions at your team hoping they’ll land.
Make It Personal
Creating your own system from scratch is beautifully simple with AI. Fire up a conversation with your chatbot, IDE, or terminal of choice. Then frame the problem:
I want to create a system for me to [do my job, take some action, run my business].
Add some version of this to make the conversation open-ended:
Interview me Q&A style until you have enough information to create the documents and instructions needed.
Hit enter and voila - you’re on your way to engineering a system that works for you. The result of that conversation can be used in a ChatGPT project, at the root of your Claude Code folder, or anywhere you want AI to have that context.
What I appreciate most about this method to context engineering is in it’s simplicity: it is hard to overthink it. The models work with you to pull information out. And if you’re unsure what to do with the output, just ask in that very same thread.
Once you have a setup working, the feedback loop is nearly instant - you’ll know if an output looks off or the model is trying to solve things incorrectly because this is your domain, your expertise. Every misstep or poorly-executed workflow is an opportunity to iterate the system and update the context.
Tools You Can Trust
"It's a stochastic thing, it's a non-deterministic thing, but with scaffolding you can get these deterministic outcomes." - Boris, founding engineer of Claude Code
The reason I’m writing this today is because I can finally see how we get from impressive demos to reliable systems. It’s not about better models or perfect prompts. It’s about scaffolding.
Scaffolding is the infrastructure that wraps around non-deterministic AI to create predictable, trustworthy outcomes. It's built from four complementary components:
RAG (Retrieval Augmented Generation): You've already seen this technique in action. Focused knowledge retrieval that tells the model what’s important, right now. It's the foundation of context engineering.
Tools: The capability layer. Things like bash, git, and MCP (Model Context Protocol) that let AI actually do things instead of just suggesting them. Write code, commit changes, query databases, integrate with your existing systems. Tools turn conversation into action.
Hooks: Guardrails and steering mechanisms. These are your deterministic triggers - the "when X happens, always do Y" rules that ensure critical workflows never deviate. Hooks let you specify exactly when the model should think freely versus when it must follow strict procedures.
Skills: Prepackaged expertise. These are simple folders that bundle context, tools, and instructions into reusable, shareable modules. A skill might contain your brand guidelines, data schema, common workflows, and the specific tools needed to execute them. Skills ensure the model does the boring, repetitive work you want done, how you want it, every time.
RAG tells the system what to know, tools give it what to do, hooks control when to do it, and skills enforce it how it’s done.
Skills have given me a glimpse of what the future of working with AI can look like. Systems that are perfectly customized to you, with the right context, triggers, and tools to be reliable or non-deterministic when you need it. Skills were the deterministic ingredient I needed not only to improve my own workflows but to empower my team. They are modular, transferrable, and context efficient, which means they can be used by your team out-of-the-box, no additional context engineering required. This is where you can start to see the leverage in building a personal system first - time invested to make something work exceptionally for you is now easy to package and share with the next person.
From Tool to Personal Operating System
The reason to start personal isn't because it's easier - it's because context engineering requires constant iteration to work. You need tight feedback loops to know what's wrong, what's missing, what to trust. That's why I'm building my own system around these principles of personal engineering. An operating environment that helps me do anything I can do on a computer, with AI. It's early, messy, and constantly evolving. Every session spent working within the system improves it, and gives me confidence to loosen the leash and let the models operate with more autonomy. Coming up with entire plans - from design through prototype to execution - and running them without waiting for my approval at each step.
That's where this is all heading. Not autonomous agents replacing us, but engineered systems that make us exponentially more capable.