The latest articles on DEV Community by Andreas Bergström (@andreasbergstrom). https://dev.to/andreasbergstrom https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F153469%2F5c1970f5-0d22-46e9-af0c-6931bb91d856.jpg https://dev.to/andreasbergstrom en Andreas Bergström Fri, 12 Jun 2026 04:47:42 +0000 https://dev.to/andreasbergstrom/the-best-bug-reports-were-written-by-the-suspect-2cd5 https://dev.to/andreasbergstrom/the-best-bug-reports-were-written-by-the-suspect-2cd5 <p>Our e-commerce rule engine holds risky invoice orders for human review, and the reviewers were drowning in false alarms. So we added an LLM second opinion — advisory only: a verdict, a confidence score, and a written rationale next to the hold reasons. The human still decides, and the model can never touch the ship path.</p> <p>The surprise wasn't the triage speedup. It was that when reviewers disagreed with the model, about half the investigations ended in <em>our</em> code: a years-old off-by-one that flagged invoices as overdue on their own due date, "outstanding credit" that was actually unshipped prepayment orders, a payload field that had silently been zero forever, and a loyalty-credit loophole that had been quietly farmable for years.</p> <p>The full post covers the architecture (de-identified payloads, prompts versioned in the database, eval fixtures that deliberately freeze time) and why a model that must explain itself turns out to be a continuous audit of your feature pipeline.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/advisory-llm-verdicts-on-held-invoice-orders" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> llm openai ai security Andreas Bergström Thu, 11 Jun 2026 19:37:26 +0000 https://dev.to/andreasbergstrom/the-x-inertia-cache-trap-cloudflare-vary-and-edge-cached-html-90e https://dev.to/andreasbergstrom/the-x-inertia-cache-trap-cloudflare-vary-and-edge-cached-html-90e <p>I clicked the logo on one of my Laravel + Inertia sites and the homepage rendered <em>inside Inertia's error modal</em> — in production, on a 200 response. The cause: Inertia serves HTML and JSON under the same URL, my app had opted its pages into Cloudflare's edge cache with <code>s-maxage</code>, and Cloudflare ignores <code>Vary: X-Inertia</code> when deciding cache hits. The edge happily handed cached HTML to an XHR that expected a JSON page object.</p> <p>The write-up walks through the live curl evidence (<code>cf-cache-status: HIT</code> for an <code>X-Inertia: true</code> request), why the <code>no-store</code> I already had on the JSON responses couldn't prevent it (store-time vs lookup-time defenses), the one-line fix, and the Cloudflare Cache Rule that lets you keep edge-cached HTML if you control your own zone. Plus a thirty-second curl test to check whether your own Inertia app is affected.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/inertia-cloudflare-cache-poisoning" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> laravel inertia cloudflare caching Andreas Bergström Wed, 06 May 2026 19:24:49 +0000 https://dev.to/andreasbergstrom/the-last-human-first-programming-language-24gl https://dev.to/andreasbergstrom/the-last-human-first-programming-language-24gl <p>Programming spent forty years climbing away from the machine — garbage collection, ORMs, dynamic typing, magical frameworks — trading runtime cost for human comfort while a person was at the keyboard. If LLMs are writing most of the code, the next generation of languages won't optimise for what's pleasant to type, but for what an agent can synthesise, inspect, test, and repair without anyone stepping in.</p> <p>The full post argues this isn't "we all go back to C" — it's that visibility at the call site, not abstraction level, becomes the new design axis. SQL keeps its abstraction; ORMs that materialise seventeen joins from one expression don't. Walks through the AI adoption tax on new languages, why Python complicates the picture, and ends on a falsifiable bet about which TypeScript and Java backends gain share by 2029.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/the-last-human-first-programming-language" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> llm ai programming tooling Andreas Bergström Mon, 04 May 2026 19:46:45 +0000 https://dev.to/andreasbergstrom/cutting-a-mysql-table-in-half-with-one-line-3aom https://dev.to/andreasbergstrom/cutting-a-mysql-table-in-half-with-one-line-3aom <p>We had a wide MySQL table — 8 million rows, 8 GB on disk, mostly index — about to grow 10× from a historical backfill. The instinct was to normalise: pull repeated strings into dimension tables. Classic relational hygiene. But twenty minutes spent measuring cardinality and average length per column pointed somewhere different.</p> <p>The biggest single column by raw bytes was a high-cardinality, near-unique click identifier from ad platforms. Normalising it would have moved the bytes around without removing them. Meanwhile InnoDB's <code>ROW_FORMAT=COMPRESSED</code> finds patterns <em>within</em> strings — particularly devastating on indexed URL-shaped columns — and it ships in a one-line <code>ALTER TABLE</code> with <code>ALGORITHM=INPLACE, LOCK=NONE</code>, no application code changes, fully reversible.</p> <p>Result on the production table: 8.18 GB → 3.63 GB, with the index side compressing 59%. The full post covers the cardinality measurements, why "won't reads get slower?" usually goes the right way for analytics workloads, and when to actually reach for normalisation.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/cutting-a-mysql-table-in-half-with-one-line" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> mysql database performance Andreas Bergström Mon, 04 May 2026 19:46:05 +0000 https://dev.to/andreasbergstrom/wiring-prisma-7-into-tanstack-start-on-bun-1enp https://dev.to/andreasbergstrom/wiring-prisma-7-into-tanstack-start-on-bun-1enp <p>TanStack Start, Prisma 7, and Bun fit together cleanly, but there are a handful of small decisions you want to get right before the code lands in production. This post is the list I'd want written down before starting.</p> <p>Highlights: Prisma 7 moved the runtime datasource into <code>prisma.config.ts</code> (the <code>url = env(...)</code> form in <code>schema.prisma</code> no longer works); <code>@prisma/adapter-pg</code> is the shortest path on Bun and turns connection behaviour into plain <code>pg</code> knowledge; the stash-on-<code>globalThis</code> singleton is non-negotiable under Vite HMR; and <code>@map</code> / <code>@@map</code> give you snake_case in Postgres and camelCase in TypeScript with zero runtime cost.</p> <p>The trickiest one is keeping Prisma out of the client bundle. <code>createServerFn</code> handles the obvious case, but a shared service module that's transitively reachable from the client graph still needs a dynamic <code>import('./db')</code> to keep Vite from trying to bundle Node built-ins.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/wiring-prisma-7-into-tanstack-start-on-bun" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> prisma tanstack bunjs typescript Andreas Bergström Mon, 04 May 2026 19:45:24 +0000 https://dev.to/andreasbergstrom/shipping-tanstack-start-and-bun-to-railway-2o7k https://dev.to/andreasbergstrom/shipping-tanstack-start-and-bun-to-railway-2o7k <p>Railway's Nixpacks autobuild detects Bun projects fine, but it can't sequence the combination this site needs: <code>prisma generate</code> at build time, Vite + the TanStack Start plugin, a custom <code>server.ts</code> entry, and <code>prisma migrate deploy</code> on boot. A four-stage Dockerfile is simpler than teaching Nixpacks all of that.</p> <p>The full post walks through the recipe: two parallel <code>bun install</code> stages (one full, one production-only), a build stage that runs <code>prisma generate</code> against a dummy <code>DATABASE_URL</code>, a lean runtime that layers the generated Prisma client on top of <code>deps-prod</code>'s <code>node_modules</code>, and an entrypoint that runs migrations before <code>exec</code>-ing into Bun so the container's PID 1 shuts down cleanly on Railway's SIGTERM.</p> <p>Plus the small Railway-side bits: how to wire the Postgres reference variable, why you should bind explicitly to <code>0.0.0.0</code>, and the COPY-order detail that determines whether your runtime sees the right Prisma client.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/shipping-tanstack-start-and-bun-to-railway" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> railway docker bunjs tanstack Andreas Bergström Mon, 04 May 2026 19:43:22 +0000 https://dev.to/andreasbergstrom/keeping-the-prisma-cli-out-of-a-bun-runtime-image-1nb https://dev.to/andreasbergstrom/keeping-the-prisma-cli-out-of-a-bun-runtime-image-1nb <p>This site's runtime Docker image was 423 MB. After one Bun install flag and a one-line Dockerfile change, it's 267 MB — no functional change, just less Prisma CLI tooling sitting on disk that the server never imports.</p> <p>The interesting part is <em>why</em> the obvious fix (moving <code>prisma</code> to <code>devDependencies</code>) doesn't do anything on its own. <code>@prisma/client</code> declares <code>prisma</code> as an <em>optional peer dependency</em>, and Bun installs optional peers by default. From there, transitive deps drag in <code>@prisma/engines</code>, <code>@prisma/studio-core</code>, <code>@electric-sql/pglite</code>, and ~160 MB of code the server never imports.</p> <p>The fix is <code>bun install --omit=peer</code>, plus narrowing the runtime stage's <code>COPY --from=builder /app/node_modules/@prisma</code> line to just <code>@prisma/client</code>. The full post covers the trap, the fix, and where migrations have to run once the CLI is gone from the runtime image.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/keeping-the-prisma-cli-out-of-a-bun-runtime-image" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> bunjs prisma docker railway Andreas Bergström Mon, 04 May 2026 19:43:19 +0000 https://dev.to/andreasbergstrom/the-llm-shaped-hole-in-your-xgboost-pipeline-3m7f https://dev.to/andreasbergstrom/the-llm-shaped-hole-in-your-xgboost-pipeline-3m7f <p>Every team shipping a tabular ML model gets the same question from leadership eventually: <em>"Have we tried GPT for this?"</em> The honest answer is that gradient-boosted trees still beat everything else on tabular prediction, and that hasn't changed because LLMs got bigger. TabPFN, FT-Transformer, and friends are interesting, but the short list of serious alternatives stays short.</p> <p>There <em>is</em> an LLM-shaped hole in most XGBoost pipelines — it's just not where most people put it. The pattern that works is LLMs <em>upstream</em> of trees: embeddings as features, text-to-features extraction over unstructured fields, and tool-using agents to fill enrichment gaps. None of these touch the prediction path; they all feed signal into the model that does.</p> <p>The full post walks through cost math, what each pattern is worth in practice, and the cases where the empirical answer turns out to be "no, the embeddings don't help."</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/the-llm-shaped-hole-in-your-xgboost-pipeline" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> llm machinelearning Andreas Bergström Sun, 10 Aug 2025 10:32:13 +0000 https://dev.to/andreasbergstrom/using-fastmcp-with-openai-and-avoiding-session-termination-issues-k3h https://dev.to/andreasbergstrom/using-fastmcp-with-openai-and-avoiding-session-termination-issues-k3h <p>If you're plugging a FastMCP server into OpenAI's Responses API and your sessions keep dying with <code>Session has been terminated</code>, the fix is one flag: <code>stateless_http=True</code> when you instantiate <code>FastMCP(...)</code>. OpenAI sends a <code>DELETE</code> after each call without recreating the session, so anything stateful gets terminated between requests.</p> <p>The full post covers the JSON-RPC error you'll actually see, the minimal server change to make it work, and the caveats — session state and certain bi-directional streaming patterns drop out in stateless mode. Worth a quick read if you're hitting the same one-call-then-broken behaviour.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/fastmcp-openai-session-termination" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> ai fastmcp openai mcp Andreas Bergström Mon, 27 Nov 2023 19:53:11 +0000 https://dev.to/andreasbergstrom/redirecting-mobile-users-to-app-or-play-store-using-nextjs-3pp1 https://dev.to/andreasbergstrom/redirecting-mobile-users-to-app-or-play-store-using-nextjs-3pp1 <p>If you're promoting a mobile app for both iOS and Android and want a single URL or QR code that drops users into the correct store, you don't need a 3rd-party redirect service. A NextJS middleware that matches <code>userAgent</code> against <code>iP(hone|ad|od)</code> and <code>Android</code> regexes does it in ~15 lines, runs before any render, and keeps the contact point — and any SEO it earns — on your own domain.</p> <p>The full post walks through the <code>middleware.ts</code> plus the placeholder <code>app/get.tsx</code> page that triggers it, with notes on the iOS-vs-Android UX quirk and why owning that redirect matters once QR codes are out in the wild and outlive your vendor relationships.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/nextjs-mobile-app-store-redirect" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> nextjs mobile javascript typescript Andreas Bergström Sat, 11 Nov 2023 16:37:38 +0000 https://dev.to/andreasbergstrom/python-del-vs-assigning-to-none-5387 https://dev.to/andreasbergstrom/python-del-vs-assigning-to-none-5387 <p>Both <code>x = None</code> and <code>del x</code> look like ways to release a variable in Python, but they aren't equivalent. <code>x = None</code> keeps the name bound and just rebinds it to <code>NoneType</code> (still ~16 bytes); <code>del x</code> removes the binding entirely so the name itself is gone. Touch <code>x</code> after <code>del</code> and you get a <code>NameError</code>.</p> <p>The full post walks through a worked example with <code>sys.getsizeof</code> and <code>gc.collect()</code> showing the byte difference, then disassembles both versions with <code>dis.dis</code> so you can see <code>del</code> compiles to a single <code>DELETE_FAST</code> while assigning to <code>None</code> becomes a <code>LOAD_CONST</code> + <code>STORE_FAST</code> pair.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/python-del-vs-none" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> python performance Andreas Bergström Mon, 16 Oct 2023 18:19:32 +0000 https://dev.to/andreasbergstrom/node-21-might-have-websockets-built-in-24f3 https://dev.to/andreasbergstrom/node-21-might-have-websockets-built-in-24f3 <p>Node 21 finally ships with a built-in WebSocket client — no more pulling in <code>ws</code> or <code>socket.io-client</code> for a basic browser-style API on the server side. Deno and Bun have shipped this for a while; this closes the gap.</p> <p>The full post (written just ahead of the v21 release) tracks the upstream Undici PR and the long-running Node issue thread that pushed it across the finish line, with a link to the v21 release announcement once it landed.</p> <p><em>Originally published at <a href="https://andreasbergstrom.dev/posts/node-21-built-in-websocket" rel="noopener noreferrer">andreasbergstrom.dev</a> — read the full post there.</em></p> node