Technical deep-dives, AI strategy, and engineering perspectives from the team building autonomous systems.
Supabase Auth and Firebase Auth both solve the same core problem, but the decision between them cascades into database choice, vendor lock-in posture, and how much of your user data you actually control. The right pick depends on where you plan to be in three years, not just what ships fastest today.
Typesense and Meilisearch both promise fast, typo tolerant search you can self host without an Elasticsearch cluster. The decision comes down to how much your product leans on vector search, how you plan to scale, and which failure modes you can live with. Here is how to choose without regret.
Most coding leaderboards have a quiet contamination problem: the benchmark problems, or ones nearly identical to them, sit somewhere in the training data, so a high score partly measures recall rather than reasoning. LiveCodeBench was built to remove that confound by tagging every problem with its publication date and scoring models only on problems that appeared after their training cutoff. That single design choice changes what the number means. A model that looks dominant on a static benchmark can lose its edge on the fresh window, because the fresh window is the closest thing we have to problems the model has genuinely never seen. We ran Gemini 3.5 Pro and Grok 4.5 across the LiveCodeBench problem set, filtered to the post-cutoff window for each model so neither gets credit for memorization, and separated pass rate from the harder question of whether the passing solutions were efficient enough to clear the time limits. The two models are close on the raw self-report and comparison-style leaderboards. On the contamination-controlled window the picture sharpens: one holds its accuracy on unseen hard problems better, and the other trades some accuracy for markedly faster, cheaper solutions. Which of those you want depends entirely on whether you are shipping the code or shipping the answer.
The model produces a probability distribution over the whole vocabulary at every step, and the sampler is the piece that turns that distribution into a single token. This is the part of the local inference stack teams tune last and understand least, which is odd because it is the setting that most directly decides whether output is repetitive, whether it hallucinates under pressure, and whether a JSON response parses. The defaults matter more than people think: most runners ship a temperature and a top-p tuned for open ended chat, and those same values are actively wrong for code generation, structured extraction, or an agent loop that needs deterministic tool calls. Worse, the parameters interact. Temperature reshapes the distribution before top-p or min-p truncate it, so changing one silently changes what the others do, and a repetition penalty stacked on top can push a model off a correct but repeated token into a wrong one. On Apple Silicon this is all essentially free to change: sampling happens on a handful of logits after the expensive forward pass, so it costs no extra memory and negligible time, which means there is no throughput reason not to tune it. This post walks through what each knob does to the distribution, how they interact, and what settings hold up for the three jobs most local deployments actually run, using an M5 Max as the test bench.
A customer data platform is the least visible and most load-bearing piece of a headless commerce stack. It is the layer that captures every event from the storefront, the mobile app, and the backend, resolves those events into a single view of the customer, and fans them out to analytics, email, ads, and the warehouse. Because it sits in the middle of everything, the CDP choice quietly decides three things that are expensive to change later: whether you own your customer data or rent access to it, how much of your compliance and consent surface lives inside a vendor versus your own infrastructure, and how your bill scales as event volume grows, which in commerce it always does. Segment, RudderStack, and mParticle are the three platforms most enterprise commerce teams shortlist, and they embody genuinely different philosophies rather than being feature-for-feature clones. Segment is the managed incumbent optimized for time to value. RudderStack is the warehouse-first, self-hostable challenger built for teams that want to own the pipeline. mParticle is the mobile-heavy enterprise option with the deepest identity and audience tooling. For a headless architecture, where the storefront is decoupled and events originate from several surfaces at once, the differences in how each handles server-side collection, identity resolution, and pricing at volume are what separate a clean integration from a costly one. This post lays out those differences and the decision framework that follows from them.
SWE-bench Verified has a scoreboard problem: the top models all cluster above seventy percent, which means the benchmark can no longer tell you which one to actually deploy. SWE-bench Pro exists to fix that. It is built from long horizon tasks that can take a professional engineer hours to days, it requires patches that span multiple files rather than a single localized fix, and it was designed from the start against data contamination by including held out and commercial repositories the models could not have trained on. The result is a benchmark where the frontier scores in the low twenties rather than the low seventies, and where the spread between models is wide enough to be a real signal again. We ran Claude Opus 5 and Gemini 3.5 Pro on the public set and looked past the headline solved rate at the thing that actually predicts production behavior: how each model fails on a task that touches six files, where getting the change right in one place means getting it right in five others too. This is the benchmark that separates a model that can patch a function from a model that can carry a change across a codebase, and that distinction is exactly what agentic coding lives or dies on.
Selling internationally on a packaged storefront is mostly a settings screen: turn on the currencies, let the platform convert, and the theme shows the right number. Go headless and the convenience disappears, because now your own frontend is responsible for asking the API for a price in the customer's currency, displaying it with the correct rounding, carrying that currency all the way through the cart and into checkout, and reconciling what the customer paid against what the store settles in. Each of those steps has a way to go wrong that a themed store never exposed you to, and the most common one is subtle: the storefront requests a presentment currency and the API quietly returns the amount in the store's base currency anyway, so the customer sees a euro sign in front of a dollar number. Add duties and import taxes on a cross border order and the surface expands again, because now the total the customer sees at checkout has to include or exclude a duty depending on whether you sell delivered duty paid or delivered duty unpaid, and getting that wrong means either a surprised customer or a margin you did not plan to give away. This post is about the architecture that keeps a headless international store honest: which system owns the converted price, how presentment currency actually flows through the Storefront API, why rounding is a real rule and not a rounding error, and how duties change the checkout total.
The mental model most people bring to a vision language model is wrong in a way that costs them latency. They picture an image as a single input, roughly one unit of work, the way a text token is one unit of work. What actually happens is that the vision encoder chops the image into patches, and a high resolution photo can turn into hundreds or thousands of visual tokens that the language model must then prefill through before it generates anything at all. On a cloud endpoint you never feel this, because someone else eats the prefill and bills you a flat per image rate. Run the same model on your own M5 Max and the cost becomes visible immediately: the model loads fine, it holds in unified memory with room to spare, and then a single screenshot at native resolution takes several seconds to first token because you just asked the machine to prefill four thousand tokens it manufactured out of one picture. This post is about that gap. We look at where the memory actually goes when you load a VLM locally, why image tokens and not model weights are usually your latency problem, how the resolution setting is the one knob that moves both accuracy and speed, and when a local VLM is the right call versus a cloud vision API. The economics of local vision are real, but only if you understand that the image, not the prompt, is the expensive part.
Coding leaderboards have converged on one kind of task: fix a bug in a real software repository, usually a web application, usually in Python. That is a real skill and it is not the only one. SciCode measures a different thing entirely, whether a model can read a scientific problem from physics, chemistry, biology, or materials science and produce numerical code that actually computes the right answer, often across a chain of dependent subproblems where getting step three right requires step two to be correct first. It is a harder axis than repository bug fixing because the model has to hold a domain concept, translate it into the correct algorithm, and implement that algorithm without a test suite handing it the shape of the solution. We ran GPT-5.6 Sol against Gemini 3.5 Pro on SciCode and measured not just the headline solved rate but the collapse point, the subproblem depth at which each model starts propagating an early error through the rest of the chain. The gap that matters is not who tops the aggregate; it is which model degrades more gracefully when a multi step derivation goes wrong, because that is the failure mode you inherit when you point either one at real scientific tooling.
The naive way to serve a fine tune is to merge the adapter into the base weights and load the merged model, which is fine until you have twenty fine tunes and a machine that can only hold two merged copies of a 70B model in memory at once. LoRA exists precisely so you do not have to do that. The adapter is a few hundred megabytes of low rank matrices that sit on top of a frozen base, which means one resident base model can back many adapters if your serving layer knows how to keep the base loaded and swap or batch the adapters around it. The gap between knowing that and running it in production is where most teams stall, because the obvious implementation reloads the whole base every time a request wants a different adapter, and that throws away the entire advantage. This post is about serving many LoRA fine tunes from a single M5 Max: how much memory each resident adapter actually costs, how fast you can bring a cold adapter in from disk, why merged serving falls over at scale, and the batched adapter pattern that lets requests for different fine tunes share the same forward pass. The economics only work if the base stays put and the adapters move cheaply, so the whole design is about protecting that invariant.
The decision to leave Salesforce Commerce Cloud is usually made on cost and velocity, and by the time it reaches engineering it has hardened into a deadline. That is where replatforming projects go wrong, because moving from SFCC to a headless Shopify Plus stack is not a migration in the copy the data and flip the switch sense; it is a rebuild of the parts of your commerce logic that lived inside SFCC cartridges and pipelines, wrapped around a data migration that is the easy part by comparison. SFCC gave you a monolith where the storefront, the business logic, and the platform were fused, and headless Shopify Plus deliberately unfuses them: Shopify becomes the commerce engine behind an API, and the storefront becomes your own application. Everything that made SFCC feel complete, the cartridge ecosystem, the pipeline customizations, the server side rendering baked in, becomes something you now own explicitly. This playbook walks the migration in the order that actually de-risks it: what maps cleanly from the SFCC data model to Shopify, what has to be rebuilt rather than ported, how to protect the SEO equity that a careless cutover destroys, and the sequencing that lets you move without a big bang launch. The projects that fail treat this as a data problem. The ones that succeed treat it as a rebuild with a data migration attached.
Almost every agentic coding benchmark you have seen a model quote is Python, because SWE-bench is Python and it became the number everyone optimizes. That leaves a blind spot the size of most production code, because the repository your agent actually has to fix is as likely to be Java, Go, Rust, or TypeScript as it is Python, and a model that tops the Python leaderboard can quietly fall apart in a language it saw less of in training. Multi-SWE-bench exists to measure exactly that: it takes the same real bug, real repository, real test suite format that made SWE-bench credible and spreads it across seven languages, so the score reflects whether a model can resolve an issue in a codebase that is not written in the language it is best at. We ran Claude Sonnet 5, a mid tier frontier model, against GPT-5.6 Sol on the multilingual splits and measured not just the headline resolved rate but where each model drops off by language, because the gap between a model's Python score and its Rust score is the number that predicts how your agent behaves on the repo you actually have rather than the one the benchmark authors happened to pick.