DEV Community: Paul Crinigan

How Particle Physics Turns Trillions Of Collisions Into One Result

Paul Crinigan — Sat, 05 Sep 2026 14:57:48 +0000

A modern particle detector sees collisions at a rate no storage system on earth could hold. The physics everyone talks about, the Higgs, the search for whatever sits beyond the Standard Model, is downstream of an engineering problem: deciding in microseconds which events are worth keeping and throwing the rest away forever.

Seventeen Particles And Four Forces

The Standard Model is a short list. Twelve matter particles, six quarks and six leptons. Four force carriers, the photon, the gluon, and the W and Z bosons. One Higgs boson, which gives the others their mass. Everything you have ever touched is built from a handful of these.

It is also the most precisely tested theory in science. Some of its predictions match measurement to eleven decimal places, roughly the accuracy of measuring the distance from New York to Los Angeles to within the width of a human hair.

The Data Problem Behind Every Discovery

Accelerators push protons to nearly light speed and collide them, and the collision energy converts into particles that do not exist in ordinary matter. Those particles decay almost immediately, so nobody observes them directly. What exists is debris, and a discovery is a statistical excess in that debris that survives every attempt to explain it as noise.

That is why the bar for a claim is five sigma, about a one in 3.5 million chance the bump came from fluctuation alone. Anyone who has argued about whether a metric moved or just wobbled is working the same problem with smaller numbers and lower stakes.

The trigger system is the part that should interest anyone who builds pipelines. It is a hardware and software filter that decides, in microseconds and without a second pass, which collisions get written to disk. Everything it drops is gone. The physics you can do later is bounded by choices that were made before the data existed.

What The Model Still Cannot Explain

Gravity is not in it. Dark matter is not in it. It does not explain why the universe ended up made of matter rather than annihilating into nothing. Those gaps are the map for the next generation of experiments, and they are laid out with the rest of the picture in this guide to particle physics: https://www.learnhowtoscience.com/particle-physics-explained/

Why This Is Worth A Developer's Attention

The interesting part for anyone who builds systems is that the physics and the pipeline are inseparable. Trigger logic, distributed reconstruction, and a worldwide grid built to move petabytes are as much a part of finding the Higgs as the theory was. It is one of the few fields where the data engineering is the instrument.

Why Web Games Break In Ways Native Games Never Do

Paul Crinigan — Sat, 05 Sep 2026 00:29:24 +0000

A native game that crashes on launch gets a refund request. A web game that crashes on load gets a closed tab, and the player never comes back to tell you why. That difference is why testing a browser game is a separate discipline from testing a native one, not a lighter version of it.

The Browser Is A Moving Target

Native games ship as a compiled binary against a known platform and a known graphics API. A web game ships as source that runs inside a browser, on top of an operating system you did not choose, on hardware you have never seen, through a driver you cannot control. Chrome, Firefox, Safari and Edge each ship major updates every four to six weeks, and any one of those can change how your game renders, how audio starts, or how input events fire. That spread of environments is the whole reason untested web games break in ways nobody predicted from a single development machine.

The Failures That Only Exist On The Web

Four failure modes have no equivalent in native development, and none of them show up on a permissive local setup.

WebGL context loss. The driver reclaims the GPU, usually on a mobile tab switch, and the context is gone. Unless the game listens for webglcontextlost and rebuilds textures and shaders, the canvas comes back black.

Audio autoplay policy. Browsers block audio until a user gesture. A game that starts music on load starts silent, and if the audio system assumes it is running, timing drifts from there.

CORS. A missing header on the asset server produces a silent loading failure rather than an error anyone notices.

Third party interference. Ad blockers, extensions and content security policies break game functionality on machines that are otherwise completely fine.

Test The Five Combinations That Cover Your Players

Compatibility testing is the most time consuming part of web game QA because the matrix is enormous, so stop treating it as a matrix. Pull the browser and device breakdown from your own analytics, then test the top five combinations, which usually covers 80 to 90 percent of the audience. In practice that tends to be Chrome on Windows, Chrome on Android, Safari on iOS, Firefox on Windows and Safari on macOS.

Test on real installs rather than five browsers on one machine. Chrome on macOS and Chrome on Windows use different GPU backends and different font rendering, and they will not always agree with each other.

Handle the differences with feature detection instead of user agent sniffing. Try to create a WebGL2 context, check navigator.getGamepads, try to construct an AudioContext, and show a clear message when something required is missing rather than a broken canvas.

Profile On The Worst Phone You Support

A game holding 60 FPS on a laptop with a discrete GPU can run at 12 FPS on a Chromebook with integrated graphics and refuse to start on an older iPhone. DevTools device emulation simulates screen size and touch events. It does not simulate GPU throughput, memory limits or thermal throttling, so it will not catch any of that.

Consistent frame time matters more than average frame rate, because players feel individual hitches more than a slightly lower average. Record five to ten seconds of gameplay in the Performance panel and look for garbage collection spikes, excessive draw calls, collision checks without spatial partitioning, and DOM work happening inside the frame.

Then run the session for ten to fifteen minutes on the real device. Thermal throttling only appears once the phone gets hot, which means a five minute test tells you everything is fine right up until it is not.

None of this is glamorous, and all of it is cheaper than losing players who were never going to file a bug report. The longer version, covering debugging, automated testing, multiplayer QA, playtesting and visual regression, is in Game Testing: QA, Debugging, and Quality Assurance for Web Games.

What A Separate Business Bank Account Actually Buys You

Paul Crinigan — Fri, 04 Sep 2026 21:51:40 +0000

Most developers who start selling something, a plugin, a SaaS, a small store, run the money through whatever account already exists. It works right up until the first tax season, and then it quietly costs more than it ever saved. Here is what actually changes when the accounts are separate, and how to pick one without reading a single bank landing page.

The Bookkeeping Cost Of One Account

When Stripe deposits, supplier payments, ad spend and personal groceries all move through one checking account, you do not have a ledger. You have a filter problem. At year end someone has to classify every line by hand, and if that someone is an accountant, the rate is typically 150 to 300 dollars an hour. The work is not hard, it is long, and it is billed by the hour.

The second cost is quieter. Expenses that are obvious in a business account get missed in a mixed one, because nobody remembers what a 240 dollar charge in March was for. Deductions you never claim do not show up on any invoice, so this cost stays invisible.

The Legal Line You Are Drawing

If you registered an LLC or a corporation, that entity is supposed to sit between your business and your personal assets. The protection is not automatic, it gets argued. When someone wants to pierce the corporate veil, the first evidence they reach for is commingled funds, because it suggests the business was an extension of you rather than a separate thing.

A dedicated account with clean records is the cheapest counter evidence available, and at several online banks it costs zero dollars a month.

Fees Are Not The Deciding Factor

Monthly maintenance runs from zero at online banks to 30 dollars or more at traditional ones, usually waived if you keep a 1,500 to 5,000 balance. That spread is small next to the fees nobody reads about.

Transactions: traditional accounts include 200 to 500 free per month, then charge 25 to 50 cents each. Run 1,000 small transactions on a 300 transaction plan and the overage becomes the real bill.

Wires: 15 to 30 dollars domestic and 35 to 50 international at traditional banks. If you pay overseas contractors or suppliers every month, multi currency accounts exist for exactly this problem.

Cash: online only banks generally do not accept cash deposits. If you handle cash at all, that single requirement settles the question and points you at a bank with branches.

Integrations Decide Your Monthly Workload

The bank sits in the middle of your financial stack, so its integrations decide how much of each month goes to admin.

A reliable bank feed into QuickBooks, Xero or Wave means transactions import themselves and the books stay close to real time. A bad feed means CSV exports and manual matching, every month, forever.

Processor settlement matters just as much. Fees deducted before deposit, refunds, and settlement timing all have to land in your accounting system correctly, or deposits will never reconcile against revenue.

Payroll comes later and follows the same rule. Banks that connect to Gusto, ADP or Paychex let payroll funding and tax payments run without a person moving money between accounts.

The Takeaway

Open the separate account earlier than feels necessary, then choose the bank by answering three questions: do you handle cash, how many transactions do you run, and do you pay anyone internationally. Those three answers eliminate most options faster than any comparison table.

The longer guide, with account types, fee structures and the integration details, is here: https://www.afcommerce.com/business-banking/

The Part Of Your RAG Pipeline That Decides Everything

Paul Crinigan — Fri, 04 Sep 2026 19:12:26 +0000

Most teams debugging a disappointing RAG system start at the end of the pipeline. They swap the model, tune the prompt, raise top k. The answer quality barely moves, because the problem arrived long before the query did.

A retrieval system can only return what it indexed. Everything downstream inherits whatever the ingestion step produced, and no amount of reranking repairs a chunk that was scrambled on the way in.

Ingestion Sets The Ceiling

Parsing is the step most teams underestimate. Plain text and Markdown are simple. PDFs, which hold the majority of enterprise knowledge, are not. Multi column layouts, repeating headers and footers, tables whose cell boundaries are implicit, images with text baked in, nested sections with inconsistent formatting. Naive extraction with a general purpose library produces text with merged columns, broken paragraphs and lost table structure.

The damaging part is that a bad parse does not throw. It becomes a chunk, gets embedded, and sits in the index looking exactly as trustworthy as everything around it. Layout aware parsers exist for this reason, and so does the cleaning pass that strips boilerplate, page numbers and repeated headers before anything gets embedded.

Metadata belongs to this stage too. Every chunk should carry its source document, the section heading it came from, its page or location, and a modification date. That is what makes filtered retrieval possible later, and it is what lets an answer be traced back to a specific page instead of arriving as an anonymous fragment.

Chunking Is The Highest Leverage Parameter

Chunking is the single most impactful decision in the pipeline. The tension is simple: small chunks retrieve precisely but lose surrounding context, large chunks keep context but retrieve imprecisely and eat the context window.

Fixed size chunking, typically 256 to 1024 tokens with 10 to 20 percent overlap, is a reasonable baseline for uniform prose. It fails on structured documents, where it splits tables down the middle and separates a heading from the content it introduces.

Semantic chunking follows the document instead. Section headers and paragraph breaks define the boundaries, or embedding similarity between adjacent sentences marks the point where the topic shifts. The result is a chunk that represents one idea, which is exactly what makes its embedding useful rather than a blur of unrelated sentences.

Document type decides the approach. Technical documentation responds well to section based splitting because it is already structured. Meeting transcripts benefit from topic shift detection. Legal contracts need hierarchical chunking that preserves nested clauses. Code needs AST aware boundaries at function and class level rather than arbitrary line counts. Keep 50 to 200 tokens of overlap regardless of chunk size, so an idea sitting on a boundary is complete in at least one chunk.

Hybrid Retrieval Covers Both Failure Modes

Dense retrieval with embeddings understands meaning. A query about reducing customer churn will find a chunk about retention strategies even with no shared keywords. Its weakness is exact strings: a query for error code E-4217 can miss the chunk containing that code, because the embedding maps it into a general error handling region of the space.

Sparse retrieval with BM25 has the opposite profile. It nails exact matches, rare terminology and proper nouns, and it misses every semantic connection.

Running both and merging the two ranked lists with reciprocal rank fusion beats either alone, and it does so consistently across benchmarks. RRF scores by rank position rather than raw similarity, which sidesteps the calibration problem of combining scores from two different systems. Add a cross encoder reranker on top, 50 to 200 milliseconds to reorder the candidates by real relevance, and the context reaching the model gets noticeably cleaner.

One thing that surprises people: three highly relevant chunks usually produce a better answer than ten of mixed relevance. Filling the context window is not the goal.

What To Fix First

Work backwards from the failure. If the system answers the wrong topic entirely, retrieval is the suspect. If it finds the right document but garbles the specifics, look at chunk boundaries. If the text itself is wrong in ways no human would write, the parser did it, and everything downstream has been faithfully serving that error.

The order matters because the cost of fixing each stage is wildly different. Reindexing with new chunk boundaries takes a weekend. Repairing a corpus that was parsed badly means going back to the source documents and starting over.

The full breakdown of every stage, from ingestion through evaluation and the advanced patterns like agentic RAG and GraphRAG, is in our guide to RAG pipelines.

PlayCanvas: Building 3D Games That Run In A Browser Tab

Paul Crinigan — Fri, 04 Sep 2026 12:50:04 +0000

The pitch for browser 3D has been the same for a decade: no install, no store approval, just a URL. What changed is that the runtime finally got good enough to make that pitch honest. PlayCanvas is one of the clearest examples, an open source 3D engine built specifically for the web, with a cloud editor sitting on top of it.

What PlayCanvas Actually Is

PlayCanvas started around 2011 from Will Eastcott and Dave Evans, and moved from a proprietary platform to fully open source under the MIT license, runtime and editor both. The engine is written in JavaScript and TypeScript, and it renders through WebGL 2.0 and WebGPU with automatic fallback depending on what the visitor's browser supports.

Architecturally it is an Entity Component System. Entities are the objects in your scene, components attach behaviour, and systems do the work. If you have written anything in Unity that model will feel immediately familiar, which is a large part of why teams pick it up quickly.

The output is the interesting part. There is no native binary at the end, no app bundle, no review queue. You get web output that runs in any modern browser, which is why it shows up in product configurators, architectural visualization and interactive advertising as often as it shows up in games. Snap and Animech have both shipped production work on it.

The Cloud Editor Changes The Workflow

The editor lives in the browser and the project lives on the server, so there is no engine install and no project folder to sync. Two people opening the same scene see each other's changes, which is closer to how a design tool works than how a game engine usually works.

That has a real consequence for small teams. The artist does not need a local toolchain, the developer does not need to package a build to show someone a change, and a reviewer just gets a link. For a solo developer or a team of three, cutting that friction out matters more than any single engine feature.

Rendering And The Mobile Reality

The engine handles physically based rendering, real time lighting and shadows, post processing, physics through ammo.js, and skeletal animation. The pieces you would expect are there.

The part worth planning for is mobile. Most of the traffic to a browser game arrives on a phone, and a phone gives you a tighter memory budget, a weaker GPU and a thermal ceiling that a desktop test will never show you. Texture sizes, draw call counts and how much you load before first render are the levers that decide whether the thing feels good or feels broken, and they need to be decided early rather than optimized in at the end.

Shipping Without An App Store

Deployment is a build and a static host. No submission, no review, no update cycle waiting on a third party. You can push a fix and every player has it on their next load.

The tradeoff is that discovery is now entirely yours. An app store is a bad gatekeeper but it is also a storefront, and a URL is not. Whatever you would have spent on store optimization goes into the page the game lives on instead.

Where It Fits

PlayCanvas is a good fit when instant access is worth more than raw ceiling: a game people should be able to try in one click, a configurator embedded in a product page, an interactive piece that has to reach people who will never install anything. It is a worse fit when you need the absolute top end of visual fidelity or a deeply native platform integration.

We put together a fuller walkthrough of the engine, the editor workflow, asset handling and the performance work, over at PlayCanvas game development.

The Physics Behind Every Kilowatt Your Code Runs On

Paul Crinigan — Thu, 03 Sep 2026 21:58:27 +0000

Every compute conversation right now ends up in the same place: power. Not GPUs, not memory bandwidth, power. Roughly $20 of every $100 spent on AI infrastructure now goes to electricity and the equipment that delivers it, which is more than networking and cooling combined. That makes the physics of energy generation a lot less abstract for anyone building systems at scale.

So here is a short tour of what is actually happening inside a reactor, and why the numbers come out the way they do.

Why One Kilogram of Uranium Beats 14,000 Kilograms of Coal

The nucleus of an atom holds over 99.9 percent of the atom's mass in a volume roughly 100,000 times smaller than the atom itself. Holding it together costs energy, and that binding energy shows up as missing mass: a nucleus always weighs slightly less than its protons and neutrons weighed separately. Physicists call the gap the mass defect, and E=mc2 converts it into energy.

Because c squared is about 9 x 10^16, a very small amount of mass becomes an enormous amount of energy. In practice, one kilogram of natural uranium, once enriched and burned in a reactor, yields about as much energy as 14,000 kilograms of coal. A large reactor's annual fuel requirement fits in the back of one truck. A coal plant of the same capacity burns roughly 2.5 million tonnes a year.

That single ratio is why the entire conversation exists.

The Curve That Explains Both Fission and Fusion

One graph carries most of nuclear physics: binding energy per nucleon plotted against mass number. Iron-56 sits at the peak, around 8.8 MeV per nucleon. Everything lighter and everything heavier sits lower.

The consequence is elegant. Splitting something heavier than iron moves you toward the peak and releases energy. Fusing something lighter than iron also moves you toward the peak and also releases energy. Fission and fusion are the same idea approached from opposite sides, and iron is the most stable element in the universe because it has nowhere left to climb.

Why Small Modular Reactors Changed the Economics

A conventional pressurized water reactor produces about 1 gigawatt, enough for roughly 700,000 homes. That is an awkward product to sell to a single data center campus, because it is far more than one campus draws. You end up building a power plant and selling most of its output back to the grid you were trying to stop depending on.

Small modular reactors are designed at 50 to 300 megawatts. They are fabricated in a factory rather than poured on site, which changes the financial risk profile, and they land at roughly the scale of one large campus. NuScale received the first US design certification from the Nuclear Regulatory Commission in 2023.

The other reason they matter is scheduling rather than physics. Grid interconnection queues in the US run for years, and new transmission lines take longer than that. Generation sited at the load skips the queue entirely.

Where Fusion Actually Stands Right Now

ITER, under construction in southern France with 35 participating nations, is aiming to produce 500 megawatts of fusion power from 50 megawatts of heating input. That would be the first burning plasma, one sustained largely by the heat of its own reactions.

Private efforts are running in parallel on different bets. Commonwealth Fusion Systems is building SPARC, a compact high-field tokamak using high temperature superconducting magnets. TAE Technologies is pursuing a field-reversed configuration. Helion Energy is going after pulsed fusion that captures energy directly as electricity, skipping the steam cycle entirely.

None of it is on the grid yet. Advanced fission is the near-term answer and fusion is the one worth watching.

The Takeaway

The energy density argument for nuclear is not marketing. It falls straight out of where the strong force operates and how steep the binding energy curve is. The hard parts are just as physical: waste that stays dangerous for tens of thousands of years, and the fact that the sodium-cooled fast reactors which could burn those long-lived actinides down to a few hundred years are still not commercial.

If you want the full picture, from the four fundamental forces through decay modes, reactor design, waste and the fusion race, it is all in a complete guide to nuclear physics.

Why AI API Bills Jump 10x In A Single Quarter

Paul Crinigan — Thu, 03 Sep 2026 17:56:42 +0000

Foundation model API spending hit $8.4 billion globally in 2025 and is tracking toward $15 billion in 2026, but the number that matters to any individual team is smaller and stranger: most production AI applications waste 40 to 70 percent of their token budget without anyone noticing. The waste is invisible in development, where conversations are three turns long and the retrieval index has forty documents in it. It only shows up when real usage arrives, and by then it is not a billing problem, it is an architecture problem.

The escalation pattern is consistent enough to set your watch by. Prototype costs under $50 a month. Pilot runs $500 to $2,000. Then production lands and the bill goes up 10x to 50x in one quarter. Nothing broke. The same design that was cheap at low volume is expensive at high volume, because the cost curve is steeper than any other infrastructure line most developers have dealt with.

Where The Token Budget Actually Goes

Language model APIs charge per token, and tokens accumulate in places that do not appear in any code review. Every character of the system prompt is sent with every single request. Every message in the conversation history is resent with every follow-up, so a twenty turn conversation pays for turn one twenty times. Every retrieved document chunk is included in full even when one paragraph of it was relevant. Every tool definition is repeated in every call even when the model uses none of them.

None of these are bugs. Each one is the obvious implementation, and each one is a multiplier. The useful exercise is to instrument a single real request and break it into four buckets: system prompt, history, retrieved context, and tool schemas. Most teams find that the part they were actually thinking about, the user's message, is a small fraction of what they paid for.

Caching And Model Routing Are The Quick Wins

Prompt caching pays first because the expensive part of most requests is also the most stable part. System prompts and tool schemas sit at the front of the request and rarely change between calls, which is exactly the shape caching wants. Moving stable content to the front of the prompt and keeping it byte identical across calls is usually an afternoon of work.

Model routing pays second and pays bigger. Pulling a date out of a receipt does not need the model that writes your hardest code, but most applications send everything to one endpoint because that is simpler to build. A small classifier in front, sending only genuinely hard requests to the expensive model, tends to cut more off a bill than any other single change. The recent harness benchmarks made this vivid: same model, same tasks, and cost per pass ranging from $1.05 to $18.34 depending entirely on what wrapped the model.

Batching is the third quick win, and it applies wherever work does not need to be interactive. Overnight enrichment, classification backfills and evaluation runs all tolerate latency, and most providers price that tolerance generously.

Memory Is The Architectural Fix

Caching and routing make each call cheaper. Memory changes how many tokens a call needs at all. If the things a model must remember across a conversation live in persistent storage and are retrieved by relevance, you stop replaying the entire transcript on every turn. Cost stops scaling with conversation length and starts scaling with how much is actually relevant right now, which is a much flatter curve.

This is also the fix that improves quality rather than trading against it. Resent history is not just expensive, it is noisy, and long contexts degrade attention on the parts that matter. Retrieving five relevant facts beats replaying two hundred turns on both axes. The full breakdown of these strategies, including the monitoring side, is written up in this AI cost optimization guide, and the caching mechanics specifically are covered in more depth under LLM caching.

What To Measure

A single monthly total tells you nothing actionable. Cost per feature, cost per user session and cost per successful outcome are the numbers that let you act, because they tell you which endpoint is eating the budget and whether the spend is producing anything. Teams that track cost per successful outcome rather than cost per call usually discover that their most expensive feature is not the one they assumed, and that a meaningful slice of spend goes to requests that fail and get retried.

The pattern across all of this is the same. AI costs do not spiral because models are expensive. They spiral because the redundancy is invisible until volume makes it loud, and every month you postpone measuring it, the architecture gets harder to change. Instrument one real request this week, split it into those four buckets, and the priority order will pick itself.

What WebGL 2.0 Changed for Browser Games

Paul Crinigan — Thu, 03 Sep 2026 13:05:43 +0000

WebGL 1.0 shipped in 2011 and it is still the default a lot of browser games are built against. That default is quietly expensive, because the version that replaced it changed what a browser can render, not just how fast it renders it.

WebGL 2.0 arrived in 2017, based on OpenGL ES 3.0, and the last real holdout on support has since closed that gap. For most new projects it is now a reasonable default target with 1.0 kept as a fallback.

The Version Split Still Costs Projects Performance

WebGL 1.0 gives you the core of 3D rendering: vertex and fragment shaders, texture mapping, framebuffer objects for render to texture, and basic blending and depth testing. It runs on essentially every GPU made after 2008, which is why its support numbers look so good.

The catch is that a lot of the techniques people reach for on 1.0 are workarounds. Instanced rendering arrives through an extension. Non power of two textures come with restrictions. Sharing large blocks of uniform data between shader programs means setting them one at a time. None of those are problems on 2.0, so a project that targets 1.0 for reach is often paying in frame time for users who would have been fine either way.

Why Multiple Render Targets Matter

The single biggest addition in WebGL 2.0 is Multiple Render Targets, which lets one fragment shader write to several textures in the same pass. That sounds like plumbing, and it is the foundation of deferred rendering.

In a deferred pipeline the first pass writes geometry information, position, normal, albedo and roughness, into separate textures called the G-buffer. A second pass then does the lighting using that data. The cost of lighting stops scaling with the number of objects and starts scaling with screen pixels, which is how you light a scene with dozens of dynamic lights instead of a handful.

Transform feedback lands in the same release and matters for the same reason. It captures vertex shader output back into a buffer, so particle systems and simple physics can run entirely on the GPU without a read back to the CPU.

The Sandbox Rules You Design Around

WebGL runs inside the browser security sandbox, and that shapes the API more than most tutorials admit. The GPU is shared, so the browser has to assume a shader could try to read memory it does not own or hang the driver.

The practical consequences show up as things that feel arbitrary until you know why. Context loss is a real state you have to handle rather than an edge case, cross origin textures need proper headers before you can sample them, and long running shaders can be killed. Designing for those from the start is much cheaper than retrofitting them after a launch.

Where WebGPU Fits

WebGPU is the successor, and it is genuinely better for compute heavy work and for cutting driver overhead on large scenes. It is also not a reason to skip WebGL 2.0.

Engines are shipping WebGPU renderers with WebGL 2.0 fallbacks, which means the fallback path is the one most of your players will actually run for a while yet. Understanding the WebGL 2.0 pipeline is what lets you reason about both, since the concepts carry over almost entirely.

The Practical Takeaway

If you are starting a browser game now, target WebGL 2.0 and keep 1.0 as a fallback rather than a baseline. The reach argument that justified 1.0 defaults has mostly expired, and the features you get in exchange, instancing, uniform buffer objects and multiple render targets, are the ones that decide how the finished game looks and how it holds a frame rate. We wrote the full pipeline up in more detail, including the version split and the WebGPU transition, in our WebGL game development guide.

Prompt Engineering Is Testing, Not Wording

Paul Crinigan — Thu, 03 Sep 2026 00:06:08 +0000

Most teams treat prompt work as a writing problem. You phrase the request, read the answer, adjust a few words, and move on when it looks right. That loop feels productive, and it is why so many prompts fall apart the moment they meet real inputs. The prompts that hold up in production are the ones that were measured, not the ones that were polished.

Why The Same Question Gets Two Different Answers

A language model is not executing your instructions, it is predicting what text should follow them. Every word in the prompt is a lever on a probability distribution rather than a statement of intent. Two phrasings that mean the same thing to a person can sit in very different parts of that distribution, which is why the same question asked two ways produces answers that differ in accuracy, format and length.

This is also why "the model got worse" is usually the wrong diagnosis. Nothing changed in the model. The inputs changed, and the prompt was only ever tuned against the handful of inputs you happened to try while writing it.

The Techniques That Actually Move Accuracy

A short list does most of the work. A system prompt that states the role, the constraints, and what to do when the model is unsure. Two or three examples of the exact output you want, because a demonstrated format beats a described one. Structured output, so the response is a schema you can parse instead of prose you have to interpret. And an explicit reasoning step for anything that contains more than one decision.

Prompt chaining is the one people skip. Splitting a task into two smaller prompts, each with a narrow job, almost always beats one long prompt trying to do everything, and it gives you a place to check the intermediate result before it poisons the next step.

Prompts For Agents Are A Different Job

For a single question, the prompt shapes one answer. For an agent, the prompt shapes every decision the agent makes for the rest of the run: which tool to call, when to stop, what to do with an error, how much to ask the user.

That raises the cost of vagueness. A tool description that never says when not to use the tool will get the tool used constantly. A system prompt with no stopping condition produces an agent that keeps going. Most agent behavior that looks like a model problem turns out to be an unwritten rule in the prompt.

Build A Test Set Before You Optimize

The cheapest useful thing you can build is a file of twenty real inputs paired with the outputs you would accept. Run it before and after every prompt change. It takes an afternoon to put together and it converts prompt work from opinion into a number that moves.

Once that exists, the cost conversation gets easier too, because you can finally see what shortening the prompt or dropping an example actually costs you in quality. The longer version of all of this, including the token budget side, is in our prompt engineering guide.

The Takeaway

Prompt engineering earns the second word only when there is a measurement attached to it. Write the prompt, then build the small test set that tells you whether the next edit helped. Everything else is rewriting.

The AI Video Stack Is Six Tools, Not One

Paul Crinigan — Wed, 02 Sep 2026 20:31:18 +0000

Ask someone what AI video tool they need and you usually get one answer: a generator. Then the work starts, and it turns out the generator was the part they needed least. The category behaves like six separate tools that happen to share a shelf, and picking in the wrong order is what makes the bill feel unreasonable.

The six are video generators, video editors, voice generators, text to speech, music generators and subtitle tools. A side by side comparison of all six, including where the free tiers stop, lives in the AI video and audio hub.

Generation Is The Smallest Part Of The Job

Text to video has moved fast. The current generation of models produces clips that hold up in a feed, and image to video gives you a way to keep a look consistent across shots by feeding the same still. What it does not give you is a finished piece of content.

Generated footage has to be cut, ordered, narrated and captioned like any other footage. Teams that start here end up paying for the most expensive tool in the stack to produce raw material they then process by hand.

There is one case where starting with a generator is right: you need footage that does not exist and cannot be filmed. Otherwise the material you already have is cheaper and more distinctive than anything a prompt returns.

Editing Is Where The Time Actually Goes

An AI video editor automates the tedious middle of post production. Cutting dead air and filler words, finding the moments worth keeping in a long recording, reframing a horizontal recording for vertical, and pulling short clips out of something that ran an hour.

That is the part of the process that consumes real hours, and it is the part where automation pays back immediately. A one hour recording turned into five usable clips is a bigger content win than any single generated video, and the source material is yours.

The limitation is judgment. These tools are good at finding pauses and speech boundaries, and much weaker at knowing which thirty seconds actually make the point. Treat the automatic cut as a first pass, not a final one.

Voice And Captions Decide Whether Anyone Watches

Voice generation and text to speech overlap but solve different problems. Text to speech turns a script into narration, which is what most explainer and tutorial content needs. Voice cloning reproduces a specific voice from a short sample, which matters when a series has an established sound or when a person cannot record every update themselves.

Captions are the least glamorous category and the one with the clearest return. Speech recognition produces timed captions in minutes rather than the hours manual transcription took, with styling and translation on top. Most feeds autoplay muted, so an uncaptioned video is asking viewers to opt in before they know whether it is worth it.

Accuracy is where these tools differ most. Names, product terms and accented speech are still where errors cluster, so budget a pass to fix the handful of words that matter rather than trusting the transcript wholesale.

What To Take Away

The order that wastes the least money is the reverse of how most people shop. Caption what you already publish. Edit the recordings you already have. Add synthetic narration where nobody needs to be on camera. Reach for a generator when you genuinely need footage that does not exist.

Music generation sits off to the side of that path, useful when licensing is the blocker rather than production.

Pick per job rather than per vendor. The six categories fail in different ways, and a bundle that is strong at generation is often weakest at the captions that decide whether the video gets watched at all.

What Petabyte Scale Science Changed About Research Workflows

Paul Crinigan — Wed, 02 Sep 2026 15:04:24 +0000

Most of what people know about "big data" comes from the commercial side, where the tolerance for noise is high and a slightly wrong dashboard costs nobody a retraction. Science had to solve the same scaling problem under a much harder constraint: the conclusion has to be reproducible by someone who was not in the room. That constraint reshaped how research is actually done, and the changes are worth understanding whether or not you work in a lab.

The Numbers That Broke The Old Workflow

The Large Hadron Collider produces roughly a petabyte of collision data per second during active runs. Even after aggressive real time filtering that discards more than 99.99% of events, the experiments still record around 90 petabytes per year, and the total from the LHC's first decade exceeds an exabyte.

Astronomy is on the same curve. The Vera C. Rubin Observatory photographs the entire visible southern sky every few nights, and over its ten year survey it will produce approximately 60 petabytes of raw imagery while cataloging roughly 37 billion objects. The Square Kilometre Array, still under construction, will generate data at rates exceeding 700 terabytes per second during peak observation, which is more than the entire global internet carried in 2010.

Genomics and climate modeling are less dramatic per second and just as demanding in aggregate. One human genome is about 3 billion base pairs and roughly 200 gigabytes of raw sequencing data, and sequencing facilities process thousands of samples a week. A single high resolution climate projection covering a century of conditions can output hundreds of terabytes, and the CMIP archive behind the IPCC assessments runs to multiple petabytes across participating institutions.

Filtering Moved To The Instrument

The old workflow was collect, then store, then analyze. At these rates the first two steps stopped being possible in that order, so filtering moved upstream into the instrument itself.

That is a bigger change than it sounds. A decision about what counts as signal now gets made in real time, in hardware or in a trigger layer, before any human sees it. Everything discarded at that moment is gone permanently. The design of the trigger becomes a scientific choice rather than an engineering detail, and it has to be documented as carefully as the analysis that follows.

Reproducibility Has To Survive The Pipeline

Commercial analytics can absorb some noise. Scientific conclusions cannot, which is why the emphasis on precision and transparent methodology shapes every layer of the stack, from collection through storage to publication.

The practical consequence is that provenance tracking stops being administrative overhead and becomes part of the result. When no human can inspect the raw data, the pipeline is the only thing standing behind a finding. Every transformation, every filter threshold, every software version has to be recoverable, because a reader who wants to check the work is really checking the pipeline.

This is also where most reproducibility failures actually happen. Not fraud, and rarely a major analytical error, but an undocumented manual step, a library that changed behavior between versions, or a data file that never made it into the deposit.

Where A Researcher Starts Today

Some people describe this as the fourth paradigm of discovery. After empirical observation, theoretical modeling and computational simulation comes data exploration, where patterns get found that no model predicted and no person could have seen by eye.

If you are moving into data heavy work, the useful starting order is: understand what your instrument discards before you tune anything downstream, script the whole pipeline so it runs without you, pin the computational environment so it runs somewhere else, and deposit the materials where someone can actually retrieve them. The full picture of collection, storage, processing frameworks and workflow design is laid out in this guide to big data in scientific research.

The takeaway that transfers beyond science: once your data outgrows human inspection, the trustworthiness of your conclusions is exactly the trustworthiness of your pipeline. Everything else is downstream of that.

The Accessibility Features Players Actually Use First

Paul Crinigan — Wed, 02 Sep 2026 12:20:43 +0000

Ask a team what they built for accessibility and you will usually hear about screen reader support. Ask how far it got and the answer is normally a partial implementation that nobody has tested with an actual screen reader user, shipped once and never revisited.

That is not a failure of intent, it is a failure of ordering. Screen reader integration is the most expensive item on the accessibility list and it serves the smallest of the four groups. Starting there guarantees a bad first experience with the whole category, and the conclusion teams draw is that accessibility is costly, when what was actually costly was the order they attempted it in.

Why The Backlog Is Usually Sorted Wrong

Accessibility work has an unusually wide spread between cost and reach. Remappable controls are close to trivial in any engine with an input abstraction, and they serve players with limited hand strength, players using one hand, players on adaptive controllers, and a large group with no disability at all who simply want a different layout. Screen reader support needs an accessibility tree, focus management, live region announcements, and a testing loop most studios have never run.

Sorted by impact-to-effort, the list inverts. The features that reach the most players for the least work are remappable controls, subtitles that are on by default and carry speaker labels, a toggle option for every sustained action, and color that never carries meaning on its own. None of those require new architecture, and all of them are cheaper before the interface is finished than after.

The Four Categories, And Where They Overlap

Accessibility needs split into visual, motor, cognitive and audio. The split is useful for coverage but misleading if you treat the categories as separate audiences. A single player often has needs in more than one, and the features that pay off best are the ones serving several at once.

Subtitles are the clearest example. They are an audio accommodation, but they also reduce cognitive load by giving players a second channel for dialogue they only half caught, and they help anyone playing muted in a shared space. Toggle instead of hold is a motor accommodation that also removes a cognitive burden during a busy fight. When a feature appears in two categories, it belongs near the top of the list.

What The Browser Gives You For Free

Web games start ahead of native builds here, and most teams never collect the advantage. The browser already ships an accessibility tree that screen readers understand, an operating system level zoom that works without your code doing anything, a reduced-motion preference exposed to CSS, and a font size setting the page can respect. A native team builds equivalents from scratch.

The catch is that a canvas is opaque to all of it. The moment you render the entire interface into a single canvas element, every one of those free affordances is gone. Keeping menus, HUD text and settings as real DOM elements layered over the canvas is the highest leverage architectural decision in web game accessibility, and it costs almost nothing if you make it early. The longer breakdown of the four categories and the standards behind them goes through the ARIA patterns that make this work.

A Build Order That Survives A Deadline

Prioritize by audience size against implementation cost and build in this order: full key and gamepad remapping, subtitles on by default with speaker labels, toggle options for sustained actions, colorblind-safe palettes where state is never encoded in hue alone, respect for the reduced-motion preference, then screen reader and ARIA work for the interface layer.

Test the cheap way first. Convert the palette to grayscale and see which elements collapse into each other. Play a level using only the keyboard. Turn the sound off and check whether the game is still legible. Each of those takes minutes and finds problems no checklist would have surfaced.

None of this needs a dedicated accessibility sprint or a specialist hire. It needs the list sorted by who it reaches and what it costs, the top of that list actually built, and the decision about canvas versus DOM made before it gets expensive to revisit. The teams who find accessibility cheap are not spending more than the teams who find it expensive. They are spending in a different order.