AI Principles That Won't Expire

Six months ago, you were told to chunk your documents and manage your context window carefully. That advice might be hurting you now. A new model drops, the old recommendations stop working, and you're recalibrating again. Maybe you've been through several rounds of this already — switching tools, rewriting workflows, reading every new guide that crosses your feed, only to find that the productivity tool is making you feel behind. Or maybe you're earlier in the arc. You watched a colleague ship a feature in half the time and you want those gains, but the sheer volume of conflicting advice makes it hard to know where to start. Either way, you're heading toward the same place if you begin by chasing the latest recommendation.

Most AI advice has an expiration date. It references a specific model, a specific capability, a specific limitation. When those change — and they will — the advice breaks. What if instead of chasing the latest best practice, you anchored to what doesn't change?

# Why AI Advice Has a Shelf Life

When early language models shipped with small context windows, entire frameworks were built around that constraint — chunking strategies, summarization pipelines, careful message management. Then context windows grew by orders of magnitude, and Google's own documentation acknowledged that "much of the conventional wisdom about using large language models assumes this inherent limitation on the model, which as of 2024, is no longer the case." The workarounds became unnecessary almost overnight.

The same thing happened with Retrieval-Augmented Generation. RAG was the default architecture for any application working with custom data. Then long context windows made it optional for many use cases. Databricks' research showed you could skip retrieval entirely for smaller datasets and feed everything directly to the model. RAG still has its place — but it went from "always do this" to "do this when you need it."

Chain-of-thought prompting followed the same arc. "Think step by step" was one of the most important prompt engineering techniques — until researchers found it didn't reliably help across models, and then newer models baked the reasoning directly in, making the manual technique unnecessary.

The pattern is the same every time: reasonable, well-sourced advice becomes obsolete within a year or two because the underlying capability changed. If a recommendation references a specific tool, model, or capability threshold, it has an expiration date. That doesn't mean tactical advice is useless — it means you should hold it loosely and invest your real energy in what survives the churn.

# What Actually Holds Up

Some practices work regardless of which model or tool you're using. They worked with early models, they work with whatever shipped last week, and they'll work with whatever ships next. They share a common trait: none of them are about AI specifically. They're about being a disciplined engineer. There's a natural arc to how they show up in your workflow — from before you touch the tool, through using it, to how you operate across tools over time.

Planning comes first because it happens before you open the tool. AI makes it dangerously easy to skip thinking and jump straight to code. The cost of producing code has dropped so far that the temptation is to just generate something and see if it works. But the cheaper code is to produce, the more important it is to ask whether you should produce it at all. Planning is the one thing that doesn't get faster with AI — and that's the point. The value is in the thinking itself: clarifying requirements, identifying edge cases, understanding the problem before you commit to a solution.

Some current tools embody this well. OpenCode ships with distinct "Plan" and "Build" modes — forcing a deliberate shift from thinking to execution. Kiro takes it further with spec-driven development, where you define requirements and design before the AI writes a line of code. The specific tools will evolve, but the discipline they encode — think first, build second — won't.

Context is what you bring when you engage the tool. The quality of AI output is directly proportional to the context you provide. This was true with search engines, it's true with prompts, and it'll be true with whatever comes next. Learning to give good context — understanding what the model needs to know, what assumptions you're making, what constraints matter — is a transferable skill. A developer who's good at providing context to an AI assistant is also good at writing clear tickets, useful documentation, and precise bug reports. The skill compounds across everything you do.

Verification is what you do after you get output. AI acts on your behalf — it has your credentials but not your judgment. You know not to run destructive queries against production. The AI doesn't. Treat it like a new team member who has full access and no institutional knowledge, because that's functionally what it is. The principle of least privilege is as old as computing itself; AI just makes it urgent again. And once the output exists, you need to know whether it's correct. Tests, sandboxed execution, code review, checking sources — these aren't new practices. What's new is that they've shifted from "good hygiene" to "the only thing standing between you and shipping a hallucination."

Portability is the discipline that protects you across tools over time. It's tempting to build your entire workflow around whatever tool you're using right now — its proprietary context format, its specific API, its way of organizing projects. But if your process only works inside one tool, you'll rebuild from scratch when you switch. And you will switch. Choose formats and processes that survive the transition. Markdown, plain text files, version-controlled configuration — these aren't exciting, but they're durable. The same applies to how you structure context for AI: if your carefully curated prompts and system instructions are locked inside one vendor's platform, they're not yours. They're the vendor's.

Intentionality governs all of it. AI usage escalates in ways that aren't always obvious. A debugging session that starts as "help me understand this error" turns into a long back-and-forth, each message carrying the full conversation context, and suddenly you've spent an hour on a problem you could have reframed in five minutes. The specific economics will change — pricing models, rate limits, what's free and what isn't — but the discipline of knowing what you want from a session before you start one won't. Unfocused usage wastes more than money. It wastes your attention, produces lower-quality output, and trains bad habits. Before you engage the tool, know what you're trying to get out of it. That forcing function keeps you asking the right questions regardless of what the tool costs.

None of this is revolutionary. That's the point. The practices that hold up aren't clever tricks — they're engineering fundamentals applied to a new kind of tool.

# Where You Lead

Those fundamentals keep you effective with any tool. But the real leverage — the thing that separates engineers who use AI well from engineers who just use AI — is intentionality about where you stay in the loop. That's where you lead. The tools will keep getting more capable. Your job is to know where your judgment is the thing that matters.

Every time a tool dramatically lowers the cost of producing something, the bottleneck shifts to evaluation. The printing press made it trivial to produce books — and created the need for editorial judgment. IDEs, open-source libraries, and Stack Overflow made it faster to write code — and shifted the bottleneck to design and code review. This pattern is older than software engineering itself. AI is the latest and most dramatic instance of it, but the underlying dynamic is the same: when production gets cheap, evaluation becomes the work.

That's the core thesis: AI shifts the bottleneck from production to evaluation. It has never been easier to produce code, content, or analysis. The hard part is no longer generating output — it's knowing whether the output is correct, safe, and appropriate. And that responsibility doesn't transfer to the tool.

The evidence here is sobering. A Stanford study found that developers using AI assistants produced more security vulnerabilities in their code — and were simultaneously more confident that their code was secure. Pearce et al. found that GitHub Copilot produced vulnerable code in approximately 40% of security-relevant scenarios. An Uplevel study of 800 developers found no significant improvement in throughput but a 41% increase in bugs. The pattern across these studies is consistent: AI makes you faster at producing output and more confident in that output, while the output itself may be less reliable than what you'd have written without assistance.

Addy Osmani calls this "trust debt": "Every time you trust AI output without verification, you incur a debt that must be paid by someone combing through that code later to actually understand and fix it." One CTO in his survey described an AI-generated database query that "worked perfectly in testing" but brought the system to its knees in production — syntactically correct, architecturally disastrous. Paul told the Thessalonians to test what they heard — even from prophets — and hold fast to what was good (1 Thess. 5:21). The same discipline applies here. Your name is on the commit, and the line isn't "don't use AI" — it's if you can't evaluate it, don't ship it.

A colleague, CJ Taylor, put this simply: the safe zone is the overlap between what AI says and what you can verify. Everything outside that intersection is where trust debt accumulates.

So what does this look like in practice? It helps to think about where AI delegation works and where it breaks down.

Will Larson, in Staff Engineer, describes a concept he credits to Hunter Walk called "snacking" — low-effort, low-impact work that feels productive but isn't. "When you're busy," Larson writes, "these snacks give a sense of accomplishment that makes them psychologically rewarding, but you're unlikely to learn much from doing them." His framework maps work across two axes — effort and impact — and the insight is that senior engineers drift toward easy, low-impact work when they don't have a clear plan. As Des Traynor at Intercom put it: "When you continually pick the low-hanging fruit, the branches will stop growing."

AI changes this calculus in an interesting way. It compresses the effort axis. Tasks that used to be high-effort become low-effort — boilerplate code, test scaffolding, documentation drafts, routine refactors. You can hand off the snacks. AI picks the low-hanging fruit faster than you ever could.

But here's what doesn't compress: complexity.

A task can be low-effort to produce and still high-complexity to evaluate. AI can generate a feature flag implementation in seconds — but understanding whether the logic correctly handles your billing rules requires knowing the business. AI can scaffold a distributed system change in minutes — but evaluating whether it'll behave correctly under load requires architectural judgment. The effort dropped. The complexity didn't.

This is where I find it helpful to think about delegation across a different pair of axes: complexity and how much you hand to AI. At one end, you have low-complexity tasks you delegate freely — boilerplate, formatting, simple test scaffolding. AI shines here, and a quick verification pass is all you need. At the other end, you have high-complexity work where AI assists but you lead — architecture decisions, business logic, system design. The dangerous quadrant is in between: high-complexity tasks that AI made feel like snacks because the effort to produce them dropped. AI can produce output here. It'll look plausible. But if you don't have the expertise to evaluate it deeply, you're shipping trust debt.

This principle extends beyond code. Whether you're writing a sermon, designing curriculum, or drafting a strategy document, the question is the same. SIL Global uses AI in over 400 Bible translation projects, and their developers put it clearly: "The core of Bible translation is still human. The people are the heart of the project. AI is here to assist, not replace." Their AI produces first drafts — never finished translations. The tool accelerates the work; the humans evaluate it. That's the model, whether you're translating Scripture or shipping software.

Which brings us to the last piece: you still need to be effective without AI. If the tool goes down, if the API changes, if the model degrades on your use case — you need to be able to do the work. More importantly, AI should augment what makes you good, not replace it. If you're using AI to avoid learning, you're borrowing against your future competence. The developers who will thrive with AI are the ones who could thrive without it — and choose to use AI to go further, not to avoid going deep.

# Where to Start

The tools will change — they already have, multiple times, since you started reading AI advice. Your responsibility to understand what you build won't. Whether you've been through several rounds of this and need permission to stop chasing, or you're earlier in the arc and want to know where to begin, the answer is the same: anchor to the principles. Plan before you build. Provide good context. Sandbox your environments. Verify your output. Own what you ship. The tactical advice will come and go. The question was never which AI tool to use — it was always what kind of engineer you want to be when you use one.