The question I get asked most often is not which tool I use. It is what this looks like over the long run. Here is the answer.

Architect: the spec that is not in the prompt

The public spec is forty-four lines with no section numbers anywhere. Yet the Texodus sources still carry references like these:

// ── Window close confirmation (§4.4) + Tauri drag-drop (§4.1) ──
/* Implements the 3-button flow required by spec §4.4 (Save / Don't Save / Cancel) */
// Debounce rendering (§6.2)

They point at a detailed, numbered specification — it runs to §12.8 — that I wrote myself, using that public prompt as the starting point. This is probably the clearest answer to what the human actually does here: not "ask for a Markdown editor", but turn a page of requirements into a document the code can cite and that you can later check implementation against, line by line.

Those markers are still in the sources four major versions later, and a rule in the agent instructions requires keeping them: "§N.N comments reference the original product spec — keep them intact". A §4.4 next to the unsaved-changes dialog is not decoration. It is an address: it takes a second to find how the behavior was meant to work, instead of reconstructing the intent from the code.

The boundary follows the cost of a mistake

The agent does not get the same freedom everywhere in the codebase. The line is drawn not by type of task but by what an error costs. The Texodus rules mark it in plain text:

services/markdownSanitizer.ts — single source of marked options + the DOMPurify whitelist, shared by live preview and export so sanitization can't drift. A regression here = XSS.

The cold-start race (macOS Opened fires before main exists) is handled in main_window_is_empty — read its comments before touching.

Where a mistake is cheap — layout, refactoring, routine changes — the agent works on its own. Where it is expensive — the sanitizer, cryptography, saving files — the freedom ends.

The rules file is an archive of mistakes already made

The most useful thing I have learned from all of this: agent instructions consist almost entirely of prohibitions, and every prohibition is the trace of something that once broke. Not an abstract style guide — a list of expensive lessons written in the imperative.

From Kivarion, my password manager:

onDragOver must decide with isEntryDrag, never with getData: the drag data store is in protected mode for the whole drag, so getData returns '' there — which is exactly how entry→group drag came to be silently dead.

Do not move it back into the webview, and do not reintroduce argon2-browser.

The second rule comes with a full paragraph of reasoning: the WASM call is synchronous no matter what the promise looks like, and kdbxweb re-derives the key on every save — so the interface froze for the length of the KDF on every auto-save.

From Texodus:

AppState.pending_files is a queue per window label — several "Open With" files can target one window before the frontend drains; don't collapse it back to a single slot.

Every one of these lines was written after something went wrong. Their value is that they stop anyone from returning to the "simpler" solution that already turned out to be the wrong one — the agent, and me six months later.

Reviewer: I look at everything, I read selectively

I go through every diff. But I do not read all of it closely — only the parts that touch critical and important code. That is the only honest way to work at the speed agents give you: reading every line would eat the entire gain, and reading nothing means eventually shipping a regression in the sanitizer.

So the other half of review is automated. The rules contain a one-line gate:

Run typecheck + test + lint before declaring frontend work done.

Work is not done until those three commands pass. The tests cover exactly the dangerous places — the sanitizer is tested for stripping XSS, and the rules even record why the test environment is jsdom rather than happy-dom: happy-dom's parser mishandles siblings after a <script>, which would have made the test useless.

This is a system, not one project's setup

CLAUDE.md lives in many of my repositories. In Texodus and Kivarion an AGENTS.md sits next to it — I work with two agents in parallel, and each one needs its own file carrying the same knowledge about the project. Those files never reach the public repositories: they are in .gitignore and stay local.

Rules pay off best where things break quietly. For example, the CLAUDE.md for this site records that routes are linked by name, so renaming one silently breaks both the links and the active-menu highlight, and that the sitemap generator parses the routes file with a regex — which is why the one-line route format must not be touched. Neither tests nor reading a diff catches that.

Where it breaks: the line between JS and Rust

The most expensive problem I have hit was not code quality. It was that the agent has no memory between sessions.

In a Tauri app, almost every task has two places it could be solved: the JavaScript frontend or the Rust backend. The agent kept getting this wrong — and it decided differently in different sessions and different tasks. Not because the choices were bad: each individual one was defensible. The problem is that every new session starts from zero, so any decision not written down in the project gets made again, differently. Architecture does not drift because of one big mistake. It drifts because of a dozen small ones, each perfectly reasonable on its own.

There is exactly one cure: draw the boundary explicitly, in writing. In Texodus the rules list all five Rust commands and state what belongs to the backend and what to the frontend. In Kivarion the line is drawn harder, with the price attached:

KDBX 4's KDF runs in the backend, not the webview. […] Do not move it back into the webview.

The frontend has no direct filesystem access; saveDatabase serializes the db and calls the Rust save_database command.

Which closes the loop on the archive of mistakes: the rules I quoted earlier exist because of exactly this problem. The agent does not remember architectural decisions. The repository does.

What it comes down to

The split is simple. I own the spec, the boundaries — both trust and architectural — and the critical parts of the code. The agent owns the volume of work inside those boundaries. Tests and the linter make sure I never have to take its word for it.

All of it reduces to one principle. An agent has no memory between sessions, so the project's memory has to live in the project: a numbered spec the code can cite, and a rules file that grows out of every expensive mistake. Whatever is not written down will be decided again — and differently next time.

How I pick models for this kind of work, and why I do not trust leaderboards, is on the AI page and in Prompt Vault.

Here is what shipping Texodus taught me about the distance between "it builds" and "they downloaded it and it started".

Linux: it did not start for everyone

I did not find this one myself. It arrived as a bug report on GitHub: the AppImage would not launch at all, dying on graphics initialization. On my machine, and on plenty of distributions, everything worked — exactly the kind of symptom you cannot reproduce where you develop.

Could not create default EGL display: EGL_BAD_PARAMETER

The cause was not in the application code but in the packaging. linuxdeploy faithfully bundles the graphics client libraries of the machine that built the app — in my case Ubuntu 22.04 on GitHub Actions. At launch they are loaded ahead of the host's own copies, and then talk to the host's Mesa driver. As long as the versions stay close, this works. On recent Mesa — the report came from Arch with RDNA4 — WebKitGTK cannot initialize EGL through that mismatched pair, and the window simply never opens.

The reasoning is the same as behind AppImage's standard excludelist: the graphics stack has to come from the host, not from the bundle. Which means those libraries have to leave the bundle.

The fix belongs in the pipeline

Fixing this by hand once would be useless — the next release would rebuild it exactly the same way. So the GitHub Actions workflow got a step that runs after the build: unpack the AppImage, delete what should not be there, and pack it back up.

find squashfs-root \( \
  -name 'libwayland-*.so*' -o \
  -name 'libgbm.so*' -o \
  -name 'libdrm*.so*' -o \
  -name 'libEGL.so*' -o \
  -name 'libGL.so*' -o \
  -name 'libGLX*.so*' -o \
  -name 'libGLdispatch.so*' \
\) -print -delete

Then came three details, each of which cost its own round trip:

• No FUSE on the runner. Extraction goes through --appimage-extract, and appimagetool itself runs with --appimage-extract-and-run.
• The appimagetool download was dead. Assets on the old AppImageKit releases return 404, so the step pulls from the maintained AppImage/appimagetool repository instead, at a pinned version.
• The asset was already uploaded. tauri-action publishes the AppImage before this step runs, so the finished file has to be swapped through the API: delete the old release asset, upload the repacked one.

None of this follows from the Tauri documentation. All three showed up on live releases.

macOS: not even in CI

The Texodus build matrix has two runners: ubuntu-22.04 and windows-latest. macOS is not there at all — those builds run locally, from a separate script.

The reason is signing. A shippable DMG needs a Developer ID certificate from the local keychain and notarization with Apple, which wants an app-specific password and a team ID. On top of that, a universal binary means two Rust targets (x86_64-apple-darwin and aarch64-apple-darwin) built and merged. All of this can be moved into CI — at the price of spreading certificates and secrets across someone else's infrastructure. For a project I run alone, a local script turned out to be the honest trade.

The result is one application with two different release paths: Linux and Windows build in the cloud at the push of a button, macOS builds on my Mac.

One feature, three mechanisms

The most underrated part of cross-platform work is not packaging. It is that identical behavior has to be implemented differently.

Take opening a file by double-clicking it in the file manager. On macOS the path arrives as a RunEvent::Opened event. On Windows and Linux it arrives as a command-line argument, plus a single-instance plugin so that a second launch hands the file to the running process instead of starting a second application.

The macOS branch also has a race that does not physically exist on the others: Opened can fire before the main window has been created. Until that was handled, double-clicking a .md file while the editor was closed opened two windows — one empty, one with the file. The routing logic saw no window and read that as a signal to spawn one.

The same category includes features that simply do not exist elsewhere. In Kivarion, Touch ID unlock is macOS-only, and reporting an honest "not supported" on Windows and Linux is as much a part of cross-platform work as the feature itself.

What I took away

• Test the release artifact, not the build. The EGL problem lived neither in the code nor in a dev build — only in the packaged AppImage, on someone else's system. If you do not test that, a user will, and then they will write to you about it.
• "Works on my machine" means nothing on Linux. Distributions differ in graphics stack versions more than you expect, and it is the newest environment that breaks, not the oldest.
• A platform fix has to be a pipeline step. Anything repaired by hand after the build is lost on the next release.
• Plan for different release paths. Apple's signing requirements differ enough that a single pipeline for all three platforms stops being an obvious goal.

"Cross-platform" is true about the code. About delivery, it is three separate projects that happen to share a repository.

Texodus is open source: repository and releases.

Let me be upfront about where I am standing. I have never worked at a FAANG company myself. But in twenty-plus years in this industry I have worked alongside plenty of people who did, a good number of my friends and former colleagues built careers there, and I have interviewed and hired candidates coming out of those companies. This is the view from the other side of the table — the side where the brand on the résumé stopped answering the only question that matters: what can this engineer actually build?

The role narrows to a single component

At a company with hundreds of thousands of employees, work has to be split into very small pieces. That is not a flaw in anyone's character — it is what scale demands. But instead of designing a system or taking a service from zero to production, an engineer can spend years maintaining one narrow component of one internal platform. Depth in that component grows. The view of the system as a whole quietly atrophies.

The result for a career is the same either way: after a few years you know something brilliantly, and that something exists only inside one company.

A closed stack does not transfer

The largest companies have always built their own ecosystems: their own frameworks, build systems, version control, deployment tooling. Inside, these are often excellent — years ahead of what the rest of the market has. The problem is not quality. It is portability. Expertise in an internal platform is worth very little the moment you walk off the campus.

There is an honest complication here worth stating. A significant part of today's open stack consists of public descendants of exactly those internal systems: Kubernetes grew out of the experience of Borg, Bazel is the open version of Blaze. The argument is not that Big Tech has bad tools. The argument is that the market runs on the public versions, and an engineer who spent four or five years on the internal ones tends to discover that the ecosystem moved on without them — from cloud providers to orchestrators to frameworks.

Golden handcuffs

High salaries and equity grants build a standard of living that is hard to maintain anywhere else. The price for that comfort is often routine work wrapped in process. Colleagues describe simple changes spending weeks in approvals that a small team would not need at all. Engineering initiative does not die suddenly in that environment. It just stops paying off.

What Big Tech still teaches better than anyone

I am not interested in building a straw man, so let me be clear about the other side. Some things scale teaches better than any startup can: operating systems where a failure reaches millions of people, a real code review culture and the discipline that comes with it, the skill of changing a running system without knocking it over. And for researchers and R&D engineers pushing fundamental work, those labs are still the best places on the planet.

Choosing stability is a legitimate choice too. Trading some speed of professional growth for comfort and predictability is an adult decision, not a mistake — as long as it is actually a decision. The failure mode is the cargo cult: treating "getting into the corporate elite" as the goal itself.

What to do about it

If you are an engineer inside a big company, do not let the internal platform become the only thing you know. Side projects, open source, a public trail — anything that lives outside the campus and can be checked from outside it.

If you are hiring, look past the brand at what the person has built and what you can verify: shipped products, breadth of stack, a visible trail in open code. The brand on a résumé answers the question of where someone was once hired. It stopped answering the question of what they can build a while ago.