Learning in Public

Where/what is my value as an engineer today?

2026-10-12T00:00:00+00:00

There are two camps right now on engineers using agents. One says agents can already do everything, you just define what you want, they build it, you manage them and review what comes back. Human attention is the bottleneck (as we are probably tired of hearing), so put yours on what to build and let the agents figure out the how. The other camp doesn't trust any of it.</p>

I don't think we have a norm for responsible AI usage in engineering yet. You're either balls deep or very skeptical, and there isn't much in between.</p>

The closest thing to a norm I've seen is Mitchell Hashimoto's "whiteboard defense":</p>

I should be able to pull you aside at any moment and ask you to explain any customer-facing system you've shipped. You should be able to clearly explain how it works and defend the decisions you made. This is my benchmark for responsible AI usage.</p> </blockquote>
He doesn't expect line-level familiarity, you don't have to remember the function name. But if he asks "why did you do X instead of Y?" or "where does this fail?" you should be able to answer.</p>
I fully agree with that. My value as an engineer now is a deep understanding of what is happening and why. I don't need to remember the method name, the variable name or the file. The agent probably writes better code than me line by line anyway. But for me that's the floor.</p>
#</a> Owning the shape</h2>
A lot of people say engineers become product people now. I think there's still a clear distinction. Product is the what, and many times the why. Engineering is the how, but also the why, and the why goes hand in hand with the how. Why this module owns that state, why that thing sits behind an interface.</p>
When the agent starts deciding the shape of the code (how big things are, where they live, how they connect) and it doesn't line up with what I would have done, I'm not engineering it anymore. I'm just product owning it.</p>
And you can pass the whiteboard test the whole time. You read what the agent built, you understand it, you can explain it to anyone who pulls you aside, and you're still stuck with a shape you never chose.</p>
I like my modules deep, a lot of behaviour behind a small interface. I wrote my own skills describing how I want codebases designed, and it works, somewhat. It never gets it fully right.</p>
Agents are very knowledgeable but lazy. They take shortcuts, a bolted-on fix here, a special case there, and each one looks fine on its own. I've let them run wild, then wanted to make a change later on and had to refactor almost the entire codebase because of one wrong turn the agent took that I wouldn't have taken.</p>
Every project already has constraints, from scratch or established. I don't want another one that only exists because of whatever the agent happened to write first. Building things that are extensible and easy to pivot without making them overkill is a judgment call, and agents don't have that judgment yet. Once I lose the how and the why, every incremental change and every pivot gets harder.</p>
#</a> The spaghetti argument</h2>
The strongest pushback I know goes like this: "If agents are the ones reading the code, who cares if the modules are deep or it's spaghetti? Tests pass (I also have opinions around ai gen tests), it works, and when it gets messy an agent refactors it in an afternoon."</p>
That's true if you could trust them blindly. I don't think we're there, and maybe we won't be for a while. Human eval is still needed, at least for now.</p>
And I'm still the one responsible for what I ship. I own the engineering side and the codebase, so I should be able to jump in and apply what I know line by line if needed. That's a lot harder in a codebase shaped by someone else's shortcuts. And agents get way more useful when you understand what's happening at a deep level anyway.</p>
#</a> Where I don't care</h2>
Ephemeral work is different. A script to do something once, a prototype, a quick automation to make a process easier one time. I don't care how it's done, I just need it to work, so I fire and forget. Hashimoto draws the same line: "For PoCs, demos, experiments, whatever: I don't care. Generate 100% of it and understand none of it."</p>
#</a> If you're all in</h2>
Slow down a bit. Look at the code, at least at its shape. Decide where things go before the agent does, write it down somewhere it will read, and step in when it bolts something on. Being AFK on the how is fine for a while, until it is not.</p>
#</a> If you're skeptical</h2>
Speed up. Let them type and keep the design yours, and for ephemeral stuff don't even look at the code.</p>
#</a> Where this goes</h2>
I don't know what happens as models get better. Maybe they get the shape right and this post ages badly. Right now there's a gap between how an agent shapes a codebase and how I would, and that gap is where my value is.</p>
I don't think agents are replacing us yet, but you never know, so adapting is key.</p>

Branding a primitive

2026-09-04T00:00:00+00:00

TrueSeal is the E2EE sync primitive I keep mentioning. It's a library and a relay, with no UI and no users of its own. Branding for that sounded like fluff to me. A primitive needs good docs and a clean API, and branding is for apps people look at.</p>

But my job with this project is to put something out and convince people to use it. Nobody installs a sync library because it exists. A dev has to land on the home page, believe it solves their problem and trust it with their user data, and all of that happens before they ever see the API. Deciding what that page says, and how it sounds, is branding. So a primitive needs it as much as an app does.</p>

When I needed to start working on the docs site, I tried one shoting a few prototypes with an agent. I had four home page variants built and I didn't love any of them.</p>

A monochrome one was too boring, I didn't know where to look. The colorful one had rounded cards and gradients, which didn't fit a building block. I figured the problem was visual, so I did a proper brand discovery: purpose, positioning, audience, personality, voice, and only then the look.</p>

Most of what came out of it had nothing to do with colors, and that's the part a primitive needs.</p>

#</a> Positioning: the competitor is giving up</h2>
One of the questions was who TrueSeal competes with. I would've expected product names to be the answer, but the main reason for TrueSeal to exist was that most devs bolt encryption onto whatever sync stack they already have, which sounds like the answer. But when I thought about what I'd actually tell a dev halfway through that, it was "Don't give up on privacy. Use this, it's free" (free in effort, mostly).</p>
Because that's the real fear. Pairing, key sharing, recovery... if you have to build all of that yourself it's a lot of work, so most people won't. They'll ship Firestore unencrypted and move on. That's the thing I'm up against, a perfectly reasonable dev who settles.</p>
So the pitch is that privacy shouldn't be a project you take on. In my head the dev lists what their app does and says "and it is fully private" at the end, almost as an afterthought.</p>
#</a> Personality: no "trust us", no "I know better"</h2>
A couple of the candidate lines leaned on "don't trust anyone". Which is kind of my whole temperament, I just don't like "trust us", it's not good enough for me. But I can't tell you to trust no one and in the same breath ask you to trust me. So that whole tone went out. Same with the more rebellious personality options, they all sounded like "I know better", and I don't want this thing to ever sound like that.</p>
#</a> The look came last</h2>
The stuff I already liked in the prototypes, square corners and the blinking cursor, finally had a reason behind it. And the first home page built on top of the brandbook was the first one I said "I love it" to.</p>

Hiding IPs from my own relay is harder than it sounds

2026-08-28T00:00:00+00:00

While I was writing down what TrueSeal promises and I called it "private and anonymous" (something I like to do detached from implementing stuff, to make myself accountable) I realised that the threat model I'd already accepted said that the relay sees IP addresses and timing, and push fan-out lets it guess who shares a group. So anonymous was out not really true unless you mask your own I not really true unless you mask your own IP.</p>

Pretty simple tho, I'll change the relay to never see IPs.</p>

The relay software already never reads, stores, logs or keys anything on an IP. But a TCP connection hands the source address to whoever hosts the thing. The host OS sees it, the VPS provider sees it, and so does any reverse proxy you put in front. So "never see IPs" really means adding a network hop the relay host doesn't control.</p>

#</a> The options</h2>
My first idea was a proxy in front of the relay, and it's useless against the one party I care about. The proxy sees the IP, the relay sees the traffic, and the same person holds both logs. The Oblivious HTTP RFC (9458)</a> says the two sides can't be run by the same entity. With a self-hosted relay, "the operator" is whoever runs the Docker compose, so the hop has to live outside their hands.</p>
A Tor onion service works. The relay host never learns client IPs, and Noise runs unchanged inside the Tor stream. But that is a bigger more expensive change:</p>

About 430 ms median to get a first response from an onion service, on Tor's own desktop measurements, and that's without the time Tor takes to boot.</li>
Every self-hoster runs a Tor daemon next to the relay and keeps a second secret key around.</li>
iOS can take the socket away when the app is suspended, and a background push gives you 30 seconds. So the phone has to boot Tor again and reach the onion service inside that window. idk, for a library that's supposed to be boring on purpose</a> that sounds like a lot of new ways to break.</li> </ul>
A proxy hop run by someone else (how iCloud Private Relay works) is the cheapest fit. About one extra round trip, and iOS 17+ supports it natively. It only helps if an independent operator exists and doesn't collude with the relay, and I don't have one.</p>
Oblivious HTTP doesn't fit at all. It's built for requests that carry no state between them, and TrueSeal keeps a long-lived receive session open.</p>
Nym is the only option that also hides timing. It's heavy and poor on mobile tho.</p>
#</a> My own code was leaking too</h2>
A device's receiving connection and its sending connections come from the same IP. The push session uses Noise NK on purpose so the relay doesn't learn who sent a message. But if the host sees the same IP on both, it can re-identify the sender anyway. That goes into the threat model whatever I decide about Tor.</p>
#</a> What I did instead (for now)</h2>
For now I changed the docs so they don't lie. They now say: "The relay never logs, stores or uses your IP address. The server it runs on still sees the connection, as with any internet service. To hide your IP from the server too, use a VPN or Tor."</p>
"Doesn't record or use" and "can't see" sound almost the same to a user, and they're very different promises.</p>
"Can't see your IP" is banned from all public copy, along with "zero-knowledge". And the claim has a test behind it: an e2e scenario runs the real relay in normal and dev mode and fails if any client address shows up in the logs or in `inbox.db</code>.</p>`
`Real IP hiding is out of the preview, and not required for 1.0 either. What I did keep is one place in the client that opens sockets, so Tor or a proxy hop can go in later without touching anything else.</p>`
`I'm also thinking about making the sync library refuse to talk to a relay that isn't running my code. It stays self-hostable, but if someone modifies the relay, the sync won't talk to it. (via checksum or something like that, have not investigated these type of mechanisms yet)</p>`


TrueSeal delivery guarantees
2026-08-14T00:00:00+00:00
The TrueSeal docs used to say this about delivery: "Every blob reaches every group member. Eventually, unconditionally." That was my promise, and no sync library can keep that promise, mine included.</p>
TrueSeal is the E2EE sync thing I've been building. A device sends an encrypted message, the relay holds it for each recipient, the recipient picks it up and tells the relay "got it, you can delete it". That "got it" is the ack.</p>
#</a>
At-least-once in plain words</h2>
The sender keeps retrying until the relay says it stored the message. The relay keeps the message until the recipient acks it. If the ack gets lost (connection drops, app gets killed), the relay doesn't know the message arrived, so it sends it again on the next connection. Nothing gets dropped, but the same message can show up twice. That's at-least-once.</p>
Exactly-once would mean the network and the app's database commit together, atomically, and they can't. There's always a moment between "the app stored it" and "the relay heard about it" where a crash puts you on one side or the other. You pick which side: maybe lose it, or maybe get it twice.</p>
And my setup had the worst version of the lose-it side. The device acked as soon as the bytes arrived, before decryptinge. That was on purpose, acking only on success would tell the relay whether decryption worked. But it meant a crash right after the ack lost the message for good.</p>
#</a>
First fix: apps dedup</h2>
Someone has to drop the duplicates. An old ADR of mine already said "callers dedup", but the SDKs dropped the sequence number, so no app could. The protocol has to stay agnostic about payloads</em>, so I went with "the app owns it". The library now exposes a stable messageId</code> (derived from the sender plus its sequence number), and every app stores processed IDs in the same transaction as its own data and skips the repeats.</p>
That shipped in every SDK, and the docs got rewritten to say "at-least-once" (and to stop telling people to dedup by content hash, which is wrong, two deliberate sends can carry the same bytes).</p>
#</a>
Less than two weeks later</h2>
Then I went through the whole delivery contract again, and my one note on it was "these developer/engineer-first primitives need to be as simple as possible to implement".</p>
Apply that to dedup and the answer flips. "Every app must store processed IDs atomically with its own data" is easy to get wrong, and every app would have to get it right on its own. And the agnostic argument doesn't hold up, the library doesn't need to understand the payload to remember an ID it already handled. So now:</p>

The app's message handler is async, and the library waits for it to finish.</li>
The library writes the message ID to its own dedup table (kept 60 days).</li>
Only then does it ack the relay.</li>
</ol>

sequenceDiagram
    participant R as Relay
    participant L as Library
    participant A as App handler
    R->>L: deliver message
    L->>L: decrypt, verify, check dedup table
    L->>A: run handler
    Note over A: crash here, relay redelivers and handler runs again
    A-->>L: done
    L->>L: write message ID
    Note over L: crash here, redelivered but skipped as duplicate
    L->>R: ack</pre></figure>