Archive
1290 posts · Page 6 of 108. ← Blog
The single constraint that shapes every aspect of agent skill design is the context window — the finite amount of information an agent can hold and attend to at once. A skill that ignores this constraint bloats the agent's context, degrades its focus, and defeats its own purpose. Designing for the context window — loading only what is relevant, only when relevant, as compactly as possible — is the craft at the heart of good skills. This post is about that constraint and how it drives skill design.
The context window is the constraint that shapes every aspect of skill design. Why context is finite AND precious (more context degrades focus), the master principle — load only what's relevant, only when relevant, as compactly as possible — and why this makes skills beat big prompts.
An AI demo is the easiest impressive thing to build and the most misleading. It runs on hand-picked inputs, in a clean environment, with the failures edited out — and it convinces everyone the problem is nearly solved when the real work has barely begun. The AI forward deployed engineer's job in this phase is to use the demo to win belief, then walk the customer honestly across the chasm to a pilot that survives real data.
An AI demo is the easiest impressive thing to build and the most misleading: it runs on cherry-picked inputs, in a clean environment, with the failures edited out — and convinces everyone the problem is nearly solved when the real work has barely begun. Use the demo to win belief, then walk the customer honestly across the chasm to a pilot that survives real data.
You cannot run your best, most expensive model on millions of items for every request — the latency and cost are impossible. The elegant, near-universal answer is to split recommendation into two stages: a cheap, fast net that narrows millions of items to a few hundred, followed by a precise, heavier model that ranks those few. This retrieve-then-rank structure is the single most important architectural pattern in production recommenders.
You can't run your best, most expensive model on millions of items per request. The near-universal answer is to split recommendation into two stages: a cheap, fast net that narrows millions to a few hundred, then a precise, heavier model that ranks those few. This retrieve-then-rank structure is the single most important architectural pattern in production recommenders — with an interactive pipeline diagram.
This is the post the whole series was building toward. Retrieval-augmented generation gives an LLM relevant text to ground its answers, but plain RAG retrieves disconnected chunks and misses the relationships between facts. GraphRAG grounds the model in a knowledge graph instead — so it can follow relationships, reason across multiple hops, and answer questions that no single chunk contains. It's where ontologies stop being theory and become the thing that makes an AI system trustworthy on your domain.
The post the series built toward. Plain vector RAG retrieves disconnected chunks and misses relationships; GraphRAG retrieves a subgraph by traversing the knowledge graph, so multi-hop answers come from walked edges, not guessed connections — typed, verifiable, citable. When to use it, and why hybrid often wins.
A capable AI agent with no way to carry expertise between tasks relearns everything every time. Agent skills close that gap: reusable, self-contained packages of instructions, knowledge, and procedure that an agent loads when relevant, turning a general model into one that reliably does your specific work your specific way. This series is about designing, building, and deploying agent skills — and it starts with the gap they close and why it matters.
A capable agent with no way to carry expertise between tasks relearns everything every time. Agent skills close that gap — reusable, self-contained packages of instructions, knowledge, and procedure loaded on demand — turning a general model into a reliable specialist at your specific work.
The most important decision an AI forward deployed engineer makes happens before any code: which problem to point the model at. Choose a problem AI is genuinely suited for, with real value and a clear way to measure it, and the engagement can succeed. Choose AI theater — impressive-sounding but ill-fit — and no amount of engineering saves it. Scoping is where AI deployments are won or lost.
The most important decision an AI FDE makes happens before any code: which problem to point the model at. Choose a problem AI is genuinely suited for, with real value and a clear way to measure it, and the engagement can succeed. Choose AI theater — impressive-sounding but ill-fit — and no engineering saves it. Fit vs value, resisting AI theater, augmentation over automation, and picking the wedge.
The technique that defined the modern era of recommendation is deceptively simple: represent every user and every item as a short list of numbers — a vector of latent factors — such that a user's affinity for an item is just the dot product of their vectors. Matrix factorization turned recommendation into learning good embeddings, and it's the conceptual bridge from classical collaborative filtering to today's deep-learning systems.
Represent every user and item as a short vector of latent factors, and a user's affinity for an item becomes just the dot product of their vectors. Matrix factorization turned recommendation into learning good embeddings — the technique that won the Netflix Prize and the conceptual bridge from classical collaborative filtering to today's deep-learning systems and vector search.
You rarely write raw eBPF bytecode by hand — a rich ecosystem of libraries, languages, and platforms sits on top, and one breakthrough (CO-RE) solved the portability problem that once made eBPF programs fragile across kernel versions. This closing post surveys how you actually build with eBPF, and where the technology is heading.
You rarely write raw eBPF bytecode by hand — a rich ecosystem of libraries, languages, and platforms sits on top, and one breakthrough (CO-RE, Compile Once Run Everywhere) solved the portability problem that once made eBPF programs fragile across kernel versions. This closing post surveys how you actually build with eBPF, and where it's heading.
The hardest part of a knowledge graph isn't querying it or designing the ontology — it's building it from messy, real-world data. Most of your knowledge lives in databases that don't connect, documents that don't parse, and records that refer to the same thing by different names. Construction is the engineering of turning that mess into a clean, connected graph, and its central, unglamorous challenge is entity resolution: deciding when two records are actually the same thing. This post is about the work that makes or breaks a knowledge graph.
The hard part isn't the ontology or the queries — it's construction. The pipeline from heterogeneous sources, and its make-or-break challenge: entity resolution (deciding when two records are the same thing). Under-merging fragments; over-merging asserts false connections; connectivity amplifies every error.
Coding agents are genuinely transformative on the right tasks and frustrating on the wrong ones, and knowing the difference is the practical skill that separates productive use from disappointment. This closing post is the honest field guide: where coding agents excel, where they struggle, how to work with them well, and where software engineering is heading. It turns the series into judgment you can apply today.
Coding agents are transformative on the right tasks and frustrating on the wrong ones. Where they shine (well-scoped, verifiable, groundable, reviewable work), where they struggle (ambiguous, weakly-verified, large/architectural), how to work with them well (scope, verify, ground, review, delegate the mechanical), and where software engineering is heading.
The forward deployed engineer was born at Palantir to bridge powerful software and messy customer reality. In the AI era the role has exploded, because frontier models have made that gap wider than ever: a model that dazzles in a demo is a long way from a system that works inside one company's data, workflows, and trust constraints. This series is the technical playbook for the engineer who closes that gap.
The forward deployed engineer was born at Palantir to bridge powerful software and messy customer reality. In the AI era the role exploded, because frontier models widened that gap: a model that dazzles in a demo is a long way from a system that works inside one company's data, workflows, and trust constraints. This series is the technical playbook for the engineer who closes that gap.
Collaborative filtering has one crippling blind spot: it knows nothing about brand-new users or items, because they have no interactions to learn from. Content-based filtering fills that gap by recommending based on what items are rather than who interacted with them — and understanding the cold-start problem, and how each approach handles it, is key to building a recommender that works from day one.
Collaborative filtering has one crippling blind spot: it knows nothing about brand-new users or items. Content-based filtering fills that gap by recommending based on what items are rather than who interacted with them. Understanding the cold-start problem — and how each approach handles it — is key to building a recommender that works from day one, which is why most real systems are hybrids.