That was the week on X, and if you only read headlines, it’s a reasonable conclusion. This text is for anyone who wants to know what each of those things actually does.

It blew up on the 9th, when the account below summed up what Brandon Thomas, a developer from Atlanta, had been publishing since late September: seven open source clones of Adobe’s main products, written in Rust with help from Claude Opus 5.5. Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, Acrobat. All free, all “clean room”, without a single line of Adobe code. This is the post that went viral:

AI is now being used to recreate Adobe's software, a developer has released seven free, open-source apps as clean-room alternatives to Adobe's main tools:

- PhotoCraft → Photoshop
- VectorCraft → Illustrator
- FilmCraft → Premiere Pro
- LightCraft → Lightroom
- EffectCraft → After Effects
- DesignCraft → InDesign
- PrintCraft → Acrobat Pro

Built in Rust with help from Claude Opus 5.5, they run on Windows, Linux, and macOS under MIT/Apache licenses without using Adobe's source code.

— Pirat_Nation (@Pirat_Nation) October 9, 2026

The same week, REA, “Reverse Engineer Anything”, passed 100K stars on GitHub, gaining tens of thousands a day. The pitch on its page: “see a feature in an app that you want in your own product? Ask your agent to investigate it with REA and build a version for your project”.

And anyone who follows retro gaming knows 2026 is the year that keeps on giving. There’s a community spreadsheet trying to list the unofficial PC ports, around 100 games from Ship of Harkinian to Skate 3, and it’s always behind. The Video Game Esoterica channel publishes a new port almost daily: Time Crisis decompiled from the arcade board, Daytona USA, Bloodborne.

The Xbox One version of Forza Horizon 2, stuck there since 2014, runs on Windows. AnyPS5 promises to convert PS5 executables into native PC binaries, and PS5 emulators like KytyPS5 and SharpEmu already run Astro Bot with actual gameplay. Much of it with AI in the loop, some of it openly vibe-coded.

Hence the consensus: programming, in general, is over. Every binary is reversible and reusable, just point the agent at it. My position is that it did get much easier, that it’s still nowhere near the silver bullet people imagine, and that the engine behind it, the LLM, stopped growing exponentially. The rest of the text is the reasons.

TL;DR: reverse engineering is a 40-year-old discipline with mature tooling, and AI sped up its grunt work, especially in retro, where the binary is available, tiny, and the target doesn’t move. The Adobe clones are alphas with hundreds of open bugs and pretty screenshots. REA is a toolbox that requires the binary in hand, Ghidra or IDA installed, and a lot of tokens. What’s worth money today doesn’t even have a binary: it’s SaaS, cloud, manufacturer partnerships and decades of color science. Rewriting Bun, with the project’s author and 64 agents, cost US$ 165K. Jump to the timeline, to REA, to the Adobe clones, to the Bun case, to why retro moves fast or to the answers at the end.

First of all: I don’t like Adobe

To be clear about where I’m speaking from. I hate Adobe’s business practices as much as anyone. I was a paying customer for years, used Photoshop and Premiere extensively, plus Lightroom and After Effects, and left for the same reasons everybody leaves: mandatory subscription, cancellation fees, prices going up with nothing in return.

And it’s precisely because I used them in depth that I know the size of what’s inside those boxes. Whoever thinks Photoshop is layers, crop and text never needed a color proof for a print shop, never opened a camera RAW whose color profile Adobe has maintained for twenty years, never did the conform on cinema footage, the work of gathering the camera’s raw material for finishing. I’ll get there, after the basics.

Reverse engineering wasn’t born last week

Every emulator you’ve ever used exists because someone opened up hardware, disassembled a binary, sniffed a protocol and, in some cases, broke cryptography. The discipline has case law, commercial tooling and decades of history. A condensed timeline, with the milestones that matter most:

• 1982 to 1984: Compaq reverse engineers the IBM PC BIOS, and in 1984 Phoenix sells a licensable BIOS built in a clean room, by a team that only read the specification. The PC compatible industry is born. Source.
• 1992: Andrew Tridgell creates Samba by sniffing SMB packets. The same year, Sega v. Accolade and Atari v. Nintendo establish in the US that disassembling code to reach functional elements is fair use (Atari lost its own case for another reason: it lied to the Copyright Office to get the source).
• 1993: Wine begins, which becomes the foundation of Proton and of every Windows game that runs on the Steam Deck today.
• 1999: UltraHLE runs commercial N64 games at full speed; bleem! emulates the PS1, Sony sues and loses the injunctions, and bleem! folds anyway in 2001; DeCSS breaks DVD protection.
• 2000: Sony v. Connectix rules that copying the PS1 BIOS to build an emulator is fair use.
• 2002 and 2003: PCSX2 and Dolphin are born, the two emulators that twenty years later are still the reference.
• 2007: the iPhone is opened eleven days after launch. The European Commission forces Microsoft to document its network protocols, and the Samba team receives the documentation for 10,000 euros.
• 2010: the fail0verflow group shows at 27C3 that Sony signed the PS3 firmware with a fixed nonce, exposing the private key (the nonce is the number that should be random in every signature). Days later, already in 2011, geohot publishes the key, Sony sues and settles in March.
• 2011 and 2013: RPCS3 (PS3) and Xenia (Xbox 360) are born, the two hardest emulators ever built, for reasons I’ll explain.
• 2019: the NSA releases Ghidra as open source. The Super Mario 64 decompilation leaks and goes public, and the PC port appears the following year.
• 2021 and 2022: Ocarina of Time 100% decompiled after almost two years of work; Ship of Harkinian becomes the reference port.
• 2024: Mr-Wiseguy releases Zelda 64: Recompiled, the first showcase of N64 static recompilation.
• 2025: Sonic Unleashed Recompiled brings the same trick to the Xbox 360, converting PowerPC to C++ and shaders to HLSL.

Notice that the current phase, decomp and recomp at scale, starts in 2019, well before any coding agent. AI joined an assembly line that already existed.

The tools

The tooling is mature too, and much of it is free:

• IDA Pro (Hex-Rays), the reference commercial disassembler and decompiler, from one thousand to almost nine thousand euros a year, with a free version limited to x86.
• Ghidra, the NSA’s open answer, with a decompiler and scripting, Apache 2.0.
• Binary Ninja, with a free edition and licenses from 200 to 3,500 dollars.
• radare2 and Cutter, the GUI for rizin, which is a radare2 fork: the open command line and the open interface.
• x64dbg and WinDbg on Windows, GDB everywhere else.
• Frida, to inject code into a live process and watch what it does.
• JADX for Android and ILSpy for .NET.

Keep this list in mind. REA, which we’ll get to shortly, is a wrapper around it.

How a binary gets taken apart, in practice

In principle, every binary is reversible. The processor has to be able to execute it, so the instructions are in there. The path is always the same:

1. Disassemble: the binary becomes assembly, one machine instruction per line. This is mechanical.
2. Decompile: the assembly becomes something resembling C. Ghidra and IDA do this reasonably well, with a lot of noise.
3. Recover what the compiler threw away: variable names, function names, types, structures, comments. None of it survives compilation. This is the real work, and it’s human.
4. Refactor until it becomes code a person can read, maintain and port.

The N64 decomp projects take step 4 all the way: their C code, recompiled, produces the original ROM byte for byte. That’s how Super Mario 64 became a project with 135K lines of game C code (around 100K of actual code, plus half a million lines of generated level and model data), and Ocarina of Time passed 430K lines. Static recompilation skips part of this: it translates the original processor’s instructions into generic C, without trying to understand them, and replaces only the parts that talk to the hardware. It’s faster and the result is less readable.

“But can’t the AI just read the binary directly?”

Someone always asks: if it’s AI, why go through C? Let the model read the binary and build on top of it. The short answer is that an LLM only knows what was in its training corpus, and a corpus of binaries paired with source code is scarce, because no human has written production assembly in decades.

The long answer is that the literature exists, and it’s instructive precisely because it’s modest. The lineage runs from 2018 neural networks to models like SLaDe (200 million parameters, one per architecture and optimization level), LLM4Decompile (up to 33 billion) and Nova. Meta published an LLM Compiler that translates assembly into LLVM IR. The best results, on isolated benchmark functions, hover around 60 to 65% of code that runs again and gives the same result, dropping sharply when the compiler optimized with -O3.

Two recent studies show the real state of things. DecompileBench, with 23K real functions, found that LLM-based decompilers produce more readable code with half the functional correctness of commercial decompilers. And a September 2026 paper measured that LLM refinement of Ghidra output raises the compilation rate from 75% to 90% and drops behavioral fidelity from 74% to 62%, with up to around 10% of functions with known vulnerabilities no longer reproducing the flaw, meaning the bug vanished without anyone asking.

Summing up what exists: small models, function by function, almost only x86-64 Linux, and the best ones are refinement layers on top of Ghidra, which keeps the classic decompiler in the loop. No emulator, no game, no whole program has been neurally recompiled. Until someone invents that, you work with reality, and reality includes the intermediate layer of programming language and compiler.

The AI assistants that exist for this in production confirm the design: aiDAPal, an IDA plugin by Atredis, Binary Ninja’s Sidekick, the MCP servers for Ghidra. All of them are an LLM naming variables and explaining functions on top of what the traditional decompiler produced.

What REA actually does

I cloned REA and read the code. It’s an MCP server and a TypeScript CLI that wraps the tools from the list above and exposes them to your coding agent: Ghidra, Hopper, IDA, JADX, Frida, Wakaru for obfuscated JavaScript, Playwright to capture what a website does. The agent asks, REA runs the tool and returns pseudocode, call graphs, strings and IPC traces, each result with an evidence record and a list of limitations.

I had already done that flow by hand, months before REA went viral. In July I had Fable 5 analyze the code of TikTok, Clash of Kings and gov.br: I downloaded the APKs, unzipped them (an APK is a zip), ran JADX on the .dex files and let the model read the Java that came out the other side. It was enough to see the endpoints, the permissions, the embedded SDKs and how each app builds the device fingerprint, that persistent identifier that survives clearing data and reinstalling. TikTok came out as industrial-grade collection, armored against auditing; gov.br, as the example of how to do it right.

The three lessons from that post apply to all of REA. Android is far too easy to decompile, and even so the result serves only static analysis, because recompiling the app is out of reach: the names come scrambled by obfuscation, resources and signing keys are missing. The most sensitive part lives in native code, .so files in C and C++, which decompile into nothing readable, and in TikTok that’s exactly where the core sits. And what came out of that work was a report on what the app does, with caveats, and no TikTok clone. REA packages that same flow into an MCP server; the walls stay in the same place.

The judgment is supplied by the LLM you already pay for. REA supplies the deterministic plumbing and the provenance. The phrase “automates the heuristics of reverse engineering”, which circulates out there, appears nowhere in the repository; the description the project itself uses is agent-driven reverse engineering with traceable evidence.

What it requires: the artifact on your machine (native binary, Electron app, .NET assembly, APK, firmware, network capture), Node 22.19 or later, and the heavy tools installed at your own expense. Ghidra is free; IDA, Hopper and JEB the README tells you to buy. There’s no REA API key because it runs locally, and the token cost lands entirely on your agent subscription.

And that cost is the detail nobody mentions. REA’s MCP tool catalog is 2.3 MB of JSON, which goes into the agent’s context. The project itself publishes an experiment in which analyzing SQLite compiled to WASM, on the default path, took 42 tool calls, five minutes and 300K input tokens. A full inventory of an Electron app like Obsidian returns almost 1 MB of JSON.

There’s an open issue complaining that inspecting an ordinary Mac app returns 80K to 230K tokens in one go.

The project is serious and goes far: six months, 2,600 commits, a thousand test files, version 6.4 released on October 11. It’s also unstable: 190 open issues, several breaking changes per minor release, subsystems marked experimental.

The limits are written in the repository itself. CONTRIBUTING excludes breaking DRM, anticheat, licensing and commercial protections. The DISCLAIMER warns that decompilation, reconstruction and AI-assisted analysis “may be incomplete or incorrect”. And even the internal instructions for generating the website’s figures say, in so many words: “never imply REA automatically clones a program” and “never say full reconstruction, exact game clone, or automatic source recovery”.

REA is a good toolbox for someone who already knows how to do reverse engineering and wants an agent holding Ghidra. It isn’t the “copy this app for me” button. The people who wrote the project are the first to say so.

PhotoCraft: pretty screenshot, alpha inside

The PhotoCraft repository was created on September 30. In two weeks, 54K stars, 8 releases and, as I write, more than 800 open issues. The README badge says “early alpha”, and Brandon Thomas himself, quoted by Gizmodo, said it’s nowhere close to ready. The press that tested it reached the same conclusion: Gizmodo called it a “glitchy, but real, Photoshop”, and OMG Ubuntu “a superficial facsimile with pronounced flaws”.

The issues tell the technical story:

• Any image above 8,192 pixels leaves the GPU compositor and falls back to the CPU, with a 6 GB memory peak, because that’s the egui-wgpu texture limit (issue 49, already closed, and the ones that came after it, 1015 and 4017).
• A 12 megapixel photo needs almost 800 MB just to open, adjust and export from the command line (issue 1637).
• Color management is rudimentary: a global working space only, instead of per document, and no view transform (issue 321). Eighteen issues mention CMYK, fifteen mention ICC profiles.
• Almost a hundred open issues mention PSD. Hue/Saturation layers composite differently from Photoshop, and saving over the file overwrites the original’s correct merged image (issue 4089).
• Fifty open issues mention “crash”.

The interface resembles Photoshop, so the screenshot is shareable, and whoever sees the screenshot assumes it’s a carbon copy. That’s expected in a two-week-old alpha. With interest, time and contributions, part of this gets fixed. And then the contributors will discover something the N64 projects never faced.

PhotoCraft today is that Ferrari replica built on top of a VW Beetle: the body has the right shape, you take a photo and most people say “wow, a Ferrari”. Then you turn the key and out comes the Beetle engine. If the photo got you hyped, that’s on you.

The target moves

Decompiling 1998’s Zelda is aiming at a stationary target. Nintendo isn’t going to release Ocarina of Time 2026 with a new file format. Copying a live product is another conversation, and we’ve seen this movie before.

In the 90s and 2000s the target was Microsoft Office. StarOffice became OpenOffice in 2000 and LibreOffice in 2010, and all of them spent years chasing a binary format, .doc, that changed from version to version and only got a public specification in 2008, when the game was already over. The proven part of that story is in the court cases: the European Commission fined Microsoft 497 million euros in 2004 for refusing to supply interoperability information, and 899 million in 2008 for failing to comply. .docx only became an ISO standard in 2008, in a vote so controversial that countries formally protested.

It took more than ten years. And when the format finally opened, Office no longer mattered the same way. The value moved elsewhere: today it’s 400 million paid Office 365 seats, 3 billion Google Workspace users and around 41 million Creative Cloud subscribers. Nobody wants to install that on a desktop, and so nobody has the binary.

Reverse engineering Google Docs means rewriting the product from scratch looking only at the interface, because the code that matters never leaves the server. After the world moved to SaaS, most proprietary software became a walled garden with no binary. No binary, nothing to disassemble.

You can build versions of it, of course. Immich replaces Google Photos for a person or a family: phone backup, face recognition, semantic search, all on your server. What it doesn’t replicate is the infrastructure and the training corpus that make Google’s search Google’s search. And Adobe made the same migration, in pieces.

Photoshop is far more than layers and crop

Here’s the part I know from having paid for it. The features that sell subscriptions today don’t even run on your computer.

Generative Fill and Generative Expand run on Firefly, in the cloud, and consume generative credits. Several Neural Filters, according to Adobe’s own documentation, need an internet connection because the processing happens on Adobe’s servers. AI object selection has had, since 2020, an option to process in the cloud for a refined result. All of this is code that doesn’t exist on your machine for anyone to disassemble.

Then comes what is in the binary, but took decades and partnerships to exist. Camera Raw carries lens correction profiles and per-camera color profiles for hundreds of models, built over twenty years and updated with every release. No clone guesses that. Either you have the data or you don’t.

And there’s color science. The example I always remember is GIMP and CMYK.

GIMP was born in 1995. The first native support for CMYK files arrived in 2022, and only for import and export, with pixels always in RGB. GIMP 3.0, from 2025, still has no CMYK editing mode. It’s on the roadmap as work in progress.

Thirty years of an open project, with good and motivated people, and the print shop still asks for Photoshop. That’s the size of the color science hole, and no coding agent invents color science: it reproduces what’s in the training data.

Why did it take so long, if it was the most requested feature? Because GIMP’s core was born with 8-bit-per-channel RGB baked into every layer, blend mode and filter. Supporting another color model meant rewriting the entire pixel engine, the migration to GEGL, which took the better part of a decade and was only finished in GIMP 2.10, in 2018. CMYK could only start after that.

And CMYK is a family of device profiles, with four inks, a per-printer ICC profile, ink limits and black generation rules, and editing in it means the whole pipeline has to compute in a subtractive four-channel model and round-trip through the profiles without drifting. A single developer, however good a programmer, without experience in this specific field will struggle to implement it, because the knowledge lives in print shops and color labs, and almost none of it is in a training corpus. In GIMP, the people who carried it forward were contributors who understand printing, and even then it took years. No new tool shortcuts that kind of knowledge.

And then there’s the layer that isn’t even technical: commercial licensing. Print-shop color is Pantone, and Pantone is a proprietary library. No open project can ship the palettes; the Inkscape developers reached that conclusion in 2005, and Linux.com explained the legal risk around the same time. Adobe itself felt it in 2022: when Pantone changed its business model, the libraries were pulled from Photoshop, Illustrator and InDesign, old files started opening with their Pantone colors replaced by black, and anyone who needs them pays for a separate plugin subscription. If even Adobe, paying, didn’t escape, imagine a clone that runs on goodwill.

Video is worse

In Premiere, After Effects and DaVinci Resolve, the problem multiplies. A cinema camera doesn’t deliver video, it delivers raw data on its own logarithmic curve: ARRI’s LogC4, RED’s IPP2. To turn that into an image you need the manufacturer’s transforms, and RED ships its own in an SDK that the editors integrate and update with every version. ACES, the industry’s neutral standard, depends on input transforms supplied by each manufacturer.

Blackmagic gives Resolve away for free and it decodes ARRIRAW and R3D. It does that because it pays for the SDK and the partnership on your behalf. An agent-built clone, “guessing” how the Alexa’s image should look, produces an image that doesn’t match the reference monitor, and in cinema that means it’s useless. That knowledge isn’t in any training corpus: it’s in contracts.

The Bun case: what it costs to rewrite big software

For a sense of the order of magnitude, the best public data point there is comes from Bun. In May 2026, Jarred Sumner rewrote the entire runtime from Zig to Rust using agents, and in July published the numbers:

• 535K lines of Zig in 1,448 files became a one-million-line Rust diff, in 11 days.
• Up to 64 Claude instances in parallel, 24 hours a day, every line reviewed by two adversarial agents and a fixer.
• 5.9 billion uncached input tokens, 690 million output tokens, 72 billion cache reads: around US$ 165K at API prices.
• 16K compiler errors fixed by 64 agents before CI went green on six platforms.
• The existing test suite, with more than a million assertions, passed 100% before the merge.

Read again what made it possible:

• the project’s original author at the controls
• a complete, working source code as reference
• a test suite with a million assertions serving as the oracle
• unlimited budget, because Bun has belonged to Anthropic since December 2025, and a pre-release version of Claude Fable 5

Sumner estimates three engineers with full context would have needed a year.

Now take each of those advantages away. PhotoCraft doesn’t have the Photoshop source to port, it has to invent. It doesn’t have a test suite that says “this matches Photoshop”. It doesn’t have Photoshop’s author.

And Photoshop is a 36-year-old product whose disk requirements Adobe lists between 10 and 100 GB, against a JavaScript runtime. Even without knowing the size of Adobe’s codebase, we’re talking about a bigger target, with no reference, no oracle and no owner. Orders of magnitude above US$ 165K, and even then it would be an approximation.

Why retro moves so fast

If it’s so hard, why does an old game port ship every day? Because retro stacks up every advantage the rest doesn’t have.

The binary is available and tiny. Super Mario Bros. on the NES: 40 KB. Super Mario 64: 8 MB. Ocarina of Time and Majora’s Mask: 32 MB each. A whole PS1 CD: 650 MB.

Compare with Baldur’s Gate 3, 150 GB, or with the latest Call of Duty, above 100 GB. That’s three or four orders of magnitude, and the scope shrinks along with it: a 1996 game has a handful of systems, not a physics engine with networking, a store and anticheat.

The technology is old and documented. Twenty-five years of community have already mapped the N64, PS1 and SNES hardware instruction by instruction. The agent discovers nothing; it speeds up work that already has a map. It’s the same pattern I saw in my retrocomputing projects: where there’s a reference and an oracle, AI flies; where there isn’t, it spins in brute force.

The target doesn’t move. Nobody is going to update 1998’s Zelda.

And the legal side was settled thirty years ago. Sega v. Accolade and Sony v. Connectix drew the outline. The ports require you to supply your own ROM.

A modern console is a PC

The second half of the explosion, the PS4, PS5, Xbox One and Switch ports, has another explanation: those consoles are PCs or phones in a different case. The PS4 uses an AMD Jaguar x86-64, the PS5 a Zen 2, the Xbox Series another Zen 2, the Switch an NVIDIA Tegra X1 ARM chip. Your PC’s processor runs that code natively. So nobody needs to emulate the CPU.

The remaining work is translating the operating system and the GPU. shadPS4 reimplements the PS4’s system libraries and recompiles the shaders: games ship from the factory with AMD GPU machine code, which the emulator decodes instruction by instruction and converts to SPIR-V, Vulkan’s format.

Azimuth, which makes Forza Horizon 2 run on Windows, translates Xbox WinRT calls to Win32 and DirectX 11.X to desktop DirectX 12, with the game’s x86 code running directly. AnyPS5 relinks the executable: it takes the PS5 binary and produces a native Linux or Windows binary, linked against reimplemented system libraries. In all three cases, Proton, DXVK, VKD3D and MoltenVK had solved the graphics translation layer years earlier.

The reverse proof is the consoles that weren’t PCs. The PS3 uses the Cell, a PowerPC with seven active coprocessors (the SPEs), each with its own local memory and no cache, and RPCS3 has been at it since 2011, with SPU emulation still the bottleneck today. The Xbox 360 is PowerPC too, which is why Sonic Unleashed needed XenonRecomp to translate PowerPC into C++. Reverse engineering is case by case, and the architecture decides whether the case is easy.

AI is in the loop, and there’s already a fight

That the 2026 ports use AI, many of them say outright. The Silent Hill decomp writes in its README that development is “heavily AI-assisted (Claude Opus 4.6, 4.7 and the newer Fable model), and we’re open about that. It is not automated translation of the game”. The Pokémon Stadium recomp lists Claude as a contributor.

The devs of the Zelda and Banjo recomps, who spent years doing this by hand, went to war with what they call “slopcomps”, agent-generated ports of alpha quality.

And it’s worth separating headline from actual state here too. AnyPS5 has a 0.1 version from September that, according to those who tested it, runs one 2D indie game; the viral claim that “the PS5 is 80% ported to PC” comes from fans, and no 3D game runs. Astro Bot runs, but in emulators (KytyPS5, SharpEmu), which take the traditional path. Forza Horizon 2 runs, and Azimuth is a closed binary from a studio that declares itself “AI assisted” without saying anything more.

“But in two years tokens will cost nothing”

The standard answer to all of this is: it’s hard today, in two years it’s trivial, because AI grows exponentially. The numbers say otherwise.

The price of the most expensive tier barely fell. GPT-4 in March 2023 cost US$ 30 and 60 per million input and output tokens; Claude 3 Opus in 2024, 15 and 75; today’s frontier models, Fable 5.1 and GPT-6 Astra, cost 10 and 50. In three and a half years, the frontier got between 1.2 and 3 times cheaper, depending on which end you look at.

What really fell was the cost of a fixed quality: Epoch AI measured drops of 9 to 900 times per year depending on the task, and in a 2026 review sums it up as “very roughly 5 to 10 times per year”, with the caveat that it might slow down. That’s real and it’s great.

But apply the math to Bun. US$ 165K divided by 10 is US$ 16K. By 100, US$ 1,650. That’s to port a runtime with the source, the tests and the author in hand.

For an amateur trying to clone Photoshop with none of that, the bill starts orders of magnitude higher and falls in the same proportion. Cheap isn’t the same as trivial.

And the “exponential” premise died in 2024. Ilya Sutskever said at NeurIPS that pre-training as we know it will end, because there’s only one internet. Epoch projects that reasoning model scaling converges to the general frontier rate in about a year.

I’ve written about this three times in recent weeks: the limits of what the model reproduces, the convergence of raw models with the gains coming from the harness, and the languages benchmark where the frontier models tied at the ceiling. The tool we have is the tool we’ll have for a good while, with incremental improvement. Plan with it.

Worth recalling the number that opens the limits post: per the Octoverse 2025, GitHub’s official report, 81.5% of contributions on the platform happened in private repositories. That’s the code that really matters, the code that pays salaries, and no LLM has seen a line of it. The model reproduces what was in the training data, and that code was never there.

Now extend that to every SaaS product and every component it uses. The Adobe code that’s actually worth something, the color engine, the profiles, the cloud filters, isn’t available anywhere, not even as a binary. Anyone who wants to reproduce it will have to redo the research and development, expensive and slow, over the same years Adobe took. And at the end they still run into third-party licensed intellectual property, Pantone, camera SDKs, manufacturer profiles, that you will never be able to have.

Answering the list from the top

Does PhotoCraft exist? It does, it’s a two-week-old alpha with more than 800 open issues, rudimentary color management, freezing above 8K and opening PSDs wrong. It looks like Photoshop in a screenshot. It can improve a lot, and it will discover that the target moves and that Photoshop’s expensive parts live in the cloud or in manufacturer contracts.

Does REA exist? It does, it’s good, and it’s a toolbox for people who already know how to use Ghidra, requiring the binary in hand, the tools installed and hundreds of thousands of tokens per analysis. The project itself avoids saying it clones programs.

Did recomps and decomps accelerate? Yes, for real, and AI has a part in it. They accelerated where the binary exists, is small, has been documented for 25 years and doesn’t move. Or where the console is a PC in disguise and the work is API translation, solved by Wine and Vulkan years earlier.

Is Adobe dead? Adobe has around 40 million subscribers by the most cited estimate, the features that sell subscriptions run on its servers, and thirty years of GIMP still leave the print shop asking for Photoshop. I wish it were otherwise. The data says what will happen is what always happened with clones of a live product: years of chasing, and when you catch up, the value has already moved.

Are programmers dead? Rewriting Bun required Bun’s author. The decomps that work have people who know the hardware driving the agent, and the ones that don’t became “slopcomps”, name and all. Reverse engineering got cheaper and more accessible, as it did with Ghidra in 2019, and it’s still an engineer’s job. Without us, the tool returns a pretty screenshot.

Proprietary software with a binary in hand will come under pressure, and it should. Most of the software you use has no binary at all, and the software that does already depends on cloud services that don’t disassemble. Software engineering with AI has a great road ahead. “It’s over” headlines get clicks and don’t compile.

It’s better to deploy faster, because fixing things afterward became fast and cheap.

That sentence is the whole article. Everything else is just me justifying why it’s true now, even though it wasn’t true a few years ago, and showing how I’ve been acting on it myself since February.

The Premise Changed, and Most People Haven’t Noticed

I started saying this on X like this:

Fixing got cheap. Stop holding things back. Just ship it and fix it after. “Ugh, but I risk shipping a bug.” The wrong premise is thinking that staring at every line is going to make any difference at scale. And idle code doesn’t improve on its own. Only used code lets you find out if it needs improving.

And I followed up in the second post, because the first read of anything I write in 280 characters always comes back angrier and more literal than intended:

Get the concept (this is an X post, not a blog post, stop reading it literally). I’m not saying AI doesn’t produce bugs. It does, obviously. But at this point, not more than you, the human, also produce. […] The old excuse was that when a bug ships to production, it sits there longer than it should, because it never becomes a sprint priority to fix. Now THAT’S NOT TRUE ANYMORE, the premise changed: fixing the bug afterward is FAST and CHEAP.

That’s the entire point. It isn’t about AI being infallible. It’s about the cost of fixing a mistake having collapsed, while most teams still run their review process as if that cost were still high.

With today’s frontier models, Opus, Sol, K3, and company, the LLM makes fewer mistakes than most human developers I’ve seen go through a code review. When it does err, the overwhelming majority of the time the mistake isn’t the model’s. It’s whoever was driving the harness. The LLM does what you ask, and it doesn’t do what you didn’t ask.

If you don’t know what to ask for, you won’t produce anything useful, no matter how good the model is. That’s exactly why only a real software engineer can get real production-grade software out of an agent: someone has to know how to break down the problem, validate the result, and recognize when the request itself was poorly framed. AI doesn’t replace that judgment. It multiplies what that judgment already knew how to do.

This Should Have Been the Norm for 25 Years

The discomfort I feel with bureaucratic review processes isn’t new, and the industry should have solved it a long time ago. Kent Beck and Ron Jeffries invented Extreme Programming in 1997, on Chrysler’s C3 project, and Beck published the book in 1999 with continuous integration, TDD, and small-batch delivery as core practices. In February 2001, seventeen developers locked themselves in a resort in Snowbird, Utah, and walked out with the Agile Manifesto. That’s twenty-five years ago.

Martin Fowler’s mantra for continuous integration has always been “if it hurts, do it more often,” and the book Continuous Delivery, by Jez Humble and Dave Farley, formalized the idea that small, frequent deploys reduce risk, not increase it. DORA’s annual State of DevOps reports have documented this with numbers for over a decade:

• elite teams: deploy on demand, multiple times a day;
• low-performing teams: deploy once a month, sometimes once every six months.

And the finding that’s hardest to swallow if you’re afraid of deploying fast: historically, more frequent deploys do not increase the failure rate. They reduce it. Teams that deploy more, on average across the last decade of reports, fail less and recover faster when they do fail.

Even with all of this documented, measured, and published for over a decade, a large chunk of the industry keeps damming up change into big batches, with slow manual review, and calling that “prudence.” It was never a settled matter even inside the agile community itself: in 2014, Kent Beck, Martin Fowler, and DHH (Rails’ creator) spent weeks publicly debating whether TDD was dead, without reaching a clean consensus. In other words, the very community that invented these practices still argues today about how much rigor is enough.

What I’m saying is simpler than that whole debate: whatever your testing rigor level is, an LLM reviewing your diff before merge is fast, and reverting a bad deploy became trivial with containers and git. The math that’s left is: how much time do you spend holding back code, versus how much time it would take to revert if it went wrong? If the second number is smaller, you’re paying a toll for fear, not for prudence.

This Isn’t “Ship Anything”

This is the part that always gets lost: I’m not saying to deploy with zero engineering practice underneath. I’m saying the opposite. This is only safe after you already have basic software engineering working, which I document exhaustively on this blog for years: automated tests, CI running on every push, real revert capability, observability to know when something broke.

80/20. Ask the LLM to do a minimal review and ship it. If it breaks, revert (that’s what containers, git, etc. are for). If you can’t revert, your infra sucks, go fix it yesterday.

That last sentence is the whole filter. If your infrastructure doesn’t let you revert fast, the problem isn’t deploy speed. It’s your infrastructure, and it needs fixing before any conversation about going faster. Nobody gets a pass to skip having real rollback capability. What changes is that, once you have it, holding back code waiting on human review became pure waste.

The Minimum Recommended Environment

I’ve already said “basic software engineering” several times in this piece without spelling out what that means in practice. Here’s the list, no hedging. Nothing on it is optional, and none of it got expensive to maintain:

• unit tests covering isolated logic, TDD or not, as long as they exist;
• scenario and integration tests covering concurrency, partial failure, and conflict, the things unit tests alone don’t catch;
• CI that builds and tests on every change, ideally for every platform you actually ship to;
• hostile automated review before merge, like pr-audit, which treats a contributor’s claim as unverified until proven;
• feature flags to control the blast radius of who sees a change first;
• real staging as a gate before any real user sees the change;
• fast revert capability, with git and containers, and observability to know when something broke;
• in compliance, financial, or health environments, one extra layer: heavier scenario testing, and more than one lock per identified failure mode.

What the diagram tries to make clear is that speed and safety aren’t competing with each other here. They come from the same stack of layers, and each layer in that stack is what gives you permission to stop holding back code waiting for manual review.

Where This Math Doesn’t Work Out

I’m not going to pretend I didn’t get good pushback in the replies on X, because several of them hit on something real that I skipped while writing fast for Twitter. It’s worth answering for real instead of just validating whoever agreed.

1. Reverting code doesn’t undo a consequence that already left your system. If the bug already processed a wrong payment, moved money to the wrong account, or controlled an elevator, reverting the deploy doesn’t undo what already happened. “If you can’t revert, your infra sucks” covers the technical side of deploy and rollback, not the case where the damage already left your system before you could react. Payments, health, and anything touching physical safety fall into this category, and there the review bar before shipping has to get stricter, not looser, because the cost of reverting stopped being technical.

2. Databases break the “reverting is easy” analogy. Reverting a binary is trivial. Reverting a migration that already ran in production, already moved data, and maybe already dropped a column, is not. There’s a pattern for this, expand-contract: add the new shape without removing the old one, wait for every consumer to migrate, only then remove the old one. This isn’t about trusting AI more or less. It’s about state that doesn’t undo with git revert.

3. Libraries and public packages don’t run on the same math as a closed application. When my own code breaks, I fix it on the spot. When a lib that hundreds of projects depend on breaks, the people who eat the cost are people who don’t even know I exist, with a much slower reaction time than mine. That’s why my pr-audit skill, which I describe further below, treats semver classification as a version gate: a breaking change ships in a major, never in a patch, because there the real review isn’t about catching a bug, it’s about not blindsiding whoever depends on you without warning.

4. App stores knock the speed down too, and my own frank_yomik example hides that instead of solving it. It publishes the APK straight as a GitHub Release, without going through the Play Store. If you distribute through Google’s or Apple’s official store, their review sits in the middle of your process, and you don’t control how long it takes. This article is about removing the bottleneck that’s inside your own control. The app store isn’t inside it.

5. The most honest point of all: every piece of evidence I bring here comes from projects where I’m the sole owner and I decide alone. I have no way to prove, with my own numbers, that the same pace works inside a large company, with Legal, Compliance, and a product manager in the middle. What I’d argue generalizes is the principle, not the exact pace: build real revert capability, automate the mechanical checking, and measure the result against real usage, not against your own sense of security. How much speed you apply on top of that depends on how much a mistake costs in your specific context, and nobody from outside answers that for you.

On the first point specifically, it’s worth opening up more, because “stricter bar” can’t stay vague. It means real scenario testing, not just unit tests. ai-memory itself has more than a thousand integration tests spread across its modules, and most of them don’t ask “does this function return the right value?” They ask things like:

• what happens when two writes race for the same file at the same time;
• what happens when the disk fails mid-way through a delete operation;
• what happens when two sessions try to consolidate the same data at the same time;
• what happens when the process dies before it finishes writing.

An environment with compliance, financial, or health requirements needs this level of testing: every identified failure mode has to have a mitigation, and more than one layer of checking, never a single lock.

And here’s the point that holds up this article’s entire argument even in those environments: this bar doesn’t change depending on who wrote the code. A human developer’s mistake takes down a payment system just as well as an LLM’s mistake does, and nobody gets a free pass for loose review just because a senior human wrote the line. The bar of scenario testing and double-layer protection is about the problem domain, not about who, or what, produced the code.

Feature flags and staging environments are the other half of that double layer, and they also changed cost. Flags used to be a pain to maintain: dozens of them, each one needing to be born, monitored, and removed once it stops making sense, and it’s easy to pile up dead flags nobody remembers the purpose of. That got cheap too: I ask the agent to audit every flag in the project, find which ones have been stuck at the same value for months, and generate the cleanup PR. Maintenance that used to take a whole afternoon turns into a task that takes minutes.

With that solved, the layered defense becomes simple to assemble: staging to catch obvious errors before any user sees them, feature flags to limit the blast radius of who sees the change first, and scenario tests to cover what staging alone doesn’t simulate. Three layers, none of them expensive to maintain.

How I’ve Been Doing This Since February

I started accelerating my output with AI in February this year, and the question I wanted to answer was simple: can you use the new generation of frontier LLMs to code full-time, at real production pace, not just for a demo? The answer turned into my biggest LLM benchmark, more than 110 articles published since then, and this, as I wrote recently:

Since February I’ve produced more than 110 articles on my blog. Most of it came from the 30+ open source projects I built and maintain (43 if you count other people’s contributing projects, like Flea or Omarchy). 1.6 million lines of code produced. By myself (with agents, of course).

The projects I use the most in my own day to day, and that survived the “am I still maintaining this months later” test, are three:

• ai-jail: an OS sandbox for my coding agents;
• ai-memory: long-term memory for the agents;
• ai-usagebar: a bar widget to monitor LLM usage.

Two of them already have a decent landing page:

ai-jail went live today. ai-memory is up at aimemorybr.netlify.app because the aimemory.io domain transfer will still take a few more days.

Both run on Netlify. That’s not a tool recommendation, it’s just where I already had an account set up. The point that matters here isn’t the platform, it’s the flow: to put a new version live, the command is git push. There’s no manual step between the commit and the updated site.

My newsletter, The M.Akita Chronicles, already has more than 15,000 subscribers:

And the newest effort is converting blog posts into podcast episodes. The whole thing runs inside Discord, with a bot that generates the preview and waits for my command:

One /publish-podcast 2 later, the episode is published and the transcript already has a URL:

From finished text to published audio, the entire process is me typing a slash command in a Discord conversation. That’s the effort bar I use to measure whether a process is good enough: if publishing takes more than one command, some step is still too manual.

Does the Quality of the Generated Code Hold Up?

Every single day someone shows up worried that automating too much with LLMs is going to dump bad code, or worse, dangerous code, into production without anyone noticing. Given that the engineering underneath is the one I described in the previous section, automated tests, CI, feature flags, staging, fast rollback, my actual experience doesn’t back up that fear.

I’ve produced more than 1.6 million lines of code with LLMs since February. I have never once seen an LLM do something randomly destructive that I didn’t ask for. Quite the opposite: in my LLM Benchmark v4, I deliberately built an adversarial scenario, a subagent planting fourteen real CVE-based sabotage items, hidden inside a project that grows across seven sprints. Most of the tested models found and fixed the sabotage on their own, without me having to point it out.

That’s anecdotal. It doesn’t prove anything beyond what that specific benchmark measures. But after all that volume, the impression that sticks is consistent: today’s LLMs produce stable code most of the time, comparable to what a decent human developer would produce, just a lot faster, and on average, more accurate.

Cross-Platform CI/CD With Zero Effort

I went and counted how many of my ai-* and frank-* projects (18 repositories total, among the ones with a README) already have automated build and deploy. Fourteen have CI configured, and most of them build and publish to multiple operating system platforms from a push made on a Linux machine.

The most complete example is ai-memory itself: a single tag push triggers a workflow that, in the same run:

• builds Linux x86_64 and arm64;
• builds macOS arm64 and x86_64;
• builds Windows x86_64, packaged with PowerShell;
• publishes a multi-architecture Docker image;
• pushes the package to Arch Linux’s AUR.

ai-usagebar follows the same build pattern for Linux and Windows, and also publishes two AUR packages, to crates.io, and to a Scoop bucket for Windows.

Then there’s frank_yomik, my manga reader with OCR and translation via a local LLM, which is the example I wanted to show that Android fits into the same pipeline. A v* tag push triggers five parallel builds:

• Linux;
• macOS;
• Windows;
• browser extension;
• Android, on an ordinary Linux runner, decoding a signing keystore stored in GitHub secrets and producing the already-signed APK.

At the end, one job waits for all five to finish and publishes a single GitHub Release with every binary together. It builds for four different systems, including Android, without ever leaving Linux.

Not everything came out perfect on first look, and I’d rather admit that than pretend it’s all clean: frank_sherlock and frank_karaoke publish the release as a draft by default, which blocks the automation that follows (like the AUR push) until someone clicks “publish” by hand. I found this hole while writing this piece.

A neighboring project, frank_scanlation, had already solved a similar but different problem: GitHub suppresses the event that triggers automation when the release itself was created by the bot’s own token, so its workflow triggers the next step by hand, via workflow_dispatch, from inside the job itself. Neither fix is hard. I’ll apply both to the projects that still need it this week, because that’s exactly the kind of accumulated friction this whole article is telling you not to leave sitting.

And speaking of hidden friction: ai-memory has Windows-specific code (NTFS file index, a native PowerShell hook) that only really runs on GitHub’s windows-latest runner, about 1000 seconds against 250 on Linux for the same suite. I went as far as setting up a local Windows VM via dockur/windows, thinking I’d gain speed.

I didn’t: the workload is dominated by disk I/O, and the result came out slower than GitHub’s runner for the full suite. It only turned out useful for fast iteration on a single isolated crate. A good tool is one you measure, not one you assume, even when the measurement contradicts your initial bet.

The Automated Review That Holds All of This Up

I already detailed my review skills in a recent article, so I’ll summarize here:

• pr-audit audits every PR before merge with the principle of evidence over narrative: nothing the contributor wrote is true until proven, with a hostile checklist for malicious code, exposed credentials, semver breaks, and prompt injection attempts;
• iss-audit applies the same distrust to issues, never executing a command pasted by whoever reported it;
• github-resolution turns what got approved into merged code, one ticket at a time, with a regression test written before the fix, and the rule that “slop is a defect”: no speculative abstraction, no forgotten TODO, no weakening a test just to pass faster.

That catches the most expensive category of garbage inside the same diff. It doesn’t catch duplication spread across different PRs, because the audit looks at one isolated diff, not the whole project’s architecture. That part still depends on me noticing the pattern repeating and telling it to consolidate.

By my estimate, this handles about 99% of review and resolution work on its own, with me supervising and deciding on the cases that are left. But that’s not the main point. Automated review is necessary, but it alone proves nothing about whether the software is good.

What Actually Keeps This Grounded: Real People Using It

Here’s the part I think is the most important in the whole article, and the one that usually gets skipped over: your own review isn’t worth as much as you think. What’s worth something is published software being used by real people, giving real feedback.

I went and checked ai-memory’s real numbers on GitHub, without rounding up to sound impressive:

• issues: 287 total, 249 came from people who aren’t me, 86.8% of the total;
• pull requests: 562 total, 371 from outside, 10 of them Dependabot’s automatic bumps and the other 361 from real people, roughly 121 distinct contributors.

The two people who contributed the most alongside me sent 64 and 43 PRs each, on their own.

That’s what keeps the project grounded. It isn’t the LLM being a good reviewer, nor me being a good reviewer. It’s hundreds of real people actually using it, finding cases I never imagined, and sending real issues and PRs. Without that, my automated review skills would just be confirming my own assumptions back to me, no matter how rigorous the rules look on paper.

It doesn’t matter how good the AI you use is: if nobody uses what you published, you have no real feedback, and without real feedback there’s no real improvement. There’s only your own opinion about your own work, validated by nobody but yourself.

The Conclusion That Matters

Real software engineering needs fast, near-zero-effort deploy. It isn’t optional, it isn’t a luxury for a big team, it’s a prerequisite. And if reviewing and shipping to production is taking longer than it took to develop the feature, you’re not just wrong.

You are the bottleneck.

Excuses and justifications aren’t worth anything at that point. Use that time to fix yourself and your process, because only real-world results matter, not the sense of security from having reviewed a diff line by line that nobody else is ever going to look at again.

If the premise changed, I change today. Not tomorrow, not next week. And if yours hasn’t changed yet, the problem isn’t AI. It’s you holding back your own work.

I posted this tweet this morning and it struck a nerve. The full point: when the technology itself becomes a commodity, the money migrates to taxonomy. They invent five new names for chaining API calls and suddenly there’s a certification that expires in six months.

Let me back up the provocation properly, because it’s not a gratuitous jab.

Let me preempt the standard comment: “but it works for me.” Good for you — honestly. Except “it works for me” never proved the ceremony is what made it work. What made it work is you knowing what you wanted. The ceremony just happened to be in the room.

My receipt

Between January and May I ran an AI marathon and published over 30 public repositories. There are tools I use every day — ai-memory, ai-usagebar, ai-jail — and personal apps built to scratch my own itch: Frank Manga+, Frank Scanlation, Frank Geary, and so on.

You know what I never once felt the urge to do in all that time? Complicate my AI setup. I don’t have a super-customized Pi, no Hermes, no orchestrated agent graph, no numbered-spec pipeline. Thanks to ai-memory, I swap harnesses like I swap underwear: daily, no drama. Claude Code in the morning, Codex in the afternoon, Kimi CLI at night — the project memory travels with me, so the harness becomes a detail.

And detail is the point. Most harnesses are optimized for their own company’s LLM. But “optimized” doesn’t mean “magic,” and I have data on that.

What my benchmark says about harnesses

In my LLM Coding Benchmark I run the same models through different harnesses under controlled conditions. The result is the opposite of what the course market implies:

• For a weak model, the harness rescues. Grok 4.3 built nothing on bare opencode (18 points) and delivered a real app on the grok CLI (55). Gemini 3.1 Pro went from 62 to 88 on Google’s own harness — but the problem there was an OpenRouter transport bug, not a lack of “harness engineering.”
• For a frontier model, the harness is noise. Grok 4.5: 92 on opencode, 91 on the grok CLI. Grok 4.6: 92 and 93. A one-point difference, inside the margin of error. No amount of harness engineering moves a good model.
• Where the harness actually bites is your wallet. The Grok 4.6 run cost $1.19 on the grok CLI versus $6.33 on opencode via OpenRouter — over 5x cheaper for the same ~11 million tokens, because the official CLI uses xAI’s native prompt caching. Same story on Codex: GPT 5.6 Terra cost $6.77 blended because 21 of its 21.7 million tokens were cache hits; Sol, same family, same score, cost about $45.

So yes, picking a decent harness matters — for cost, and to give structure to a weak model. But that’s an afternoon of reading docs and watching your token bill, not a new discipline with a learning track.

Since I mentioned Hermes up there, it’s worth explaining: Hermes Agent is an open-source framework from Nous Research for building your own personal agent — you define the tools, write the loops, configure per-model routing, local/cloud fallback, Telegram and Discord gateways, and it even “learns skills” from use. It’s paradise for the setup crowd.

It’s also a second job: every one of those pieces becomes yours to maintain, update, and debug, forever. And at the end of the day the engine is still the same Claude, GPT, or Qwen everyone else has — the custom chassis doesn’t improve the engine. What Hermes actually solves, context continuity across sessions and tools, a decent harness with something like ai-memory already covers — without you becoming the infrastructure administrator of your own assistant.

If you want an assistant on your own hardware as a hobby or for privacy, that’s a great reason, go for it. As a productivity prerequisite, it’s not one.

Remember this: a good harness is one that charges less and stays out of the way. The rest is the model. And a good model doesn’t need “harness engineering” — at most it needs the transport not to be broken.

Loop Engineering, Graph Engineering, Spec-Driven Development

On to the names, because they describe real things — just tiny ones.

Loop Engineering is this season’s name for designing the cycle an agent repeats: execute, verify against evidence, iterate until a stop condition. The guides list real failure modes — the agent declaring “done” too early, the goal drifting on each pass. But the recommended mitigation is “an independent verifier checking objective evidence.” That’s had a name for fifty years: tests and code review. An agent in a loop with a test suite is the same old basics with a new name.

Graph Engineering is drawing the agent’s workflow as an explicit graph of nodes, branches, and joins — LangChain has three years of that story. It makes sense when the flow is genuinely branched. Except the overwhelming majority of projects is a straight line with an if in the middle. Modeling that as a graph is buying a giant whiteboard to draw one arrow.

Spec-Driven Development is writing a detailed specification first and treating the code as an artifact generated from it — the spec becomes the “source of truth” and the code, a byproduct. Hold that thought, the strong argument is coming right up.

Notice the pattern: each name takes a real, small practice — looping with verification, drawing a flow, writing down what you want before building — and inflates it into a “discipline.” The inflation is the product. A new name creates a course, the course creates a certification, the certification expires in six months and sells you the recertification.

To be fair: the serious guides on these topics already carry the caveat — the most-read graph engineering guide says outright that “you probably don’t need it” and tells you to master the loop before opening a graph, and LangChain has a whole “when not to use graphs” section. The guides are right; the damage comes from the funnel, which throws away the caveat and sells the rest as everyone’s default.

The two that sell the most courses — heavy agent orchestration and spec-driven development — deserve more than definitions. They deserve the argument.

The strong argument against super-orchestration

There’s simple math that orchestrated-agent diagrams never show. If each step of your pipeline succeeds 90% of the time — and that’s optimistic — a ten-agent chain succeeds 0.9^10, or ~35% of the time. Every node is a new failure point, and every edge is tokens spent on agents talking to agents instead of working.

You don’t have to take the math on faith: I accidentally measured it in the benchmark. MiniMax M3 running under an orchestrator looked like Tier D, with 24 points. The same model, clean, scored 91 — Tier A. A swing of up to 69 points between harness conditions means the opposite of what the orchestration vendor claims: when the plumbing dominates the result, you stopped measuring the model and started measuring the plumbing. The best result in the entire benchmark didn’t come from any orchestrated swarm: it came from one strong model, alone, in a simple loop — Fable 5, 96 points, Claude Code, done.

It makes sense once you remember coordination scales badly. Each additional agent doesn’t just add capacity; it adds edges, message contracts, shared state, and conflicting versions of the truth. The router deciding “which agent handles this” becomes both the bottleneck and the bug farm. A committee of mediocre agents with a conductor doesn’t beat one capable agent with good tools and memory.

I’ve tested this directly. Back in April I ran three rounds of “strong model orchestrating cheaper models” — planner + executor, forced delegation, the full package. The result: no multi-agent combination beat the Opus running solo in a mature harness. On a cohesive task like building an app, the planner has to read every output from the executor before dispatching the next step — the two become sequential, with tripled latency and a coordination queue in the middle. It’s the committee again: lots of talking, little software.

It’s not just my benchmark. Cognition, which sells Devin, published “Don’t Build Multi-Agents” with a mechanism sharper than my 90% math: every action carries implicit decisions the other agents can’t see — one subagent draws a Mario-style background, another draws an incompatible bird, and no amount of individual reliability fixes the divergence.

Anthropic itself, which runs a multi-agent research system, admits in its engineering post that multi-agent burns 15x more tokens, that coding is a poor fit for it — most coding tasks aren’t truly parallelizable — and that 80% of their improvement came from simply spending more tokens, not from the architecture.

When Berkeley measured what actually runs in production, 86 systems across 26 domains: 68% of production agents execute at most 10 steps before human intervention. What’s really out there is the simple supervised loop — not the constellation of colored nodes on the consultant’s diagram.

Where orchestration is legitimate: genuinely parallel, independent work — scanning ten thousand files, running ten thousand disposable analyses. Map-reduce has existed for twenty years and never needed a pompous name. And there’s one serious corner beyond it: agents running overnight, unwatched, holding credentials — there, independent verifiers and hard budgets become a security matter, not a style one. But that’s fleet operations, not the day-to-day coding the course is selling you. Outside those niches, most “multi-agent architectures” are one agent’s job with extra YAML.

There’s a reason you hear so much about it: orchestration is visible complexity. It has diagrams, colored nodes, dashboards. A well-driven agent has none of that — no slide deck, no certification, nothing to sell.

Remember this: every added agent multiplies the failure modes. If your system’s result changes when you swap the orchestrator, your system is the orchestrator — and the model was the costume.

The strong argument against spec-driven development

SDD sounds mature because it sounds like “writing documentation.” But look at what it actually proposes: the spec becomes the source of truth and the code becomes a generated artifact. The problem is that a spec precise enough to generate correct code already is a program — except written in prose, and prose doesn’t compile. Every ambiguity in the spec is a bug no compiler catches, in a medium with no tests, no linter, no feedback. SDD doesn’t remove the hard part, which is thinking precisely; it moves the hard part into a format where errors don’t scream.

Remember this: a spec precise enough to generate correct code already is a program — except in prose. And prose doesn’t compile.

Even if you write the perfect spec, it starts dying with the first hotfix. A bug shows up in production, someone fixes it straight in the code, and the spec becomes a lie. We’ve known this law for decades — it’s why documentation rots. Calling the spec the “source of truth” doesn’t change anyone’s incentives.

We’ve run this experiment before, by the way. UML, MDA, “the code generates itself from the model” — twenty-odd years ago it was the same promise with different acronyms. It collapsed every time for the same reason: the model was never the reality; the code was. SDD is MDA with an LLM bolted on. And I’m not the only one seeing Waterfall 2.0 there.

The people who tested the tools seriously landed in the same place. Thoughtworks put spec-driven development in the “Assess” ring of its Technology Radar — not “adopt”, “assess” — after watching the tools inflate small tasks into ceremony, and nailed the summary: we may be “relearning a bitter lesson — that handcrafting detailed rules for AI ultimately doesn’t scale.” That’s Rich Sutton’s Bitter Lesson knocking again — handcrafted structure loses to scale, it always has.

There’s also the temporal inversion. The great lesson of agile was that you discover what you want by building — working software over comprehensive documentation. LLMs just made iteration cheaper than it’s ever been. And what does SDD propose? Expanding the planning phase, right now that iterating got cheap. Wrong answer, wrong direction, wrong time.

It’s the thesis I’ve been hammering since the first Agile Vibe Coding posts: software emerges, it isn’t planned. I wrote this back in February, with receipts: the most important features of the M.Akita Chronicles were born from problems that showed up mid-way — a job that failed silently, a site that blocked the gem, a crash that left emails in limbo. No spec in the world predicts that. The correct system emerges from iteration, not from specification.

The process got documented again when ai-memory grew through 26 contributors in 24 days: good software is a clay sculpture, not a Lego tower — malleable, always adjustable, never done. Whoever tries to design the whole architecture before the first line builds a straitjacket, not a system. Only amateurs still believe you can spec out an entire piece of software before coding it. Real modeling doesn’t come from templates or courses — I covered this years ago in Akitando 144 (video in Portuguese): it’s born from a repertoire of real problems and real code. There’s no ready-made recipe; there never was.

SDD tries to resurrect the idea that you can plan software ahead of time — the idea the industry buried after decades of projects delivered late, wrong, and over budget. LLMs didn’t revalidate that idea; they just gave it a new slide deck.

Even the pro-SDD guides separate the two things: “spec-as-source is where the hype lives; spec-anchored is where the value is today”. My target here is the former. Where heavy specs are legitimate: large teams, legacy codebases, asynchronous work crossing time zones and sprints — the good old design document, which has always existed and always had value. What doesn’t fly is selling that as the new default for everyone.

My benchmark prompt, for the record, is one page of goals. The difference is that I don’t trust the prose: I validate by running it. Precision lives in tests, not in paragraphs.

What you actually need

I’ve already written all of this on this blog, with real-project receipts. It’s called Agile Vibe Coding, and it fits in a paragraph:

It’s XP (eXtreme Programming, the original agile) with an LLM: tests, Clean Code, CI (continuous integration), pair programming, and deploy. You drive the agent like you’d drive a very fast pairing partner: say what you want, watch the execution, correct while mistakes are still cheap. The idea is 10% of the work; the other 90% is normal software engineering, the usual kind. Forget frameworks and three-page templates: what you need is to know what you want, know what you don’t want, and know how to validate when it arrives. And you need balance: neither handing the wheel to the agent nor turning into a comma cop.

That’s over 600 hours of it, over half a million lines, dozens of projects shipped. No graphs, no certifications, no loop with an English name.

Remember this: the idea is 10% of the work; the other 90% is plain software engineering, the usual kind.

The piece that lets me swap harnesses: ai-memory

One of my own tools is the opposite of taxonomy: ai-memory. It was born from a concrete problem. Every harness stores its session in its own format, and when the conversation gets long, it compacts the history to fit the window — and compaction throws away exactly the details that explain why each decision was made. Then you switch tools and start from zero, with the whole project to re-explain.

ai-memory solves this from outside the harness. It reads the native session without touching the original file and stores everything in a searchable ledger: messages, tool calls with results, compaction summaries, a git checkpoint — every event tagged with its origin (from Claude, Codex, OpenCode). When I open another harness, it gets its own native session and receives only the delta it hasn’t seen. When I go back to the previous one, ai-memory resumes it in that client’s format and hands over what happened on the others meanwhile.

That’s why “I swap harnesses like I swap underwear” isn’t a figure of speech. The project’s knowledge lives in the project, not in one tool’s session. If Anthropic changes pricing, limits, or models tomorrow — and they will — I swap the engine without throwing away the trip. The details of how this works are in this post.

There’s an inversion here that takes SDD down as a bonus. Spec-driven development says the source of truth is a document written before the work, trying to predict the future, and that the code owes it obedience. ai-memory does the opposite: the source of truth is a wiki distilled from the work itself — every session becomes evidence, and what deserves to survive (decisions, rules, gotchas, failed attempts) gets consolidated into short Markdown pages that any agent reads before starting.

The spec tries to guess the project; the wiki records the project. A document written beforehand rots at the first hotfix, because nobody is forced to update it. The wiki is fed by the very act of working — and when it goes stale, you notice immediately, because the agents trip over it every session.

Notice that this is real harness engineering: one tool, written once, solving a problem of mine. No course, no acronym, no certification.

Conclusion: ask for the receipt

Don’t waste time or money on a “harness engineering” course, “loop engineering,” or whatever taxonomy is trending this week. It’s a shameless attempt to charge you for things you already do if you know basic software engineering.

We’ve seen this movie before, by the way. Pedro Arantes nailed it on X: “Microservices, clean architecture, hexagonal, and Domain-Driven Design are all bullshit to sell more consulting hours and courses.” Same story, same script. Each of them was born from a real problem — and became the default for people who didn’t have the problem. Microservices for a three-person team, hexagonal architecture for a CRUD (the plain old create-read-update-delete app), DDD to never write code again. The technique passes, the taxonomy stays, the course sells.

So nobody plays dumb: none of this is useless. A loop with verification works. A graph works when the flow is genuinely a graph. Heavy specs save large teams. Microservices solved real problems for people with real scale; DDD shines in genuinely complex domains. The problem was never the tool — it’s selling the tool as a silver bullet, the universal hammer you must apply to everything. Silver bullets don’t exist, they never have. Whoever sells you one isn’t selling a solution; they’re selling a course.

Understand the psychological mechanism, because it’s old and efficient: those terms exist to give you FOMO (Fear of Missing Out). To make you anxious, thinking you’re falling behind, that you’re leaving productivity on the table, that everyone else already migrated to the new paradigm and you haven’t. Anxiety sells. Once you’re insecure, they charge you to implement something you never needed. FOMO is real — and here, it’s the business model.

The model is recurring, too — admire the elegance. First they sell you the methodology that generates artifacts — specs, graphs, boards, diagrams. The artifacts multiply, nobody knows where anything is anymore, and guess who shows up? The same consultancy, now selling the tool that manages the artifacts, the course that teaches you to manage the tool, and the artifact-governance workshop. It’s the shovel salesman congratulating you on the hole you dug — and offering you a bigger shovel.

Gartner even has an official name for it: “agent washing” — take an existing product, slap the “agentic” label on it, resell. Their estimate: only about 130 of the thousands of companies selling themselves as “agentic AI” are real, and their prediction is that 40% of such projects get canceled by the end of 2027, over cost, unclear value, or badly managed risk. No grudge of mine here: it’s the hype cycle, measured, with a public forecast and everything.

Next time an influencer or consultant tries to push those products on you, ask a simple question: where are your dozens of high-quality open-source projects that got better because of those “techniques”?

They have nothing to show. I do — it’s all public, with code, benchmarks, and documented process. When technology becomes a commodity, money migrates to taxonomy. Don’t be a customer of that migration.

The pattern repeats in all of them: I run into a small friction in daily life, the kind we normally swallow because fixing it would cost an entire weekend, and instead of swallowing it I open an AI agent and fix it. The cost of turning irritation into tooling dropped so much that the math flipped. Today it’s worth fixing almost everything.

Everything below is on my GitHub, with binaries, releases and install instructions.

In this post: clock-tui (with the google-calendar-tui and ghpending widgets), github-visualize, frank_geary, frank_scanlation, frank_lyrics, frank_type, distrobox-gaming and aitrepreneur-docker.

clock-tui: a desk clock that became a panel

The use case is simple: I have a secondary vertical monitor, and I wanted something more useful there than a wallpaper, something I could just glance at and get relevant information. But it all started because I just wanted a desk clock. I found a little old open source terminal clock program, the original clock-tui, which had been paused for ages, and decided to fork it and continue the work: clock-tui.

I made it prettier, modernized the Rust dependencies, and the most important change: I added support for command widgets. The clock sits at the top and below it come panels that run any command that prints text, each with its own refresh. Two widgets I built for it myself:

• google-calendar-tui: a read-only Google Calendar agenda in the terminal, using the accounts already in GNOME Online Accounts (zero OAuth setup). One glance and I know my appointments for the day.
• ghpending: lists open issues and pull requests across all the repositories I care about. Now that I have dozens of open source projects, this is how I notice within seconds when a new PR or issue arrives, without opening GitHub.

And today I spent the day adding theme support, because someone on X commented that the look could be made to resemble Evangelion. Challenge accepted: there’s now an evangelion theme (purple and lavender) and a nerv theme (red, amber and green, inspired by the show’s alert screens), switching at runtime with Shift+T. The theme is injected into the widgets via an environment variable, so the panels follow the palette.

Installing on Arch: yay -S clock-tui-bin. The widgets: yay -S ghpending-bin (there’s also brew install via akitaonrails/tap on macOS) and yay -S google-calendar-tui-bin. All of them have prebuilt binaries on GitHub Releases for those not on Arch.

github-visualize: useless, but pretty

This one was born because of Jarred Sumner’s article about rewriting Bun’s TypeScript in Rust, which I posted about recently. I don’t know which tool he used to illustrate the post, but I really liked the chart animations. Is it useless? It is. But it’s pretty, and pretty is reason enough to make a copy.

github-visualize is a self-hosted dashboard that monitors my GitHub repositories and replays their progress with animated visualizations: a commit timeline with lines added and deleted on a log scale, a commit heat map by day and hour, a CI race to green. Now I can add any repository of mine and get pretty visualizations of productivity, activity, commits and builds. Maybe I’ll use it in presentation slides, or to illustrate future posts here on the blog.

Install: public image on Docker Hub as akitaonrails/github-visualize, single container with SQLite in a volume, no external database or Redis.

Frank Geary: email the way I wanted it

I decided to use GNOME’s Geary as my main email client. It’s the closest to the interface of Apple’s default Mail app: clean, direct, no ceremony. I know, there’s Thunderbird, but I find it bloated and very ugly. There’s Mailspring, which I find bloated and heavy. My email flow is short: sweep the inbox, tag, archive and reply. Nothing else.

Geary is almost perfect, but it had two big problems for me. First: on my vertical monitor there’s much less horizontal space, and Geary has 3 fixed columns. The first column, which only lists accounts and folders/tags, I don’t need to see all the time, but there was no way to collapse it.

Second, and worse: the composer’s recipient field in practice never autocompleted anything (Geary does have the mechanism, but with a contact visibility filter so restrictive it never suggested anyone). I had to type the address by hand or copy and paste from another email. In 2026.

My first solution was two external GTK modules injected into Geary, one for each problem (both obsolete now). They worked, but they required installing Geary compiled from source, and on every yay -Syu there it went recompiling everything again.

I got tired and did what I should have done from the start: I forked Geary and created Frank Geary, which adds both features straight into the code. The sidebar now collapses, and the recipient autocompletes by consulting the contacts from your existing emails. I’ll keep maintaining the fork by rebasing from upstream frequently.

And the best part: there’s now a package on the AUR, so installing goes like this:

yay -S frank-geary-bin    # prebuilt binary (x86_64), from the GitHub release
yay -S frank-geary        # or compiling from source

Both packages replace the system’s geary (they provide/conflict with it), so the swap is clean and updates arrive like any other package. One detail after installing or upgrading: when the watch-for-new-mail option is on, Geary keeps running in the background as a D-Bus service, so run a geary --quit to make sure no old process is left hanging around.

Japanese manga: FrankYomik, FRANK MANGA+ and FRANK Scanlation

Anyone following the blog knows about my love for Japanese manga. I already posted about FrankYomik, which was born so I could read the original Japanese manga I buy from Amazon Japan.

The problem: manga aimed at adult audiences (no, not porn! I’m talking about subjects like business or military topics) doesn’t have “furigana”, the little kana subtitles printed next to difficult kanji, indicating the reading. Shounen manga has furigana on everything, so you can read it with student-level vocabulary. The adult ones assume you already know how to read the rare kanji. I don’t.

FrankYomik solves that by adding furigana on top of the page, in real time: a model detects the speech bubbles, manga-ocr extracts the text, and the furigana (or a full translation, via a local LLM on Ollama) is rendered on top, all running on my own hardware. And the important detail: on-the-fly, over the image I already have legitimately open, without downloading or redistributing a single page, so no copyright or license infringement.

Then came FRANK MANGA+, which I also posted about. I pay for the subscription to Manga Plus, Shueisha’s official app, but it only lets me read on mobile (Android/iOS). On a small tablet it’s tolerable, but I have a 32" Samsung Odyssey OLED monitor sitting right in front of me.

I figured out how to use my own subscription outside the app and built a desktop reader in Tauri: it runs on Linux, macOS and Windows, the free tier works out of the box and subscribers paste their own secret to unlock the premium chapters.

Install: AppImage, .deb and .dmg on the releases, or yay -S mangaplus-reader-bin on Arch.

And finally, I also read the occasional community “scanlations”: fans scan the pages of the original Japanese manga and translate them (nowadays most use AI in the process, there are even models trained to recognize speech bubbles, and I used one of those in FrankYomik itself). These scanlations are spread across several different websites, like MangaDex.

First I made a Chrome extension to prettify those sites (obsolete now), but I got tired of living with dozens of tabs in Brave just for scanlation sites. So I built FRANK Scanlation, along the same lines as FRANK MANGA+: a desktop app that concentrates all my favorite scanlations in one place, with a library, per-title reading progress and checking for new chapters.

The reading windows load the site itself and inject a decent reader on top, with double-page spreads and keyboard navigation. Nothing is hardcoded to any website: they’re heuristics that detect image sequences and chapter numbering in any URL. It became my preferred way to read the manga that can’t be bought on Amazon or from Shueisha.

Install: AppImage, .deb and .rpm (and a macOS build) on the GitHub releases.

Frank Lyrics: memorizing songs line by line

I already posted about Frank Karaoke, a little app to add scoring on top of YouTube and enjoy karaoke with family and friends. But there’s a sibling use case: I like learning new songs (a new anime opening, for example), and the process of memorizing lyrics is repeating the SAME line several times. In the YouTube player that’s hell: you keep hunting by hand for the exact spot on the timeline to go back to, miss it by two seconds, rewind too much, overshoot.

To solve that I created Frank Lyrics, a simple Chrome extension that figures out the correct timing for each line of the lyrics using the public markers from LRCLIB and injects controls into the YouTube page itself. LRCLIB, for those who don’t know it, is an open, community-driven library of synchronized lyrics: each line comes with a timestamp (the classic LRC format from music players), with a public API, free and keyless.

The extension matches those timestamps to the video and gives me buttons to repeat the exact line I’m memorizing, as many times as I need, without hunting the timeline. If you enjoy karaoke, the Frank Karaoke + Frank Lyrics combo should serve you well.

Install: download the .zip from the releases, unzip it, open chrome://extensions, enable developer mode and “Load unpacked” pointing at the folder.

Frank Type: typing practice with actual prose

Anyone who has followed me for a while knows I love my keyboards. There are videos on the Akitando channel about it and posts here on the blog about my favorite keyboards. And from time to time I like to train on MonkeyType. But I dislike typing random words. TypeRacer solves that by using real public texts, except it makes me wait for other players in the room (I hate multiplayer games). In other words: I wanted a single player experience, with real prose, but with the MonkeyType aesthetic, which I prefer.

So I created Frank Type, a mini-clone of both: a typing trainer in Rails 8 that uses normalized public-domain prose excerpts instead of random word lists. It’s local-first and account-free: session history, timing data and profile charts stay in the browser’s local storage. It even has a digraph heat map to show which key combinations slow you down.

Install: it’s a Docker container published as akitaonrails/frank_type. One command brings it up at http://localhost:3200:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/frank_type/master/bin/docker-run.sh | bash

distrobox-gaming: a library of how to install games on Linux

I game on the same PC I work on, but I refuse to mix emulator packages and Wine hackery with my development environment. The solution was to isolate gaming entirely inside a distrobox (containers that integrate with your desktop as if they were native), and distrobox-gaming is the repository of Ansible playbooks that builds that Arch box from scratch: ES-DE as the frontend, standalone emulators, RetroArch cores, per-game configs. My Arch/Omarchy host stays clean.

The rule I imposed on myself: every new game I install has to become a reproducible Ansible recipe. I confess I haven’t tested the full rebuild from scratch yet, but that’s the idea: any trick or hack required gets documented in code instead of lost in shell history.

And there’s no shortage of tricks, because I’ve been installing old abandonware: the Colin McRae Rally series (from the PS1 version with a 60 fps patch up to 2007’s DiRT), Sega Rally Revo, OutRun 2006 Coast 2 Coast, among others. Each with its own Wine quirks, patches and configs. Without meaning to, the repository is becoming a library of documentation on how to install games, emulators and retro games on Linux.

Along the same lines there’s distrobox-llm, which does the same isolation for my local LLM environment (CUDA, Ollama, LM Studio and friends), leaving only the NVIDIA driver on the host.

Install: clone the repository and run the playbooks:

cd ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml
ansible-playbook site.yml

aitrepreneur-docker: ComfyUI without dirtying the system

For image generation I like ComfyUI, and I posted about it last year. I follow a youtuber called Aitrepreneur who maintains a Patreon page with recipes to install and configure ComfyUI with the newest models and workflows. His curation work is great, but the recipes are old school .sh scripts, meant to run as one-shots on a RunPod instance, for example.

Now that LLMs evolved to the point of writing decent Dockerfiles, I created aitrepreneur-docker, which converts those scripts into proper Docker images and containers: pinned versions, persistent data on the host or NAS, one command to bring up or upgrade each app. That way I run everything isolated on my machine, without littering my Linux with tons of Python packages and hacks that could destabilize the system.

Two important notices. The credit for the stack selection, model curation and workflows all goes to Aitrepreneur: the repository only translates his work into Docker form, and his original scripts are paid Patreon content that is NOT included.

If you find it useful, subscribe to his Patreon to contribute to his content creation (that’s also where you get the original files). And the repository doesn’t cover everything he has produced, only the most recent recipes.

Install: git clone, make setup (creates the .env for you to put your Hugging Face token), make build and make up.

And there’s more where these came from

If you’re new here: this is just the batch that hadn’t shown up on the blog yet. There are plenty more projects I’ve covered in dedicated posts. ai-memory is the most popular, most used and most contributed-to of all. ai-jail, which showed up again in yesterday’s post about destructive agents, was the first of the series and is the second most popular.

And there are the others in the Frank series (“Frank” in honor of Frank Rosenblatt, creator of the perceptron, the original neural network; the name marks the experimental projects I do for fun):

• Frank Sherlock: smart image indexer
• Frank Mega: MEGA clone for my home server
• FrankMD: markdown editor
• Frank FBI: email fraud analyzer
• Frank Investigator: teaches you to question the news

Everything is open source and on my GitHub. Everybody is welcome to contribute with issues, pull requests, or just by sharing with your friends. Each of these projects was born from a real little problem of mine. Maybe one of them solves yours too.

In the last few months, we started seeing stories about large companies burning absurd amounts of tokens on AI tools without being able to point, clearly, to the matching product value. The most famous case was Uber burning through its annual AI budget in a few months with heavy use of tools like Claude Code, while executives admitted they still could not draw a straight line between token consumption and value delivered. It is not that nobody used the tool. They used it too much. That is exactly the problem.

By now, I think most people understand that a one-line prompt solves nothing. The fantasy of typing “build me an Uber clone” and coming back to a finished product died quickly. The market response was to run in another direction: spec-driven development.

Instead of asking for everything in one sentence, you write a specification. Scope, use cases, acceptance criteria, desired architecture, constraints, flows, maybe even a full PRD. Then you hand that to the agent and expect it to implement with less ambiguity.

Is that better than one-shot prompting? Of course. I still think it is wrong.

The problem is not lack of specification

I have been hammering this idea for years, long before LLMs became fashionable. Two of my videos matter for this point: Don’t Outsource Your Decisions and Forget Agile Methodologies.

The summary is simple: most professionals were trained not to decide.

Think about your own routine. Many people do nothing if there is no backlog ready. They cross their arms, blame management, blame colleagues, blame customers, and wait for someone else to say what should be done. When the task arrives, they execute. When it goes wrong, the requirement was bad. When the customer complains, the priority was wrong. When the product degrades, the process was to blame.

Almost nobody really decides, commits to the decision until the end, and suffers the consequences. Without suffering the consequence, you never learn how to decide.

You do not learn which choices lead to which results. You do not learn how to prioritize. You do not learn how to explain why something needs to exist. You do not learn how to write a specification because you understand the problem; you learn how to fill a template so nobody complains.

Agile became structured bureaucracy

The original 2001 principles were crushed. What many companies call Agile today is bureaucracy in shorter cycles.

Everybody knows the classic drawing: backlog, sprint planning, sprint, daily, review, retrospective, next sprint. The Scrum Guide describes the formal events. Diagrams like the Scrum process on Wikimedia show the pretty circle. In practice, many teams turned it into theater.

An entire day is spent debating what goes into the backlog. The final backlog is rarely what actually needs to be done. It is the consensus of least resistance. Compromise after compromise. Small tasks, small risks, small wins, small failures. Everything designed to avoid too much conflict.

That is not merely mediocre. It is worse: it is the active choice for easy decisions, the kind that will not bring too much criticism your way.

Then the team spends days or weeks implementing that lukewarm backlog. QA comes in, finds problems, tries to fit corrections into the next round. A few more days, maybe two more weeks. A month later, maybe two, the original decision finally starts to show results in production.

But the result is so far away from the decision that almost nobody makes the connection. The team does not feel the real weight of what it decided. The error does not become learning. The process does not improve. The most important part of any continuous improvement system, kaizen, never happens.

Something else happens instead: everybody learns to stay invisible.

You learn to please management, not the product. You learn to reduce friction, not solve the problem. You learn to survive the meeting, not deliver value. And when results get worse, upper management reacts in the usual way: more control, more rules, more gates, more committees, more checklists. The machine gets heavier. The team gets more cowardly.

Then AI arrives

Now the LLM enters the room.

Until recently, the biggest bottleneck in software development was writing and adjusting code. Coding took days or weeks. That is why so much energy went into planning. If the team is going to spend two weeks implementing, spending a day arguing about what goes into the sprint feels reasonable.

But coding tools with LLMs change where the bottleneck sits. They can do a large part of the manual work: generate structure, write basic tests, refactor, adapt APIs, create screens, fill boilerplate, try fixes. It is not perfect, but it is fast enough to change the economics of the process.

It is the old chain and weakest-link problem. You strengthen one link, another one starts limiting the system. Before, the weak link was coding speed. Now, increasingly, it is the human ability to decide, explain, test, and review.

The mistake companies make is putting LLMs inside the same broken process and expecting multiplicative gains.

You take people trained for years not to decide, give them a tool that requires clear decisions, and then act surprised when garbage comes out faster.

The LLM reflects the user

A coding agent needs you to explain the goal, the context, the constraints, the priorities, what must not break, which paths are acceptable, and how success should be measured. It needs direction.

Now go interview your team. Ask each person:

• what is the real goal of what you are doing?
• how does this improve the product?
• which metric should move?
• what trade-off are you accepting?
• what must not break?
• which unhappy paths need to be tested?

Many people cannot answer. They know which ticket they picked up. They know they need to close a few tasks per week. They know there is a daily tomorrow. They do not know why the work matters.

Then you give that person an LLM.

The result is not magic. It is a mirror. Bad code ten times faster. Bugs ten times faster. Angry customers ten times faster. Giant pull requests ten times faster. The problem is not only AI. AI amplifies the lack of direction.

Spec-driven development tries to fix this with documentation. But if the specification is born from the same cowardly process, it only documents the cowardice. A PRD written by someone who does not understand the decision is still bad. Acceptance criteria written to avoid conflict still dodge the real problem. The agent will execute a bad decision better.

The process has to change

My hypothesis is that the whole process has to be redesigned around the new constraint. Again: speculation. I do not have enough data to prove it. But looking at the kind of failure I see in companies, and the kind of success I see in intense individual use, my theory is this:

throw away the sprint ritual as the central unit of work.

It makes no sense to keep days of planning, days of review, and weeks of coding as if the bottleneck were still the same. With LLMs, the cycle needs to be shorter. Much shorter. Ideally, inside the same day.

In my ideal setup, each programmer with an LLM should pair directly with a Product Manager for short blocks of work. The PM’s job is to close the gap the programmer usually has: goal, priority, constraint, business context, expected result. That needs to enter the prompt and the conversation with the agent.

But because coding is no longer the main bottleneck, the PM does not need to wait two weeks to see a result. They can sit with the programmer for a morning, implement a small functional slice, adjust on the spot, decide on the spot, cut scope on the spot. Then the PM rotates to another programmer.

Then QA comes in. Not as a distant phase, but as pairing inside the same cycle. QA closes another common gap: testing only the happy path, forgetting error cases, not automating enough, not thinking about behavioral regression. QA’s job becomes helping turn the implementation into something verifiable now, while the context is still hot.

Then the Tech Lead comes in. Also on the same day, not two weeks later. They look at what changed and close the third gap: unnecessary complexity, poor design, hidden regression, missing documentation, obvious vulnerability, performance getting worse, coupling that did not need to exist.

Build, check, adjust. In real time.

The new role of each person

This model demands more responsibility, not less.

The programmer stops being the person who only picks up tickets. They need to learn how to turn a goal into executable instruction. They need to discuss trade-offs. They need to understand why they are coding. They need to use the LLM as a tool for execution and investigation, not as an excuse to turn the brain off.

The PM stops being a backlog factory. They need to decide with the programmer, looking at the live product. This is not writing a card and disappearing. It is watching the thing come to life, adjusting it, cutting it, prioritizing it, and accepting the consequence.

QA stops being the person who receives the package at the end and returns defects. QA enters early to turn expected behavior into verification. If the LLM accelerates code, QA needs to accelerate learning about risk.

The Tech Lead stops being a late PR stamp. They enter while change is still cheap. They help keep things simple, remove complexity, protect architecture, documentation, security, and performance.

None of this works if everybody keeps using AI as expensive autocomplete inside the same bureaucratic Scrum.

Why companies will not like this

Because this process exposes decisions.

In the current process, the decision dissolves. It was the backlog. It was the PM. It was refinement. It was the sprint. It was the team. It was a dependency. It was the customer changing their mind. Everybody can hide.

In a short LLM cycle, the decision appears quickly. You said this was the priority? Then implement it now. You said this was the acceptance criterion? Then test it now. You said this design was good? Then review it now. If it is wrong, the consequence shows up the same day.

That is uncomfortable. But that is how you learn.

Without nearby consequence, decision becomes theater. With nearby consequence, decision becomes training.

How to implement this without burning money

The first step is accepting something professional programmers usually hate: you can throw code away.

In fact, you should throw code away much more often.

Code is not a monument. Code is working material. Deleting code is as important as writing new code. That is why we use Git. The idea was always to work in branches, try paths, change our minds, compare alternatives, delete what did not work, and keep only what survived contact with reality.

But in the traditional process, code becomes too emotionally expensive. If it took two weeks to produce, nobody wants to admit it was waste. The manager feels that deleting it proves the previous decision was bad. The programmer defends the implementation because they suffered to make it. The team pushes the problem forward because deletion feels like defeat. It is not. Sometimes it is hygiene.

With LLMs, that cost changes. Making mistakes becomes cheap. Prototyping becomes cheap. Building a proof of concept becomes cheap. Trying two paths and throwing one away becomes cheap. Asking the agent to rewrite an entire approach in a temporary branch, compare it, document what was learned, and git reset without drama becomes cheap.

So do more of that. More prototypes. More proofs of concept. More internal A/B tests. More disposable branches. Less attachment to the first code that appeared. LLMs are good at this kind of work: exploring alternatives quickly, showing where the specification was vague, and producing material you can destroy without guilt.

But do not expect everyone to receive LLM tokens on Monday and know how to do this alone. That is the fastest way to burn the budget and then say AI does not work.

My suggestion is the opposite: assume one or two weeks with no planned delivery. Say clearly that the goal is not to ship a feature. It is to train the new process. Break the old ritual. Let the team practice in a safe environment. If it goes wrong, fine: reset the branch, delete the prototype, document what you learned, try again.

In that phase, the PM should not write a twenty-page spec. They should pair with the programmer and build small prompts, one step at a time, watching the result in real time. With each LLM response, the PM learns how much detail the code actually needs. The programmer learns to ask better questions. QA learns to turn behavior into tests early. The Tech Lead learns to cut complexity while it is still cheap.

This is how LLM adoption has some chance of working: as a process change, not as an expensive autocomplete license.

The uncomfortable conclusion

LLMs fail so often because they are inserted into processes made by people who were trained not to decide.

It is not just lack of a better prompt. It is not just lack of a larger spec. It is not just lack of token governance. Those things help, but they do not touch the center of the problem.

The center is that many people do not know how to explain a measurable goal, prioritize, accept a trade-off, or connect decision with result. An LLM needs exactly that to be useful.

If you put AI into the old process, you accelerate the old process. More mediocre backlog. More bad decisions. More bugs. More cost. More rework. More reports trying to prove productivity the customer never felt.

If you want LLMs to work, redesign the process around them. Smaller cycles. Real pairing. Decision close to execution. Testing close to decision. Review close to code. Result close to whoever decided.

This is the part programmers need to face: yes, you probably never learned how to decide properly. You never learned how to describe a goal objectively. You never learned how to measure consequence. The process trained you that way. Now AI is revealing the failure.

The good news is that you can train the opposite.

But it will not happen with another ceremony, another prompt spreadsheet, another AI usage policy, or another sprint full of tickets written so nobody gets criticized.

It will happen when you stop outsourcing decisions.

Instead of doing a one-day demo and risking a “yeah I think so,” I went all-in: over 500 hours, almost half a million lines of code and documentation, 24 repositories between public and private.

But today someone flagged a point I never thought would need defending:

“Are all 24 projects perfect, models of code excellence?” — ABSOLUTELY NOT.

I thought that was obvious. For starters, if I believed any of them was that good, I’d be spinning up a startup around it. I don’t lack capital to invest. If I’m not doing that, clearly all of this is at hobby pace.

Second obvious point: if I’m jumping between projects every few days, it’s because I lost interest. If I really liked it, I’d still be tuning it today. I keep saying it in the videos — software never “finishes”. The moment it stops moving, it dies.

The goal was to test different kinds of projects to see how the LLMs handled each. That’s why there’s stuff in Ruby on Rails, Rust, Go, Python, Crystal. Plus frameworks like Tauri and Flutter. I figured, for instance, that Flutter being super popular would mean the LLMs wouldn’t struggle. They did. They could move forward, just not as smoothly as in Rails. Tauri was “rough” too. Crystal was REALLY rough.

Third point: every experimental project got named “Frank”. Sarcasm, obviously. I don’t have the patience to invent a pretty name for a project I already know is going to be one-off.

I use my GitHub basically as a repository of exercises and experiments. Look at all the old repos: barely any are a “real” project I want to maintain. I do what I’ve been preaching in the videos: to actually learn, you exercise on MANY projects, even if most of them are meant to be THROWN AWAY. Nobody learns by trying to build a single perfect project. Check out my videos A Dor de Aprender or Guia Definitivo de Aprendendo a Aprender (Portuguese).

In the middle of a bunch of half-baked projects, some naturally emerge as the ones I like and maintain. In practice I threw them all at the wall to see what stuck. The good ones naturally pulled in more contributors too. I don’t keep an eye on Issues and PRs every day. I check once a week. Two or three days ago I made a sweep and cleared everything that was pending, for example. Even on projects I don’t care much about, if a PR shows up, I review and accept it. It wasn’t useful to me, but it can be useful to someone else.

The project ranking

To make it clear, here’s a ranking of the projects with a comment on each. The PR counts below are non-dependabot (gem bumps don’t count). The score is my estimate of “how stable and usable is this thing in its current state.”

Top tier (7-8/10)

ai-jail — 8/10. The only one really close to a stable 1.0 release. Got the most traction: 19 PRs closed, 23 Issues resolved. Recommend using, it works very well.

akitando-news (the M.Akita Chronicles) — 8/10. The one I built with the most care, in the “Agile Vibe Coding” mode I described a few posts back. And the one I touch most often. There’s always some little thing to tweak, stuff I keep adding, removing, experimenting with. Which is why it’s been shipping every week. Also why: it’s closed and I don’t plan to open it.

akitaonrails.github.io — 7/10. This is the blog you’re reading. I touch it often and I’ve already closed about 7 Issues and 30 PRs from contributors. I’ll keep tuning it bit by bit.

FrankMD — 7/10. One of the first ones I built, with no criteria at all: I just wanted an editor with automatic image upload to my S3. These days I use Claude Code to edit posts, so the only people using it are the people contributing to it. Got solid traction, I closed 17 PRs and 29 Issues. It’s not perfect, but it’s good enough to use — at least it’s been tested enough.

easy-ffmpeg — 7/10. Tiny little project, but I actually use it in the videos. My OBS always records in MKV and when I want to share I convert to MP4. Small use cases like that. Good enough to use.

Middle tier (5/10)

distrobox-gaming — 5/10. Most recent one, serves as a “dump” of documentation for my retro games. I use it as a notepad and it’s been working fine for my setup. Not worried about it working for anyone else. If anyone wants to send PRs, go ahead.

llm-coding-benchmark — 5/10. This one doesn’t run on its own. I have Claude Code execute it. The goal is to tabulate data so I can write articles about new LLMs. The code has to be REALLY rough.

FrankMega — 5/10. The closest thing to a “todo list” exercise. I just needed to share a big file with a friend and thought “hmm, I bet I can build a mini-Mega in 1 day”. And that was it. The name is a joke, obviously — this is nowhere near the actual Mega.

distrobox-llm — 5/10. More personal organization on my PC: I wanted to isolate the AI tooling into a distrobox so I wouldn’t have to keep updating big packages on the main system.

Lower tier (3-4/10)

FrankYomik — 4/10. This was an idea I’d had in my head for years. I just wanted to see if the concept worked. It works. But running local LLMs for it is slow and not as practical as I’d like. It’s the only one I might come back to, because I actually want to use it. As-is, it’s in “works, sort of” territory.

NW-Omarchy — 4/10. Another “let’s see if this works” experiment, lasted 2 days. The concept worked, but I don’t plan to do much more than that. Up for grabs if anyone wants to take it further. The real test I wanted to run was whether X11 would be MUCH worse than Wayland. The gap turned out smaller than I expected, but I don’t see myself using it day-to-day. Like I’ve said: for the niche of people who can’t use Wayland, it’s a decent alternative.

frank_investigator — 3/10. Started it, didn’t have the patience to keep going. Planted the seeds of the idea. If nobody sends PRs, it’s not going to evolve much. Needs more research and a lot more testing.

frank_fbi — 3/10. Another concept test, no personal use case (I never fall for phishing). No idea where this would go yet.

frank_karaoke — 3/10. Born from a weekend conversation with my brothers. Another shot at using Flutter (and seeing the limits, both of Flutter and of LLMs writing Flutter). Useful for me to learn about the karaoke ecosystem and find out that real scoring only works with per-song metadata. So I didn’t push it past toy territory.

Bottom of the barrel (1-2/10)

FrankSherlock — 2/10. I don’t use it myself. So it’s probably full of bugs that nobody’s fixed. It was a test to see if I could build a Tauri app, but I lost interest fast. There’s room to make it better, but it’d take a lot more hours of actual use, testing, and fixes. It was also my first time touching Tauri, so that part is probably pretty rough too.

FrankClaw — 1/10. I don’t use it, and this is the only one I haven’t even run a single time. The exercise was just to see how hard it’d be to port the original openclaw from TypeScript to Rust. But as I’ve said many times, I don’t see any use for openclaw in my own workflow. When I finished version 0.1, I stopped. Even so, there were 6 PRs I closed. If anyone’s interested, feel free to contribute.

shadPS4 — 1/10. Despite generating a lot of code and a lot of documentation, none of it was meant to be a real contribution. Pure learning, plus solving one very specific problem. I left it open just to show what “study-material” code looks like.

easy-subtitle — 1/10. Started it, lost interest, never actually tested it. Just pushed it and forgot.

The private ones

Beyond akitando-news, I have stuff on my private Gitea like my-omarchy-config, emulators-reorg-2026, thinkpad-omarchy-config, homelab-docs, akitando_english_translation, etc. I’m not going to describe them because you’re never going to see them. They serve as “scratchpads” for Claude Code to administer my machines.

What this ranking actually says

Notice: there’s no project on this list that I think is 10/10.

For a project to graduate from hobby to real project, you need users and feedback. If nobody uses it, there are always dozens of functional bugs nobody’s stumbled on, so nothing ever gets fixed. A project with no users is a dead project.

That’s why I keep saying in the videos: there’s no such thing as planning every detail, writing a pile of code, and one day “finishing”. Nope. When you think you’ve “finished,” what you actually have is version 0.1. Then comes months of experimentation with real users reporting bugs. You go fixing. Out of those fixes come refactors, architecture changes because your initial assumptions were wrong against actual use. Software NEVER finishes.

What I took out of this marathon

16 hours a day, every day, vibe coding, the output is always going to have slop in it. There’s no way around it. Forcing volume doesn’t fix it. You have to review manually, commit by commit, PR by PR. Why didn’t I do that on all of them? Simple: nobody’s paying me. I did it on 2 or 3 projects. The rest I just wanted to test the concept and move on to the next one.

The right way is what I reported a few posts ago: “Agile” Vibe Coding. That’s my sarcastic way of saying “use XP and normal software engineering practices”. Metrics, monitoring, CI, the whole nine yards. None of that changed. Without it, you’ll end up like a lot of my exercises: one-offs to throw away.

Don’t be embarrassed to push “bad” projects. What I didn’t anticipate is that some people assume just because I pushed code, I think it’s perfect. But that’s projection: they only push code they consider great, which is why they never push anything. I’ve said this MANY times and I demonstrate it: I don’t care about my code, I have no preciousness about my code, GitHub is a temp dump directory for whatever. The ones I really like usually live private.

If a project is really good, don’t just say it. Put your money where your mouth is: build a business around it, charge users, deliver quality. I’m retired, I don’t need to charge anyone, but I also have no interest in working for free. The moment the code stops being fun, I drop it and move on. The ones I actually got hooked on (ai-jail, M.Akita Chronicles) I keep touching more often. That simple.

As I expected, and as I showed both in these little projects and in the benchmark, the choice is simple: use GPT Codex or Claude Code on one of the subsidized plans. Don’t pay per token. That’s where the 5x productivity lives (max 10x, with slop along for the ride). Yes, there’s Kimi v2.6 or DeepSeek V4 Pro. But I’ll save you the trip: the projects I scored below 5 here would quickly become projects below 2 with those.

The point that matters most

AI doesn’t replace a good programmer. AI mirrors and accelerates who you are. If you’re a good programmer, AI accelerates good code. If you’re a bad programmer, AI accelerates bad code.

That’s exactly what I showed: most of the projects I built were one-offs and proof-of-concept tests. Bad code, with no interest from me to keep going. AI accelerated me finishing those tests in a half-baked way. Which is fine by me: without AI I never would’ve started. Now that I’ve seen what they look like, I can cross them off my list and move on.

What matters is your OBJECTIVE. If yours is to build a business and charge people, you have to do it with 10x more care than I did. Everything I do is meant to be thrown away. I don’t need to make money on any of these projects. Don’t assume things I never said.

The problem: subtitles

Anyone who maintains a movie and TV collection knows the pain. You download the MKV, but the embedded subtitle is out of sync. Or worse: there’s no subtitle at all in the language you want. So you go to OpenSubtitles, download a subtitle, and it’s 3 seconds ahead because it was made for a different release. The manual flow is:

1. Extract subtitle tracks from the MKV with mkvextract
2. Go to OpenSubtitles, look for a subtitle for the movie
3. Download, test, see it’s out of sync
4. Run some sync tool (ffsubsync, alass)
5. Rename the file, move it to the right place
6. Repeat for every language, for every movie

For someone with 10 movies, it’s tolerable. For someone with hundreds, it’s insanity. It’s exactly the kind of thing that should be automated.

Subservient: the Python solution

Looking at what already existed, I found Subservient. It’s a Python project that automates exactly this flow: it extracts subtitles from MKVs, downloads them from OpenSubtitles via REST API, syncs them with ffsubsync, and cleans ads out of SRT files.

The project is complete. It has movie mode and series mode, smart sync (tests every candidate in parallel and picks the best one) and first-match (stops at the first one that works). It uses the OpenSubtitles hash for exact matching and cleans watermarks and ads with more than 30 regex patterns.

But it has the typical Python distribution problems:

• 7 pip dependencies: colorama, requests, langdetect, ffsubsync, platformdirs, pycountry, tqdm
• ffsubsync as the sync engine: which in turn depends on numpy, auditok, and a bunch more Python packages
• Interactive menu UI: good for manual use, terrible for scriptability
• Config in INI format: not the end of the world, but YAML is more ergonomic
• 10,220 lines across 6 Python files: 2,700-line files with hundreds-of-lines functions each

The point isn’t that Python is bad for this. Subservient works. But installing and maintaining it in production is another story. If you want to run it on a headless server, you need Python 3.8+, pip, virtualenv (or you’re going to pollute the system), and pray no dependency breaks with the next OS update.

The experiment: porting it to Crystal with Claude

Here’s where it gets interesting. I wanted to test a hypothesis: can Claude take a large open source project, understand the architecture, and do a complete port to another language?

I’m not talking about translating it file by file. I’m talking about understanding what the project does, redesigning the architecture where it makes sense, and generating idiomatic code in Crystal.

What I did:

1. Asked Claude to clone and analyze the Subservient repo
2. Explained the design decisions: use alass (a Rust binary, no Python dependencies) instead of ffsubsync, CLI subcommands instead of interactive menus, YAML instead of INI
3. Asked for a feature-parity port, with tests

alass is an important detail. ffsubsync works fine, but it’s a Python package that pulls in numpy and does audio analysis. alass does the same thing (subtitle synchronization through timing analysis), but it’s a standalone Rust binary. Swapping one for the other eliminates the biggest Python dependency in the stack.

The result: easy-subtitle

Five commits. Less than 40 minutes from the first to the last.

The first commit already delivers a working project: 8 CLI commands, OpenSubtitles client with rate limiting, 76 passing tests, GitHub Actions with CI and release for Linux and macOS.

Numbers

The LOC difference is loud: 10,220 vs 2,516. But that’s not all Crystal’s doing. The original Python has monolithic files of thousands of lines, with a lot of duplication and UI logic mixed with business logic. The port separates the responsibilities into small, focused modules.

Architecture of the port

easy-subtitle/
  src/easy_subtitle/
    cli/           # Router + 9 commands (init, extract, download, sync, run, clean, scan, hash, doctor)
    core/          # Language map, SRT parser/writer/cleaner, video scanner
    acquisition/   # OpenSubtitles API client, auth, search, download, movie hash
    extraction/    # MKV track parsing, extraction, remuxing
    synchronization/  # alass runner, offset computation, smart/first-match strategies
    models/        # VideoFile, SubtitleCandidate, CoverageEntry

Every module has a clear responsibility. The biggest file is 144 lines (config). In the original Python, acquisition.py alone has 2,726 lines.

What each command does

# Generate the default config
easy-subtitle init

# Extract subtitles from inside MKVs
easy-subtitle extract /path/to/movies

# Download subtitles from OpenSubtitles
easy-subtitle download -l en,pt /path/to/movies

# Sync downloaded subtitles with the video
easy-subtitle sync /path/to/movies

# Full pipeline: extract → download → sync
easy-subtitle run /path/to/movies

# Clean ads/watermarks from SRTs
easy-subtitle clean /path/to/subtitles

# See subtitle coverage by language
easy-subtitle scan --json /path/to/movies

# Compute the OpenSubtitles hash (debug)
easy-subtitle hash /path/to/movie.mkv

# Validate the setup: config, credentials, dependencies
easy-subtitle doctor

doctor is a command I added later. It checks whether the config exists, whether the API key is configured, tests login against the API, and checks whether mkvmerge, mkvextract and alass are on the PATH. It shows OS-specific install instructions when something is missing.

Smart sync with fibers

Smart sync is the part I most enjoyed seeing in the port. In the original Python, it uses ThreadPoolExecutor to run multiple candidates in parallel. In Crystal, the same logic is more natural with fibers and channels:

def execute(candidates : Array(Path), video : VideoFile) : SyncResult?
  channel = Channel(SyncResult).new(candidates.size)

  candidates.each do |candidate|
    spawn do
      result = sync_one(candidate, video)
      channel.send(result)
    end
  end

  results = Array(SyncResult).new(candidates.size)
  candidates.size.times do
    results << channel.receive
  end

  accepted = results.select(&.accepted?)
  accepted.min_by(&.offset)
end

Each subtitle candidate gets synced in a separate fiber (via spawn). The results come back through the Channel. At the end, it picks the accepted one with the smallest offset. No ThreadPoolExecutor, no futures, no callbacks.

API rate limiting

OpenSubtitles requires throttling of 500ms between requests. The Crystal client implements that with a Mutex:

RATE_LIMIT_MS = 500

private def throttle! : Nil
  @mutex.synchronize do
    elapsed = Time.utc - @last_request_at
    remaining = RATE_LIMIT_MS - elapsed.total_milliseconds
    sleep(remaining.milliseconds) if remaining > 0
    @last_request_at = Time.utc
  end
end

Simple, thread-safe, no external library.

Installation

The static binary comes out of GitHub Actions and can be installed three ways:

# Homebrew (macOS / Linux)
brew install akitaonrails/tap/easy-subtitle

# Install script
curl -fsSL https://raw.githubusercontent.com/akitaonrails/easy-subtitle/master/install.sh | bash

# Or grab the binary directly from Releases

One binary. No Python, no pip, nothing.

On porting things “just because”

I’ve always argued that porting software from one language to another just for the language fetish is a waste of time. How many projects have been rewritten in Rust “just because”? How much effort spent on rewrites that delivered no new value?

But I have to admit this experiment made me reconsider.

When the cost of porting drops from weeks/months to less than 40 minutes, the equation changes. Porting Subservient to Crystal with Claude wasn’t an exercise in linguistic vanity. I wanted a static binary I could drop on a server and forget. No managing a Python runtime, no pip install breaking on the next system update.

And the result isn’t a mechanical port. It’s 2,516 lines across 42 files, against 10,220 in 6 monolithic ones. The port came with 76 tests the original didn’t have, CI with automatic release for Linux and macOS, a Homebrew formula and an install script with checksum verification.

The point isn’t that Python is bad. It’s that the bar for “is it worth porting?” got ridiculously low. Feature-parity port with tests in less than an hour. Hard to argue against that.

The repository is here. GPL-3.0, like the original.

ffmpeg -i input.mkv -c:v libx264 -crf 23 -preset medium \
  -profile:v high -level 4.1 -c:a aac -b:a 128k \
  -movflags +faststart output.mp4

What does that do? Convert to H.264 with reasonable quality for the web, using AAC for audio and moving the moov atom to the start of the file to allow progressive streaming. If you already knew that, congratulations. If you didn’t, welcome to the club of 99% of people who use FFmpeg by copying commands from Stack Overflow.

And that’s the easy case. Want to make an animated GIF from a sequence of PNGs? You need a two-pass pipeline with palette generation:

ffmpeg -framerate 10 -i frame_%04d.png \
  -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.gif

Want to cut a clip, resize to 720p and force a 16:9 aspect ratio? Good luck assembling the filter chain.

I got tired of memorizing flags. I wanted a CLI where I’d say “convert this to MP4 optimized for the web” and it would figure it out. So I built easy-ffmpeg.

What easy-ffmpeg does

It’s a smart wrapper. You give it the input file and the output format, and it analyzes the video with ffprobe, finds out which video, audio and subtitle streams exist, checks codec compatibility against the destination container, and decides on its own what can be copied directly (no re-encoding, instant) and what needs to be transcoded.

The most basic use:

# Convert MKV to MP4 (copies compatible streams, no unnecessary re-encoding)
easy-ffmpeg input.mkv mp4

# Optimized for the web (H.264 + AAC, faststart)
easy-ffmpeg input.mkv mp4 --web

# Optimized for mobile (720p, AAC stereo, smaller file)
easy-ffmpeg input.mkv mp4 --mobile

# Maximum compression (H.265, CRF 28)
easy-ffmpeg input.mkv mp4 --compress

# High quality for streaming (H.265, CRF 18)
easy-ffmpeg input.mkv mp4 --streaming

Examples of what you can do

Cut a clip from the video:

# From minute 1:30 to 3:00
easy-ffmpeg video.mp4 mp4 --start 1:30 --end 3:00

# The first 90 seconds
easy-ffmpeg video.mp4 mp4 --duration 90

# Accepts several time formats: 90, 1:30, 01:30.5, 1:02:30

Resize:

# To 720p
easy-ffmpeg video.mp4 mp4 --scale hd

# To 1080p
easy-ffmpeg video.mp4 mp4 --scale fullhd

# Presets: 2k (1440p), fullhd (1080p), hd (720p), retro (480p), icon (240p)

Change aspect ratio:

# Force 16:9 (adds black bars if needed)
easy-ffmpeg video.mp4 mp4 --aspect wide

# TikTok/Stories format (9:16 vertical)
easy-ffmpeg video.mp4 mp4 --aspect tiktok

# Square for Instagram
easy-ffmpeg video.mp4 mp4 --aspect square

# Crop instead of adding bars
easy-ffmpeg video.mp4 mp4 --aspect wide --crop

Image sequence to video:

# Auto-detects the numbering pattern (frame_0001.png, frame_0002.png...)
easy-ffmpeg /folder/with/frames/ mp4

# Animated GIF with optimized palette
easy-ffmpeg /folder/with/frames/ gif

# Image sequence at 720p, 30fps
easy-ffmpeg /folder/with/frames/ mp4 --fps 30 --scale hd

See what it’ll do without running it:

easy-ffmpeg video.mkv mp4 --web --dry-run
# Shows the exact ffmpeg command that would be executed

Combine everything:

# Cut, resize and compress to send over WhatsApp
easy-ffmpeg video.mkv mp4 --start 0:30 --end 2:00 --scale hd --compress

And if you run easy-ffmpeg with no arguments in an interactive terminal, it opens a TUI mode with file selection through fuzzy search, preset choice through a menu, and time input with validation — all without having to remember any flags.

Why Crystal

I hadn’t touched Crystal in years. The last time was for fun, before version 1.0. And I wanted to revisit it.

Crystal occupies an interesting niche. Go and Crystal compete for the same space: compiled languages for applications, generating static binaries, with garbage collection and no runtime dependency. But the approach is very different.

Go is famously, deliberately simple. No generics for years (they only landed in 1.18), no exceptions (error returns), no expressiveness. The argument is that this makes it easier to read and maintain in big teams. In practice, it produces verbose, repetitive code, with if err != nil on every line.

Crystal has static typing with inference, compile-time macros, blocks as closures (just like Ruby), exceptions, generics from day one, and a syntax any Rubyist will recognize:

# Crystal: read a JSON and extract data
streams = json["streams"].as_a.map do |s|
  StreamInfo.new(
    codec: s["codec_name"]?.try(&.as_s) || "unknown",
    width:  s["width"]?.try(&.as_i) || 0,
    height: s["height"]?.try(&.as_i) || 0,
  )
end

# Go equivalent: would be 3x more lines with type assertions and error checks

Crystal’s stdlib has an HTTP server, JSON parsing, YAML, regex, fibers (green threads with a cooperative scheduler), channels (just like Go), and even IO::FileDescriptor with raw mode for the terminal — which I used for the interactive mode. Concurrency works with spawn (the equivalent of Go’s go) and Channel (identical to Go’s chan). The difference is that everything comes with Ruby’s ergonomics.

For a CLI that needs to compile into a static binary with no dependencies, run on Linux and macOS, and be distributed as a direct download — Crystal is perfect. The compiler generates native binaries, and with Docker Alpine you can do static linking with musl for Linux. The final easy-ffmpeg binary is around 6MB.

I think Rust is better for systems code (kernels, drivers, databases, things where ownership and lifetime matter). But for a video conversion CLI? Rust would be overkill. Crystal gives you the same end result (fast static binary) with a third of the code and without fighting the borrow checker.

The numbers

The whole project was built in one afternoon. 10 commits between 18:32 and 21:33 on March 7, 2026. Three hours.

Language     Files       Lines     Code
Crystal      13          2,823     2,342
Shell        1           109       91
Markdown     1           266       210
YAML         2           46        34
─────────────────────────────────────────
Total        20          3,326     2,419

2,342 lines of Crystal do: a CLI with 5 presets, media analysis through ffprobe, smart conversion planning with a codec compatibility matrix, a progress bar with ETA, an interactive mode with fuzzy search, support for image sequences and GIFs, and trimming/scaling/aspect ratio with validation.

The tool already has CI/CD on GitHub Actions, compiling static binaries for Linux (x86_64 and arm64) and macOS (arm64), with installation through a one-line curl:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/easy-ffmpeg/master/install.sh | sh

Three hours of one afternoon, from the first line of code to a release on GitHub with binaries for three platforms. FFmpeg keeps doing the heavy lifting — I just put a decent interface in front of it.

The repository is here. MIT license.

The result was 653 commits, ~144K lines of code across 8 projects published on GitHub, and a series of articles documenting each one. If you’ve been following along, you’ve already read the post-mortems. If you haven’t, here’s the index:

The articles

• Vibe Code: I built a small app 100% with GLM 4.7 (TV Clipboard)
• Vibe Code: Which LLM is the BEST?? Let’s get real
• Vibe Code: I built a Markdown editor from scratch with Claude Code (FrankMD) PART 1
• Vibe Code: I built a Markdown editor from scratch with Claude Code (FrankMD) PART 2
• RANT: Did AI kill programmers?
• Vibe Code: From Zero to Production in 6 DAYS - The M.Akita Chronicles
• From Zero to Post-Production in 1 Week - How to Use AI on Real Projects
• Vibe Code: I built a Mega clone in Rails in 1 day for my Home Server
• Vibe Code: I built an Intelligent Image Indexer with AI in 2 days - Frank Sherlock
• RANT: Did Akita open his legs to AI??
• ai-jail: Sandbox for AI Agents
• Software Is Never ‘Done’ - 4 Projects, the Life After Deploy
• I Built a Data Mining System for My Influencer Girlfriend
• My First Vibe Code Failure and How I Fixed It - Frank Yomik

The projects

All of this happened between January 27 and March 5, 2026.

I’m not going to repeat the technical details of every project. Each post-mortem above already covered that. What I want to discuss here is the consequence.

What these 37 days showed me

Projects that used to take weeks or months for an experienced developer now take days. A complete Markdown editor in 5 days. A Mega clone in 1 day. A data mining system with 40+ bot tools in 3 days. An image indexer with vision AI in 2 days.

And I’m not talking about throwaway prototypes. These projects are in production. They have tests. They have automated deployments. It’s real software built with real engineering practices, just at a speed that was unthinkable before.

This speed isn’t unique to me. Cloudflare just demonstrated something similar. In a recent post, they describe how an engineer reimplemented the Next.js API surface on top of Vite in a week, using Claude as the main tool. US$ 1,100 in API tokens, more than 800 sessions, 1,700 unit tests, 380 E2E tests, builds 4.4x faster than the original Next.js. Controversies aside about whether it’s a “complete” reimplementation or not, the central point is real: software that used to require teams and months can now be built by one person in days.

And that changes everything for anyone wanting to start a company.

The death of the easy startup

For years, the classic startup model worked like this: someone has an idea, puts together a small team, builds an MVP in 3-6 months, raises seed money, and tries to scale. The barrier to entry was development cost. Programmers are expensive, development is slow, and the first to market has the advantage.

That model is breaking.

If I can build a working Mega clone in 1 day, what’s a “cloud storage” startup worth? If Cloudflare reimplements the Next.js core in 1 week with one engineer and US$ 1,100 in tokens, what’s the real moat of a platform like Vercel? The “social listening” SaaS that charges R$ 500/month is competing with something I built in 3 days as a side project.

Every entrepreneur who used to show up describing their idea as “it’s like Uber, but for…” or “it’s like Airbnb, except…” or “another social network, but with…” — those people need to stop and rethink. When any competent developer with access to Claude Code or GPT Codex can replicate your MVP in a week, your idea isn’t worth anything anymore. Execution got too cheap.

I’m not exaggerating. In my 37 days, I built things I wouldn’t even attempt in 6 months before. Small CRMs, ecommerces, content managers, productivity tools, data mining apps, processing pipelines — all of that became commodity. The code itself is no longer the differentiator.

So what is the differentiator?

This is where most vibe coding enthusiasts miss the point. To illustrate, let me use my own project as an example.

Frank Yomik translates manga pages from Japanese to English in near real-time. The full pipeline (balloon detection, OCR, translation, rendering) works. But the most important component of the system isn’t any code I wrote. It’s the ogkalu/comic-text-and-bubble-detector model, an RT-DETR-v2 trained on ~11,000 labeled comic images.

I didn’t train that model. I couldn’t easily train that model. Collecting 11,000 diverse comic images, manually labeling the speech balloons in each one (or generating labels with some semi-automated pipeline, which isn’t trivial either), configuring the training, and running it on the necessary hardware — that’s work of a different nature. It’s work that vibe coding doesn’t solve.

And that’s the case of a relatively small model. An object detector can be trained with a few hundred to a few thousand labeled images on a single GPU in hours. Studies show useful results are possible with 100-350 images for specific domains, but robust real-world detectors usually need thousands. The cost is low, in the hundreds of dollars range.

Now look at what happens when we scale up to bigger models.

The numbers that matter

GPT-4 cost more than US$ 100 million to train, according to Sam Altman himself. Stanford estimated the compute cost of Google’s Gemini Ultra at US$ 191 million. Meta’s Llama 3 consumed 39.3 million GPU-hours on H100s, and Meta built two clusters of 24,576 GPUs each to make it possible — and by the end of 2024 it planned to have 350,000 H100s in its infrastructure.

These costs are accelerating. According to Epoch AI, the cost of hardware and energy to train frontier models grows by 2.4x per year since 2016. If that trend continues, the largest training runs will cost more than US$ 1 billion before the end of 2027. Dario Amodei, Anthropic’s CEO, has said frontier developers are probably spending close to a billion per training run now, with US$ 10 billion training runs expected within two years.

And the hardware? An H100 GPU costs US$ 25,000-40,000 per unit. A server with 8 GPUs runs between US$ 200,000 and US$ 400,000. The HBM memory those GPUs use is at capacity — SK Hynix, Samsung and Micron have already announced ~20% price increases for 2026. NVIDIA consumes more than 60% of the global HBM production. It’s a structural bottleneck, not a temporary one.

In terms of energy: global data centers consumed ~415 TWh of electricity in 2024, according to the IEA, about 1.5% of the world’s electricity. The projection is ~945 TWh by 2030. New data centers are being built with capacities of 100 MW to 1 GW each.

And the big tech investments reflect that. In 2025, the aggregate capex of Amazon ($125B), Google ($91B), Microsoft ($80B) and Meta ($71B) crossed US$ 400 billion, a 62% increase over 2024. Goldman Sachs projects more than US$ 500 billion in 2026.

These numbers aren’t meant to scare. They’re meant to put the real entry barrier in context.

The new barrier: exclusive data and training capacity

If software got cheap to produce, the competitive differentiator migrated. The question stopped being “who writes code the fastest?” and became “who has access to data nobody else has, and knows how to turn that data into useful models?”

DeepSeek-V3 announced that its training cost US$ 5.5 million in compute. The press celebrated the “cheap Chinese model.” But The Register reported that the acquisition cost of the 256 GPU servers used was over US$ 51 million — and that excludes R&D, data acquisition, data cleaning, and all the failed training runs before the final successful one. The real cost of developing the capability is one or two orders of magnitude above the marginal cost of the final successful training run.

That’s why we only see large companies producing frontier models. Meta, Alibaba, Google, Amazon, Microsoft, Anthropic — companies investing tens of billions in hardware and energy. A garage startup can’t compete on this dimension.

But the question goes beyond frontier models. Even smaller specialized models require something you can’t buy: high-quality proprietary data.

Llama 3 was trained on 15 trillion tokens. Epoch AI has documented that we’re approaching the limits of human-generated text data on the internet. Public data is being exhausted. Whoever has exclusive data — medical, financial, industrial, logistics, sensor, user behavior — has something that vibe coding can’t replicate.

And even those who train specialized models with proprietary data face a problem: the advantage is temporary. Another competitor can collect similar data and train a competing model in months. The differentiator needs to be continuously fed: more data, better curation, more efficient training pipelines, access to hardware that’s increasingly scarce and expensive.

The picture

If you’re thinking about starting a company, the question that matters has changed.

Before it was: “can I build this software?” Now the answer is almost always yes, fast and cheap.

The question now is: “do I have exclusive data nobody else has, and do I know how to turn that data into something useful that’s hard to replicate?”

If the answer is no, any competitor with Claude Code replicates your product in days. And then another one shows up. And another. The race to the bottom on price is immediate when the cost of building is close to zero.

If the answer is yes, you have a real moat — but a temporary one. Competing models trained on similar data can show up in months. Your differentiator needs to be continuously fed.

The era of easy startups is over. Not because building software got harder — it got way easier. But precisely because of that: when everyone can build the same thing in a week, the competitive advantage has to come from somewhere else. And that “somewhere else” requires capital and infrastructure that are orders of magnitude more expensive than writing code.

The garage still works. But what comes out of it can no longer be “an app.”

TL;DR: I have always “bent over” for AI. But if you only watched clips from the podcasts, I get why you are confused. Let me explain.

Anyone remember this video of mine: “16 Languages in 16 Days”? It is from late 2023 (1 year after the first ChatGPT launched) and it is about the first Rinha de Backend. How do you think I wrote code in 16 languages in 16 days??

I have been using AI to write code since early 2023 (3 years already). I did not start now: I never stopped. 🤷‍♂

“But you said AI would never be any good, you hate AI”

That is what you understood because you are lazy and only watch out-of-context clips or out-of-context tweets. If you read my blog, I have literally dozens of posts (particularly in the last 2 years) detailing every aspect of the evolution and use of AIs (whether for code, images, or 3D modelling).

“Hype?”

And what about my famous line:

“Your hype about AI is inversely proportional to your knowledge of AI” ?

Still correct. Same as the people who used to say Low Code would replace every programmer. It will not. Same thing now: no matter how good AI gets, it is not going to replace every programmer. Only the bad ones, as I already explained in this other rant.

Programmers like me have zero problem: we are the decision-makers who can decide what AIs cannot today and never will (it is an impossibility baked into the foundations of computing, I will come back to that).

The “hyped-up” crowd I talked about is every non-programmer startup bro who - with or without AI - throws garbage code into production and that is how things like the “Tea” app fiasco happen, remember?

There was no “hacking” attempt at all; their database was already wide open to the public in production: anyone could just download it. That is a “hyped about AI” guy.

Or the morons who already fired all their programmers because they think AI code will be so much better. Spoiler alert: it will not.

So now you are even more confused. “You don’t like AI then?” No, no, I like it. “But if you like it, it means it is already intelligent?” No, no. See how your line of reasoning makes no sense.

“Stochastic Parrot?”

Someone reminded me today that I also said:

“AI is just a glorified text generator”

Confused? “How can it be good if it is just a text generator??”

I really do not understand this line of reasoning. Text generators are objectively good. You and I use the auto-corrector on every email and messaging app every day. Whether it is the iPhone or Android keyboard. Whether it is Grammarly. None of you will say it has “personality” or even “intelligence,” but I think we all agree it is very useful. Even when it slips up now and then, most of the time it fixes our text just fine, right?

GPT or Claude or GLM or Gemini or DeepSeek, all of them are still “stochastic parrots” or “glorified text generators.”

• Stochastic parrot: something that repeats stuff using a random or partially random method (there is an element of entropy)
• Text generators: they use probabilistic math (transformers on the complicated side, or Markov chains on the simple side) to try to figure out the most likely next word/token, given the preceding text.

Every “AI” (more correctly “LLM”) has worked exactly like this from their launch in 2022 until today: gigabytes of hyper-dimensional matrices of weights and probabilities where your text/prompt is computed against those matrices to pick the “next token.” Concatenate that new token onto the original text and recompute everything again against the same matrices (more correctly, tensors), draw the next token from a small group of probabilities, concatenate, repeat, and so on.

That is a “text generator.” But yes, they are so good that they “seem” to have personality in their replies. And human beings are very easily fooled into “anthropomorphizing” non-human things. It does not take much.

Back in 2023, in the video “Understanding How ChatGPT Works” I explain the Turing Test, one of the first “conversational” apps that passed the test, “Eliza”, which already passed it without needing AI at all.

That is why I said they are “glorified,” because everyone who has little knowledge of AI thinks of it the way the ape in the movie thinks of the monolith: as a divinity that must be glorified.

“But What About Flow?”

“But Akita, on Flow you were against AIs.”

Nope, again, you only watched clips. Look at how I open the conversation: I am talking about the hysteria around the “AI 2027 Report”, I am talking about Sam Altman’s nonsense that they were very close to hitting “AGI” (General Artificial Intelligence, an intelligence that, like a human, reasons and decides things on its own and is capable of evolving autonomously). And all the controversies about AIs coming up with a “plan” to kill their owner (what I call “fanfics”).

Then I spend hours explaining in detail the history and exactly how the “next token calculation” is done, as I also gave more details here on the blog. And I always say there has to be some “new breakthrough” (that has not happened yet). As long as every new GPT or Claude is just an evolution of the previous one, there are limits. And I explained the limits.

It is not a “matter of time.” That does not exist. Even though we have never been to, say, Saturn, we know what it takes and more importantly: how much it costs. “WITH TODAY’S TECHNOLOGY” - which is always the premise - there is no practical way, it does not make sense.

Tomorrow some “new breakthrough” may appear that changes everything. But until it shows up, we cannot “count on it.” And my entire explanation is based on that premise. And the conclusion is objective and mathematical:

AGI is not achievable. That has not changed.

It does not mean current AIs are USELESS. That is the counter-conclusion whose reasoning I cannot understand either. On every podcast after the first one, I would come back saying: “The way I talk, some people seem to understand that I do not like AIs, but it is the opposite: I like them.”

I got tired of repeating this on the podcasts, on the blog, on X, but that is the part everyone pretends is not there and OMITS. That is why I always put everything in writing here on the blog and, as I said, you can see I was already using it back in 2023 - 3 years ago.

In summary: EVERYTHING I said on the latest videos of my channel and on the podcasts STILL HOLDS. The explanation is still correct. What is wrong are YOUR CONCLUSIONS. Review them and interpret them literally and not subjectively, with the lack of knowledge you people have. Do not ignore the terms I used that you do not understand. The argument only makes sense if it is complete, and it cost me 4 hours to explain it in each video.

A Message to the “Hyped”

I said this on X the other day:

It does not matter if you want to call it “Vibe Code,” “Agentic Engineering,” “AI Assisted Programming,” it is all bullshit.

EVERYTHING now is “programming with AI.”

And there are only two ways to do it: the right way and the wrong way. The wrong way is the way you and the owner of the Tea app (probably, allegedly) do it: you let AI write the code, you have no clue how to review it or criticize it, you push it to production and let users use it, with no idea of the risks.

The right way: I spent TWO MONTHS writing more than TWENTY POSTS on this blog explaining the right way, which I called “Agile Vibe Code,” but it is basically “Software Engineering applied to AI” and guess what: you need to have studied and have experience to know it.

It is not 2026 and it will not be 2027 or anywhere near as soon as you think before Claude or Codex “replace ALL programmers.” No, they WILL replace all the bad ones and that is excellent! Again, read this rant.

You are never going to build a “new Linux” and “replace Linus Torvalds” with AI. You will manage to “copy parts,” sure. Copying is not enough. Bad programmers were already copying before, and it never made them good.

A Message to the “AI Haters”

Give up, this is a one-way street. Same as mobile, same as the internet, same as microcomputers, etc. Pandora’s box is open, there is no closing it anymore. AIs are here to stay.

“But you said AI was a bubble that was going to pop!”

Again, either you are playing dumb or you are dumb.

The 2001 Internet Bubble popped, but the Internet did not disappear. On the contrary, it grew! What disappeared were the companies that thought they would make easy money riding the bubble wave, and everyone who blindly believed in it. Still, whoever was an “Internet Hater” lost out too.

At this point, every anti-AI argument already sounds like a lousy excuse. Let’s look at a few:

“AI makes lots of mistakes, every now and then I see some half-assed code.”

True, and that is exactly why I said not to get hyped for nothing. It makes mistakes, I catch them every day. Up until last year, the error vs. success rate was high enough that I could not recommend any amateur use it on a daily basis. Only someone who pays close attention and knows how to fix it - like me.

However, in 2026, that rate has improved significantly. It does in fact hit more than it misses now, enough for me to trust it without “micro-managing” every step.

The truth is every human programmer makes mistakes, and they make MANY. Whoever makes mistakes has confirmation bias and does not think they mess up that much. Only someone watching from the outside - someone like me, who has managed hundreds of programmers across dozens of projects - knows they screw up much more than they are prepared to admit.

I GOT TIRED of asking people to only push PRs with unit tests: everyone ignores it.

I GOT TIRED of asking people to at least run it once on their own machine to see if it works, instead of me pulling the PR and finding out it does not even run: everyone ignores it.

I GOT TIRED of asking people not to just copy and paste from stackoverflow, and at least adjust and adapt it for our project. Everyone ignores it.

I GOT TIRED of asking people not to dump everything into the same giant file and to refactor from time to time so technical debt does not pile up: everyone ignores it.

I GOT TIRED of asking people not to push more commits with messages saying “bug fix,” without explaining what is actually in there: everyone ignores it.

I GOT TIRED of asking people to remember to update the documentation when they change some feature, to make it easier for whoever is going to test it: everyone ignores it.

I GOT TIRED of asking people to cover a bug fix with a regression test so we would not see the same error again. The same error kept repeating: everyone ignores it.

I GOT TIRED of asking people to follow the conventions we agreed on in the project and not write different code with different patterns. Everyone ignores it.

I GOT TIRED of asking people to adjust deploy scripts, CI or things like that when there are pieces that affect the infra: everyone ignores it.

I GOT TIRED of asking people not to pile up a bunch of code that makes no sense together and not to git add . at the end and just write “new feature” and commit everything together. Everyone ignores it.

These are just a few examples. Know what is new: Claude and Codex do not ignore. Everything I just listed, which happens on EVERY project with humans, no matter the size of the project, does not happen to me anymore with Claude.

Understand: all of this should be the basics of the basics, intern level. But I GOT TIRED of asking seniors to be more careful, to not set a bad example for the juniors: EVERYONE IGNORES IT.

And now, all these people who WORE ME OUT, are precisely the ones who became “AI Haters.” But of course, the AI does everything they DO NOT. Look in the mirror and reflect on whether your code was really that good (Spoiler: it was not).

90% of all code produced is nowhere near something like “optimization of the Linux memory management solution” or “bug fix for a performance regression in the file system drivers” or “improvement in the firewall security algorithm” or “rewriting this old Assembly part in C”..

90% of most code produced day to day is MUNDANE, it is consuming an API, it is writing a front-end, it is one more report, one more CRUD, one more email validation, one more cleanup job, one more deploy script. Absolutely NOTHING actually “interesting.”

What did I like about LLMs? It REMOVES from my plate all the mundane tasks and lets me focus on the parts I like: research, forming hypotheses, benchmarks, a/b tests so I can make better decisions, integration tests that make sure the various parts of my system actually work. Everything I could not do before, because 90% of my time was spent fixing somebody’s crappy CSS.

I HATE messing with CSS. It is about time I did not have to anymore.

I HATE writing CRUD. It is about time I did not have to anymore.

I HATE doing the initial dev environment setup for every different project. It is about time I did not have to anymore.

I HATE having to spec out idiotic things like mapping fields on a poorly designed fintech/bank API. It is about time I did not have to anymore.

I HATE having five hundred poorly designed front-end frameworks to stitch everything together and pray it works through trial and error. It is about time I did not have to anymore.

I HATE having to attend sprint meetings, where what was asked for keeps getting modified along the way because nobody paid attention. It is about time I did not have to anymore.

I HATE being blocked, having to wait around because another dev or another team is working on something that affects my side and in the end I will spend days later just fixing merge conflicts by hand. It is about time I did not have to anymore.

Who are the “AI Haters”: exactly everyone who used to block me before, the ones responsible for dragging out and delivering in bad quality all the MUNDANE tasks, and thinking they were doing something big.

What History Has Taught Me

Computers understand machine instructions. They do not give a damn about our “favorite languages.” That is what I spent hours explaining on the podcasts and in the videos on my channel.

Fuck your favorite language/framework. Fuck your favorite design pattern. At the end of the day, the machine only cares about the binary that is going to run.

Back in the day, it was extremely costly to feed those instructions to the machine. We had to literally key in, bit by bit, each instruction, at the exact address in memory. Whether with WIRES or with SWITCHES, ONE BIT AT A TIME:

Fortunately, things evolved and we improved the ways of “INPUTTING” instructions and data. Whether with punched paper or teletypes (electric typewriters adapted as dumb terminals):

Programming was expensive, because it was VERY costly to “fix” an error. There was no easy “backspace.” The moment you went to type, you had to be VERY SURE of what you were going to type, without screwing up!

Even by the late 70s, early 80s, it had already evolved a lot, but having permanent storage was an OPTIONAL thing on most “micro” computers. We had to type the programs in from scratch to run them and when the machine shut down, whatever was in RAM was wiped and we lost everything. Recording was expensive, and one of the most popular options was recording to cassette tape:

But to record/read just a measly 1 kilobyte of data, it could take MORE than 20 seconds. A little 10-kilobyte game (which is very little), would take almost 4 MINUTES to load.

You have no idea what 10 kilobytes means. Any PNG or SVG icon or any stupid little JS file on your website has way more than that.

All this to say the following:

• computers run machine instructions, to this day
• it has always been costly to feed those instructions to the computer

Nowadays we have NVME SSDs that let me read 1 gigabyte today (<70ms) faster than I used to read 10 kilobytes in the 80s.

But to compensate, our programs kept getting more and more complex and “bloated.” Once memory, storage, data bus, everything became orders of magnitude faster, we humans kept throwing more and more data at them. A text editor today does the same thing a text editor in the 80s did: edits text. But, of course, it has way more features: pretty fonts, smooth scrolling, auto-correct, auto-format, etc.

We traded resources for comfort, and that is a good thing.

I said in my videos, in the recent rant posts, that it was a very bad thing that the startup bubble only popped in 2022 (and its aftershocks are still going today). We traded programming efficiency for cheap bad programmers. Why bother trying to be more efficient if it was “cheap” to just throw more “bodies” at the problem? The same mentality that enabled the rise of cheap software sweatshops in the 2000s, cranking out bad software like there was no tomorrow.

Personally, I am very happy we finally took one more step toward feeding instructions to the machine more efficiently. LLMs, our stochastic parrots, are, in fact, the most efficient way to produce 90% of the instructions we need to give the machines so they can compute what we need. Same way I do not miss punched cards, or teletypes, or cassette tape, if I do not need to use an IDE in my day-to-day anymore, I will not miss it.

I did not choose to become a programmer to become an IDE operator. When I started, the concept of IDEs did not even exist.

I chose to become a programmer because I like the idea of instructing a machine to compute the things I want. Whether it is a spreadsheet or a game. HOW those instructions are input is not the main thing for me. It never was. IDEs were just a small phase within decades of career and they will not be the last.

I do not understand the reasoning of the over-hyped or the over-haters. Why do you need to glorify a hammer? Why do you need to hate a hammer? That is all I needed to say 🤷‍♂

Some Idiotic Excuses

“But Anthropic (or OpenAI) are evil”

Fuck that. Microsoft was too, it even went through an anti-trust trial in the year 2000 that almost split the company. Even though I prefer Mac or Linux today, has Windows stopped being the most used operating system in the world? No.

“But AI uses a lot of energy, what about the environment?”

Fuck that. This was never a consensus (and most likely never will be and is not even a problem). The planet has already gone through 5 or 6 great extinction events before, the last one was a meteor that fell and wiped out the dinosaurs. We have gone through multiple Ice Ages. The planet is going to be fine, don’t worry.

The problem of the last decade was the stupidity of not investing in more nuclear power plants - and now that option is finally back on the table. I said on Flow that Germany shutting down theirs was one of the dumbest decisions of all time, and I stand by it: it was.

Those are the two most common ones I can think of today. But that is how it is: anything is an excuse now. Pandora’s box has been opened, there is no going back.

The name is Frank Sherlock — a local image cataloging and search system using AI. You point it at a folder (it can be a NAS with terabytes), it scans everything, classifies each file using a vision LLM running locally on your GPU, and gives you full-text search over the content. It’s not cloud, nothing is sent out, it runs 100% on your machine.

Here are some examples of text it extracted from some of my images:

And check out the Surya OCR details: it read the text on the Game Boy screen perfectly:

More than that, I have directories of screenshots of payment receipts. I would never find anything in there again, but now:

It does make some mistakes, of course, with obscure anime (it keeps thinking everything it doesn’t recognize is Evangelion 😂). But it surprisingly gets many of them right too. And the descriptions themselves already help a lot.

You’ll need a minimum GPU (I only tested on my 5090, but there are smaller models to download for smaller GPUs, and it theoretically supports AMD and Mac too, but I haven’t tested yet - I’ll accept Issues and Pull Requests from anyone who wants to do beta-testing on Mac and Windows). You just need Ollama installed and running; optionally, Python (to have Surya OCR, which is optional, but is the best).

I’ll mark it as “1.0” when I have more people testing on Windows/macOS and I have the certificates to sign the executables properly. This is still a “beta” version! Compile and run it yourselves on your machines, everything is explained in the README.

And I did this with my “Agile Vibe Coding” — basically, programming in partnership with an LLM (in this case, Claude Code).

Agile Vibe Coding works. And it works very well. But the idea is only 10% of the work. The other 90% is engineering.

Engineering requires experience, judgment, and knowing how to ask the right questions. The LLM is an excellent executor. But whoever decides what to execute, in what order, and why, that’s still the developer’s job.

There’s a growing discourse that anyone with a good idea can build software now. In a certain sense, yes, you can get a prototype up fast. But the distance between “runs on my machine” and “software that works on 3 operating systems, survives cancellations in the middle of processing, doesn’t corrupt data, and scales from 94 test files to 500,000 in production” is still enormous. That gap is engineering, and engineering still demands someone who knows what they’re doing.

I’ll tell the complete story: from initial research to release, going through benchmarks, proof of concept, architecture decisions, multi-platform CI/CD, and everything that sat between “I have an idea” and “here’s the AppImage, the DMG, and the MSI”.

The Original Idea

It all started with a simple question: can open-source vision LLMs actually classify content? I’m not talking about “woman on the beach” — any model does that. I’m talking about looking at an image and saying “this is Ranma, from the anime Ranma 1/2 by Rumiko Takahashi, in a scene from the OVA The Battle for Miss Beachside”. Are we at that level yet? (TL;DR no, but enough)

And if we are, can you build a smart file catalog? Something where I point at my NAS with terabytes of media accumulated over decades and can search by content, not by filename? Anyone with a home NAS knows: after a few years, files pile up and directory organization simply stops scaling. You know you have that 2019 payment receipt somewhere, but the file is called IMG_20190315_142301.jpg and it’s in a directory with 3,000 other photos.

My hardware: AMD 7850X3D, RTX 5090, Arch Linux. Absolute restriction: no remote APIs, no OpenAI, no cloud. Everything open-source, everything local. If I’m going to process terabytes of personal files, including financial documents and private photos, I don’t want to send anything to third-party servers. Plus the cloud API cost for that volume would be prohibitive.

But first: research. Without knowing if the technology delivers what I need, there’s no point building anything. Small scripts, quick prototypes, different models. See what works before writing the first line of code of the real app. This is a pattern I’ve followed for years: validate the riskiest assumption first. If the vision LLM can’t classify decently, everything else is a waste.

A/B Research: Benchmark Driven Development

This is the part most people skip, and it’s exactly where experience makes the difference. The temptation to jump straight into implementation is enormous. “I’ll use model X because I read on a blog that it’s good.” No. Before choosing model, framework, or architecture, I set up a formal benchmark.

I built a test corpus with 94 files: 60 images (photos, screenshots, anime, documents, receipts), 9 audios, 13 videos, and 12 documents. For each file, I created a ground truth in JSON with the correct classification — type, description, series (when applicable). That ground truth is what lets you measure real accuracy, not “I looked at the result and it seemed OK”.

The benchmark has 6 phases, each answering a specific question:

1. Metadata: how much does it cost to extract basic metadata? (answer: cheap, 0.07s/file)
2. Images: which vision model is best? Which OCR?
3. Audio: does Whisper work? Which model size?
4. Video: does frame-based classification work?
5. Unified catalog: does the full integrated pipeline work?
6. Cost projection: how much time and money to process a real NAS?

Phase 2: Vision — The Result Nobody Expected

I tested qwen2.5vl:7b, llava:13b, and minicpm-v:8b on 30 labeled images. The result:

The 7B parameter model crushed the larger ones. It’s not a typo. qwen2.5vl:7b beat llava:13b (almost twice its size) in every metric, and was also 3x faster. This contradicts the intuition of “bigger model = better model”. In practice, it depends on the task and the prompt.

Naturally, the next question is: what about the 32B? Same model, giant version. We should be able to get much more, right? Wrong:

The 32B gave +0.06 in series accuracy (literally 1 more hit out of 16 labeled items) and cost 29x more time. For someone who’s going to process hundreds of thousands of files, this trade doesn’t close. 29x slower means a 6-hour job turns into a week-long job.

Here I’ll make a comment about tooling: I did the first round with Claude Code and had asked it to pick the models it thought were best. But then I decided to go to GPT Codex and it made other suggestions I found interesting to test. In summary: I’ve been finding Codex much better for experimentation and exploratory code, for actual research. I find Claude better when we already know exactly what we want.

With Codex, I tested the new candidates qwen3-vl:8b and qwen3-vl:30b-a3b with 3 repetitions for statistical significance. The result? Both worse than qwen2.5vl:7b — type_accuracy of 0.55 versus 0.89 for the incumbent, with a 95% confidence interval that doesn’t even come close. And even slower: 2x and 2.2x respectively. A newer model isn’t always a better model for your use case. qwen3-vl frequently returned truncated or malformed JSON — a real regression in robustness.

OCR: Surya vs Ollama Vision

For text extraction (scanned documents, receipts, screenshots with text), I tested two engines:

Surya finds text in many more files (83% vs 58%), but is 5x slower. When it finds text, the quality is practically the same (similarity > 0.94 on both). Obvious solution: hybrid approach. Use Surya when you need maximum coverage, Ollama Vision as fast fallback. The pipeline design became: try Surya → if it fails or doesn’t find text → fallback to Ollama Vision. That’s why I said at the beginning that Surya is optional, if you don’t want to install it.

Cost Projection

Phase 6 did something I rarely see in open-source projects: cost projection for real usage. With the timings measured per file type, we extrapolated to NAS scenarios:

Take these numbers with some skepticism because it’s back-of-napkin math. $34 in electricity to classify 500,000 files with a local GPU. Try doing that with the GPT-4 Vision API — at $0.01 per image (conservative), that’s $5,000. The price of my setup (GPU + electricity) pays for itself on the first big use.

The lesson: benchmark, don’t guess. I could have assumed the bigger model would be better, or that the newer one would beat the older. The data showed the opposite. ~2 hours of benchmarks saved me from wrong choices that would cost days of rework (in the old days I would have said “weeks”).

Proof of Concept in Python

With the benchmarks in hand, the next step was to validate the complete pipeline before moving to Rust. Not the benchmark pipeline (which tests each model in isolation), but the real classification pipeline — the exact sequence of calls that the final app will make for each file.

I created a Python prototype — 754 lines in a single file (classification/run_classification.py) — implementing the winning strategy from the benchmarks.

The pipeline has 4 enrichment stages:

1. Primary classification: sends the image to qwen2.5vl:7b with a structured prompt, asks for JSON with type, description, tags, confidence
2. Anime enrichment: if the primary type is anime/manga/cartoon, does a second pass with a specialized prompt asking for series, character, scene, artist
3. Document/OCR: if it’s a document or receipt, extracts text with Surya and/or Ollama Vision, then asks for structured data (dates, values, transaction IDs)
4. Output: writes the result in YAML mirroring the directory structure of the source

The most critical part is parsing the LLM’s JSON. Anyone who has worked with LLM output knows they’re… creative with formatting. Sometimes it comes with markdown fences (json ... ). Sometimes there’s text before and after the JSON. Sometimes the JSON is almost right but missing a closing brace. The prototype implemented a 3-attempt cascade that later became the rule for the whole project:

1. Direct parse: json.loads(response) — works in ~70% of cases
2. Brace-balancing extraction: finds the first {, counts opened and closed braces, extracts the substring — catches another ~20%
3. Regex field salvage: if all else fails, uses regex to extract individual fields (“type”: “…”, “description”: “…”) — saves the last ~10%

This cascade stayed in the Rust code practically identical. A well-done PoC shortens the path to production.

Result: 60 images processed, zero errors, 6.29s/image average. The pipeline worked end to end. Time to build the real app.

Building the Tauri App

At this point, I tried to continue with Codex, but then it choked on trying to convert the Python PoC to Tauri. But since the choices had already been made, I went back to Claude Code, and it had no problems mapping from Python to Rust.

Here’s where vibe coding shows what it can do. I’ll tell the real timeline, commit by commit, so you get a sense of the rhythm. The timestamps are from git log, so they’re accurate.

Saturday 02/21 (19:29 → 21:08) — 6 commits, 1h39

It all started with research. Six commits of setup, benchmark scripts, results analysis:

f57221c 19:29 Phase 0: Project setup with uv, environment verification
4977497 19:45 Implement all phases: metadata, image/audio/video classification
af6e3aa 19:49 Add research results report
41d6c2a 20:12 Add per-file timing, OCR phase, cost estimation
0cd1b10 21:02 Fix Surya OCR, re-run on 94-file corpus
25b3ace 21:08 Add conclusions, cost analysis, recommended pipeline

Saturday night, pure research only. Not a single line of app code. But when I went to bed, I knew which model to use, which OCR approach, and how much it would cost in time and electricity.

Sunday 02/22 (13:05 → 23:30) — 14 commits, ~10h25

Sunday was the day of heavy construction. I woke up, had lunch, and sat down to work.

13:05 — First commit of the day: the Python classification prototype. 749 lines validating the complete classification pipeline, the JSON parsing cascade, and the conditional enrichment. This prototype wasn’t throwaway — it was the executable design document for the Rust pipeline that would come later.

I took a break to go out, take a walk, have a glass of wine, then came back and continued:

17:31 — Benchmarks updated with the new candidates (qwen3-vl:8b and qwen3-vl:30b-a3b). Three repetitions each, confidence intervals. They confirmed that qwen2.5vl:7b was the right choice — not by a little, but by a huge margin.

17:56 — The “big bang”: Tauri app scaffold. 9,631 lines inserted in a single commit. The entire app structure: Rust backend with SQLite + FTS5, React frontend, config system, file scanner, data models, query parser for natural search. At that point the app was already searching the database. It didn’t have classification yet, but the foundation was solid — and that’s exactly the point. The scaffold came with tests, TypeScript types, and the directory architecture I defined. Claude generated the code, but the module structure (config, db, scan, models, query_parser) came from how I wanted to organize responsibilities.

19:04 — The heaviest commit of the project: 4,186 lines. Classification pipeline in Rust (1,069 lines of classify.rs — practically the translation of the Python PoC), thumbnail generation (Lanczos3, 300px, JPEG 80%), incremental scanning with fingerprint, the Surya OCR Python script, runtime detection for Ollama, and the brutal expansion of the database with upsert, touch, delete, and FTS indexing. In one commit. With 47 tests. I had to make the architecture decisions (how the cache mirrors the rel_path, how the scan is divided into two phases, how errors propagate), but Claude wrote most of the code and the tests that came with it.

19:55 — UI redesign, scan cancellation, auto-cleanup of orphan classifications, reorganization of the whole repo (moved everything from research to _research_ab_test/). CI and release workflow already configured in this commit — I knew I was going to need them the next day.

21:02 — DB resilience (WAL mode, backup, health check), root management (add, remove, list monitored directories), zoom, sidebar redesign with tree view, thumbnail fix. Four features in one commit. In a manual workflow, each one of these would be a separate PR with days of review.

21:14 → 21:39 — Read-only database mode for sandbox filesystems, resume of interrupted scans on startup, grid tiles redesign with hover overlay, selection model, infinite scroll. Three commits in 25 minutes. Claude was on an absurd pace.

22:41 — Multi-select with Ctrl/Shift click, collage preview with selected items, Ctrl+C copies to the OS clipboard.

23:30 — The big refactor: monolithic frontend (everything in App.tsx - if you don’t explain, Claude always does this) broken into 15 components + 10 hooks + 84 frontend tests. This is the kind of thing that normally takes a full day of tedious work. With vibe coding, it was a one-hour commit. Claude extracted each component, created the hooks, set up the tests with proper mocks, and kept everything working. I just had to say “refactor this monolith into components and hooks, and write tests for each one”.

Monday 02/23 (00:09 → 14:33) — 30 commits, ~14h

Monday was polish, robustness, and the cross-platform marathon.

00:09 — Multi-OS abstraction: all platform-specific code isolated in the platform/ module. This decision, taken early, saved hours of pain in CI. When Windows needed special treatment for UNC paths, the change stayed contained in platform/process.rs instead of spread across 8 files.

00:12 → 01:18 — Quick sequence: cargo audit in CI, duplicate removal, GPL-3.0 license, help dialog (F1) with query syntax examples, sort controls for results, formal SQLite migration system, context menu (copy, delete, rename). Six commits in just over an hour.

09:38 — After sleeping about 8 hours, the first commit of the morning: extraction of the LLM module. The monolith of Ollama calls that lived inside classify.rs was separated into llm/client.rs (HTTP calls, JSON parsing), llm/management.rs (download, listing, cleanup of models), and llm/model_selection.rs (hardware-aware selection by tier). Atomic file ops so cache doesn’t get corrupted if the process dies in the middle of a write.

10:54 — EXIF location extraction (GPS coordinates → readable address), metadata editing modal, setup instructions per OS (each OS has different dependencies for Ollama and Python).

11:34 — PDF support: scanning, indexing, and preview using PDFium. Not trivial — PDFium needs a native binary per platform, page rendering to image, blank page detection (so you don’t generate a thumbnail of an empty cover), thumbnail assembly with the first 2 pages that have content, and native text extraction as a faster alternative to OCR.

12:08 — Albums and Smart Folders. Albums are manual collections (the user drags files in), Smart Folders are saved queries that appear in the sidebar and update automatically. Two database migrations, new sidebar component, drag-and-drop. In 34 minutes.

12:11 → 12:52 — macOS-inspired SVG icons in the sidebar, CLI argument support (sherlock /path/to/folder), copy description/OCR text in the context menu, PDFium path fix in production, icons and screenshots in the README, tauri script in npm, sidebar toggle, dynamic titlebar, Windows compilation fix (Unix-only imports). Ten commits in 41 minutes. Most of these were issues that showed up in CI or during manual testing.

13:14 → 13:54 — The CI fixes marathon. Auto-provision of the Surya OCR venv with progress bar in the SetupModal, icon regeneration with alpha channel, cargo fmt + clippy + UNC paths fix on Windows, tests for help dialog examples, individual folder rescan, Windows assertions fix, release workflow permissions fix. Seven hardening commits. Each one resolving a real bug that appeared in the CI matrix or in testing.

14:26 — Drag-and-drop to reorder roots in the sidebar, scan cancellation before deleting a root (so you don’t leave the scan running in the background on a directory the user removed — a subtle edge case that could cause a crash).

14:33 — Last commit: responsiveness fix in scan cancellation. Check the cancel flag after each classification, immediate poll instead of waiting for the next tick. Small detail, big impact on UX.

Architecture Decisions

Here’s what separates “letting the LLM write code” from “building real software”. None of these decisions came from a prompt. Claude didn’t suggest any of them spontaneously. I had to ask for each one.

Read-Only Principle

The app never writes to the scanned directories. Everything — thumbnails, classification cache, database — sits in ~/.local/share/frank_sherlock/. This is more than good practice, it’s respect for the user’s data. If someone points at the company NAS, the app can’t go around creating .sherlock/ in every subdirectory. If the directory is mounted as read-only via NFS, the app needs to work normally. It sounds obvious, but many cataloging apps you know create caches and thumbnails inside the source directories. (cough Synology @eaDir cough)

Incremental Scanning

Scanning terabytes of data every time the app opens would be insane. The scan is incremental in two senses:

1. Discovery phase (fast): walks the filesystem comparing mtime + size of each file. If nothing changed since the last scan, it doesn’t even read the content — just updates the “seen in this scan” marker. For a NAS with 500K files where 99% hasn’t changed, this phase takes seconds, not hours.
2. Processing phase (heavy): only for new or modified files. Calculates fingerprint (SHA-256 of the first 64KB), generates thumbnail, classifies with the LLM. And here’s where move detection comes in: if a file changed path but the fingerprint is the same, the app preserves the entire classification already done and just updates the path. You reorganized 10,000 photos into new folders? The app detects and doesn’t reclassify any of them.

The checkpoint is per file. If the scan is interrupted (the app crashed, the user closed it, the power went out), the next time it resumes from the last processed file, not from zero. This is implemented via scan job persistence in the database: the scan cursor is saved in scan_jobs.

Cooperative Cancellation

The scan runs on a separate thread via tokio::spawn_blocking. To cancel, I use an AtomicBool shared between the scan thread and the frontend. The flag is checked:

• Before each file in the discovery phase
• Before each classification in the processing phase
• After each classification (in case the Ollama call takes a while)

This ensures cancellation responds in at most the time of one classification (~1 second), not the time of the whole scan. Without this design, canceling a scan of 500K files could take minutes — or simply not work.

Database Resilience

SQLite with WAL mode (allows concurrent reads during writes), health check on startup, automatic backup before migrations, formal migration system via rusqlite_migration. Five migrations in total:

0. Initial schema (files, roots, scan_jobs tables, and the virtual FTS5 table for search)
1. location_text column for EXIF address
2. FTS index rebuild (needed after changing tokenization)
3. albums and album_files tables for manual collections
4. smart_folders table for saved queries

Migrations are identified by position and can never be edited or reordered after being published. This is the kind of rule you learn after corrupting someone’s production database once. The rule is coded in the project’s CLAUDE.md so future vibe coding sessions don’t violate it.

Hardware-Aware Model Selection

Not everyone has an RTX 5090. The app detects the GPU on startup and picks the appropriate model:

• Weak GPU or no GPU: qwen2.5vl:3b (small tier — runs on anything)
• GPU with >= 6GB VRAM: qwen2.5vl:7b (medium tier, the benchmark default)
• Apple Silicon with >= 48GB unified: qwen2.5vl:32b (large tier, only where unified memory allows without swap)

Detection uses nvidia-smi on Linux/Windows, system_profiler on macOS, and sysinfo as fallback for system RAM. The result is cached in the Tauri AppState so it doesn’t keep running subprocesses all the time.

Multi-OS and CI/CD

If there’s one part of the project that justifies having experience, it’s this one. Making software that compiles is easy. Making software that compiles and passes all tests on Linux, macOS, and Windows at the same time teaches you humility.

Platform Module

All OS-specific code lives in src-tauri/src/platform/:

• gpu.rs: GPU detection (NVIDIA via nvidia-smi, AMD via sysfs/rocm-smi, Apple via system_profiler)
• clipboard.rs: image copy to clipboard (xclip on Linux, pbcopy on macOS, PowerShell on Windows)
• python.rs: Python location (python3 vs python in PATH), venv paths per OS
• process.rs: subprocess execution abstraction with output handling

This means classify.rs, scan.rs, thumbnail.rs — none of them know which OS they’re running on. They ask the platform and the platform resolves it. When Windows needed special treatment for UNC paths (those that start with \\?\), the change stayed contained in platform/. When macOS needed a conditional import, same thing. The rest of the codebase wasn’t touched.

GitHub Actions Matrix

Two workflows:

• CI (push + PR): build and test on Linux, macOS, and Windows. Each push runs cargo test + npm test on the 3 OSes. Includes cargo fmt --check, cargo clippy -- -D warnings, and cargo audit. If any platform fails, the PR doesn’t pass.
• Release (tags v*): build via tauri-action, generates AppImage (Linux), DMG (macOS arm64), MSI (Windows), and creates a Draft Release on GitHub with the binaries attached.

The 10+ CI fix commits on Monday morning were the least glamorous part of the project. Things like:

• #[cfg(not(target_os = "windows"))] on imports that use std::os::unix::fs::PermissionsExt
• dunce::canonicalize instead of std::fs::canonicalize because Windows generates paths with \\?\ prefix that break string comparisons
• Install rustfmt and clippy explicitly on the runner because they don’t always come in the default GitHub Actions toolchain
• Remove the macOS Intel target from the release workflow (Apple Silicon only — not worth the cost of maintaining two Mac targets)

Nobody posts these things on X. But without them, your app doesn’t build on 2 of the 3 targets.

External Integrations

The app depends on 3 external systems. Each one brought its own problems.

Ollama

Ollama serves the vision models via local REST API (port 11434). The app does:

• Status check: checks if Ollama is running and lists installed/loaded models
• Model download: if the recommended model isn’t installed, offers download with a progress bar via API streaming
• Generation: sends image in base64 + prompt, receives JSON (with the 3-level parsing cascade)
• Cleanup: unloads models from VRAM when not classifying, so it doesn’t monopolize the GPU from the user’s other applications

Ollama is the only hard requirement. Without it, classification doesn’t work. The SetupModal guides the user through installation and model download.

Surya OCR

Surya is a Python OCR engine that runs locally. The problem: the app is Rust and can’t depend on a system Python installation. The solution:

• The app maintains an isolated Python venv at ~/.local/share/frank_sherlock/surya_venv/
• The surya_ocr.py script is bundled as a Tauri resource (packaged in the binary)
• On first use, the SetupModal offers to automatically provision the venv (finds Python, creates venv, pip install surya-ocr + dependencies)
• Classification calls the script via subprocess, passes the image as argument, reads the extracted text from stdout

Surya is a soft requirement: if it’s not installed, the app works normally — it just won’t have dedicated OCR. The pipeline gracefully degrades to use Ollama Vision as fallback, which is worse in coverage but works. The user sees a warning in setup, not an error that blocks usage.

PDFium

For PDFs, I needed native text extraction and page rendering for thumbnails. PDFium is Chrome’s PDF engine, and has Rust bindings via pdfium-render.

The PDFium binary is downloaded by a script (scripts/download-pdfium.sh) and bundled via lib/ in Tauri resources. Each platform gets the correct binary (.so, .dylib, .dll). lib/ is gitignored — the binaries are downloaded at build time, not versioned.

The PDF pipeline:

1. Tries to extract native text (no OCR) — many PDFs already have a text layer
2. If there’s enough text, uses it directly for indexing (faster and more accurate than OCR)
3. If not, renders the page and sends it to the image pipeline (Ollama Vision)
4. Detects blank pages, finds the first page with real content
5. Generates thumbnail as a montage of the first 2 pages with content (gives a better sense of the document than just the cover)

What Agile Vibe Coding Really Is

OK, now the point that really matters. The reason I’m writing this.

What Claude Did

• Wrote most of the Rust and TypeScript code
• Generated 166 Rust tests and 172 frontend tests
• Implemented JSON parsing with 3 fallback levels
• Set up CI/CD with 3-OS matrix
• Did massive refactors (monolith → 15 components + 10 hooks)
• Handled edge cases of encoding, Unicode paths, and exotic file formats
• Wrote SQL queries, migrations, FTS5 indexes
• Implemented GPU detection, clipboard per OS, Python resolution
• Created the setup flow with progress bar and model download
• Debugged and fixed dozens of cross-platform compilation issues

The speed is hard to describe without sounding like exaggeration. Saturday’s 19:04 commit, the one with 4,186 lines and 47 tests, took about an hour including my review. A human dev, even a good one, would take a full day to write that with the same test coverage.

What I Did

• Decided to do benchmarks before writing any app code
• Chose Tauri over Electron (smaller footprint, native Rust, no Node runtime in prod)
• Defined the read-only principle as an inviolable rule
• Designed the incremental scan with move detection via fingerprint
• Decided on cooperative cancellation with AtomicBool
• Demanded formal schema migration (no ad-hoc ALTER TABLE in loose scripts)
• Insisted on platform abstraction from the first multi-OS commit

And mainly: I asked the annoying questions. “What if the scan is canceled in the middle?” became the checkpoint system. “What if the database corrupts?” became WAL + backup + health check. “What if the person doesn’t have a good GPU?” became tier model selection. “What if Surya isn’t installed?” became a soft requirement with fallback. “What if the user deletes a root that’s in the middle of a scan?” became cancel-before-delete. “What if the file moves but the content is the same?” became move detection.

Oh, and I decided when to stop adding features and publish.

That last one is underrated. The temptation to keep adding “just one more thing” is enormous when the marginal cost of implementing is low. Claude implements any feature I ask for in minutes. But software that’s never published is useless to anyone. Knowing when to stop is a skill no LLM will give you.

The Real Pattern

Agile Vibe coding isn’t “asking the LLM to make an app”. It’s pair programming with a partner who’s stupid fast, has perfect memory, and never complains about refactoring. You say what you want, it implements, you review and adjust the direction. But if you don’t know where to go, speed doesn’t help — you just get to the wrong place faster.

The questions I asked — about resilience, cancellation, multi-OS, graceful degradation, edge case detection — none of them came from the LLM. They came from years building software that has to work in real environments, with real users, on diverse hardware. Claude isn’t going to ask you “what if the user pulls the network cable in the middle of downloading the model?”. But if you ask, it implements the handling in minutes.

It’s tempting to look at this project and conclude that anyone with a good idea could have done the same. But try to imagine: without the decision to do benchmarks, I would have picked the wrong model. Without the Python PoC, I’d have discovered JSON parsing problems in production. Without the platform abstraction, I’d be debugging Windows issues scattered across 15 files. Without the scan checkpoint, users would lose hours of processing on every crash. Without the formal schema migration, the first update would break everyone’s database.

Think of an architect with an absurdly efficient construction crew. The architect doesn’t need to lift every wall, but needs to know where they go and what happens if you take one out. The crew executes fast, works at night, doesn’t complain. But someone needed to have drawn the blueprint. Without a blueprint, it’s just a pile of bricks stacked quickly.

Final Numbers

For those who like concrete numbers:

The first commit was Friday 02/21 at 19:29. The last was Monday 02/23 at 14:33. Discounting sleep (~8h on Saturday/Sunday night, ~8h on Sunday/Monday early morning) and breaks, that’s ~26 hours of work distributed over a weekend.

From zero — without a single file in the repository — to published binaries for 3 operating systems, with automated tests running in CI on every push. Including the research phase, which on its own would justify a sprint.

Conclusion

Agile Vibe coding works. But it works like any powerful tool: in the hands of someone who knows what they’re doing.

The idea for Frank Sherlock would fit in a tweet: “classify images with local LLM”. But turning that into real software required: benchmarked research with formal ground truth, proof of concept validating the complete pipeline, incremental architecture, error handling at 3 levels, cooperative cancellation, formal schema migration, platform abstraction, CI/CD with 3-OS matrix, integration with 3 external systems with graceful degradation, and 338 tests to ensure none of that breaks when someone runs cargo update.

The LLM sped all that up absurdly. But it didn’t replace the need to know what to do. If I had asked “make an app that classifies images” without the 2 hours of benchmarks, without the proof of concept, without the architecture decisions, without the annoying questions about edge cases, the result would be a prototype that works on my machine and breaks anywhere else. And I probably wouldn’t even notice until someone complained.

The vibe needs an experienced conductor. For now, that conductor is still human.

Code at github.com/akitaonrails/FrankSherlock. GPL-3.0, local-only, open source.

So I did what any programmer would do: sat down, wrote a spec document, and with the help of Claude Code (Claude Opus 4.6) I built FrankMega, a simplified, self-hosted Mega clone, in Rails 8, in a single day of work. 21 commits, 3 hours of active development, 210 tests, zero external dependencies beyond SQLite.

And before the smart guy shows up in the comments with “ah, but Vibe Coding is just prompt engineering, anyone can do it” – hold on. This post exists exactly to show that it isn’t.

From Idea to Code: the IDEA.md

Every project starts with a document. Mine was docs/IDEA.md – 56 lines describing what I wanted:

• Single file upload, with a shareable link
• Download counter (default 5, configurable)
• Automatic expiration within 24 hours
• Full authentication: password + 2FA + passkeys
• No public registration page – invites only
• Admin creates invites, manages users, bans abusers
• Aggressive rate limiting, automatic IP banning
• Deploy via Docker + Cloudflare Tunnel on my home server
• Stack: Rails 8, SQLite, Tailwind CSS, Hotwire/Stimulus

I deliberately added at the end: “Suggest important features that may be relevant for a service like this.” Because I know a spec document never covers everything. And that’s where the interesting part begins.

The Big Bang: Commit #1

The first commit (e277226) at 12:17 delivered 207 files, 6,901 lines of code. In a single commit. Yes, I know it’s controversial, but when you’re building from scratch with AI, the first commit is necessarily huge.

What came in that initial commit:

• Full authentication with has_secure_password (bcrypt), TOTP via rotp, passkeys via webauthn
• Invitation system with unique codes and expiration
• Full admin panel (Users, Invitations, Files, MIME Types)
• Upload with Active Storage + drag-and-drop via Stimulus
• Download links with 24-byte hashes (SecureRandom.urlsafe_base64(24))
• Rate limiting via Rack::Attack on every public endpoint
• Automatic IP banning with a Ban model and async job
• Dark/light theme with Tailwind CSS inspired by Mega.nz
• 73 tests (Minitest + FactoryBot)
• Docker configuration with Puma + Thruster
• Solid Queue/Cache/Cable – zero Redis

Got it? All of that in commit #1. The IDEA.md became functional code in a single shot. But here’s the point: the first commit was not production-ready. Not even close.

The Reality: 20 Iteration Commits

After the Big Bang came 20 commits over 3 hours. And this is where the truth about software development lives, the one no “Vibe Coding” tutorial will tell you.

Phase 1: “Works on my machine” (12:40 - 12:46)

Four commits in 6 minutes. You know what happened? I went to build the Docker image and it broke. Missing libssl-dev. Fixed it. Then the CSP (Content Security Policy) from secure_headers clashed with the inline scripts from Rails’ importmap. Fixed it. Changed the port from 3000 to 3100 to avoid colliding with other services on my server.

Look at commit 389ebe8:

# CSP is now handled by the Rails built-in, not by secure_headers
# Because secure_headers doesn't support nonces for importmap inline scripts
config.csp = SecureHeaders::OPT_OUT

This kind of gem incompatibility you only discover in the moment. No LLM will warn you about this up front because it’s a specific combination of versions.

Phase 2: The Security Commit – 22 Issues Fixed (13:10)

This is the most important commit of the entire project: 4a854a6. 35 files, 612 lines, 22 security issues fixed. I’ll go into detail because this is where toy code separates from production code.

What the initial commit got wrong:

CRITICAL – Encryption keys with hardcoded fallbacks:

# BEFORE (dangerous):
config.active_record.encryption.primary_key = ENV.fetch("KEY", "test-primary-key")

# AFTER (fail-fast):
if Rails.env.production?
  config.active_record.encryption.primary_key = ENV.fetch("ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY")
end

If the ENV var didn’t exist in production, the app would happily run with the hardcoded key. Anyone reading the source code could decrypt every user’s OTP secrets. Now in production, if the variable is missing, the app crashes on boot. That’s the correct behavior.

CRITICAL – Replay Attack on OTP:

# BEFORE:
def verify_otp(code)
  totp = ROTP::TOTP.new(otp_secret)
  totp.verify(code, drift_behind: 30, drift_ahead: 30).present?
end

# AFTER:
def verify_otp(code)
  totp = ROTP::TOTP.new(otp_secret)
  timestamp = totp.verify(code, drift_behind: 30, drift_ahead: 30)
  return false unless timestamp

  # Prevent replay: reject if this code's timestamp was already used
  if last_otp_at.present? && Time.at(timestamp) <= last_otp_at
    return false
  end

  update_column(:last_otp_at, Time.at(timestamp))
  true
end

Every TOTP tutorial online shows verify(code).present? and stops there. The problem: a TOTP code is valid for 30 seconds. If I intercept your code (shoulder surfing, camera, clipboard), I can use it multiple times in that window. last_otp_at guarantees real one-time use.

HIGH – Race Condition on the Download Counter:

# BEFORE (race condition):
def increment_download!
  increment!(:download_count)
end

# AFTER (atomic):
def increment_download!
  self.class.where(id: id)
      .where("download_count < max_downloads")
      .where("expires_at > ?", Time.current)
      .update_all("download_count = download_count + 1") == 1
end

increment! does: (1) read the value, (2) add 1 in Ruby, (3) write it back. Two simultaneous requests can both read 4, both write 5, and the user gets two downloads when they should only have had one. The atomic UPDATE ... WHERE in SQL guarantees only one request wins. And the == 1 returns success/failure in a single operation, with no lock.

This is the classic TOCTOU bug (Time of Check, Time of Use). You’ll never see it in local development with one browser. It only shows up in production with concurrent requests.

HIGH – Open Redirect after login:

# AFTER:
def safe_redirect_url?(url)
  uri = URI.parse(url)
  uri.host.nil? || uri.host == request.host
rescue URI::InvalidURIError
  false
end

Without this, an attacker could send a link like frankmega.com/session?return_to=https://evil.com and after login the user would be redirected to the malicious site.

MEDIUM – Predictable CSP nonce:

# BEFORE:
config.content_security_policy_nonce_generator = ->(request) { request.session.id.to_s }

# AFTER:
config.content_security_policy_nonce_generator = ->(_request) { SecureRandom.base64(16) }

Session ID doesn’t change between requests. If the nonce is predictable, an attacker can inject scripts with the correct nonce. It has to be random per request.

And more: Cloudflare IPv6 added to trusted proxies, minimum 12 characters for passwords, server-side MIME detection via Marcel, file size verified from the tempfile (not from the client header that can be forged), protection against deleting/banning/demoting the last admin.

The test count jumped from 73 to 109 with this single commit.

How Rails Makes Security Easier

Rails makes implementing security MUCH easier than doing it from scratch. Look at the comparison:

Rails 8 in particular brought rate_limit built into the controller:

class SessionsController < ApplicationController
  rate_limit to: 10, within: 3.minutes, only: :create,
    with: -> { redirect_to new_session_path, alert: t("flash.sessions.create.rate_limit") }
end

And authentication? Rails 8 now ships with a built-in authentication generator. You no longer need Devise for basic stuff. FrankMega’s app/controllers/concerns/authentication.rb is based on that and extends it with 2FA, passkeys and invitation-only registration.

File Sharing Is More Than Downloads

One thing lots of people don’t realize: a file sharing service has a huge attack surface. It goes way beyond “save file, generate link”. Look at everything you need to consider:

Filename Sanitization

def sanitize_filename(name, content_type = nil)
  sanitized = File.basename(name.to_s)                          # Strip path traversal
  sanitized = sanitized.encode("UTF-8", invalid: :replace,      # Handle invalid UTF-8
                                undef: :replace, replace: "")
  sanitized = sanitized.gsub(/[\x00-\x1f\x7f\/\\:*?"<>|]/, "") # Control chars + unsafe chars
  sanitized = sanitized.sub(/\A\.+/, "")                        # Leading dots (hidden files)
  sanitized = sanitized.gsub(/\s+/, " ").strip                  # Collapse whitespace

  # Windows reserved device names
  base_without_ext = sanitized.sub(/\.[^.]*\z/, "")
  if base_without_ext.match?(/\A(CON|PRN|AUX|NUL|COM[1-9]|LPT[1-9])\z/i)
    sanitized = "_#{sanitized}"
  end

  sanitized = strip_extension_junk(sanitized, content_type)
  sanitized = truncate_filename(sanitized, 255)
  sanitized.presence || "unnamed_file"
end

Every line exists for a reason:

• File.basename blocks path traversal (../../etc/passwd becomes passwd)
• Stripping control chars blocks null byte injection and terminal escape injection
• Windows reserved names (CON, NUL, AUX, LPT1-9) cause problems if storage is accessed from Windows
• Truncating to 255 bytes (not characters!) while preserving the extension – a 4-byte emoji counts as 4 toward the ext4/NTFS limit
• strip_extension_junk handles names that come from URLs with glued-on parameters: photo.jpg_1280x720+quality=80 becomes photo.jpg

And this is server-side. There’s also client-side validation in the Stimulus controller to reject before upload:

isInvalidFilename(name) {
  if (new Blob([name]).size > 255) return true
  if (/[\x00-\x1f\x7f/:*?"<>|\\]/.test(name)) return true
  return false
}

Server-Side MIME Type Detection

@shared_file.content_type = Marcel::MimeType.for(uploaded.tempfile, name: uploaded.original_filename)
@shared_file.file_size = uploaded.tempfile.size

Don’t trust the Content-Type the browser sends. Marcel inspects the file’s magic bytes to determine the real type. And the file size comes from the tempfile on disk, not from the Content-Length header which can be forged.

Quotas and Disk Usage

Each user has a disk quota (5 GB default, admin can customize):

def can_upload?(file_size)
  grace = Rails.application.config.x.security.disk_quota_grace_bytes
  (storage_used + file_size) <= (disk_quota + grace)
end

Without a quota, a single malicious user fills up the server disk. With the 10% grace buffer, an upload that slightly exceeds the limit is accepted so the user isn’t frustrated in the edge case.

Automatic Cleanup

class CleanupExpiredFilesJob < ApplicationJob
  queue_as :default

  def perform
    SharedFile.inactive.find_each do |shared_file|
      shared_file.file.purge if shared_file.file.attached?
      shared_file.destroy
    end
  end
end

Runs every 15 minutes via Solid Queue. If nobody downloaded in 24 hours, gone. If it hit the download limit, gone. Without this, the server disk fills up and the service dies.

Automatic IP Banning

class InvalidHashAccessJob < ApplicationJob
  queue_as :default

  def perform(ip_address)
    security = Rails.application.config.x.security
    return unless security.enable_banning

    cache_key = "invalid_hash:#{ip_address}"
    count = Rails.cache.increment(cache_key, 1, expires_in: 1.hour) || 1

    if count >= security.max_invalid_hash_attempts
      Ban.ban!(ip_address, reason: "Repeated invalid download hash access",
               duration: security.ban_duration)
      Rails.cache.delete(cache_key)
    end
  end
end

Tried 3 invalid hashes? Banned for 1 hour. That stops hash enumeration. With 24 bytes of entropy (192 bits, 2^192 possibilities) brute force is computationally infeasible, but the extra protection costs nothing.

Layered Rate Limiting

Rack::Attack operates at the middleware layer (before Rails processes the request):

# Login: 5 attempts per minute per IP
Rack::Attack.throttle("logins/ip", limit: 5, period: 1.minute) do |req|
  req.ip if req.path == "/session" && req.post?
end

# Login: 5 attempts per minute per email
Rack::Attack.throttle("logins/email", limit: 5, period: 1.minute) do |req|
  if req.path == "/session" && req.post?
    req.params.dig("email_address")&.to_s&.downcase&.strip
  end
end

# Downloads: 60 views and 30 downloads per minute
Rack::Attack.throttle("downloads_get/ip", limit: 60, period: 1.minute) do |req|
  req.ip if req.path.start_with?("/d/") && req.get?
end

# General: 300 requests per 5 minutes (except assets)
Rack::Attack.throttle("requests/ip", limit: 300, period: 5.minutes) do |req|
  req.ip unless req.path.start_with?("/assets")
end

Seven different throttles for specific scenarios. Plus Rails 8’s rate_limit in the controllers. Banned IPs never even hit Rails – they’re rejected at the middleware blocklist with status 403.

And the limits are configurable: 1x in production, 10x in development so you don’t lock yourself out during testing. Everything centralized in config/initializers/security.rb.

The Download Saga: 5 Commits in 21 Minutes

This part is fun because it shows real debugging. Between 14:44 and 15:05 I made 5 commits trying to get downloads working with Turbo Drive:

1. cc3c23d – Added data-turbo=false on the download button. Didn’t work.
2. 5224ed2 – Moved data-turbo=false to the <form>. Didn’t work.
3. 98b0d4f – Dropped redirect_to rails_blob_path and used send_file directly. Partially worked.
4. 1fdf5f9 – Switched from POST to GET link. Worked, but… bots can burn downloads with GET.
5. 4c74b27 – Went back to POST. Added URL artifact cleanup in filenames.

The root cause: Turbo Drive intercepts navigation aggressively, and downloading a file via redirect_to (which generates a chain of 302 redirects from Active Storage) confuses Turbo. The final fix: send_file straight from disk with disposition: "attachment" via POST with data: { turbo: false } on the form.

This kind of problem an LLM won’t solve on its own. You need to test in a real browser, see what happens, try, fail, adjust. It’s pure iterative development.

The Gap Between the Idea and the Final Product

Look at what the IDEA.md didn’t mention and that emerged during development:

1. Per-user disk quotas – without these one user fills the server disk
2. Full I18n (EN + PT-BR) – 66 files, ~250 strings extracted
3. Terms of Service with mandatory acceptance
4. User self-deletion – privacy requirement
5. Blocked downloads for banned users – their links return 410 Gone
6. Client-side upload validation – checks size, quota and filename before upload
7. Inline file previews – images, video and audio on the download page without consuming downloads
8. Styled error pages – instead of plain text “Not Found”, branded pages with i18n

The IDEA.md said “use activeadmin or administrate”. In practice I built a custom admin panel with Tailwind because administrate had compatibility issues with Rails 8.1. The IDEA.md mentioned “progress bar if possible”. In practice I used drag-and-drop with a file preview via Stimulus, which is better than a progress bar.

Nobody can predict every feature on day 1. You discover requirements as you build. And each new feature brings edge cases that need handling.

The Numbers

At the end of the project:

• 21 commits in a ~3-hour session
• 210 tests (Minitest + FactoryBot), 513 assertions, zero failures
• ~3,100 lines of application code (models, controllers, views, JS, CSS, configs)
• ~1,965 lines of tests (including dedicated security tests)
• 9 models, 20 controllers, 36 views, 9 Stimulus controllers
• 24 distinct security measures across 7 layers
• CI: SimpleCov, RuboCop (zero offenses), Brakeman (zero warnings), bundler-audit (zero vulnerabilities)
• Zero external dependencies beyond SQLite. No Redis, no PostgreSQL, no external queue service

The Invitation-Only Server

FrankMega has no public signup. The flow is:

1. On first run, with no users, the setup screen appears to create the admin
2. The /setup route only exists while User.count.zero? – afterward it vanishes entirely:

constraints(->(request) { User.count.zero? }) do
  get "setup", to: "setup#new"
  post "setup", to: "setup#create"
end

3. The admin creates invites in the admin panel (with expiration)
4. Each invite generates a unique 16-byte code
5. Each code can only be used once (with_lock + transaction to prevent a race condition)
6. After signup, the invite is marked as “used”

This is perfect for a personal/family service. Full control over who gets in.

Deploy: Docker + Cloudflare Tunnel

To wrap up, the deploy tutorial in case you want to run this on your own Docker home server. It’s not complicated but there are details that matter.

The Dockerfile

Multi-stage build in 3 stages:

# Stage 1: Base (runtime)
FROM ruby:3.4.8-slim AS base
RUN apt-get install -y curl libjemalloc2 libvips sqlite3
# jemalloc for better memory management

# Stage 2: Build (throwaway)
FROM base AS build
RUN apt-get install -y build-essential git libssl-dev
# Bundle install + asset precompilation with dummy env vars

# Stage 3: Final
# Copies gems and app, runs as non-root user (rails:rails, UID 1000)
CMD ["./bin/thrust", "./bin/rails", "server"]

bin/thrust is Thruster (from Basecamp) – an HTTP proxy in front of Puma that handles gzip/brotli compression, asset caching, X-Sendfile acceleration. It listens on port 80 and proxies to Puma on 3000.

The entrypoint runs db:prepare and db:seed automatically at boot:

#!/bin/bash -e
if [ "${@: -2:1}" == "./bin/rails" ] && [ "${@: -1:1}" == "server" ]; then
  ./bin/rails db:prepare
  ./bin/rails db:seed
fi
exec "${@}"

docker-compose.yml

Two services:

services:
  web:
    image: akitaonrails/frankmega:latest
    ports:
      - "3100:80"
    volumes:
      - /home/seuuser/frankmega/uploads:/rails/storage/uploads
      - /home/seuuser/frankmega/db:/rails/storage
    environment:
      SECRET_KEY_BASE: ${SECRET_KEY_BASE}
      HOST: ${HOST}
      # ... around 15 more variables
    restart: unless-stopped

  tunnel:
    image: cloudflare/cloudflared:latest
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    depends_on:
      - web
    restart: unless-stopped

The cloudflare/cloudflared sidecar creates an outbound tunnel to Cloudflare’s edge. No need to open ports on your home server’s firewall. Cloudflare handles SSL termination, DDoS protection, and routes traffic to the container.

Step by Step

1. Create the Tunnel on Cloudflare:

• Cloudflare Zero Trust Dashboard > Networks > Tunnels > Create
• Type: Cloudflared
• Copy the TUNNEL_TOKEN
• Configure the hostname: frankmega.yourdomain.com pointing to http://web:80

2. Generate the secrets:

# SECRET_KEY_BASE
openssl rand -hex 64

# Encryption keys (3 separate values)
openssl rand -hex 32  # PRIMARY_KEY
openssl rand -hex 32  # DETERMINISTIC_KEY
openssl rand -hex 32  # KEY_DERIVATION_SALT

3. Configure .env:

SECRET_KEY_BASE=<generated above>
RAILS_MASTER_KEY=<from config/master.key>
HOST=frankmega.seudominio.com
WEBAUTHN_ORIGIN=https://frankmega.seudominio.com
WEBAUTHN_RP_ID=frankmega.seudominio.com
ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY=<generated>
ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY=<generated>
ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT=<generated>
TUNNEL_TOKEN=<from Cloudflare>
FORCE_SSL=true
APP_LOCALE=pt-BR

4. Bring it up:

docker compose pull
docker compose up -d

5. Visit https://frankmega.yourdomain.com, create the admin account, start using it.

Important Caveats

• FORCE_SSL=false to test locally at http://localhost:3100 without Cloudflare in front, otherwise you hit a redirect loop
• The WebAuthn origin has to match exactly, including https://. If you get it wrong, passkeys silently stop working
• Cloudflare IPs are hardcoded in the initializer (because the cloudflare-rails gem isn’t compatible with Rails 8.1). If Cloudflare changes the ranges, you need to rebuild the image
• Encryption keys are permanent. If you swap them after users configure 2FA, the OTP secrets become unreadable and users lose access
• Cloudflare free has a 100 MB upload limit. On the free plan, files above that don’t make it through the tunnel. The app allows up to 1 GB but Cloudflare is the bottleneck
• The container runs as UID 1000. If you use bind mounts instead of named volumes, the directory has to be owned by UID 1000
• There are 4 separate SQLite databases in production (app, cache, queue, cable), all in the db_data volume. Backup means copying the entire volume

The Real Point About “Vibe Coding”

Claude Code is absurdly productive. I wouldn’t have done all of this in 3 hours without it. Remember when you’d bang your head against the wall for a week just to get login working? Yeah.

The I18n commit alone (66 files, ~250 strings extracted for two languages) would take a full day by hand.

But here’s the point nobody wants to hear: the LLM did not make the security decisions. I asked it to run an audit and it found the problems, but I had to know how to ask. And I had to know which questions to ask. “Review security” is a vague instruction. “Check if there’s a race condition on the download counter increment” is an instruction only someone who knows what TOCTOU is can give.

Those 56 lines of IDEA.md carry decades of web development experience. I knew to ask for rate limiting because I’ve seen services taken down by bots. I knew to ask for IP banning because I’ve dealt with abuse. I knew to ask for an atomic download counter because I understand concurrency.

If a beginner wrote the same IDEA.md, they probably wouldn’t have half of those concerns. And the LLM wouldn’t spontaneously suggest them. The result would be a service that’s functional, pretty, and completely insecure.

The experienced programmer’s value in Vibe Coding isn’t writing code. It’s knowing what to ask for and reviewing what was generated. Experience is the filter between “works” and “works in production”.

Those 210 tests and 24 security measures didn’t come from prompt engineering. They came from knowing what to test and why.

The code is open source under AGPL-3.0: github.com/akitaonrails/frank_mega. Deploy it on your server, poke around the code, learn from the commits. And if you find more security flaws, let me know.

Remember:

AI is the mirror of your own competence.

–

On February 10, 2026, I posted the tweet above, just throwing out there something that had been on my to-do list for years, ever since I was publishing videos on YouTube. I never did it because I hate HTML/CSS, and having to build an email template was enough to keep me from starting. On top of that, doing yet another newsletter, which is just a boring list of links, didn’t motivate me.

But that day I was already wrapping up my second vibe coding project, FrankMD, and I think I figured out the main tricks and the methodology to build a complete product the right way. So a bunch of ideas started popping up. I dumped them all into this little document.

I thought: what if I vibe coded not only the newsletter system’s code, but also had part of the actual content generated by AI in a quirky way, in the form of commentators: me and a robot? And, of course, with Hitchhiker’s Guide in mind, it had to be MARVIN, or rather, “M.Arvin” (so nobody hassles me about copyright).

Obviously, there would be a weekly email version and an archive blog. But since we were going all in, why not rewrite the whole newsletter as a podcast script? And since Qwen3 TTS recently came out, open source, why not train a LoRa with my voice (obviously, I have hundreds of hours of my voice on YouTube) and put together a fully automated podcast?

Finally, one of the things that would demotivate me is building a traditional Web Admin and having to log in manually to register news links and my comments. I knew I’d get lazy and, at some point, burn out. There was only one solution: build a smarter bot I could talk to via DISCORD. That way I can quickly jump in, whether from my PC or my smartphone, without having to log into a separate system or anything. I already chat with people on Discord, so the friction would be zero.

So:

• Marvin Bot to manage all the content (the stuff I send in and the automated stuff, with comments and everything else)
• An X.com monitor to check what I posted and grab it for the newsletter. Including the replies I give, which will become Q&A!
• Newsletter website to subscribe, unsubscribe, etc
• Blog for newsletter archives and podcast transcripts (also with terms of service and privacy — yes, I’m LGPD compliant!)
• Automatic voice generator and podcast assembler that uploads automatically to make it available on Spotify
• And also blog and email templates, with light and dark theme versions.

You, an experienced programmer, without AI, how long would it take you to build all of that?

Well, I started on February 10. I finished everything on Sunday, February 15. And today, the 16th, the production jobs ran for the first time, which generated the newsletter, blog posts, podcast, Spotify upload, email delivery.

And it wasn’t done the crappy way every amateur vibe coder does it:

Rails folks must be surprised: a project with a 1 to 1 test ratio! 1 line of tests for every 1 line of code: 100% coverage. And that’s without counting a separate full end-to-end integration project (which I used to make sure production would be flawless).

All the strategies I’ve learned over the years putting projects into production: security, scalability, durability, delivery guarantees without spamming duplicate emails, etc. I’ll see later if I write more specific posts about some of the technical tricks.

I’m not going to open source this project. I built it 100% custom for me, my workflow, and my style. It’s not hard for another competent programmer to do the same thing with vibe code: if I pulled it off, anyone can. So just don’t be lazy about thinking and doing. Honestly, I don’t get how tech YouTubers still aren’t launching 1 complete project in production, per video, for everyone to test and watch.

The screenshot also doesn’t show the Qwen3-TTS server, which produces audio. That one is much simpler, a PyTorch server. Here I actually used Python. The most important part is the fine tuning of the model to generate voices exactly the way I wanted:

The blog is all Hugo/Hextra, same as this one. And my bot publishes there automatically.

M.Arvin Bot

M.Arvin has a personality I spelled out exactly the way I wanted. And it’s a Discord bot, so my workflow looks like this:

I just need to send a link with my comment (the same way I’d do on X.com), or I can post directly on X and it’ll pick it up the same way. Then it fetches the content, writes a little summary, does a small fact-check, and M.Arvin generates its own comment on top of mine.

I programmed it to respond to a bunch of commands to make my day-to-day easier. This is just a small part of it:

Here’s an example: I have control over how much AI it’s using (it’s pretty cheap):

Deployment

In this post I’m not going to go into too much detail, but one thing I spent a lot of time on, going through several discussions and versions with Claude Code, was the infrastructure architecture. And in the end it managed to give me a Deployment Guide that I was able to follow all the way through, knowing at a minimum it’s set up the way I would have done it myself if I’d built everything alone:

No software is guaranteed to be 100% perfect; this one shouldn’t be either. Even with me reviewing for days, going through every step multiple times, there’s always some bug I didn’t anticipate. I “think” that, at least, everything I know usually causes problems in production, I “think” I managed to cover satisfactorily. If it were a human team, I would have pushed it to production in a worse state than what I reached with Claude.

Everything I could protect with Cloudflare, I configured. Every good practice for email/mailing, I followed. Every precaution against accidents I took (every deploy automated with Kamal) and every subscriber’s email was encrypted with AES-256 in the database (even if they leaked by accident, the user data doesn’t leak). I didn’t implement profiling, cookies, or tracking pixels, nothing. Privacy was the focus.

Everything I could reduce costs on, I reduced; after all, I’m paying out of pocket. So things like the RunPod GPU for generating the audio are serverless. I only spin it up at the moment of generation; it runs the whole process and then the machine shuts down. The server is all organized into a lightweight Docker image. All the AI models live on a separate network volume.

Process Spoiler

Later I plan to do a bigger post about my methodology, but it’s very simple: treat Claude Code/Codex like a hard-working human programmer — one who’s going to make lots of mistakes, but knows how to obey super explicit, direct, clear, unambiguous orders. My role is product manager, Tech Lead, or QA. It has to be all THREE roles.

In total, Claude Code made 201 commits. But these aren’t normal commits; I figure that in a normal project with humans, each one would have been roughly 150 Pull Requests.

Question for you folks doing sprints on real projects: how long does it take to get 150 user stories/bug fixes approved and in production on your actual project? How many user stories can you get done and approved (with QA and everything) in ONE week?

Here’s an example of a commit/“user story”:

When I was around commit 50, I was already thinking: “It works already!”* That’s the stage where every content creator (who has never actually put real projects into production) would already be posting, saying: “I vibe coded it in 2 days”. In fact, in 2 days I already had the bulk of the functionality ready.

The other 4 days were:

• 1 day for production deploy (when everything is planned ahead of time, all the contingencies already thought through, it’s easy).
• 3 days just testing, writing automated/integration tests, generating and regenerating, exercising every step of every part, multiple times, and making adjustments, refactors, or even throwing away entire pieces to change them, because the tests showed it was worth it.

That took from commit 50 to 200! And that’s the part every vibe coder skips. To be fair, it’s the part anyone, with or without AI, would skip. And that’s why projects always go wrong and end up in production full of errors and obvious security holes.

Even after asking Claude Code to review security best practices and test coverage, multiple times. Then I opened Codex and asked it to do the same thing, and it still found more security holes and more missing tests, multiple times. Even after both of them did these checks several times, I still found more holes on my own that I had them fix. At no point was either of them able to find “EVERYTHING”. Nobody can, not even AI.

Conclusion

Vibe Coding the right way has only one path: Extreme Programming!

Yes, all the “boring” and “bureaucratic” things every developer hates doing are what guarantees the AI will give you back a result acceptable for production:

• Pair Programming: you need to tell the AI to plan first and spell out exactly everything it’s going to do, BEFORE starting. I review, I tweak, and only when I’m satisfied do I let it go. I watch every single thing it does and, at the end, I tell it to fix whatever I think it missed.
• Test-Driven Development: every feature must come with unit tests. Every bug fix needs regression tests.
• Continuous Integration: every time it finishes implementing, you need to run the CI script to see if anything broke somewhere else. More than that: on the master branch, there are only commits with passing tests. I can revert at any point and the project runs.
• Small Releases: I really liked this about Claude, even if I end up forgetting to tell it to commit a task and send it off to do another one, in the end it doesn’t do that ugly git add . thing — no: it separates into 2 commits and describes each one the right way. On top of that, I pushed to production on Friday, and kept going Saturday and Sunday testing integration locally and in the production environment, to make sure there’s none of that “it only works on my machine” stuff.
• Coding Standard: I started with the bare minimum of technical requirements, but during development I had it refactor my way over and over again.

Those are the main tasks that need to be done. Let me get ahead of it: “Spec Driven Development” isn’t totally useless, but the structure doesn’t matter: it’s your text that counts.

It’s the same thing as User Stories. Big deal, you wrote “As the end user, I want that when I type X…, the system responds with Y”. The format is NEVER important. What’s important is HOW you wrote what goes in the middle. If you can’t write, the AI won’t know how to respond to you the way it should. I’ll do another article just to show how terrible all of you are at writing.

The message is simple: Vibe Code works, in part.

What actually works is “Senior Agile Vibe Coder”

I’ll ask again: how long, without AI, would it take you to produce 150 user stories/bug fixes, in the scope I outlined at the beginning? All the way to production with everything tested? I doubt it would be in 6 days like I did it.

“As a total zero in programming, I want to build a perfect, secure, quality app using only prompts. Which LLM will do that for me?”

My answer two years ago and still today is:

NONE!

Yesterday I wrote a LONG article where I DEMONSTRATE what it’s like to build a tiny app from scratch using only Vibe Coding. Something with a smaller scope than a “to-do list” exercise.

Getting it to “just work” was easy: in 1 hour I had the app. That “total zero” above would stop right there.

But to get quality code, secure, optimized, tested, etc, it cost me the next 12 hours and more than 250 prompts and manual interventions.

When I posted it, some people still came at me with “Ah, but you used GLM, if you had used Claude Code or Codex it would have been a thousand times better.”

Ok, I took the bait.

Today I spent another solid 2 hours on top of GLM’s final code and did the following:

• I told Claude Code to run an EXTENSIVE analysis for security, optimization, tests, etc and it produced this commit

• On top of what Opus fixed, I asked GPT 5.2 Codex to do the same EXTENSIVE analysis. And it produced this commit

• Not satisfied, and seeing that Kimi 2.5 had just come out, I asked it to do the same EXTENSIVE analysis. And it produced this commit

• Just to be really sure, I then asked Gemini 3.0 Preview to do the same EXTENSIVE analysis. And it produced this commit

• I couldn’t resist and wanted to wrap things up by asking MiniMax v2.1 to join in and do the same EXTENSIVE analysis too. And it produced this commit

Are you getting it??? LET THAT FUC–NG SINK IN!!

NOT ONE of them is capable of building a tiny app smaller than a to-do list in perfect form. That doesn’t exist.

The only thing that exists is your requirements. The quality of the app is directly proportional to your seniority!

The more junior you are, the worse your app will be, with or without AI. The more senior you are, the better your app will be, with or without AI. AI is directly correlated with your knowledge AND your experience.

AIs are not geniuses with a will of their own. They won’t guess what you WANT, nor what you REALLY NEED.

What you WANT and what you NEED tend to be VERY different things.

There’s no point putting NASA-level security on a system that doesn’t need it. There’s no point leaving an open admin password and shipping to production. You need to know what the right boundaries are for your particular use case.

AIs are probability machines, glorified text spitters, with zero intelligence. They will never reach 100% because that’s impossible.

And I mean “mathematically” impossible. That’s because the amount of effort/resources needed to push each percentage point up that scale grows exponentially. As you’d say in Calculus, “in the limit”, 100% goes to infinity.

So it will always necessarily be “below 100%”.

99% of the effort goes into building a minimal to-do list app. The rest of the road: scalability, optimization, security, maintainability, etc depends solely on the person asking: you.

Russian Doll of LLMs

This whole game of Opus ➡️ GPT 5.2 ➡️ Kimi 2.5 ➡️ Gemini 3 Pro ➡️ MiniMax V2.1 was actually cheap, totaling about USD 3. But again, it’s an app smaller than a to-do list. It “should have” been trivial for any one of them, don’t you think?

Let’s quickly take a look at what the LLMs did after my tiny app was already done.

For anyone who didn’t see the previous article, the final code is on this GitHub.

1. Opus 4.5

I’ve said this before and I’ll say it again, when in doubt, use Claude Code. It has the best balance between speed and quality. If you use the Max plan, the cost-benefit is good too. I agree it’s superior to GLM 4.7, that was never in question.

At the same time, it’s not magic and far from infallible. The whole process I described in the previous article will be exactly the same, it will just take a lot less time (costing less of my patience).

GLM really struggled with the CORS check and, as Opus shows, there were still bugs left in that check.

Opus adjusted a few things that are fine, but unnecessary. Improving the encryption of the communication wasn’t needed, because it was just obfuscation. Real encryption will always be TLS. But that’s ok, good to keep it tuned.

But what GLM let slip and Opus also missed is that in the first version the token was encrypted because it went in the URL, but after we moved to server-side it wasn’t needed anymore. Yet old code was still hanging around, and Opus, instead of removing it, tried to improve that old code!!

It should have been obvious it wasn’t needed: it’s server-side, the new token is just a random ID. There’s no need to keep an encrypted timestamp on the server.

It also wanted to fix the possibility of overflow when loading the I18n file. But that’s something I control, not the user. There’s no way to have an overflow. It’s overengineering, but fine too.

Opus tends to be overly proactive on aspects that usually aren’t needed, giving the impression it’s smarter than it actually is.

You know that annoying intern who reads a lot of blog posts and in every meeting blurts out random things to show off? But in practice makes no difference? Yeah, that’s it.

2. GPT 5.2 Codex

Despite being OpenLieAI, I find GPT 5.2 Codex more “honest” than Opus. It doesn’t try to be smartpants all the time, showing off where it doesn’t need to. I feel it goes more directly to the point and follows exactly what I asked more closely, instead of going off on tangents I didn’t ask for - and that end up being unnecessary.

Just this time, who knows why, it made the worst commit message of all (super short, no explanation). But it caught something pretty dumb that GLM and Opus didn’t pay attention to: a silly little timeout configuration:

For my app, it’s not needed. But at this stage where I really asked for an EXTENSIVE analysis, it surprises me that verbose Opus let this slip.

And GPT ran into the problem I mentioned above with the encrypted token: I had to interrupt it when it started trying to reimplement the encryption because it saw leftovers from the past. In this case I explicitly told it to remove those leftovers. But neither GLM, nor Opus, nor GPT picked up that this was no longer needed and kept trying to mess with that old leftover.

3. Kimi 2.5

Every week a new version shows up that everyone starts hyping. 3 weeks ago it was MiniMax v2.1, 2 weeks ago it was GLM 4.7, now it’s Kimi 2.5, so I decided to test it via OpenRouter. And the TL;DR is that I liked it.

I found it slower than Opus or GPT, but better than GLM. And it really did keep finding items I don’t know how Opus let slip.

Again, it’s a silly and unnecessary thing for my tiny app, but no one so far bothered to configure security headers:

In a real web app, you have to include it!

Another unnecessary thing, but that you do need in a real app: the WebSocket Ping/Pong pattern so it doesn’t disconnect if it goes idle:

The interesting thing is that Opus didn’t suggest this. See? It’s verbose, keeps suggesting a bunch of small unnecessary things to look smart, but the really interesting things, it forgets.

But then Kimi also suggested bringing back a feature I had told GLM to remove: a cleanup routine for the in-memory token storage:

As I already explained: this is server-side. When space runs out, the new token automatically takes the place of the oldest one and that’s it. But Kimi was probably worried about leaving expired tokens lying around in memory. Thing is, it’s overengineering: it’s a tiny storage, kilobytes maybe. There’s no need to keep a routine running in the background cleaning up an in-memory list.

Even in a production app, I wouldn’t include this!

There was a tweet jokingly suggesting that Kimi was a pirated version of Claude. Even though it’s a joke, this behavior of keeping implementing unnecessary things like an intern who reads blog posts and wants to show off really is pretty similar to Claude. 😂

4. Gemini 3 Pro Preview

Unlike Opus, similar to GPT, I tend to think of Gemini as a bit more “honest” and straight to the point as well. Sometimes I still catch it rambling and suggesting unnecessary tangents, but overall I feel it sticks to my prompt a bit more closely.

In its case, besides the analysis, I explicitly asked it to reevaluate the need for the cleanup routine that Kimi had added.

And Gemini agreed with Kimi and wanted to keep it, and even optimized the routine!! 🤦‍♂️

But at least it still found a deadlock during server shutdown that no one before had thought of. It’s nothing serious, and it’s only during shutdown, but even so, I asked all the previous ones for an EXTENSIVE analysis, they suggested unnecessary things, and skipped this. In a production app it’s important to have this care. It’s the kind of thing that can block container restarts in production or cause pointless delays/timeouts.

5. MiniMax v2.1

By this point I really hoped there wouldn’t be much left to touch, but MiniMax still found more silly little things missing.

Kimi added the missing security headers on the HTTP server but forgot to do the same for WebSockets:

And at this point, 5 LLMs later, there are still some Go best-practice silly things that everyone let slip. This nonsense, for example:

Again: it’s nothing. But everyone checked, analyzed, ran linters and everything else and only MiniMax fixed that leftover. THERE ARE ALWAYS LEFTOVERS

Conclusion

I could keep going, I could keep running more LLMs on top of this. But remember: all of this was just on top of a miserably tiny app, smaller than a to-do list. Imagine on a large, complex app, with real users, in production?

Don’t underestimate programming, it’s much more complex than you beginners think.

I just burned through the equivalent of tens of billions of dollars, I must have burned enough energy to power a whole house in the datacenters of Z.AI, Anthropic, OpenAI, Google, etc and still, there are leftovers.

And even with all that, I have zero confidence in putting this tiny app out in public. For my private personal use it’s overengineered, but for production I would still need to spend hours on manual review and manual testing, extensive QA, security scans and all the rest to make sure nothing important is left over.

LLMs are EXCELLENT, they help me a lot. But they are highly motivated interns, and not geniuses that do everything on their own. Far from it.

This is a concept I’ve talked about multiple times in videos on my channel and in talks. Everything in programming happens more or less at the Pareto ratio: 80/20:

• 80% of the code is “easy” and usually gets done in 20% of the time. The most important 20% will eat up most of the remaining 80% of total time.
• For bugs and issues like performance or security, if you fix the top 20% you solve 80% of the general problems.
• 20% of the scope is truly important, which is why you can always simplify, replace, change, or even cut 80% of it - and that’s how you squeeze a project into budget/deadline.

Everything is based on Top X. Learning to prioritize is learning to identify the 20%. The difference between someone senior/experienced and someone amateur/beginner is that beginners think 100% is important and can’t pick the 20%. What experience brings is the ability to isolate that 20% faster and faster.

HOWEVER, it’s very easy to just say this. Everyone has heard it at least once, but most likely still doesn’t understand what it means. That’s why I decided to write this (LONG) article: I’ll show you in practice what the easy 80% and the hard 20% are, and how that actually affects code quality, time spent and cost.

This article is for beginners mainly, but also for you: the senior who has juniors to mentor, or the teachers with students. Use it as discussion and study material with your apprentices. This is the kind of thing that should be taught.

Since this is going to be long, remember that on desktop, on the right side there’s a menu with the sections so you can jump straight to each topic and study it piece by piece.

The App: TV Clipboard

I picked a little app I had been wanting for a while for my personal use. It’s simpler than a to-do list, it doesn’t need a database or any other external service. In practice it’s a peer-to-peer (p2p) communicator over websockets.

The use case is this: I have a gamer mini-PC that I hook up to the living room TV. I usually leave a mouse by the armchair to navigate on it (it’s a damned Windows 11). But occasionally I need to type something (passwords, fill out some form). And I don’t want to leave my important accounts logged into that PC (I don’t trust gamer PCs).

Either I have to grab my bluetooth keyboard, or use the Windows on-screen keyboard. Both options are inconvenient in a living room. BUT, what if I could open a website (that’s already in my bookmarks), a QR Code shows up, I scan it with my smartphone and from there I can type or paste whatever is in my mobile clipboard and transfer it to the mini-PC clipboard instantly? That’s the app:

Then I open the camera on my phone, scan that QR Code and it opens this page:

Done. Now I can type anything or paste the password from my password manager (by clicking “paste”) and when I send it, on the TV I’ll see this:

It shows that it was received, and it goes straight to the TV clipboard automatically. It shows it “blurred” because if it’s a password I don’t want it legible in large text on the TV - and yes, the mouse cursor is gigantic because it’s easier for me to see on the TV.

This is useful not just for the TV, but for any situation where I want to send text from my phone to one of my PCs. A lot of people end up using WhatsApp or other messengers for this. I, for instance, have a “Just me” group that only has me in it, where I keep sending links and silly stuff from my phone. Then I always keep WhatsApp Web open in a tab on my PC and I can grab it from there. WhatsApp for me is a remote clipboard.

But that’s not safe for sending things like passwords, crypto addresses, or any other sensitive message. WhatsApp is a company with zero transparency. The advertising “claims” they have end-to-end encryption, but I don’t believe it. It’s equally likely they open everything in transit and keep it logged - it’s data worth money, even more in this era of LLM training.

Recommendation: NEVER COMMUNICATE ANYTHING IMPORTANT VIA WHATSAPP.

For file transfers I already use LocalSend:

That’s where the inspiration came from: I wanted a LocalSend for Clipboard. I’m sure there are already dozens of apps that do exactly this. But I wanted to take the opportunity to do this exercise.

The Plan: 100% Vibe Code

Honestly, I know enough about front-end, I started my career as a “webmaster” in the 90s. But I hate front-end. It’s slow, it’s tedious, yuck. In particular, I hate dealing with CSS. Even more particularly, I take no pleasure in writing Javascript. So I’m always lazy about starting a web app from scratch. But with Vibe Coding, this is one of the parts I can finally get rid of, especially if I don’t care about the exact look as long as it’s not crooked.

While we’re at it, I’m going to use a language I know the basics of but don’t have enough experience in, much less fluency (meaning, on my own I’d be slow): GoLang. Why Go:

• it compiles to a native binary: I don’t even need the performance, but having a compiler helps the LLM get feedback on obvious errors.
• no dependencies: later I’ll want to deploy it to my home server, and it’ll be infinitely easier to set up Docker with a dependency-free binary compared to something like Ruby or Python where you have to install a ton of stuff.
• full standard tooling: besides the compiler it already has a formatter, linter, tests and everything else that also gives good feedback to the LLM
• simple, short and unambiguous syntax. I like how Go is Python-like. I don’t consider either of them “pretty” (aesthetically, I much prefer Swift, Kotlin or Ruby). But unlike Javascript and even Rust, it’s much less verbose and much less ambiguous.
• rich standard library. Unlike Javascript, you don’t have to keep installing 500 external libs for basic things.
• since I’m going to use websockets, GoLang’s channels will make my life easier. Its async mechanism is simpler, more robust and better than Node’s reactor.
• most importantly: because I want to. It’s a personal project, that only I’ll use, I pick whatever I feel like and that’s that.

By the way, since I’m not fluent in Go, I’ll probably let some bad practice or obvious anti-pattern slip through. If that happens, you Go senior reading this, don’t hold back, comment below and explain what you think.

If you want to see the end result now, all the code is on this GitHub. I’ll be linking snippets from it all the time.

Another goal is to test how good the famous GLM 4.7 really is. I’ve written posts and tweets about it before. I’ve tried running the Flash version on my local PC (it’s good, but VERY slow). Overall, my impression is that it has similar quality to Claude Opus, GPT Codex, Gemini, but it’s WAY slower (at least 2x slower). Meaning if I had used Gemini or Claude, I’d get the same result but probably in half the time, though at a higher token cost (GLM is “cheaper”).

Let’s get to the TL;DR: it managed to implement the app the way I wanted, but it was SLOW. I spent an entire day, having lunch and dinner in front of the PC while Crush kept thinking, a total of more than 10 HOURS. And, according to OpenRouter, I spent just over USD 40 (over 200 reais). It was neither fast nor cheap, considering the app’s scope. Reminder: it’s simpler than a To-Do List.

In terms of size, even a simple app like this one resulted in more than 3,000 lines of code (LOC) of GoLang:

=== Code Statistics ===

Total Go code: 3493 lines

Production code: 1431 lines
Test code: 2062 lines
Test ratio: 1.44:1

Top 10 largest files:
  3493  total
  602  ./pkg/server/server_test.go
  560  ./pkg/hub/hub_test.go
  385  ./pkg/token/token_test.go
  304  ./pkg/hub/hub.go
  283  ./pkg/server/server.go
  263  ./i18n/i18n.go
  262  ./pkg/config/config_test.go
  253  ./pkg/QR Code/QR Code_test.go
  243  ./pkg/config/config.go

And for Javascript it came out to more than 1,000 LOC:

=== JavaScript Code Statistics ===

Total JavaScript code: 1360 lines

Production code: 787 lines
Test code: 573 lines
Test ratio: 0.73:1

All JavaScript files:
  1360  total
  573  static/js/test.js
  313  static/js/client.js
  249  static/js/host.js
  114  static/js/common.js
  111  static/js/i18n.js

Oh right, out of curiosity, I added loc.sh and loc-js.sh scripts to do this counting.

Phase 1: Making It “Work” - what does that mean?

Contrary to what many amateurs might think, it’s not enough to type a description of the application (like I did in the previous section) as a prompt, throw it at the LLM and it will automatically come out with a working app: IT WON’T.

This is what I was saying 2 years ago and it’s still true: it doesn’t matter how much more LLMs evolve. They might get a bit faster, a bit more efficient, but the architecture is still the same since 2022: transformers are glorified text generators, with a random sampling factor that always embeds entropy into the process (it will never be exact, deterministic). There will ALWAYS be a need for human intervention (and a lot of it).

Now I’ll demonstrate with a real example what that means.

In the end, I stopped this project after 43 commits. I followed the process I always say is the best: small prompts, one feature at a time, verify that it works and is correct, have it git commit, then move on to the next feature or requirement.

On a back-of-the-envelope count, each commit took about half a dozen prompts on average. Let’s say 43 commits x 6 prompts = nearly 258 prompts over more than 12 hours. Some prompts were a simple sentence that got solved in 2 seconds. Most took minutes and multiple iterations from the agent (Crush).

GLM 4.7’s context window is average: around 200k tokens. Crush has a mechanism where, when usage gets well past 90%, it asks to summarize the context so far so it can reset and reload from that summary to keep going. But it still has bugs and sometimes crashes and loses context:

Then I have to recover the last prompt, sometimes type part of the interrupted context myself, so it can pick up where it stopped. It’s tedious and you have to keep paying attention. This is a problem that Gemini suffers from less because its context window is MUCH larger (but attention in the middle degrades as it gets bigger, it’s a trade-off).

“Ah, Akita must be dumb. I built a Todo app and it didn’t even get close to 250 prompts. He did it wrong.”

Now let’s get to the part that separates the boys from the men. Indeed, to “make it work” you don’t need all those prompts. Of the 43 commits that took 10+ hours, I already had an app that “worked” after 10 small commits, which took about 1 hour.

If you want to see the “v0.1” version, just do this:

git clone https://github.com/akitaonrails/tvclipboard.git
cd tvclipboard
git fetch --tags
git checkout v0.1

This version has 1,827 LOC of Go and 255 LOC of Javascript. But the Go backend itself is only 549 LOC vs 1,431 LOC at the end. And that’s because in this minimal version I had already added backend unit tests (1,278 LOC), which most beginners never bother with. So you could “solve” my problem in just over 800 LOC, less than 1 hour and half a dozen prompts.

The project structure looked like this. Save this image to compare with how it ends up at the end:

In this version it already opens what I call the “host” page, which is the page that would open on my TV, showing the QR Code to connect. It already has the “client” page, which is what the QR Code opens on my phone. And it can already paste text on the client, send it to the host and copy it to the host’s clipboard. Pretty simple.

This is where 99% of people would stop and call it done.

Phase 2: Going beyond “just working”

Let me repeat: this project is simpler than a todo list and was built exclusively for me alone to use, at home, on my local network. Anyone thinking “ah, all of this is unnecessary for this app” - I KNOW!.

The idea is to demonstrate the minimum you have to think about for a real project. If you’re building a toy just for yourself alone, quality doesn’t matter.

For Go seniors, or Javascript seniors (because I’ll use it on the front), I know you’ll think “ah, he should have used framework X or library Y” - I KNOW!! 😅 At the end there will be a section where I’ll discuss some of those other options, wait before commenting!!

Back to the Pareto concept. I said 20% of the most important work costs 80% of the time, but that’s just an order of magnitude. In my example, the whole project took more than 10 hours and “to make it work” took only 1 hour. So it’s closer to 90/10 than 80/20.

What the hell cost 90% of the time if 10% “already worked”??

1. Token Management

The first thing I think about when I see a QR Code is that the link inside it should be disposable and volatile. It’s not a rule and obviously depends on the app. For my little app it’s definitely “overkill” but I’ll do it as an example. (I won’t keep repeating “yes, for my app it wasn’t needed”, this is the last time).

I don’t want a visitor who uses my app at home to be able to bookmark the link and use it from outside (I’ll expose my service on the internet to be able to use it from anywhere later). I want each use to be unique and to expire after a few minutes, requiring a new QR Code.

So I need some kind of token system that expires.

This article is already going to be very long, so I won’t keep copying the full code of every feature. I’ll always point to the commit where I implemented it so you can look it up later, and only show snippets for illustration.

Anyway, the goal will be to have a URL like http://clip.example.com/?token=blablabla. Nothing out of this world.

Yes, it could be a JWT, but my use is very simple so I had it built from scratch, and GLM 4.7 came up with a JSON structure with a random private key and a timestamp, which it decided to encrypt with AES (it really wasn’t necessary) and encode in hexadecimal to be the token (it ends up hyper long, more than 100 characters).

It turned out to be a little monster like this:

I didn’t like it but I decided to leave it because it’s working. I can mess with it later - in fact, a lot of things were done “out of order” because I just did them as I remembered them. I didn’t have a step-by-step plan written beforehand. I literally pulled it out of my head in real time.

The goal of this is to remember that Session Management is a concern every dev must have in mind in a real system.

2. First Refactor

The main code was already over 500 LOC, the tests over 1000 LOC. That’s too big to stay in a single file. So I asked GLM to refactor it into packages. This kind of thing I know Claude Code handles more easily, but GLM did well too. In the end it looked something like this:

This is what we call “Separation of Concerns”. Each package has an isolated domain. One package to deal only with configuration options, another to handle only the HTTP server, another to handle only QR Code generation, and another to handle only token management. Each with unit tests in the same package.

Asking for tests from the start was a huge help to the LLM, because every so often it would run the test, get confused about why it wasn’t working and the penny would drop that it needed to adjust the implementation. All automated feedback is important for the LLM to have context to work with.

And refactoring isn’t something you do only once. It’s a process that has to be done from time to time to consolidate and simplify the code, improving maintainability.

The goal here is to remember that “just because it works” doesn’t mean the code is frozen and you never touch it again.

3. Docker Support

Since I was going to run it on my home server, Docker support is mandatory. But regardless of that, it’s good practice to keep a Dockerfile that works. It’s another kind of “automated test”: see if you can “build” an image and run it. And document it for another user so they don’t need to install anything on their system to run it, just run Docker:

docker run -d \
  --name tvclipboard \
  -p 3333:3333 \
  akitaonrails/tvclipboard:latest

In fact, the command above works, in case you want to test it right now. I uploaded the image to my Docker Hub account.

And if you hadn’t already implemented it this way, this also forces you to add configuration options as environment variables (like TVCLIPBOARD_SESSION_TIMEOUT) or via command-line arguments (like --expires), exposing what is configurable.

The goal here is to remember how important it is to automate builds and document how to use it for other people.

4. Organizing Javascript and adding Cache Busting

To “just work”, way back at the beginning, all you had to do was make an “index.html” and go writing if host or if client in the middle of the HTML and JS. But at least GLM started out by duplicating a host.html and a client.html. But the javascript was all inline between <script>...</script> tags and duplicated in both files, so another refactoring step was to ask it to separate common.js, client.js, host.js.

This is the bare minimum of maintainability. Again: refactoring doesn’t end in a single step.

But I could run into a problem. Being a very simple little system, I had no ETAGs implemented and no asset pipeline like WebPack or similar.

In a dynamic web framework, most will support generating CSS and JS files dynamically, changing their names to things like /assets/host-20260128123456.js, and every time we edit some JS, the pipeline regenerates that file with a different name.

When we open it in a web browser, the browser always tries to “cache” static assets like images, JS, CSS, so it doesn’t keep asking for the same thing all the time. If it already downloaded host.js, on the next “reload”, if the same file is requested, it just pulls from the cache instead of asking the server again.

The problem with that is if you change the content of the file and keep the same name. The browser will think it’s the same thing and you’ll spend hours scratching your head thinking “damn it, I already fixed that, why isn’t it showing up??” - and it might be cache.

To avoid this, there are Cache Busting techniques, like ETAG headers. But the most common is just to add some kind of timestamp indicator in the URL, for example /static/js/host.js?v=20260128120431. This way, every time my server restarts, the timestamp will change (it’s not the best rule, but for now it works). The URL will be different and the browser will be forced to download the newest version, making sure I don’t waste time hunting down cache issues.

Again, any minimally competent web framework with HTML template support will have this, but I asked to do it from scratch:

Since I serve static HTML pages, my server code needs to modify the URLs before sending them to the browser, and that’s what the commit above does.

While writing this post, I noticed it added cache busting for “.js” files but forgot about “style.css”, which was left without it. I didn’t notice because I barely touched the original CSS it made. But again, to show that LLMs are never perfect and you have to keep constantly checking if it didn’t forget anything or leave anything behind. I had it fix this in this last commit

The goal here is to remember that you can’t just drop files on the server without knowing how they’re being served. Every front-end dev needs to know how a browser works. “Knowing HTML” isn’t enough.

5. Adding Command-Line Arguments and doing more cleanup

The next three commits are nonsense I should have squashed into a single commit.

This is more of a reminder that it’s not entirely bad to let an agent like Crush do git commits automatically, but you need to pay attention because you might have to tell it to undo (git has ways to redo commits, with options like -amend).

I just added command-line options. Now the binary has this support:

And since it forgot to document it in the README, the other commit is for that. This is why I said the right thing to do was to squash into a single commit, because they’re the same task.

6. Dev vs Production environment configuration

This is another point every beginner ignores. The classic “ah, but it works on my machine”.

On the web, especially, “your machine” is always going to be a localhost, or 127.0.0.1 or 0.0.0.0 (watch my Networking playlist to understand the difference).

The problem: if I run this app locally on my PC, I access it via http://localhost:3333. When the QR Code gets generated, it’ll use “localhost”. Now imagine your phone trying to load a “localhost” link. Obviously, it won’t work. Because your phone doesn’t have the app running on that port on localhost. I need my PC’s IP. So the first thing I have to ask to fix is that, if it’s localhost, it should look up my PC’s IP - which will be something like 192.168.0.xxx. With my PC and my phone on the same DHCP, on the same network, they can find each other via that private IP.

But what about when I run it in Docker? The internal IP of a Docker container is different from the external IP (the container is always either on NAT or on Bridge). The container’s “external” IP will be something like 192.168.xxx, but the internal IP will be something like 172.xxx. Again, if the QR Code uses the internal IP, there will be problems.

So I need a new configuration, usually called PUBLIC URL or PUBLIC HOST or just HOST. Where I explicitly declare it.

For example, when I’m done, as I said, I’ll leave my service exposed on the internet using a real personal domain. Something like https://clip.example.com with TLS support and all. So I need my docker-compose.yml to have an option like:

  - TVCLIPBOARD_PUBLIC_URL = https://clip.example.com

And that way the QR Code is generated with this name instead of having to guess. But at the same time, if nothing is passed, it assumes “localhost”.

In this first commit it doesn’t yet do all of this - I built it little by little. But that’s how you start this kind of feature.

The goal here is to remember that “running on my machine” (localhost) means nothing. We don’t put “your machine” into production. “Working” means “working OUTSIDE your machine”.

7. More code cleanup

I’m deliberately mentioning “code cleanup” all the time so it’s very clear that a considerable part of the work of programming is “cleaning up” code that has already been written.

The next four commits are just maintenance.

For example, the LLM inadvertently left a duplicated snippet inside the code. It didn’t break anything because it was in the Docker Compose configuration:

On top of that, there’s an accidental behavior in the way this app works that I decided to keep as a “feature”. There always has to be a browser that opens first and automatically becomes the Host and displays a QR Code. The next browser to open needs the link from that QR Code and becomes the “client”.

But when the host closes, the client loses the connection and is automatically promoted to host. I didn’t ask for that but it ended up working out, so I asked to keep it and document it.

The goal here is to remember that LLMs aren’t perfect, they’ll leave leftovers behind, and you need to keep monitoring all the time.

8. Optimizing Javascript

The next three commits are about cleaning up the Javascript.

Last time we touched it, I had only asked it to pull the inline Javascript out of the HTML and separate it into reusable “.js” files. But the time came to take a look at them.

Right off the bat, I could see there was duplication between client and host, so I asked to deduplicate and move things into “common.js”.

On top of that there were several small issues:

• a bunch of variables and functions in the global scope (global pollution: bad practice)
• websockets that open but with nothing checking the close
• timers being started but never cleared (leaks)

Javascript code that “just works” is always like this: everything global, everything open, nothing checked, multiple leaks. That’s normal and every LLM will do it this way.

I also don’t think you need to start from the beginning demanding SOLID and everything else. First make it work, then make it work properly, finally make it work fast. It’s always in that order, especially in a simple scope like this.

That’s why now it’s time to ask it to refactor. And the first thing to do is always to isolate the scope, for example, in a block like this:

(function() {
  'use strict';
  ...
})();

The problem with this is that every function the HTML was calling, like “onclick”, will fail because there’s nothing in the global scope anymore. Once everything is hidden, now you have to expose only what actually needs to be public.

This is called IIFE Encapsulation (Immediately Invoked Function Expression). There are thousands of practices like this that Javascript needs to get “cleaner”. I know, I should be using modules, Typescript, blah blah, but this is a simple example.

The goal here is to remember that, just because it “works” doesn’t mean it’s “good”, especially with Javascript.

9. Optimizing the Golang

This is the longest section. The Golang code already “works”, but it’s not good yet. I know it has race conditions in channels, I know the error handling is bad, I know there are still micro security issues, so I want to fix what I can.

The next 6 commits deal with:

• Refactor: Improve error handling, race conditions, and graceful shutdown
• Fix: Critical race conditions, memory leaks, and security issues
• Security: Add message size validation and rate limiting to prevent abuse
• Config: Tighten security limits and add origin validation
• Fix: CORS origins, Web Crypto API fallback, and clipboard issues
• Fix: QR code uses correct port from PublicURL and document Web Crypto API HTTPS requirement

6 commits

GoLang itself has a tool to check for race conditions, the Data Race Detector. Just pass the --race option to commands like go build or go test. And luckily GLM was smart and immediately used this tool when I asked it to check for these issues.

Race conditions happen when two asynchronous tasks try to modify the same data structure, for example. One way to “fix” them is to put Locks or Mutexes on structures that can only be modified synchronously. Any application with anything asynchronous will eventually have race condition issues. It’s not “maybe”, it’s “when”.

A server has to be “well-behaved”, it can’t just “crash” or “panic”. But the first “working” code GLM wrote had several snippets like this:

This is wrong. Besides that, we need the server to correctly accept system signals like SIGINT, SIGTERM, etc. This is when we hit “Ctrl-C”, for example, or when Docker tells the container to shut down. It won’t simply crash the program, first it asks the program to shut itself down, giving it a chance to do cleanup, like flushing files, closing ports and things like that.

This is called Graceful Shutdown.

I didn’t stop to check how right GLM was but according to itself, some of the issues it itself found in the code it itself wrote included things like:

As you can see, just because it “compiles” doesn’t mean it’s ok. Just because it “runs” doesn’t mean it’s ok. Even asking it to check MULTIPLE TIMES, the LLM doesn’t catch all the errors in one go. Each of these commits took hours to resolve and I had to intervene multiple times, and even so I’m still not sure it caught everything (I’d have to review more carefully - but I wanted to publish this article quickly 😂).

10. Adding Security Systems

Again, none of this is necessary in a system that only I will use on my local network, but you as a developer have to take responsibility.

ALWAYS assume every user of your system is MALICIOUS! That’s the RULE, not the exception.

A silly example: the user can paste and transmit any text over websockets to my server. The 3 most obvious things that immediately crossed my mind were:

a) When the host receives the text, it renders it into the HTML in the “Received” box

What if the user sends a <script>....</script>? That will render into the HTML and the browser will EXECUTE it. That’s how Code Injection works. That’s how XSS (Cross-Site Scripting) works. This was very common in old forums or comment systems. To avoid it you must SANITIZE everything coming from the user.

Luckily, the way GLM did it is already sanitized because it writes the content with textContent instead of innerHTML, so the text is written literally without being executed:

It happened to get this right on the first try, but you need to check because it could have done it wrong.

b) There was no message size check

A user should never be able to send text of any arbitrary size. They can always try to POST a gigabyte file directly to see if it blows up some Overflow error on the server, exposing some security exploit.

EVERY user field needs limits and it needs to be checked not only on the client/front-end, but more importantly, on the backend:

c) You have to reject Spammers!!

Again, you can’t assume everyone will use your web app nicely. The rule is to expect everyone to try to take it down or break in. And one way to do that is to write a script to keep making thousands of POSTs per second to try some kind of Denial of Service, where the server queues up so many requests it blows up.

The right thing is to configure this in another service that sits in front of yours, like Cloudflare.

But it doesn’t hurt to implement a fallback in your application itself. A way to configure how many requests a single user can make at a time (e.g. 4 requests per second - no one is going to paste text that many times per second in an app like this).

If they try more than that, the app has to immediately REJECT and drop the connection, without wasting time processing any more, freeing resources for other real requests. This is called RATE LIMITING.

d) Another issue beginners don’t stop to think about is CORS and Origin Check.

As I said before, we have Javascripts like /static/js/common.js. It’s not a huge problem if someone else uses them because they don’t have any big secrets in them. But at the very least I don’t want some site like “http://malware.pk/index.html” to include https://clip.example.com/static/js/common.js inside it and for me to end up paying for its traffic.

I want only the SAME ORIGIN, in this case “clip.example.com”, to be able to load files from the same server. No one from outside is welcome and that’s the BEST PRACTICE. Study CORS (Cross-Origin Resource Sharing). This is more important if your system spans multiple domains where one depends on the other, then you want - in a controlled way - to allow only certain other domains that are under your control.

The rule for everything on networks is DENY ALL and then ALLOW [specific]. It should NEVER be ALLOW ALL.

Implementing this took a while, because GLM kept tying itself in knots over how to allow “localhost”, but also “192.168.xxx:3333”, but also “clip.example.com” (via port 443), etc. It’s not hard, GLM just got itself all tangled up and I had to intervene several times with prompts to steer it in the right direction. It ended up taking multiple commits for it to get it right.

e) Another little thing beginners don’t think about: browser resource PERMISSIONS.

Every time you load this system on “localhost” and it receives a message to drop into the clipboard, this alert pops up asking for permission:

And that’s normal and correct: nothing should have access to things outside the browser. That’s why the Javascript asks “send this to the clipboard”, the browser intercepts it, checks the permission and, if it doesn’t have it, asks for it. Every time it will ask. But if you use a real domain (e.g. clip.example.com), it asks once and then remembers per domain. That’s one of the reasons I’m going to expose it on the internet: to have a real domain.

Exposing services on the internet is DANGEROUS. That’s why I wrote this article explaining how to use real domains and this other article about using Cloudflare Zero Trust.

f) There was another security factor which is “overkill” but I wanted to implement anyway.

Let’s say I want to run only on localhost. Let’s say it’s a private but shared network (guests, roommate, office, etc). Running on localhost there’s no TLS, meaning HTTP packets travel in plain text.

Anyone with Wireshark can “sniff” the packets on the network and intercept mine. And if I happen to be passing sensitive data, like a password, it will be visible in the clear.

The right thing is to run with TLS (HTTPS). But just as a “stopgap”, I asked GLM to implement a simple obfuscation (it’s not a fully secure process, but it uses AES-GCM), which is enough to not be obvious with a sniffer. For this it uses the Web Crypto API.

But there’s a catch: Web Crypto API is only available if the site opens over HTTPS or if it’s localhost. But if I try http://192.168.xxx:3333, it won’t be available. For that there’s this commit that deals with this and documents it.

The goal here is to show that security, optimization, and maintainability aspects are much more than a beginner thinks. In fact, they’ll never think about them, because you need to have studied beforehand to even know they exist.

11. Open Source Licenses

This topic alone would be material for a long article, but in practice I tend to think simply:

• if it’s a project where I don’t care whether anyone contributes or not, I just open it with PERMISSIVE licenses, like BSD, MIT
• if it’s a project where I’d like contributions and that no one uses commercially, I just put a RESTRICTIVE license on it, like GPL
• if it’s restrictive and it’s an app that could turn into a SaaS (so the code isn’t distributed, so there would be no obligation to contribute), then I add AGPL (Affero)

That’s what I did here: I licensed it under AGPL 3.0.

The warning is to not let LLMs write the license file. Always take texts on laws, regulations and rules from the official site. The LLM always produces a shortened or incomplete or even wrong version. Legal documents need to be EXACT, they can’t have wrong words and ambiguous meanings or incomplete statements.

LLMs are not good at producing correct legal text on the first try, there will always be errors. Always assume such text is wrong: there’s no “compiler” for laws.

12. Fixing the problem of overly long tokens

Way back I said that the tokens GLM generated for me are too big (over 100 characters). This results in super gigantic links.

It’s not a problem because no one has to type this and it’s not meant to be bookmarked. This is more of a personal choice: I like short tokens in URLs.

The advantage of the long token is that I don’t need to implement any kind of “database” (key-value store, or KV Store - Memcached, Redis). That’s because all the session info (ID and expiration timestamp) is encoded inside that token, which is why it’s long. It’s a json struct, encrypted with AES, converted to Hex.

Trying to keep the same concept, in this first commit I only asked it to try to optimize the size of the structure. So GLM on its own chose to try to change from UUID (36 chars) to a random 24-char Hex ID. Swap standard ISO timestamp (24 chars) for UNIX (10 chars). This went from 130-140 chars down to around 112 chars. A reduction on the order of 20% to 25%.

It wasn’t a bad attempt. But in the end I wasn’t really swallowing tokens that big (it could be a cookie too, I know, but I wanted to keep everything in the URL).

In the end I decided I wanted really short tokens (8 chars, base62) and so I’d need to keep the Session in some “storage”. I decided it would be “in-memory” (process-affinity, but I’m only going to run 1 instance, no load balancer, so it’s fine). And that would be a FIFO with rotation (older keys get discarded to make room for newer ones, and they expire that way).

This is the commit for that feature and I still had to intervene several times. For some reason it thought it would be a good idea to have a background goroutine cleaning up expired tokens from this storage. But that’s completely unnecessary if it’s a FIFO. It did it anyway, I had to tell it to undo. That’s the routine.

13. More refactoring and cleanup (almost done!)

The last 6 commits are MORE MAINTENANCE!!

Sounds like a joke, but the amount of maintenance I did is actually small. In a real project this is part of the routine. Every time you add something new, you break something that was already there, and you need to adjust it to avoid accumulating technical debt.

Remember we ran the race condition check? We added new code, so it has to be checked again. And it found more issues fixed in this commit. I don’t remember now whether these were already there way back and it skipped them without fixing, or whether the last edits ended up creating these new bugs.

After adding so many things and refactoring, I decided to bump up Go code coverage a bit more. The go test command has the -coverprofile option to help check which parts of your code haven’t been tested yet. So I asked GLM to add tests for new features like Rate Limiting, message size check, origin check and other things.

I asked for a trivial thing which is a Close button on the client side, to not keep piling up tabs on my smartphone.

After I had it swap the token system, there’s no more need to encrypt the timestamp structure. But it left behind unit tests about that. So I told it to remove them. Again: LLMs will leave things incomplete behind. A lot of times it doesn’t know whether to keep code so as not to break the test, or to drop the test because the code is no longer needed.

Then I asked Go to run the linter and support golangci-lint for last-pass checks. A Linter is a sort of formatting, syntax and good-practice check for a particular language. But most of the adjustments were extra whitespace, a few bad indentations and stuff like that. Nothing major.

One last thing that was my own negligence is that I was forgetting to add Javascript tests. A considerable part of the code is front-end dealing with WebSockets and everything. I had to add them, and that was in this commit.

Since I was doing it all in one go, I also asked it to add ESLint, and to prioritize testing everything only unit-wise, with mocks and stubs so everything is headless and doesn’t need to load Chromium. Just test the publicly exposed functions. This raised front-end test coverage from zero to 73%, which is great coverage. See the commit to see how it turned out.

14. Last thing: I18n

This is something I remembered while I was already writing this article. Completely unnecessary, but I wanted to see if GLM could do it. And it “did”. I didn’t detail how I wanted it and I let it come up with the solution. I would have had the Go server swap the strings before sending the HTML to the client.

But GLM preferred to add this on the front-end side and swap the strings via Javascript. It’s not wrong, but it’s not the best way.

Language translation is exactly one of the things AIs were originally built to be good at: Natural Language Processing (NLP). I had it extract all the English strings and then make a Brazilian Portuguese version, and I can say it did it well:

In a real web app this is something we always need to worry about: not leaving user-facing messages “hardcoded” and always extracting and testing them. Which brings me to the last part:

Wouldn’t it have been better to use Framework X or Library Y?

The Go crowd might not like that I didn’t use Gin, Fiber or another web framework. But really in this case the app is too simple. There are no more than 3 endpoints. The most complicated part would be the WebSockets, which wouldn’t look much different using a framework. Or bigger checks like CORS, which also wouldn’t have much less LOC.

On the Javascript side, maybe I18n would have been worth importing a ready-made package, but again, it’s very simple. There was no major feature I had to reinvent.

Of course, this is because this app is miserably small, as I said at the beginning. For a real larger app, I would indeed recommend using a popular framework with good community support, well documented and so on. But things the size of a ToDo List really don’t make a difference unless the exercise was about learning a particular framework.

Thinking about that, you have to be careful because no LLM will pick for you. If you start with small prompts, one feature at a time (which is the right way), it tends to write things all from scratch, without importing any library.

You have to know beforehand which library to ask for each thing!

Again, a beginner wouldn’t know, so they’d end up reinventing the wheel dozens of times instead of using popular libraries.

Remember I said, way back at the beginning, to save the structure of the project in version v0.1 that “already worked”? Here’s how it looks at the end in a real project:

Conclusion

Phew! That was long! Congrats if you made it this far!

My experience on this little project was like having a super motivated intern that I needed to spend the whole day looking over the shoulder of, and every other minute saying:

“Whoa! Stop everything, this is wrong!” “Whoa! Undo it and do it again but this other way!” “Whoa! No, you already did this wrong before and you’re repeating it!”

I’m not kidding when I said it was more than 250 prompts. And that’s a low estimate, I think I wrote MANY more than that.

As soon as I finished the Vibe Coding process, I pushed to GitHub and started writing this article, so there are still hours of REVIEW of the whole code, from beginning to end, to see if I missed anything. You couldn’t put it in production without doing that! If anyone sees weird things in the code, feel free to post in the comments.

It really felt like I was mentoring an intern. But with one problem: unlike a real intern, the LLM has already forgotten everything I taught it.

When I do a new project with GLM, it will make practically ALL the same mistakes and mix-ups. It’s like I was mentoring a blind intern with the memory of a goldfish.

It’s extremely exhausting!!

In the end it took around 12 hours to code everything, and I have the impression that a senior Go developer would have done it on their own in half the time. A junior would have taken this long over 2 or 3 days (stopping to research).

I already knew this, I’ve repeated it dozens of times, but the notion of:

“I don’t need to hire programmers anymore, AI does everything by itself.” - is a GIANT FALLACY.

And it’s not going to get much better than this. We’re already at the top of the S curve I’ve explained in every podcast I’ve been on and in videos on my channel. It costs orders of magnitude more energy to train the next version than it took for all previous versions combined, for incremental progress.

While the architecture stays the same, it’s not going to get past this. There needs to be some NEW BREAKTHROUGH (which hasn’t happened to date, since 2021 when Transformers came out).

A Claude Code will be a bit faster than GLM. The next version of GLM will be a bit faster. Maybe the 12 hours I spent will turn into 6 hours (for this miserable app). But the PROCESS will be the same: it does it wrong, I tell it to fix it, and it does this ad eternum.

There will never be such a thing as writing a single prompt and out comes a perfect, secure, optimized app. It will ALWAYS come out buggy on the first try. That’s why someone who is not a programmer should not build software to put in production with only Vibe Coding: it must go through review by a real experienced programmer.

This is not optional.

Post-Mortem

This section was written the day after publishing the original article. Once I was done, I asked Claude Code to do a deep quality analysis, focused on security and tests. And it found SEVERAL errors. Remember when I said you couldn’t put it in production without reviewing carefully first?

This is the commit with the fixes, take a look.

So it “already worked” in Phase 1, with a ton of problems. I intervened and spent 90% of the time in Phase 2 adding the foundation. I didn’t review it properly and I published the file, now I came back and there are still problems.

Software is NEVER “done”.

Even what Claude Code found doesn’t mean it fixes EVERYTHING. It means it fixes SOME THINGS. No software ever has “a guarantee” of being perfect. That doesn’t exist.

Even if I had started with Claude Code, as I said before, it would indeed have been faster. But it all depends on what you ask it. If you don’t know exactly the requirements and specs for security, or performance, or scalability, or maintainability BEFORE asking, it will do SOME THINGS. Not necessarily the PERFECT THINGS, just SOME THINGS.

Then someone might say “See? Now that you’ve reviewed it with Claude Code, it’ll be perfect”

So, afterwards I also asked GPT 5.2 Codex to do the same extensive analysis and guess what: it also found more little issues. Far fewer, of course. But look at it: after GLM 4.7 and Opus 4.5, GPT 5.2 still found more things. IT NEVER ENDS!

In particular, remember how earlier I had tokens encrypted, then I changed the requirement asking for them not to be and to stay in-memory on the server? Old code from that feature was left behind. GPT 5.2 thought the intention was to finish implementing the encryption and started putting it back. I had to interrupt it and tell it to stop and remove it. Not even Opus 4.5 had removed this dead code.

Always, you who ask are the one responsible for asking exactly and checking afterwards.

• Hello World for LLMs - in this article I explain how to build a simple (educational) little chat program loading an LLM (Qwen2.5) and even how to use prompts so it can call scripts/agents and run a few simple tasks like loading local files. I pushed the code to GitHub as Tiny-Qwen-CLI and I left the code “dirty” on purpose so I could test how LLMs manage (or fail) to adjust that code.
• Your Own Free Co-Pilot - here I explain more about the Aider tool, which is like a Co-Pilot or Cursor, but free and open-source. It does not require plugins or IDEs. It runs in the terminal and is easy to use. I also show how to integrate it with Ollama and spin up your own local LLMs.
• Dissecting an Ollama Modelfile - in this one I dig deeper into LLM theory and explain what Key Sampling is and how various parameters affect an LLM’s text generation, like Temperature or Top_P. This is to demystify even further that there is no “magic” in how an LLM manages to generate text.

Over the last few days I have been testing and posting on X my impressions about the most varied commercial and open source models like Claude Sonnet, Gemini 2.5, OpenAI O4, Deepseek-R1, the new Qwen3 and more. There are more posts on the blog beyond the ones I mentioned above, but these are the main ones.

The goal of this post is to demystify LLMs even more and talk more about my experience testing most of the most popular LLMs.

Demystifying LLMs - 1. Benchmarks and Rankings

Anyone who has followed my talks and videos for years is sick of hearing me talk about the book “How to Lie with Statistics”. And what I see most in the hundreds of posts about LLMs are the rankings based on benchmarks. Here is an example that went viral yesterday, at the launch of Alibaba’s new model, Qwen3:

The problem: the rankings are not wrong. What they mean is this:

“Qwen 3 beats Qwen 2.5 and also other famous ones like OpenAI o1, DeepSeek-R1, Grok 3 Beta, Gemini 2.5, etc …. IN THE BENCHMARKS THAT WERE RUN - and ONLY in the benchmarks that were run.”

That’s all. But 99% of posts publish it like this:

“Qwen 3 IS BETTER AT WRITING CODE than Qwen 2.5 and also other famous ones like OpenAI o1, DeepSeek-R1, Grok 3 Beta, Gemini 2.5, etc”*

The benchmarks are not wrong, what is wrong is whoever interpreted that to mean being better at everything. Let’s go to another analogy:

“Student So-and-So got 99% right on every college entrance mock exam”

People’s conclusion:

“Student So-and-So is 99% better than everyone at everything”

I hope that sounds obviously wrong. Being better at 1 thing makes nobody better at everything, but in AI this is how every news item about a new LLM version is published in personal posts and journalistic outlets. It is an obvious CLICKBAIT. And you fall for it.

And if you are used to hearing it this way, it makes it seem that with every new LLM version - that is “better at everything” than the previous one - we are very close, or have already reached, the point where yes, human programmers are no longer needed, nor mathematicians, nor engineers, nor doctors, since after all, the LLM is “GOOD AT EVERYTHING”.

And nothing could be further from the truth than this. These statistical ranking studies have a testing METHODOLOGY and a fixed benchmark suite. The tests are SIMPLE, think things at the level of “write a function that computes a factorial”, “write a function that sorts a list of words”, “given a list of words, find a specific one in logarithmic time”, etc. Things you see in introductory computer science courses or on Leet Code.

These tests are run MULTIPLE TIMES and the “outliers” (tests where it got way too much wrong, or tests where it got way too much right, or anything that falls out of the average) are discarded, a statistical distribution is built, and a generic overall “number” is compiled like “got 99% right” or something like that.

It got a lot wrong, but that data point is an outlier, and it was removed from the tally. It is statistically irrelevant within the methodology. But here is a fact: no LLM gets it right 100% of the time, and none ever will. I demonstrated this in my post about Modelfiles where I explain that there is a controlled random factor (temperature, top_p, top_k, min_p, key sampling). And there are also normalizations and random factors during training (softmax, relu). And there are also later optimization factors that “round” or “truncate” the probabilities like quantization (fp8, Q4, etc). In other words, there are several “micro error” factors and randomness baked into the entire process. It will never be a “correct” answer, only “possibly one of the most correct” and this “possibly” can vary A LOT.

Dissecting AI Myths - 2. Exponential Evolution

Whoever just arrived and is seeing frequent news about releases of new LLM versions like Alibaba’s Qwen3 now, Xiaomi’s new MiMo, Gemini version 2.5, ChatGPT version 4.1, etc has the impression that we are evolving by leaps and bounds.

But the truth is that yes, 2022 was a historical milestone with the original ChatGPT, mainly GPT 2. But from then until now, evolution has slowed down. Each new version is no longer visibly “twice as good” as the previous one, except in certain benchmarks, under certain specific conditions - that do not match reality. I will demonstrate this shortly.

A friend of mine reminded me about the evolution of deep learning technologies in image recognition, years earlier:

• 2012 – AlexNet: First major victory on ImageNet with 8 layers, reaching 84.7% top-5 accuracy.​

• 2014 – VGG: Networks with 16–19 layers, incremental improvements, but with a significant increase in parameters.​

• 2015 – ResNet: Introduction of residual connections, allowing networks with more than 100 layers and surpassing human performance in top-5 accuracy.​

• 2016–2017 – Inception, ResNeXt, SENet: More complex models with marginal gains.​

• Post-2018: Top-1 accuracy stabilizes around 85–88%, with marginal gains even in models like EfficientNet and NasNet.

AI has been studied since literally the beginning of modern computing in the late 1930s, by none other than Alan Turing himself or John Von Neumann. I talked about them here:

Think of a “slow beginning”: from 1930 until around 2012 when ImageNet and things like AlphaGo, GANs and such started to pick up speed. We left the bottom leg of the “S” for the middle starting in the 2010s and have been accelerating until now. I “guess” that we are either already at, or heading toward, the top of the “S”, where the curve stabilizes and slows down. That is what happened with deep learning for images:

Remember AlphaGo? I followed it live. As a hobbyist amateur in Go, I watched live the games with the South Korean masters like Lee Sedol, at the time it happened, I think 2016. You probably just watched the documentary on Netflix only now, but this has been going on for years. And now, where is AlphaGo evolving exponentially? Everyone has forgotten already, because the hot thing of the moment is LLMs, which is just one more category in the AI world.

The vast majority of optimizations have already been done or are being done. If I had to summarize just some of the most important milestones of this part of the generation, it would go roughly like this:

Every engineer and scientist knows this: when you have nothing, anything is a quantum leap. When you only have 1 real, 2 reais is already “double”. When you have 10 reais, 20 is already a lot. But when you get to 20 thousand, another 100 no longer adds as much value as when you only had 1 (there it would be 100x).

Every new drop of optimization now COSTS A LOT. Even in lossy optimization (quantization) we already went from fp32, moved to fp16, fp8, already reached 1-bit. There is nowhere further down to go after that. We are at the point where we are trading precision for performance.

Doubling parameters no longer results in doubling result quality. Need to double to get 5%? Maybe? And it is no use to keep increasing, the result starts getting worse instead of better. That is why we already jumped to things like specialist LLMs, MoE (Mixture of Experts).

Deep thinking/Chain-of-Thought/Reasoning was a big leap, but just increasing more thinking no longer delivers as much either, in fact, in many cases it makes the result worse with “over-thinking”. Thinking too much is not linear either.

Increasing context does not help improve the answers either. On the contrary, we already see that past a certain point, more context hurts the result, because the attention architecture (the great differentiator of LLMs), has limits. Yes, a Deepseek or Gemini claim to support “1 million tokens”. But I already explained in previous articles that this is Sliding Window Attention like SDPA or Flash where the attention is focused only on a PART of that large context: it cannot pay attention to everything all the time.

Every spot where you could put the obvious things, like caching, whether in training or in generation, has already been put there. We are running out of options here. And yes, new discoveries continue to happen, but as I said, none has yet managed to push past the limits we know exist.

Demystifying AI Myths - 3. Ending Programmers

What I hate most about the current hype are the false promises of “AGI”, “Vibe Coding”, “replacing employees with MCPs”. Let me state it again: it is all propaganda.

Lying propaganda and false snake oil promises (something that always existed and will always exist in history) DEVALUES the reality of the innovations we have today.

“But Anthropic’s CEO and uncle Zuck said they will replace programmers. Microsoft and Google said that 30% of their code already comes out of AI.”

As I said before about statistics. Yes: a lot of stuff IS going to be done with AI indeed. You don’t need AI to optimize work in several areas:

• a stick and a clay block are enough to replace people’s memory. Nobody remembers details, especially numerical ones, permanently. For millennia we have been evolving in helping our memory with some kind of external storage. Whether a clay block, whether paper, whether a post-it, whether a .txt file on your machine.

• the first photographic camera already removed the need to hire a painter to have a “selfie”.

• the first primitive computer already eliminated the need for an entire building of mathematicians doing and redoing calculations on paper. Even so, this is how the first rockets went to space. Have you watched the movie Hidden Figures? I recommend it.

• cars have been assembled almost entirely by robots for years now. Robotics is nothing new in industry. These days, a tablet has already replaced supermarket and McDonald’s cashiers. All of this without needing AI. IVRs and little bots have already replaced a lot of telemarketing and support.

So yes, in practice, AI will also replace an entire class of programmers: the low-value-added ones. The ones who don’t know how to do much more than copy and paste, or whose work routine is repetitive. If your job involves repetitive tasks, it is obvious that it is a matter of time until they get automated, whether by AI or mere scripts. Something we already do today.

A programmer’s job has always been to replace other people’s work. You, who work building an e-commerce system: you helped replace the work of salespeople, window dressers, store decorators, cashiers. You, who build ticketing and support systems, you already replaced human attendants. You, who build delivery systems, already replaced telephone operators. You, who build financial systems, already replaced bank clerks, the people who build bank branches, etc.

You, programmer, have always worked replacing other people’s work. It was a matter of time until programmers replaced the work of programmers. Call it poetic justice. It is just evolution. It happens. Nothing in the world is made to be static nor guaranteed.

Here is the good news: as always happens. There are still painters, even though there are photographers. There are still salespeople, even though there is e-commerce. There is still construction, even though there is not as much need for stores or even offices (with home office). There still exist and will continue to exist, doctors, lawyers, accountants, several professions. The difference is that before, an accounting firm needed a building full of people who knew how to use abacuses and write spreadsheets on paper. Today a single accountant who knows how to use Excel replaces an entire floor. In the old days, an advertising agency was an entire building, today it is one person using Canva, CapCut and Photoshop.

Programmer is the same thing. Before it was an entire building with a purple ball pit. Tomorrow it will be one, GOOD, programmer with Cursor and Aider. Who disappears in this game? Whoever did the low-value-added grunt work.

I warned this was going to happen. For 5 years, before this generation of LLMs and AI even existed. Because it is the natural course of things. The weekend online course programmer. That is the first one who is going to disappear.

Do you know calculus? Do you know Algebra? Do you know Linear Algebra? Do you know Probability Statistics? Do you know what a statistical distribution is? Do you know what vectors or tensors are? Do you know what a Hilbert space is? No? I would take precautions if I were you. If all the articles I published this month of April/2025 were very difficult, you already know what you need to study.

My Experience with LLMs

I have been using LLMs for 2 years. Every kind of research or code I do passes through some LLM in some capacity. I use it heavily, really. My ChatGPT history is gigantic.

And after doing another intensive round to make sure. Yes, o4-mini-high, Sonnet 3.7, Gemini 2.5, Qwen3, Deepseek-R1, etc are all extremely useful and none of them, absolutely none, can satisfy me.

Vibe Coding is enormous nonsense. Nobody without programming knowledge can build more than super simple software (and full of bugs) using only LLMs and prompts or MCPs. That is a fact.

“But evolution is exponential, next year it will be perfect.”

It won’t. I already argued that point above.

“But the benchmarks say they already manage to produce 99% perfect code.”

I already argued that point too, your interpretation is mistaken.

We are near or already at the beginning of the top of the “S” curve. And I see no problem at all with that. I understand how LLMs are made, I understand how they are optimized, I understand what they can do and, more importantly, I understand what they are incapable of doing.

Look at the pull requests of every attempt I made to do code refactoring and unit tests with the main LLMs on the market, open and closed. What I see:

• it needs LOTS of prompting and lots of instruction to get them to start spitting out code that works.
• they look like an intern, the famous “it works on my machine”. They come out spitting, a bunch of copy-pasted code, and don’t re-check whether it makes sense or whether it was needed. The amount of useless code they generate is scary.
• they repeat the same mistakes, even when warned not to commit them.
• even with “agents”, “MCP”, even running the code that was generated and giving the error stacktrace, they easily lose focus, lose attention and cannot fix it. Even retrying multiple times to fix the same error. Even giving hints. Even writing at length what is wrong. They quickly enter a loop. Especially if the so-called “thinking” is enabled. They think too much and don’t solve it.
• I’m tired of seeing attempts to randomly go around tweaking the code, in parts I didn’t even ask them to touch, and breaking more than fixing.
• none of them was able to generate unit tests that work on the first try. Some managed to write a few simple ones, after giving them the error and asking them to fix it. Some get stuck in a thinking loop, confused, and go around changing things without fixing. In the end they fail.
• Out of nowhere they start hallucinating. Qwen 3 itself, if I try to raise temperature just a bit, from 0.1 to 0.2, out of nowhere Chinese characters start coming out in the middle of the code, like this:

• Every now and then, more than one LLM pulled off the feat of generating a unit test that gave a recursive error. This filled the stacktrace so much that if I tried to pass it to the model (over 12 thousand tokens), it would blow the context window and from there it couldn’t pay attention to anything else:

• since they mess up a lot, I repeatedly and exhaustively give it chances to fix things. I run the code it generated, send the error stacktrace, ask it to fix. It touches another part of the code. I run again, it errors and I repeat. If you do this more than half a dozen times, the context starts filling up, sliding window makes it split attention, it “forgets” what came before, starts repeating the same error and stays there forever.

• it does not matter whether it supports 8 thousand tokens, 30 thousand tokens, 100 thousand tokens or 1 million tokens of context. That did not influence the quality of the code nor improved this routine of error repetition. It never manages to pay attention to everything.

• there is no point trying to tune key sampling. whether with temperature 0, 0.1, 0.6. It only makes it err a little later or a little earlier, but it quickly errs and quickly becomes unable to fix its own mistakes. Tools like Aider take the code it suggested and write it over the real code file. Several times, from filling the context too much, it starts to “forget” and delete chunks of code. Thank goodness GIT exists, because several times I needed to run git checkout to go back to the beginning. If you don’t check, be careful, it deletes code or overwrites it with nonsense, and this is frequent.

• deep thinking/reasoning/chain-of-thought, whatever you prefer to call it, just means it spends a lot of time thinking in excess and filling the context with filler, eating up your tokens. If it’s your commercial API, be careful: you will burn through your credits very fast and the result is not significantly better. There are isolated cases where it helps. I recommend leaving it off by default and turning it on only in a few special cases.

And look: my example project is ridiculous: it is 5 files. 4 of them have fewer than 100 lines of code, the biggest one has 400-something lines. A real, large project is MILLIONS of lines of code. It does not fit in any context window of any Gemini or Deepseek. And even if it did fit, it would only make the model more confused. The good practice in any tool is to give it the minimum number of files. And that restricts the use cases to local and isolated refactorings, never things like renaming a class or function that is used in hundreds of files. For that, keep using your IntelliJ.

No model I tested is perfect. Some models do a bit better in some cases. On the first attempt I made with Gemini 2.5, it actually managed to perform the tasks I asked. It did not produce marvelous code, but at least it didn’t break anything.

The second time, I ran git reset --hard and started over, with the same files and the same prompts. This time it was extremely disappointing. It broke the main code during the refactoring and was unable to finish a unit test that works, even though I forced it several times. I gave up out of exhaustion.

The third time, it gave a different result, improved the code a bit and managed to finish the same test. But it also required a few rounds of broken tests, giving stacktraces and asking it to fix obvious errors. And when I say “obvious” it is for it to fix a mock that it itself had placed without needing to.

And this is consistent across all the other models. If I run it only once, I get an impression. For example, that Claude is better than Qwen3. But if I run it again, the same test, now Claude disappoints me and Qwen3 jumps ahead. There is never an objectively better winner. They are all more or less at the same position and keep shuffling in the ranking depending on how many times you repeat exactly the same test, with the same code and the same prompts.

And who keeps repeating the same thing? Nobody. Everybody accepts the first answer. And the first answer can be QUITE wrong. At an obvious level of wrong. If you accept it automatically, you will insert garbage into your repo. And that is my problem with things like MCP or agents: if you leave everything on autopilot and ask things like “take all the code files in this directory and fix every bug”. It will, with full certainty, generate more bugs, delete code, vanish files and leave the final repository in a worse state than before.

Pure Vibe Coding, with zero interaction from a programmer, does not work. I tested all the main models. None was able to pass simple tests. None will be able to pass real larger tests. Not without a lot of interaction from a good programmer to reject errors and demand it try again, or manually fix what came out wrong.

And guess what: a coder who only knows how to copy and paste from stackoverflow (and now from ChatGPT), is unable to recognize many of these errors. So instead of helping, he may make things worse.

For me, who knows exactly what I want, the errors are obvious and I automatically reject them. And I reject what every LLM does more than I accept. Many times I just grab a snippet of what it suggested and discard all the rest. That is the real day-to-day. Everyone who says otherwise has not written code more complicated than a Hello World.

Why do you think every example of “wow, look at the LLM writing code on its own” is always writing a factorial function? Or a crappy web page? Because that is all it actually manages to do. No MCP example I have seen so far has impressed me. It was all smoke. And you got fooled by the propaganda.

Now you know.

How do you learn more and avoid getting fooled? Start by learning the fundamentals. 1 year ago I made several videos explaining how LLMs work. You should already have watched them:

And how to become a programmer who will not be replaced by AI? That is what I made my channel for. When everything I said becomes common knowledge for you, congratulations, you have a good chance of surviving.