标签：#tooling

If you've built large-scale applications in TypeScript, chances are you've used a Dependency Injection (DI) container. As the creator of InversifyJS, I've spent years thinking deeply about inversion of control, decoupling, and how to make enterprise patterns feel natural in TypeScript. But for all those years, there has been a glaring elephant in the room: our heavy reliance on experimentalDecorators and emitDecoratorMetadata . These compiler flags have served us well, but they are exactly that— experimental . They tie us to legacy decorator implementations, require specific compiler configurations, and often feel like a magic black box that doesn't perfectly align with modern build pipelines. I've spent a lot of time recently thinking about how we could finally drop these flags entirely while keeping the developer experience pristine. With the release of TypeScript 7, I'm thrilled to introduce the solution: 🪞 RFLCT . What is RFLCT? RFLCT is an ahead-of-time (AOT) reflect metadata injector for TypeScript 7. It injects design:symbols and design:arguments directly at build time. Zero decorators. Zero emitDecoratorMetadata . It integrates seamlessly with virtually any build tool (Vite, Rollup, webpack, esbuild) via unplugin , or you can use the built-in CLI using the TypeScript 7 API for standalone tsgo projects. Let's look at how it actually feels to write code with RFLCT. The Magic: Before and After With RFLCT, you annotate the types you want to expose to your runtime metadata using a special Reflect<T> wrapper type. What you write: import { Reflect , resolve } from " rflct " ; interface Shape { sides : number ; } class Polygon { constructor ( public shape : Reflect < Shape > , public label : Reflect < string , { optional : true } > ) {} } // resolve<T>() → the runtime identity of T (Symbol for interfaces, class for classes) container . bind ( resolve < Shape > ()). to ( Polygon ); What RFLCT compiles it to: Notice how the interfaces are safely converted into global

I spend more hours in a terminal than in any other window, and for years the configuration behind it lived nowhere: a .zshrc I had edited so many times I no longer knew which line did what, a colour scheme picked in a preferences dialog, an SSH config that only existed on one laptop. What follows is what that turned into. Not a list of everything installed on my Mac, but the terminal I actually type in and the two-part trick that keeps it reproducible: every setting is a plain-text file, and every plain-text file is in a repository. The terminal: Ghostty I moved off iTerm2 because I wanted a terminal that was fast and, more importantly, one whose entire appearance I could describe in text. Ghostty — A fast terminal with no tabs of its own to manage. Native on macOS, GPU-accelerated, and quick enough that a long build log scrolls without the fan spinning up. The configuration is a single plain-text file with one setting per line, which means the whole appearance of my terminal is a handful of lines in my dotfiles rather than a screenshot of a preferences pane I would have to redo on the next machine. Ghostty's config is a single file, ~/.config/ghostty/config.ghostty , with key = value on each line and # for comments. That is the whole format: theme = dracula font-family = "MesloLGS NF" font-size = 14 window-padding-x = 8 window-padding-y = 6 macos-option-as-alt = true copy-on-select = true The interesting part is theme . A Ghostty theme is just another config file, so any file dropped in ~/.config/ghostty/themes/ can be selected by name. Mine is Dracula and starts like this: palette = 0=#21222c palette = 1=#ff5555 palette = 2=#50fa7b background = #282a36 foreground = #f8f8f2 cursor-color = #f8f8f2 selection-background = #44475a Sixteen palette entries and a handful of colours: that is the difference between "my terminal looks right" and "my terminal looked right on the old machine". cmd+shift+, reloads the config without restarting, so tuning it is a live loop rathe

On 30 September 2025, Imgur blocked the entire United Kingdom. No warning. No migration tool. No grace period. One day it worked, the next it didn't — and with it went millions of embedded images across forums, Discord servers, tutorials, Reddit threads, and personal blogs. Grey boxes everywhere. I'd been thinking about building a proper image hosting tool for a while. That was the push I needed. What I actually built DBimg is a free media hosting and sharing service. The pitch is simple: upload a file, get a permanent direct link, share it anywhere. Here's what that looks like in practice: No account required — anonymous uploads work out of the box No compression — files are served at original quality, always Permanent hosting — no expiry dates, no "inactive account" deletion Automatic EXIF stripping — GPS and metadata removed on every upload Instant embed codes — HTML, BBCode, and Markdown generated automatically REST API — API key support for developers who need programmatic access Global CDN — fast delivery wherever the link gets shared 75MB free / 250MB Pro — covers most real-world use cases without friction Supported formats: JPEG, PNG, GIF, WebP, AVIF, HEIC, BMP, TIFF, MP4, WebM, MOV, AVI, MP3, FLAC, WAV, and more. Why I built it this way Imgur was originally built by a Redditor, for Redditors. It was frictionless by design — drop an image, copy a link, done. No account needed, no compression, no nonsense. Then it got acquired. Then acquired again. Then the NSFW purge happened in 2023. Then anonymous uploads disappeared. Then compression got heavier. Then ads got more aggressive. Then the UK ban. Each decision made sense from a business perspective. None of them made sense from a user perspective. What frustrates me about this pattern is that image hosting isn't technically hard. Serving a file from a CDN is a solved problem. The thing that's hard is committing to doing it simply and not gradually enshittifying it in pursuit of growth metrics. That's what I w

When I shipped KittyClaw two weeks ago, the tool did one thing: serve as a board. The Claude agents ran alongside - first by hand, then via a dispatcher.mjs : a Node script polling KittyClaw's API, triggering the right agent based on who was assigned to which ticket. The dispatcher worked great. It orchestrated Aekan's 13 agents for weeks. But it was an external process : one more node dispatcher.mjs to launch, a state file ( dispatch-state.json ) to keep in sync, logs to dig up in .agents/channel/debug.log , a config to copy-paste across projects in JS. Today, the dispatcher doesn't exist anymore. Orchestration lives inside KittyClaw . I run dotnet run on KittyClaw, nothing else. Aekan's 13 agents still run - but the infra that drives them is now a first-class citizen of the board. This shift from "dispatcher on the side" to "dispatcher inside the board" is small in lines of code, but it completely changes what the tool is. And how I work. This piece documents KittyClaw , the kanban orchestrator at the center of the Ekioo agent-fleet R&D. Alongside Bloomii (constructive-journalism media) and Kalceo (regulatory B2B SaaS for construction contractors), KittyClaw runs the AI agents that drive these projects in production. Before: two processes to run, two places to look The old setup was three stacked layers: KittyClaw - the board, with its UI and REST API. dispatcher.mjs - a separate Node script in the project's .agents/channel/ , launched manually in a terminal. Claude Code - the agents themselves, launched by the dispatcher. It worked. But every project had its own dispatcher.mjs , usually forked from Aekan and hand-adapted. Patterns duplicated: 30s polling, code lock, evaluator debounce, daily budget. Adding a feature (say boardIdle or subTicketStatus ) meant re-coding it in every dispatcher, or accepting that one project had it and others didn't. And visually, orchestration was invisible from the board . To see an agent's live activity, I'd pop a terminal, tail -f

Today we're open sourcing Strata , the session infrastructure that powers Stele. https://github.com/Stele-Dev/strata Coding agents already leave surprisingly rich trails on your computer: prompts, responses, reasoning, tool calls, results, timing, token usage, cost, injected context, subagents, and more. The problem is that every agent stores this differently. Strata turns those trajectories into one normalized CLI and TypeScript API. You can use it to: search across past sessions inspect transcripts and granular tool use see token usage, cost, and active time replay complete agent trajectories tail running sessions in real time see which agents are currently running on your machine build your own agent infrastructure on top of the same normalized data It currently supports Claude Code, Codex, Cursor, DeepSeek Harness, Gemini CLI, GitHub Copilot CLI, Kimi, OpenCode, and Pi. But things get more interesting when agents use Strata themselves . Run strata --skill and an agent can learn the CLI. Now an agent can search previous sessions to find when and how something was built, inspect the trajectory behind a decision instead of rediscovering it, or watch another agent working in a different terminal in real time. Agent A can effectively observe Agent B. A message bus is also on the roadmap, opening the door for local agents to communicate directly through Strata. We built Strata because we needed this infrastructure inside Stele. It powers Stele today, so while this is the first public release, the core has already been battle tested against real agent workloads. Everything stays on your machine. Local-only. Read-only. No telemetry. MIT licensed. Your coding agents already leave a trail. Strata makes it readable. https://github.com/Stele-Dev/strata

I recently built filetools, a suite of file utilities that run entirely in the browser. No server backend, no file uploads, no data collection. The Problem Existing tools for CSV extraction, PDF manipulation, and table conversion often require uploading files or creating accounts. That creates friction and privacy concerns. But these tasks are fundamentally simple: extracting text from a PDF or parsing a CSV can happen entirely in JavaScript. The Solution filetools is a collection of single-purpose utilities: PDF Tools: Merge, split, rotate PDFs Extract tables from PDFs to CSV Convert bank statements to CSV Data Tools: Extract tables from HTML to CSV or JSON Convert between XLSX, JSON, YAML, and CSV Remove duplicate lines, sort CSV files, merge/compare data files Each tool is its own page, targeting one specific task without bloat. Architecture Why static hosting? Keeps infrastructure simple and costs near zero. Files are built once, served from GitHub Pages. Why client-side only? User files never leave their machine. Processing is fast (no network round-trip). Privacy is the default. Tech stack: vanilla JavaScript using npm libraries (pdfjs-dist, exceljs, js-yaml, pdf-lib) - no framework, no server. Each page is roughly 5-15KB gzipped. Design: Started with demand mining, looking at actual Google search queries and autocomplete suggestions to pick which tools to build first. What's Next Live site: https://usefiletools.com/?utm_source=dev.to&utm_medium=article&utm_campaign=filetools-launch I'm building more tools based on real search demand. If there's a file utility you've always wished existed, especially for data professionals, I'd love to hear about it.

Updating old codebases usually means hours of re-configuring environments, fixing broken dependencies, and hunting for lost secrets. In this walkthrough, we use Cursor IDE and the new Auth0 plugin to automatically resurrect a 2-year-old Python Flask application. Watch how AI seamlessly sets up the Auth0 CLI, generates environment variables, and configures our authentication tenant from scratch. What You'll Learn How to install and navigate the Auth0 plugin within Cursor IDE. Using AI prompts to automate Auth0 tenant creation and Flask secret key generation. Navigating the Auth0 CLI device authorization code flow inside an AI environment. Troubleshooting AI prompt timeouts and natively restarting development servers via Cursor. Resources & Links 🐙 GitHub Repo 💻 Auth0 Plugin in Cursor Marketplace 🔐 Auth0 Python/Flask Docs 📖 Auth0 CLI

Gate your CI on a dollar ceiling, not a percentage — the number your finance team actually asks for Most cost gates for agent/LLM workflows check a delta : did this PR make the run more expensive than the last one, by more than X%? That's a good regression alarm. But it answers a developer's question ("did I make it worse?"), not a budget owner's question ("are we going to blow the monthly number?"). Those are genuinely different gates, and a team that only has the percentage one keeps getting surprised. A workflow can pass every percentage check — each PR adds a harmless-looking 3% — and still cross the line where the absolute monthly spend stops being okay. Percentages compound quietly; dollars are what shows up on the invoice. So the second gate I want on any agent workflow is an absolute ceiling : "a single run of this job must not cost more than $N," full stop, regardless of whether it went up or down since yesterday. Three things make that gate actually usable rather than theater: 1. The ceiling is priced, not token-counted. "Under 2M tokens" is meaningless to the person who signs off on spend, because a token of Opus output and a token of cached Haiku input differ by ~100× in price. The gate has to multiply each token bucket (input, output, cache-write at ~1.25×, cache-read at ~0.1×) by that model's real per-token price and sum to an actual dollar figure. If your gate reports tokens and makes a human convert, nobody converts, and the ceiling drifts. 2. The ceiling is per-run and per-workflow, not global. A nightly full-repo audit and a per-PR lint agent have wildly different legitimate costs; one global number is either too loose for the small job or too tight for the big one. You want to set max-usd on the specific workflow, so each job carries the ceiling that matches what it's for . 3. It shows the headroom, not just pass/fail. "$0.43 of a $0.50 ceiling — 86%" on every run is the line that lets you move the limit before it starts failing builds, instead of

Part 1 of a series. Part 2 covers the full tool catalog. Part 3 covers ObjectScript skills. Part 4 covers benchmarking and measuring what actually improves. The Problem Hiding in the Comments Thomas Mazur's post "Frogs, Chickens, AI, and VS Code" on VS Code productivity — Peacock, scoped workspace files, Copilot Agent mode — drew a sharper problem in the comments. Pietro Di Leo and Mike.W pointed out that when you work server-side in VS Code, the isfs:// workspace most production IRIS shops use, Copilot can only see the files open in your editor . It cannot index the virtual filesystem. On a mature IRIS application with thousands of classes, the AI works through a keyhole. John Murray pointed people at a project I've been building — iris-agentic-dev — and noted no Developer Community article existed for it yet. So here it is: why the problem exists, how the tool addresses it, and how to get it running in about five minutes. Why the AI Can't See Your Namespace When you open an isfs:// workspace, your IRIS classes live on the server, not on disk. The VS Code ObjectScript extension streams them to you on demand via the Atelier API — open a class, it fetches it; save it, it writes back. This works beautifully for editing. AI assistants such as Copilot work differently. They need a picture of the code around the file you're editing. Who calls this method? What inherits from this class? What other code touches this global? On a local project, the assistant can scan the files to answer those questions. An isfs:// workspace materializes files only when you open them, so there is nothing complete to scan. For a new project with a handful of classes, that may be tolerable. For a production IRIS system — ten thousand classes, Ensemble productions, custom %Library subclasses, business logic accumulated across years of development — the AI becomes nearly useless for the hard questions. It can help you write a new method if you paste in the surrounding context yourself. It cannot

Every few weeks a new checkpoint drops and the timeline fills up with claims that it's cheaper, smarter, and about to change everything. Some of those claims hold up. Many don't. And even when a model genuinely is better on public leaderboards, that tells you almost nothing about whether it's better on your codebase, your tasks, and your budget . I wrote previously about building a reproducible harness before wiring any model into your workflow. This article is the sequel nobody asked for but everybody needs: once you have a harness, how do you evaluate a steady stream of new models without spending a steady stream of money? The answer I keep coming back to is routing by task difficulty : don't run your whole eval suite against every candidate. Tier your tasks, send the cheap ones to cheap models, and reserve expensive runs for the cases that actually discriminate between models. The problem with "run everything against everything" If your eval suite has 60 tasks and a new model appears every two weeks, naive evaluation costs scale linearly forever. Worse, most of those runs are wasted signal: Easy tasks (rename a variable, write a docstring, fix an obvious off-by-one) are solved by almost every current model. Running a frontier-priced model on them tells you nothing. Medium tasks (implement a small feature against an existing test, refactor across two files) are where models actually diverge. Hard tasks (multi-file reasoning, subtle concurrency bugs, unfamiliar framework internals) discriminate strongly but are few — and they're where failures are expensive to verify. So the harness should spend its budget where the signal is. A concrete artifact: a tiered router in ~80 lines of Python Here's a minimal, runnable sketch. It assumes your eval tasks are JSON files with a tier field ( easy , medium , hard ) and a verify command you can execute (a test suite, a diff check, whatever your harness already uses). # router.py — tiered evaluation router (working sketch, adapt

Most discussions about AI coding tools start with "which model is best?" I've found that's the wrong first question. The better question is: which of my tasks actually need the strongest model, and which ones don't? In my earlier posts I wrote about building a small evaluation suite for AI coding models and a falsification loop for reviewing AI-generated refactors. This post is the missing piece between them: a routing layer that decides, per task, whether a free-tier model is good enough — and a way to measure whether that decision was right, instead of trusting vibes. The problem: paying frontier prices for boilerplate work When every prompt goes to the most expensive model by default, two things happen: You burn budget on tasks a weaker model handles fine (renaming, boilerplate, docstrings, simple test generation). You never build intuition for where the strong model genuinely matters, because you never see the failure distribution of the cheap one. The fix isn't a blog-post benchmark. It's a per-task routing rule plus a log you can audit weekly. Step 1: Classify tasks by blast radius, not difficulty Difficulty is subjective. Blast radius — what breaks if the output is wrong and you don't catch it — is not. I use three tiers: Tier Task examples Failure cost Default route Low Rename/refactor with compiler backing, boilerplate, doc comments, unit test scaffolding, commit message drafts Caught by compiler/CI in seconds Free/cheap model Medium New function in an existing module, bug fix with a clear reproducer, small migration script Caught by code review or tests, costs an hour Free model first, escalate on failure High Concurrency changes, auth/payment logic, schema migrations on live data, security-sensitive parsing May reach production silently Strongest available model + mandatory human review Two rules make this table work: Escalation is cheap, so bias toward the free tier. If the free model's output fails your checks, you escalate that one task. You lose minut

One pass of my board eval bills $9.14 on the Anthropic API. Through Claude Code it bills $0. Same model, claude-opus-4-8. That is 27 calls, and it is not an estimate. The CLI prints a total_cost_usd in its envelope: what the run would have cost on the API. It bills the subscription instead, so the number is a receipt for money nobody spent. The switch fixed something better than the bill Running with --output-format json and --json-schema rides the same structured-output machinery the API does, an internal forced tool call. Format reliability on my suite went from 7 out of 15 to 15 out of 15. The schema needs relaxing first: strip pattern , minLength , maxLength , minItems , maxItems , format and the $schema meta-ref, because the CLI validator rejects draft-2020-12. The strict version stays in Zod on the caller side, so nothing is actually loosened, the validation just moves to where it can run. One trap is worth the whole post If ANTHROPIC_API_KEY sits in the child process environment, the CLI quietly bills the API account rather than the subscription. Nothing errors. Nothing warns. The invoice arrives. It gets stripped explicitly at spawn. This is the failure mode I would look for first in anyone else's runner: the money leak is silent, and the only symptom is a bill at the end of the month for a run you believed was free. And the limit, which matters more than the savings This is a dev-loop tool. Anthropic's consumer terms prohibit automated access "except when you are accessing our Services via an Anthropic API Key or where we otherwise explicitly permit it", and the commercial terms governing API use do not cover consumer subscriptions. An eval runner on my own machine is the CLI used as designed. A shipped service is not. Iterate on the CLI, ship on the API. What does one pass of your eval suite cost, and does anyone know it? Originally published at dylan.merigaud.com .

I develop several tightly related repositories at the same time. Some are reusable SDKs for declarative schemas, infrastructure, stateful workflows, and other domain abstractions. Others are applications that consume several of those SDKs together. The development loop constantly crosses package boundaries. SDK A ──────┐ │ SDK B ──────┼──▶ application │ │ SDK C ──────┘ │ ▲ │ └──── feedback ───┘ I've already written about why I don't think this requires a monorepo, and why I prefer the repository itself to carry the current source of truth: AI Agents Don't Need a Monorepo. They Need a Readable Codebase The Repo Is the Context: Why Agents Don't Need History I won't repeat those arguments here. This post starts one layer later. As these SDKs became more agent-aware, each package started needing to tell coding agents how it should be used. I was already using project-local surfaces such as .claude/ , .codex/ , AGENTS.md , and package-specific skills. They are useful. Explicit project-local context works. The maintenance was the awkward part. When an SDK changed, I would tell the agent to update the corresponding instructions, rules, or skills in the consuming repository. That worked too. But after doing it repeatedly across several packages and repositories, I noticed something: My repeated update instructions had quietly become an undocumented protocol. Which files should change? Which source is canonical? What should be copied? What should only be referenced? What belongs to the package, and what belongs to the consuming repository? How should different coding-agent harnesses receive the same package knowledge without creating independent copies? I initially thought I needed a better synchronizer. I now think the problem is one layer higher. Packages already have an interface for programs. They increasingly need an interface for coding agents. I've been calling the protocol I'm using for that interface AIC — Agent Index Convention . It is still a draft from my own dev

If your Sentry bill is climbing faster than your signups, the usual cause isn't more users — it's more events per user . Error trackers meter on event and transaction volume, and a single bad deploy, a noisy third-party SDK, or one uncaught exception in a hot loop can burn a monthly quota in an afternoon. Before you migrate, the honest first move is to fix what you're sending. If you've already done that and the economics still don't work, GlitchTip, self-hosted Sentry, Bugsnag, Rollbar, and an OpenTelemetry-based stack are the realistic exits — each with a different trade. Why does the bill scale with events instead of users? Error tracking is priced on the thing that's expensive to store and index: individual events. Sentry, Rollbar, Bugsnag, and most SaaS competitors bill primarily on captured errors (and, increasingly, performance/tracing spans and session replays as separate meters). A product with 500 daily active users can generate millions of events if one component throws in a render loop or a retry storm hammers a failing endpoint. That decoupling is the whole problem. Your revenue tracks users; your observability bill tracks failures and instrumentation depth . When you add performance monitoring and session replay — both of which emit far more events than plain error capture — the meters multiply independently of how many humans are actually using the app. The takeaway: before you evaluate a single alternative, confirm whether you have a pricing problem or a volume-hygiene problem, because migrating won't fix a firehose. Can you cut the bill without switching tools? Often, yes — and it's worth an afternoon before any migration. The levers that matter most: Sample transactions, not just errors. Performance/tracing volume is usually the bigger line item once enabled. A tracesSampleRate of 0.1 or lower is fine for most apps; you rarely need every transaction. Filter noise at the SDK, before it's billed. ignoreErrors , denyUrls , and beforeSend let you drop

I was writing TypeScript one day. any everywhere, functions nested five levels deep. AI code review tools exist, but their output is cold. "Critical: Type 'any' is not recommended." Zero personality. So I thought, what if code review was done by a Chinese neighborhood auntie? She doesn't know programming, but she's been mediating disputes for 20 years, and explains code problems using life wisdom that's accidentally accurate. ts-auntie-review was born. An Agent Skill that reviews TypeScript code across six dimensions. Real technical analysis, hilarious delivery. Repo What it looks like Paste TS code, say "review my code", auntie goes to work. Write function getUserData(id: string): any , auntie says: "This any makes auntie shake her head. any is like saying 'eat whatever, drink whatever' — when something goes wrong, nobody can explain." Change API_URL from https to http , auntie says: "You replaced your front door with cardboard. HTTPS encrypts, HTTP sends your login credentials naked on the street." Nest functions five levels deep, auntie says: "You're making Matryoshka dolls. Your mom would lecture you to death." Six audit dimensions Type safety: any abuse, as without validation, missing return types, ! assertions. Naming: camelCase/snake_case mixing, Boolean prefixes, constant style, I prefix. Complexity: nesting depth, function length, cyclomatic complexity. Boundary: unhandled null/undefined, silently swallowed exceptions, uncaught Promises. Dead code: unused functions, unused imports, unreachable code, commented blocks, unused variables. TS conventions: type vs interface consistency, enum pitfalls, readonly, generic constraints, satisfies operator, import type. Scoring 100-point "Community Harmony Score". Fatal costs 30, warning 15, suggestion 5. Four tiers. 90+ is Model Resident, "bring auntie a tangerine". 70-89 is Needs Improvement. 50-69 is Deadline for Cleanup. Below 50 is Eviction Notice, "this code is a condemned building, rebuild." Honesty Auntie label

Most "which AI coding model is best?" debates I see devolve into vibes. Someone pastes a cherry-picked diff, someone else counters with a different cherry-picked diff, and nobody learns anything transferable. The problem isn't the models — it's that we almost never evaluate them on our code, with our constraints, using a method we could rerun tomorrow. This article is the harness I wish more teams built before arguing. It's a small, language-agnostic evaluation loop you can point at any model you have access to — including free tiers — and get a defensible answer to a narrow question: does this model help with the tasks I actually do? The evaluation trap Public benchmarks (HumanEval-style tasks, leaderboard scores) measure performance on curated problems with clean specifications. Your work is rarely that. Real tasks look like: "Add retry logic to this half-migrated HTTP client without breaking the old call sites." "Write tests for a function whose behavior depends on a config file three directories up." "Refactor this 200-line function, but the ORM calls must stay in the same transaction." These tasks share a trait: correctness is checkable, but only by you . Your test suite, your type checker, your lint rules. That's actually good news — it means evaluation can be automated against artifacts you already have. The artifact: a task-runner harness The core idea is dumb on purpose. Define a set of tasks as directories. Each task has a prompt, a snapshot of the relevant code, and a verification command. The harness applies a model's patch and runs the verifier. No scoring model, no LLM-as-judge — just your own build. eval/ ├── tasks/ │ ├── 001-retry-http-client/ │ │ ├── prompt.md │ │ ├── repo/ # snapshot of the relevant files │ │ └── verify.sh # exit 0 = pass │ ├── 002-test-config-loader/ │ └── 003-split-billing-fn/ └── run_eval.py Here's a minimal runner (Python 3.10+, stdlib only): #!/usr/bin/env python3 """ run_eval.py — apply a model-produced patch to each task and

I built a free tool that checks a supplier before you pay them. The part that took most of the work, and taught me most, was reading ten national company registers instead of relying on the EU's own VIES service. This is what I found out, mostly so the next person doesn't have to. The problem with "the VAT number is valid" VIES — the European Commission's VAT Information Exchange System — answers one question: is this VAT number currently registered. That sounds like the question you want answered. It isn't. A company that has gone into liquidation keeps a cleanly resolving VAT number in VIES. So does one that has been struck off the register. Deregistration and insolvency are run by different authorities on different timetables, and the gap between "this company has stopped being a going concern" and "the VAT number stops validating" can be months. So you can check a supplier, get a green tick, and be looking at an insolvency estate. The national registers know. VIES doesn't ask them. Ten registers, and what each actually gives you I found free, public, machine-readable-enough sources for ten countries: Bulgaria, Czechia, Estonia, Finland, France, Greece, Latvia, Poland, Romania and Slovenia. They are not equivalent, and this is the thing I'd have liked written down somewhere before I started: Six of them report company *state * — inactive, in liquidation, bankrupt, insolvent, terminated, ceased, struck off: Romania, Estonia, France, Greece, Bulgaria, Latvia. This is the valuable one. Three report whether the company is actually VAT-active — Poland, Romania, Slovenia. That matters more than it sounds, because VIES does not distinguish "this is a real company that isn't VAT-registered" from "this number belongs to nobody". The rest give you a name and not much more. Czechia, for instance, is in the ten but in neither of the other two groups. It confirms a name. That's it. Worth knowing before you build a feature around it. Poland is the interesting one Poland is the

A deep dive into AURA, the desktop AR companion that watches your face, reads your hand gestures, and — in a previous life — took 35 seconds just to say "hello." So There's a Glowing Orb on My Desktop Now Let me introduce you to AURA , a desktop companion whose entire personality can be summarized as: "I will float on top of your windows, stare at your webcam, and silently form opinions about your code and your life choices." Per its own README, AURA is built to look at your screen, evaluate your facial expressions, and judge your open browser tabs in real time. No notes. No euphemisms. That's just the mission statement, printed in broad daylight, by the people who made it. Bold. Deranged. Kind of iconic. It's a semi-transparent holographic orb pretending very hard to be a sentient biological interface, the way a Roomba pretends to have feelings when it gets stuck under the couch. It changes color depending on whether you look focused, happy, or the specific flavor of "deeply stressed by my own code" that only a 2am debugging session can produce. It does not, notably, offer to help you fix the bug. It just watches. Like a nature documentary, except you're the nature. Chapter 1: The Dark Ages (a.k.a. "Please, Just Let Me Open One App") Before the great rewrite, launching AURA was less "spin up an AI assistant" and more "sit down, we need to talk about your life choices while the computer thinks." It behaved less like software and more like a extremely judgmental houseplant that needed 35 seconds of silent contemplation before it would even acknowledge your existence. Here's the greatest hits album of suffering, straight from the project's own changelog, presented with the reverence it deserves: The 35-Second Cold Start Penalty — On launch, the app synchronously imported PyTorch, EasyOCR, MediaPipe, PyAutoGUI, Pygame, and the Windows speech drivers, all before doing anything useful, like a chef who insists on individually greeting every vegetable before starting dinne

You know exactly what you want. You can see it. You just don't know what it's called. So you open your AI tool and type "pixelated fade effect". Then "retro dot gradient". Then "that grainy old-computer image style". Six rounds later you have something almost right, and almost right is the most expensive kind of wrong. The word was dithering . With it, one prompt gets you the real thing. This gap has a shape. AI collapsed the cost of building, so the bottleneck moved: it's no longer "can the AI do it", it's "can you name it". Every field you touch as a builder has a precise vocabulary, and the words you're missing are costing you rounds of generation, wrong libraries, and vague briefs. Vocabulary is the highest-leverage thing you can pick up right now, and nobody teaches it. Jargon Buster is the cure. It's a free reverse-lookup glossary built for exactly this moment: you describe the thing in your head, it gives you the word. Reverse lookup: describe it, get the word Press Cmd+K on any page and type what you'd say to a colleague, not the term: What you type What you get "the glowy circles behind them" Bokeh "the grid of differently sized cards" Bento grid "the scroll that takes over the page" Scrolljacking "grainy speckles when I turn the number up" ISO "why is my payout smaller than my sales" Settlement "the inside of the letters fills in when I bold it" Counter Misspellings work too. "Ditter" lands on Dithering. That's deliberate: the fuzzy phrasings and typos people actually reach for are stored on every entry as first-class search data, not errors to correct. A normal glossary is indexed by the words you don't know. This one is indexed by the words you do. Every entry ends prompt-ready Knowing the term is half the loop. Each of the 2,142 entries closes the other half: A plain-language one-liner for the "that's the word!" moment A short explainer : what it is, when to reach for it, the gotcha A prompt-ready snippet : the concept translated into an instruction an

If you subscribe to more newsletters than you read, which tool fixes it depends entirely on which problem you actually have. Most roundups skip that step and just rank apps. Disclosure up front: we make one of the eight tools below. It's the last entry, it's new, and it has no track record — its section says so plainly. The other seven are real options and for most people one of them is the better pick. Every price and behaviour here was checked against the vendor's own site on 2 August 2026 . Where a vendor doesn't publish a price, this says that instead of guessing. The two problems people both call "too many newsletters" They aren't the same problem, and the tools split cleanly along the seam. Clutter. Newsletters are burying your real email. You'd read them, you just don't want them sitting next to your bank and your on-call alerts. The fix is routing: move them somewhere else. Volume. Twenty-five arrive a week and you have time for three. Moving them changes nothing — now you have twenty-five unread items in a nicer app. The fix is either condensing the pile or deciding what's in it. Almost every tool below solves exactly one of these. Buying a clutter tool for a volume problem is the standard way to end up paying a subscription and still having the same unread count. The plumbing, since you're the one wiring it up Four mechanics show up across all eight: Dedicated intake addresses. Readwise Reader, Meco, Readless and Digest each hand you an address on their domain (Meco's look like you@mecoinbox.com ). You subscribe with it and their infrastructure receives the mail — the cleanest integration point available: no OAuth scope on your mailbox, no IMAP polling, no shared credentials. Mailbox connection. Meco will alternatively connect Gmail or Outlook and pull your existing subscriptions across, setting the selected ones to skip your inbox (reversible at any time, per Meco's FAQ). Much faster than re-subscribing to 25 newsletters by hand. The cost is a read scope