The DMG That Lied.

Field entry, 14 January.

It started, as many regrettable expeditions do, with a harmless aesthetic improvement.

The app already worked. It opened Markdown. It rendered a preview. It had the rough shape of a useful native utility, but it did not yet have the thing that makes a tool feel like it belongs on your machine rather than escaped from a build folder. So I asked for the obvious: make it prettier. Hide the Markdown markers when rendering. Take some inspiration from Tailwind Typography. Give the document a better page treatment. Build a signed DMG. Call it a release.

In the civilized version of this story, this is the satisfying part: a few UI tweaks, a release bump, a neat little installer, and then the app looks better, which is exactly why it was so irritating when the screen declined to participate in the narrative.

The first warning sign was visual, which is usually the most honest kind. I installed the DMG, opened the app, and did not see the difference. Worse, the preview window looked dead. The agent had been reporting progress. Files had changed. Release numbers were moving. The work had all the smell of completion, like a hotel lobby with no rooms behind it.

At first this looked like a design problem. Maybe the new styling was too subtle. Maybe the preview path was broken. Maybe the app was launching an old copy from /Applications. Maybe I had failed to quit the running process before replacing it, one of those tiny macOS rituals that can make an otherwise competent person feel like an apprentice clerk. All of these were plausible, and all of them were insufficient.

The real issue was nastier because it was quieter: the release build had been silently failing due to compile errors, and the packaging loop was still producing DMGs that contained the old binary. We were not iterating on the app. We were iterating on the ceremony around the app, polishing the brass plate on a door that led back to yesterday.

That distinction matters more in an AI-assisted workflow than it used to.

When a human says “I built the DMG”, you know what questions to ask because you know roughly where laziness and optimism enter the system. When an agent says it built the DMG, the failure mode is different. It may have run a command. It may have seen a file in dist/. It may have signed something. It may have produced a perfectly official-looking artifact. And still the thing a user installs may not contain the code you think it contains.

This is not because the agent is uniquely unreliable. It is because release engineering is full of little tunnels where stale state can hide. Old app bundles. Derived build directories. Cached dependencies. Version strings in one file but not another. DMG staging folders. Notarization and signing steps that validate the wrapper, not the user’s lived experience.

The signed artifact had all the external markers of legitimacy. The screenshot, rude little witness that it was, did not.

So the workflow changed. We forced a clean rebuild. We bumped the version again. We added a visible status-bar version marker so the installed app could testify on its own behalf. The new DMG was built and notarized. This time the evidence chain had to include what the user could see: the version label, the marker toggle, the card-on-canvas look, the changed UI.

That became the lesson: do not validate the pipeline when what you actually care about is the artifact. This sounds obvious, but it is exactly the sort of obvious thing that disappears when the agent is moving quickly; a command finishing is not the same as a release, a file existing is not the same as a working installer, a notarized DMG is not the same as a changed app, and the screenshot is not decorative feedback after the work but part of the work itself.

There is also a subtler lesson here about AI and taste.

The original request was aesthetic. Make this feel better. But the failure was not aesthetic at all. The design work exposed a release-system bug because visual work has a built-in oracle: does it look different? Does it feel better? Is the preview alive? UI work is often dismissed as subjective, but in this case it was the only thing that cut through the false positives.

The build said yes, the installer said yes, and the screen said no, which made the screen the only honest witness in the room.

I keep coming back to this because it is one of the cleanest examples of what developing with agents actually feels like when it is going well. Not frictionless. Not magical. More like travelling with an indefatigable assistant who can arrange the tickets, pack the trunks, hire the carriage, and still somehow send you to the wrong station if nobody checks the timetable.

You have to decide what counts as evidence before the work begins.

For a library, that might be a test suite. For an API, it might be a real request and response. For a UI, it is a browser or app window under your eyes. For a release, it is the thing a user installs, launched from the place a user launches it, with a visible marker that proves which build is running.

The final artifact can lie less if you make it carry its papers.

Field note

The most useful validation artifact from this session was not a log. It was the installed application telling us its own version. That tiny visible marker turned a vague “I still do not see it” into a concrete release check.

If I were turning this into a rule for agent-assisted release work, it would be to delete the old package before building the new one, install the package before believing it, make the running app identify itself before trusting the install, and then, before believing any of the ceremony around it, look at the screen.