DEV Community: Paul Crinigan

Your Retrieval Layer Should Learn From Every Query

Paul Crinigan — Sat, 26 Sep 2026 19:36:13 +0000

If you have built a RAG pipeline or a search feature, you have probably shipped a ranking function and never touched it again. This post is about changing that with a few ideas borrowed from reinforcement learning.

Most retrieval systems are frozen on the day they ship. The embedding model was trained once, the ranking formula was written once, and from then on every query is scored the same way, whether the last thousand users found the results useful or ignored them completely. That is a strange design for a system that sees feedback on every single request.

Reinforcement learning offers a way out. The ideas come from game AI and robotics, but they map cleanly onto search, RAG pipelines and agent memory.

Why Static Ranking Stops Improving

A retrieval system takes an action every time it answers a query: it returns a ranked set of results. It then gets to observe what happened. Did the user click the first result or scroll past it? Did the model actually use the retrieved passage in its answer? Did the user rephrase the question a moment later?

Those behavioral signals are implicit rewards. A static system throws them away. An adaptive system treats them as training data, running a simple loop: serve results with the current ranking policy, observe the outcome, turn the outcome into a reward, and adjust the ranking so the expected reward goes up next time.

Designing a Reward Function From Noisy Signals

The loop is easy to describe and hard to get right, because feedback in retrieval is noisy, delayed and ambiguous. A result nobody clicked might be irrelevant, or the snippet might have answered the question already. A reformulated query might mean the results were bad, or that the user moved on to a related topic.

Single signals are easy to game. Click through rate rewards clickbait, dwell time rewards long content regardless of quality, and reformulation rate punishes exploration. Composite rewards that weight several signals together hold up much better, and the strongest signal of all is task completion: the bug got fixed, the ticket got resolved, the user found what they needed. There is a practical walkthrough of designing reward functions for memory systems if you want to go deeper on the tradeoffs.

Bandits, Replay and When to Update

You do not need a full deep RL stack to start. Multi armed bandits capture most of the value for ranking. Each ranking strategy is an arm, and the system balances exploiting the best known ranking against exploring alternatives that might be better. Epsilon greedy is the simplest version, serving a variation a small percentage of the time. Thompson sampling is smarter, exploring strategies in proportion to how uncertain their quality still is. Contextual bandits go one step further and learn different strategies for different query types or users.

Experience replay, borrowed from game playing agents, stores tuples of query, results served and user behavior, then reprocesses them in batches. That decouples learning from serving, so updates never add latency to live queries, and it averages out the noise in individual interactions. Most production systems end up with a hybrid: a fast online layer for small immediate adjustments and a slower batch layer for changes to the ranking formula itself.

Evidence Gating and Production Guardrails

The biggest risk in production is learning the wrong lesson from a handful of coincidences. Evidence gating addresses this by refusing to change behavior until a pattern shows up across multiple independent interactions. A memory that helped once might be luck. A memory that helped across ten queries from five different users is evidence. The idea is covered in more detail in this piece on evidence gated learning.

A few other guardrails matter just as much. Start new users and new content from a strong baseline, like similarity plus recency, so cold start is not a coin flip. Make ranking changes gradual and reversible. Log every policy change with the evidence behind it, and track retrieval metrics like mean reciprocal rank and recall at k so you can roll back when a change hurts.

The Takeaway

A retrieval layer that never learns is leaving its best training data on the floor. Start with a clear reward, add a bandit or a simple feedback loop, gate every update behind real evidence, and keep a baseline to fall back on. The full guide to reinforcement learning for AI systems walks through each of these pieces, from feedback loops to production monitoring.

What Recruiters Actually Notice in an AI Written Cover Letter

Paul Crinigan — Fri, 25 Sep 2026 23:06:40 +0000

If you are a developer on the job hunt, there is a good chance you have pasted a job post into an AI tool and asked it for a cover letter. Here is what recruiters actually notice in those letters, and how to get output that reads like you wrote it.

Cover letters are the part of an application most people dread, and AI generators have made them fast. They have not made them good by default. The difference between a letter that earns an interview and one that gets skipped usually comes down to how you use the tool, not which tool you pick.

How the Generators Match Your Resume to the Job

Most AI cover letter generators follow the same steps. They parse your resume into structured data like job titles, dates, skills and measurable achievements. Then they read the job description and pull out the role, the required and preferred skills, and the language the employer uses to describe the person they want.

The matching step is where tools separate. Basic generators look for keyword overlap, so "Python" in your resume lines up with "Python" in the posting. Better ones understand that leading a team of twelve engineers at a SaaS company answers a request for "leadership experience in a fast paced tech environment", even when no exact keyword matches.

The output usually follows the format hiring managers expect: an opening that names the role and company, a middle that maps two or three achievements to the top requirements, and a closing with a specific next step, all in roughly 250 to 400 words.

What Gets Flagged Is Generic, Not AI

Surveys say 88 percent of hiring managers believe they can spot AI written applications. Blind tests tell a different story. In one study of 1,000 recruiters, 82 percent could not correctly identify all of the AI letters in a mixed set.

What recruiters do notice is a letter with nothing specific in it. Phrases like "passionate team player" and "proven track record" read as low effort whether a person or a model wrote them. About 20 percent of recruiters say they would reject a candidate for using AI at all, but most are fine with it as long as the final letter clearly reflects the specific role and company.

So the real risk is not using AI. It is sending unedited output that reads like a template.

Getting Specific Output From Any Tool

Start with your resume, because the generator can only work with what you give it. If your resume lists duties instead of outcomes, the letter will be vague. "Responsible for the API layer" gives the AI nothing to work with. "Cut p95 latency on the payments API from 900ms to 200ms" gives it a sentence worth reading.

Then edit the draft for the three things only you can add: a real reason you want this role at this company, one detail about their product, stack or recent work that shows you looked, and a number from your own results that the resume might bury.

If you are early in your career, lean on side projects, open source contributions, internships or coursework. A good generator will map those to the job's requirements instead of padding the letter with enthusiasm.

Free or Paid

Free generators, including Grammarly's cover letter tool and several options that need no signup, produce complete letters and are enough if you apply occasionally and do your own editing. Paid tools, usually $5 to $30 a month, add saved letter libraries, multiple resume profiles, ATS scoring and job tracking, which starts to pay off once you are sending more than ten applications a week. Starting free and upgrading only if you find yourself fighting the drafts is a sensible default.

The Takeaway

Let the AI handle the first draft and the structure, and be the editor who adds what no model can know about you. That combination is faster than writing from scratch and reads better than either one alone. For a deeper comparison of the tools, the features that matter and how to handle the no experience case, see our guide to AI cover letter generators.

Three API Calls And A Model: Running Your Own Prediction Endpoint

Paul Crinigan — Fri, 25 Sep 2026 13:04:06 +0000

If you have ever wired a classifier into an app, you know the model is the easy part and the plumbing around it is where the weekend goes. This is a walkthrough of a setup that keeps that plumbing small: a PHP front, a one file Python worker, and a JSON API you can call from anything.

A lot of everyday prediction work does not need a hosted AI service or a large language model at all. Routing a support ticket, scoring a lead or flagging a strange day in your metrics is a job for a small trained model, and a small trained model can run on the same box as the app that needs it. ML Prediction Engine is our free, MIT licensed take on that idea, and the rest of this post covers the three pieces you touch when you use it: getting it running, picking a model, and calling it.

Getting It Running

The engine is two parts that install together. A PHP app serves the admin area and the JSON API, and a single file Python worker runs the models. Storage is one SQLite file plus a data folder for datasets and trained models, so there is no database server to set up.

With Docker, you copy the sample config, set an API key and admin password, point mlServiceUrl at the worker container, and run docker compose up --build. Without Docker you start the worker yourself and serve the public folder with PHP's built in server. One config line, mlDriver, decides how the two halves talk: service runs the worker as a tiny HTTP service on localhost, and cli has PHP call Python once per request, which suits light traffic and means there is no daemon to babysit. The getting started guide walks through every setting on the way to a first trained model.

Picking A Model Is Mostly One Decision

The engine ships 18 model classes, which sounds like a lot of choice until you notice they sort into four answer shapes. If you want a label, you want a classifier. If you want a number, a regressor. If you want natural groups with no labels, a clusterer. If you want a normal or weird flag, an anomaly detector.

Inside each shape, start simple. For text classification that means Naive Bayes, moving to logistic regression or the neural network as rows pile up. For tabular classification, a random forest. For numbers, Ridge first and gradient boosting once you have a few hundred rows. For grouping, k means when you know how many groups you want and DBSCAN when you want the data to decide. For anomalies, Isolation Forest, or a robust z score when you need a rule you can explain in one sentence.

Starting simple is cheap here because the dataset is the source of truth. Every model's training rows live in a visible table, and switching a step to a different class keeps the rows and costs one retrain. The guide to choosing a model covers every class and its parameters in plain language.

The Three Calls You Actually Use

Everything the admin does, the API does too, and every endpoint is a POST with a JSON body and an X-API-Key header. Day to day, an integration comes down to three calls in a loop.

dataset/add appends a labeled row the moment a real event happens: a ticket gets solved, a deal closes, someone confirms a spam report. train rebuilds the model from the complete dataset and tells you how many rows it learned from. predict runs an input through a pipeline and hands back the answer.

curl -X POST http://localhost:8080/api.php/predict \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_KEY" \
  -d '{"pipelineID": 1, "input": "why was i charged twice"}'

The response is about as small as it gets, something like {"output": "billing"}, with per step output included when a pipeline chains several models. Classifiers return a label, regressors a number, clusterers a group number, and anomaly detectors 1 or 0. There is also a pipelines call for discovery and a bulk dataset/set loader for first setups, all listed in the API reference.

The Takeaway

The useful mental model is that you are not deploying a model, you are deploying a dataset with a model attached. Keep the rows visible, start with the simplest class in the right shape, and let your app feed real outcomes back through dataset/add. Once that loop exists, turning a model into a better one is a data habit, not a project.

Sending Bulk SMS From Your Own Server: Batching, Drips and Opt Outs Done Right

Paul Crinigan — Thu, 24 Sep 2026 13:22:37 +0000

If you have ever wired texting into an app, you know the send call is the easy part. This walks through the parts around it that decide whether your messages actually arrive, using SMS Campaign Engine, a free MIT licensed PHP engine, as the worked example.

The Send Call Is Not the Hard Part

Every provider, Twilio, Telnyx, Vonage, Plivo and the rest, gives you an HTTP endpoint that takes a number and a body. What none of them give you is the scheduling, suppression, per carrier throttling and tracking a real broadcast needs. SMS Campaign Engine wraps twelve providers behind one send API, keeps everything in a single SQLite file, and runs on PHP 8.1 on almost any hosting, so all of that logic lives in one place you can read.

Spread Broadcasts Across the Day

The naive broadcast loops over the list and fires. Carriers treat a sudden burst from a small sender as a warning sign, and replies pile up faster than anyone can answer them. The engine instead fills a daily queue and spreads sends into hour buckets, shifting each one to the recipient's local time based on area code, so a 10 AM bucket reaches New York and Los Angeles at 10 AM local. When a broadcast has fewer slots than contacts, engaged contacts go first, using an activity level on each profile that moves from inactive to clicker to converter.

Per carrier caps sit on each list. Your 10DLC trust score limits what each network accepts from you per day, and capping volume per carrier keeps the engine under those limits instead of spending messages that get silently dropped. The step by step guide to sending bulk SMS walks through lists, caps and scheduling, including the broadcast/schedule endpoint if you want to drive it from code.

Drips Run on Relative Time, Not Calendar Time

A broadcast is one message to many people on a date you choose. A drip is many messages to one person on a schedule relative to when they enrolled, so every subscriber moves through the same sequence at their own pace. That makes the data model per enrollment: series, step, enrolled at, next due.

Enrollment comes from your signup form calling responder/create, a bulk upload, or the admin area, and the first message goes out right away when the recipient's local time allows it. Quiet hours and skip days are handled by the engine, and responder/unsub removes someone from one series without suppressing them everywhere, which is what you want when a lead converts and should move to a customer sequence. The SMS drip campaign setup guide covers the full flow, including testing a series against your own phone first.

Suppression Has to Survive Every Import

STOP handling is the requirement home grown senders most often get subtly wrong. Flagging the contact row is not enough, because the same number comes back the next time someone imports an old CSV. The engine writes every STOP to a suppression list that is checked on every send, so a number that opted out a year ago stays opted out no matter how many files get uploaded later.

Click tracking uses a per recipient placeholder link that the engine rewrites into a unique URL, so clicks are counted per subscriber and per drip step, with bots filtered out. That per step data is how you find the one message in a sequence that is driving opt outs.

Costs and Compliance in One Section

The software is free, so the real cost is the provider rate, in the US roughly half a cent to two cents per message, which puts ten thousand messages somewhere between 50 and 200 dollars. Marketing texts need prior express written consent, opt out language in every message, and 10DLC registration before carriers will pass your volume. The engine automates the mechanical parts, but consent collection and registration are still on you. The SMS broadcast software FAQ answers the rest of the common questions in short form.

The Takeaway

Sending one text is an API call. Sending ten thousand that arrive at a sensible local hour, to people who still want them, is a scheduling and bookkeeping problem, and it is worth solving once in code you can inspect rather than rebuilding it inside every app.

How Game NPCs Make Decisions: State Machines, Behavior Trees And Utility AI

Paul Crinigan — Wed, 23 Sep 2026 16:27:34 +0000

If you write software for a living you have probably built a decision system: a rules engine, a router, a workflow that picks a branch. Game developers have been building those under hard real time constraints for forty years, and almost none of it involves machine learning, so the patterns are worth a look even if you never ship a game.

The Four Patterns Behind Almost Every NPC

Finite state machines give a character one active state at a time. Patrol, alert, chase, attack, with rules for moving between them. They are trivial to reason about and cheap at runtime, and they fall apart once the state count grows, because transitions grow roughly with the square of the number of states.

Behavior trees replace that web with a hierarchy that gets walked from the root each tick. Sequence nodes run children in order and need all of them to succeed. Selector nodes try children in order and stop at the first success, which is how fallback chains get expressed: attack if possible, otherwise take cover, otherwise run. They became the AAA default around 2005 and they are the reason a modern enemy can gain a behavior without anyone rewiring the rest.

Steering behaviors handle movement once a destination exists. Craig Reynolds described the three flocking rules in 1987, separation, alignment and cohesion, and those three forces still drive squads moving down a corridor, crowds fleeing an explosion and birds in the background of a menu screen. Individual behaviors like seek, arrive, flee and wander get weighted and blended, usually with collision avoidance given absolute priority so nothing walks into a wall while holding formation.

Utility AI skips explicit structure entirely and scores every possible action against the current world state, then runs the winner. The Sims is the famous example, where every object in the world advertises a utility value that pulls characters toward it. It is the most flexible of the four and the hardest to debug, because the answer to why did it do that is a number that beat other numbers.

Why Enemies Feel Smart When They Are Not

The four ghosts in Pac-Man are four targeting functions. Blinky heads straight for you. Pinky aims a few tiles ahead of where you are going. Inky uses an offset computed from Blinky position. Clyde alternates between chasing and giving up. Players read those as four personalities with different attitudes, and they are four small functions with no state worth mentioning.

The marines in Half-Life were the same trick at a larger scale. They were not doing deep tactical reasoning, their behaviors were tuned so that the timing and the callouts read as coordination. That is the central lesson of the field: perception beats complexity. A simple system with responsive timing feels smarter than a sophisticated one with awkward pacing, every time.

The practical version of this is the pattern vocabulary encounters get built from. Patrollers walk a route and give the player something to learn. Turrets hold a zone and force movement decisions. Flankers push wide while something else holds attention from the front. Rushers collapse the distance and disrupt positioning. Supporters heal or buff and make the player choose a priority. None of them is interesting alone. Mixed into one encounter they produce pressure that a player has to think their way out of, which is the actual goal. The full game AI guide goes through each pattern along with the pathfinding layer underneath them.

Difficulty That Adjusts Without Telling You

Static difficulty settings tune parameters: health, damage, aggression, drop rates. They are honest and they are coarse, and most players sit between the bands or move between them as they learn.

Dynamic difficulty adjustment watches how the player is doing and quietly moves those numbers. Resident Evil 4 is the textbook case, tracking damage taken and deaths and adjusting enemy accuracy, aggression and item drops behind the scenes. The reason it is admired rather than resented is that it never announces itself and never makes a large jump.

The more expensive version changes behavior rather than numbers. Instead of dealing less damage, the enemy reacts a beat slower, picks a worse position, or telegraphs longer. It costs more to author because you are writing several tiers of AI, and it feels far better, because the enemy still looks like it is trying.

The LLM Question

Everything above is deterministic, and that is the feature. Designers can author the experience, balance it precisely, and know an NPC will never break the fiction or say something the studio has to apologize for. The price is that NPCs feel scripted, because they are.

Language models offer the opposite trade. Freeform dialogue, memory of earlier conversations, sensible answers to questions nobody anticipated. They also add hundreds of milliseconds of latency, per interaction cost that scales with playtime, content safety work, and nondeterminism that makes a guaranteed story beat impossible.

So the shape that ships is hybrid. Classic systems own combat, navigation and world simulation, where failure is visible and control matters. Generative models own dialogue, quest text and reactive narration, where surprise is the product.

The Takeaway

The transferable idea for anyone building agents is not A star or behavior trees. It is that games settled the predictability argument decades ago by putting deterministic systems wherever a user can see failure, and keeping the unpredictable parts at the edges where surprise is welcome. Most agent architectures would be better off with the same split.

What AI Headshot Generators Do With Your Face After They Deliver

Paul Crinigan — Tue, 22 Sep 2026 23:44:22 +0000

The pitch is easy to follow. Upload a dozen selfies, wait an hour, and get back forty professional portraits for less than a third of what a photographer charges. Independent testing puts recruiters at roughly 73 percent unable to tell the results from studio work, so the quality argument is largely settled. What is not settled is what happens to the model that was trained on your face once the session ends.

How The Model Learns You

When you upload photos, the platform first maps your facial geometry. The distances between your eyes, the line of your jaw, the shape of your nose, and a few hundred other landmarks. That map becomes the anchor the generator works against, and its resolution is most of the reason some tools come back looking like you and others look like a stranger with your bone structure.

Then comes fine tuning. A pre-trained image model is briefly retrained on your specific photos, picking up skin texture, hair, freckles, scars and facial hair. This takes anywhere from a few minutes to about four hours depending on the platform, and the longer runs tend to produce more consistent output. Generation then swaps everything around your face: studio lighting, a neutral background, business attire, with post processing to catch artifacts like unnatural edges and skin tone drift.

The practical consequence is that your input photos matter more than which platform you pick. Natural light, several angles, no filters, no sunglasses, and photos taken on different days rather than fifteen near identical frames from one sitting. Near duplicates make the model overfit to a single look, and the output comes back stiff.

What The Session Actually Costs

A professional session runs $150 to $400, and above $500 in New York, San Francisco or Los Angeles. Average photographer starting rates are above $250 in 38 US states. For that you get 30 to 60 minutes, basic retouching, and 3 to 10 final images, plus travel and scheduling on top.

AI tools sit between free and about $75, with most of the market at $29 to $39 for 40 to 80 headshots. The volume difference gets underrated. Choosing from 200 variations is a different exercise than choosing from eight.

There is also a cost to having no headshot at all. LinkedIn profiles with professional photos get up to 14 times more views, and for anyone freelancing or consulting that gap dwarfs the price of either option.

Where the photographer still wins is narrower than the marketing suggests, but it is real. A generator cannot capture a genuine expression from a real interaction, it struggles with unusual features and accessories, and it cannot produce environmental or action portraits. If your face is part of your brand, book the session.

Where Your Photos Go Next

This is the part that gets skipped, and it is the only part that is hard to undo. A facial image is biometric data, and it is regulated as such in a growing number of places.

Retention policies vary more than the pricing does. Some platforms delete your photos and the fine tuned model within 24 to 48 hours of delivery. Others hold your data 30 days so you can re-download. A few retain it indefinitely unless you file a deletion request. Aragon AI, HeadshotPro and BetterPic all state that uploads are not used to train their general models and are deleted after processing, but the specifics differ between them, and the policy is the only place any of it is written down.

Jurisdiction matters too. GDPR applies if you are in the EU. Illinois has BIPA, and Texas and Washington have their own biometric statutes. Reputable platforms are built to comply, but compliance with a law that does not cover you does you no good, so the thing worth checking is whether the policy addresses yours.

What This Comes Down To

The choice is not really AI against photographer. For a LinkedIn photo, a corporate directory, a conference speaker page or a job application, the generators have closed the quality gap and the price is not close. For a press photo or a personal brand built on your face, pay for the session.

What is worth two minutes either way is the retention section of the privacy policy, read before the upload rather than after. Everything else in this process is reversible. That part is not. There is a fuller comparison of the platforms, their input requirements and their data policies in this guide to AI headshot generators.

Why Ecommerce Email Still Outperforms Every Other Channel

Paul Crinigan — Tue, 22 Sep 2026 16:13:04 +0000

Email is the only marketing channel where the audience list belongs to the business rather than to a platform. That one fact explains most of what follows, including why a channel everybody assumes is old keeps returning more per dollar than the newer ones.

The Channel You Actually Own

Industry benchmarks put ecommerce email campaigns at a 15 to 25 percent open rate and a 2 to 5 percent click through rate. Those numbers are unremarkable on their own. What makes them matter is the denominator. Organic reach on a Facebook page sits near 5 percent of followers, Instagram is lower, and paid social stops working the moment the budget stops. An email list does not get throttled by an algorithm change announced on a Tuesday.

The cost structure reinforces it. Most platforms are free below five hundred subscribers, and sending fifty thousand emails a month usually lands between thirty and a hundred and fifty dollars. Comparable traffic bought through paid search or social runs an order of magnitude higher and leaves nothing behind when you stop paying.

The Four Flows That Carry the Revenue

The common mistake is treating email as a publishing calendar. Someone picks a send date, fills in a template, and the channel gets judged on what that one campaign earned. Meanwhile the automated flows, the ones that fire because a person did something, quietly do most of the work.

A welcome sequence reaches a first time subscriber while the reason they signed up is still fresh. An abandoned cart flow recovers a shopper who left a full cart, and it performs better when the first message names the specific objection, shipping cost or sizing or the returns policy, instead of leading with a discount. Leading with a discount teaches people to abandon carts on purpose. A post purchase sequence turns a single order into a second one. A win back campaign re-engages someone who has gone quiet for ninety days.

Segmentation is what keeps these from reading as generic. A first time buyer and a lapsed repeat customer should not get the same message, and the data to tell them apart is already sitting in the order table. The way these flows fit together, along with the list building and platform decisions underneath them, is covered in this complete guide to email marketing for ecommerce.

Deliverability Is an Engineering Problem

A flow that lands in the spam folder has a zero percent open rate no matter how well it is written, which makes deliverability the least glamorous and most load bearing part of the channel.

The fundamentals here are technical rather than creative. Authentication records, so receiving servers can verify that you sent what you claim to have sent. A list built entirely from voluntary opt in, because purchased lists break anti spam law in both the US and the EU and get sending domains blacklisted. Consistent sending volume rather than a dormant list hit with a sudden blast. Prompt removal of hard bounces and long term non openers, since engagement rate is itself an input to deliverability.

Treat it like uptime. It degrades quietly for months, then it fails all at once.

What Is Actually Worth Measuring

Open rate has been noisy since privacy features started prefetching images, so it works as a directional signal and not much more. Click through rate, conversion rate per flow, and revenue per recipient are the numbers that survive contact with reality.

The more useful comparison is per flow rather than per campaign. A welcome sequence and a win back campaign have different jobs, and averaging them together hides which one needs the work.

The Takeaway

Email rewards infrastructure more than inspiration. The campaigns are the visible part and the flows are not, but the flows are what keep earning after the quarter closes. Starting from nothing, build the welcome sequence first, then the abandoned cart flow, and get the authentication records right before either one goes live.

AI Voice Generation In 2026: What Actually Separates The Tools

Paul Crinigan — Mon, 21 Sep 2026 23:25:26 +0000

Every AI voice platform markets the same three things: natural sounding output, a big voice library, and cheap pricing. Those claims are almost useless for choosing one, because they describe the surface rather than the thing that differs. Underneath, every one of these products runs the same four stage pipeline, and knowing where they diverge tells you in about five minutes which tool fits the job you actually have.

The Four Stages Every Platform Shares

Text goes in and audio comes out, but there are four distinct steps in between.

First is text analysis and preprocessing. The system tokenizes your script, runs grapheme to phoneme conversion to decide how each word is pronounced, and predicts prosody, meaning where the emphasis, pauses and pitch movement go. Better systems read context clues here, spotting questions, exclamations and quoted speech and adjusting delivery accordingly.

Second is the acoustic model, a large transformer trained on speech corpora that converts the processed text into a spectrogram. This is where most of the intelligence lives. Breath sounds, micro pauses between phrases, the way pitch rises and falls inside a sentence, all of that is learned here. When two platforms sound noticeably different on the same script, the acoustic model is almost always why.

Third is the vocoder, which turns the spectrogram into an actual waveform. Early vocoders like WaveNet generated audio sample by sample and were accurate but painfully slow. Current flow based and diffusion vocoders produce high fidelity output in real time. Vocoder quality shows up in the high frequency detail, sibilant consonants and breath.

Fourth, and only for cloning, is the voice embedding. The system extracts a compact representation of a reference voice covering timbre, pace, accent and tonal character, and that embedding conditions the acoustic model so output matches the target speaker.

Cloning And Text To Speech Solve Different Problems

Standard text to speech means picking from a prebuilt library and generating. No setup, no recordings, thousands of voices across languages and ages. For narration, e-learning modules, app prompts and most video voiceover, this is the entire job and anything more is wasted effort.

Voice cloning is for when the identity of the voice is the point. Scaling your own narration, holding a consistent brand voice across a team, or preserving someone's voice for accessibility. Here the tier matters more than the vendor. Instant cloning works from a few seconds to a minute of audio and produces something recognizable but rough, fine for a draft and obvious on a long script. Professional cloning wants thirty minutes or more of clean, consistent recording, and that is what gets you a clone that survives a full audiobook.

There are two more categories worth knowing exist. Real time voice conversion transforms your live microphone input into a target voice with minimal latency, which is what gaming and streaming use. Singing voice synthesis handles pitch control, vibrato and musical phrasing, a genuinely separate technical problem that dedicated platforms specialize in.

What To Actually Evaluate Before Committing

Start with naturalness, but test it on your own script rather than the demo reel. Every vendor's demo is tuned. Listen specifically for robotic artifacts, unnatural pause placement, mispronounced proper nouns and monotone stretches in longer passages, because short clips hide all four.

Then check language and accent coverage against what you will actually need, since the spread across platforms is enormous, from English only to well past a hundred languages at native quality. Check emotional control too, whether you get sliders, style tags or prompt based direction, because a voice that cannot shift tone within a passage reads as flat over anything longer than a minute.

Finally, look hard at the pricing model and the free tier, because they vary more than the output quality does. A full comparison of the current platforms, the cloning tiers and what each free plan actually allows is worth reading before you commit, since switching later means regenerating everything you have already shipped.

The Takeaway

Pick the stage that matters for your use case and evaluate against that. If you need any decent voice quickly, standard text to speech from almost any major platform will do, and you should optimize for price and language coverage. If the voice identity is load bearing, budget for professional cloning and the thirty minutes of clean recording it needs, because the instant clone will not hold up. And when you are comparing two tools that both claim to be the most realistic, you are usually comparing acoustic models, so test them on a hard script instead of trusting the leaderboard.

Marketing An Indie Game Is A Build Task, Not A Launch Task

Paul Crinigan — Mon, 21 Sep 2026 15:47:55 +0000

Every indie postmortem that ends badly reads the same way. Two years of work, a launch day announcement, and a download counter that never moves. The developer concludes the game was not good enough. Usually the game was fine. Nobody knew it existed.

That gap between "made a good game" and "found the players who wanted it" is the single most under engineered part of indie development, and it is engineering. It has a schedule, dependencies, and assets that either exist or do not.

Visibility Is The Real Constraint

Over 14,000 games shipped on Steam in 2025, plus thousands more across itch, browser portals and mobile stores. The average indie title earns under $5,000 in its first year and the median is worse. Games that run a real marketing campaign, wishlists, press, creator coordination, launch timing, routinely land 10x to 50x that median.

That spread is not a quality spread. There are well made games sitting at under 100 downloads because no channel ever carried them. Marketing does not trick anyone into playing a bad game, it just makes sure the people who would have loved it get the chance to find out.

The Timeline Starts Before The Build Ends

The trigger to start is not a feature complete build. It is the first artifact that communicates what the game is: a screenshot, a GIF, a five second clip of the core mechanic. For most projects that exists within the first few months.

From there the schedule looks a lot like any other release plan:

Early development: accounts, devlog, Discord, sharing process publicly. A few hundred engaged followers here beats zero on launch day by an enormous margin.
6 to 12 months out: store page or landing page live, first trailer, initial press and creator outreach, followers converting into wishlists and email subscribers.
Final 3 months: press kit finalized, review keys sent, launch announcements scheduled, social cadence up. You want to enter launch week with coverage already queued.
Post launch: content updates, community events, continued outreach. The launch spike fades within a week, and plenty of indie games earn more in year two than year one.

Treating that as a parallel track instead of a phase after the code freeze is the whole difference.

Community Is Distribution

A Discord and a devlog are not vanity metrics, they are the only owned distribution an indie developer has. Every other channel is rented, and the rent is set by an algorithm you do not control.

The practical value shows up at launch. A few hundred people who watched the thing get built will play on day one, review it, and post about it without being asked. That early activity is exactly what platform algorithms and press both look for, so the owned audience ends up priming the rented channels too.

Web Games Play By Different Rules

If you are shipping to the browser rather than a storefront, the calculus shifts hard. There is no wishlist system, no discovery queue, no store page quietly surfacing your game to people who were already browsing for something like it.

A browser game lives on direct traffic, search visibility, social sharing and portal distribution. That sounds worse and in one way it is, because nothing arrives for free. But it is also fully addressable: you can rank for the thing your game is about, you can be linked, you can be embedded, and you can measure all of it. The work just has to be deliberate, because there is no platform underneath doing a share of it for you.

The channel by channel version of all of this, including visual identity, press kits, creator outreach and post launch retention, is laid out in this guide to game marketing for indie developers.

The Takeaway

If you are mid project and have not posted a single screenshot, that is the highest leverage hour you can spend this week. Not because posting is magic, but because it starts the clock on the one asset that cannot be built in a weekend, which is an audience that already knows the name of your game.

Routing Is The Cheapest AI Optimization Most Teams Skip

Paul Crinigan — Sun, 20 Sep 2026 23:07:05 +0000

Most teams trying to cut AI spend start with the prompt. They shorten instructions, trim context, cache what they can. The bigger lever sits upstream of the prompt entirely, in which model gets the request at all. LLM API calls account for 70 to 85 percent of what it costs to run an AI agent, and the most common driver of overspend is sending every request to a frontier model regardless of what that request actually needs.

Why One Model For Everything Gets Expensive

A keyword check and a complex architectural review cost the same per token when they go to the same model, even though one of them could be handled by something 50 to 100 times cheaper. That gap is the entire opportunity.

Cost is not the only problem with a single model system. Building an application around one provider exposes you to their pricing changes, their rate limits and their outages, and every major provider has had multi hour outages in the past two years. No single model is best at everything either, so a one model stack inherits that model's specific weaknesses across every feature you ship.

The Three Tier Split

The architecture that keeps proving itself sorts available models into three tiers by capability and cost.

Frontier models take the 5 to 15 percent of work that genuinely needs deep reasoning, complex code architecture or long context synthesis. They run 10 to 50 times more per token than economy models, so the discipline is reserving them for tier one work rather than defaulting to them.

Workhorse models carry 70 to 80 percent of a typical workload, the ordinary coding, writing, analysis and conversation. Getting the routing right between just these top two tiers tends to cut spend 40 to 60 percent on its own.

Economy models handle classification, keyword extraction, formatting and template filling at fractions of a cent per thousand tokens. This is the most underused tier in most systems, because teams default to their workhorse model rather than build the routing logic that would send simple work somewhere cheaper.

Routing Without Rebuilding Your Stack

A multi model system needs three components. A registry that tracks each model's price, context window and strengths. A routing layer that classifies each incoming task before choosing a tier. A normalization layer that hides the differences between provider APIs so the rest of the code never needs to know which model answered.

The routing does not have to be clever to pay off. Rule based routing, code review to tier one, content generation to tier two, data formatting to tier three, captures most of the available savings and is easy to reason about. Stanford's FrugalGPT research measured 50 to 98 percent cost reduction with that approach while matching or exceeding the accuracy of using a frontier model for everything.

Tools like LiteLLM cover the normalization layer, which turns a model swap into a configuration change instead of an integration rewrite. It also means a failed call or a rate limit can fall back to another provider without the calling code knowing anything changed.

Cross Model Review Beats Self Review

There is a quality argument here that gets less attention than the cost one. Asking a model to check its own work tends to compound its confidence rather than improve its accuracy, which produces output that is more confidently wrong rather than more carefully reasoned. An independent model evaluating the same output, with no context of how it was generated, catches errors that self review structurally cannot.

That is the part worth remembering when the savings tempt you to route everything down a tier. The second model is not only cheap insurance, it is the only reviewer whose judgment is actually independent.

Routing is the highest return change available to most AI systems and it does not require touching a single prompt. The model registry, the routing layer and the three tier split are broken down further in this guide to multi-model AI.

What Actually Changed In AI Video Generation, From A Pipeline Point Of View

Paul Crinigan — Sun, 20 Sep 2026 13:24:20 +0000

Most of the AI video conversation is about whether the output looks real yet. If you are wiring these models into a product or an internal workflow, that is the less useful question. The useful one is which part of the pipeline the model actually replaces, and what you still have to build around it.

The Model Families Under The Hood

Three broad approaches sit behind the tools you can call today, and they fail in different ways.

Diffusion based text to video generates frames from noise conditioned on a prompt. It gives you the most freedom and the least control, and it is the family behind the impressive one shot clips as well as the one that loses object permanence across a longer sequence.

Avatar and lip sync systems take a script and a likeness and drive a fixed model. Control is high, variance is near zero, and the output is boring in the good sense: it does the same thing on every run. This is what sits behind multilingual talking head video across 140 plus languages.

Edit and reframe systems do not generate video at all. They ingest existing footage, find the segments worth keeping, reframe for vertical and burn in captions. These are the easiest to adopt because the input is something you already have.

Where The Output Is Production Ready And Where It Is Not

Talking heads, explainers, product walkthroughs and localized marketing clips pass. Most viewers cannot tell, and the ones who can do not care in those formats.

Cinematic storytelling and complex physical interaction do not pass. Hands manipulating objects, fluid, cloth, and anything that needs consistent physics across a cut still show artifacts. If your use case depends on those, you are building on a moving target.

For most teams the economics matter more than the quality curve. A 2 minute explainer that cost $5,000 to $15,000 through a production agency now runs $30 to $100. That does not make existing video cheaper so much as it makes a whole category viable that never cleared a budget review: API documentation walkthroughs, per customer onboarding, internal runbooks, one region at a time localization.

Wiring Video Generation Into An Existing Workflow

Treat it as an async job, not a request. Generation takes seconds to minutes depending on resolution and length, so the calling code needs a queue, a job id and a webhook, the same shape you would use for any long running render.

Budget for regeneration. First pass acceptance rates are not high enough to skip review, so design for about three attempts per final clip and put a human approval gate before anything ships externally.

Keep the script as the source of truth. The durable asset is the structured script plus the shot list, not the rendered mp4. When a better model lands you want to re-render, not rewrite.

Version your prompts the way you version templates. Prompt drift between runs is the most common cause of a series of videos that do not look like they came from the same place.

The Takeaway

The real shift is not that AI video got good. It is that video moved from a project with a budget to a build step you can call from code, which changes who gets to make one and how often. There is a full breakdown of the tool categories, business use cases and cost tiers if you want the non technical version to hand to whoever signs off on it.

Shipping A Game To The Browser Instead Of A Store

Paul Crinigan — Sat, 19 Sep 2026 16:14:02 +0000

A web game has one advantage that no other distribution channel can match. The player clicks a link and is already playing. There is no download, no installer, no account creation, and nothing left behind on the machine afterward. That single property changes who tries your game, because someone who would never install a 400 MB build will happily spend two minutes in a tab.

The catch is that the browser does not remove difficulty, it relocates it. Everything you stop paying to a store, you start paying to the runtime.

Why The Browser Wins On Distribution

No store review queue means the build you finished this morning can be live this afternoon. No platform approval means nobody decides whether your game is allowed to exist this week. No 30 percent cut means whatever you sell is yours minus payment processing.

Updates are the underrated part. There is no patch to push and no version fragmentation to support, because every player loads the current build on their next visit. For a live game with weekly balance changes, that alone is worth the move.

Discovery also behaves differently. A web game is a URL, which means it can be indexed, embedded, linked from a forum post, and opened from a phone without leaving the conversation it was shared in.

What The Browser Costs You In Engineering

Load time becomes a hard constraint rather than a preference. A native game gets to spend five minutes installing before anyone judges it. A web game gets a few seconds before the tab closes. That pushes asset compression, texture atlases, lazy loading and deferred audio from nice-to-have into the critical path.

Mobile is where this gets real. Phone browsers throttle aggressively, and sustained GPU load triggers thermal limits that will quietly halve your frame rate several minutes into a session. Profiling on an actual mid-range device, not a desktop with the viewport resized, is the only way to know what you shipped.

Input handling is the other multiplier. A native game usually targets one input model. A web game is expected to work with touch, keyboard and mouse, and a connected gamepad, often on the same build.

The Storage And Install Question

A progressive web app closes part of the gap. A service worker gives you offline play, a home screen icon, and local saves, which covers most of what players actually wanted from installing something.

The limits are worth knowing before you design around them. iOS caps what an installed web app may store and will evict it under storage pressure, so anything you cannot afford to lose belongs on a server rather than in local storage. Plan the save system around that from the start instead of discovering it from a bug report.

Deciding Between A Web Build And A Native Wrapper

Wrappers like Capacitor and Tauri let you keep one web codebase and still submit to the stores. That is the right call when you need a store listing for credibility, want platform payment rails, or need a native capability the browser does not expose.

It is the wrong call if you are doing it out of habit. You inherit the review queue and the revenue cut you just spent the whole project avoiding, and you now maintain a second shipping path.

The honest default is to ship to the web first, because the feedback loop is faster and the audience cost of trying is near zero, then wrap later if a specific reason appears.

None of these tradeoffs are hidden, they are just spread across a dozen separate decisions that usually get made one at a time and too late. We collected the full path in one place, covering mobile, PWA, performance, publishing and hosting, monetization, multiplayer and native wrappers: Web Game Delivery.

If you shipped a browser game recently, which side bit you first, load budget or input handling?