Compile

These past months I wrote a novel and built an app, more or less at the same time.

The novel is a literary thriller about an inexplicable phenomenon in Seattle. The app converts college notes into study songs. They have nothing to do with each other except that both are text projects that another entity has to compile. In one case the computer does it. In the other, a reader compiles it. And the feeling of building something that constantly iterates is exactly the same.

In both cases I made detailed plans before starting, both technological and conceptual. Without prior planning I wouldn't have had a solid starting point to know what I was breaking when things stopped working. The plan doesn't predict, it serves to build a framework where improvisation has something to lean on.

But what really connects both processes is what comes after: the gap that opens between what you imagined and what exists when you finish building it.

In programming that gap has a very precise name: debugging. You open the logs and an authentication error appears. You fix it and it mutates into another error. You fix that one and discover the external provider's API documentation was outdated. Each layer you solve reveals the next one. In the novel, debugging is editorial revision: temporal inconsistencies, objects that appear without being introduced, duplicate scenes because you expanded a chapter without cutting the one that came after. The mechanics are surprisingly similar.

But there's a difference that seems important to me. In the app, the error has an identifiable cause. The log tells you what failed and where. The causal chain is traceable. In the novel, many times the problem isn't technical but experiential: the scene is well written, the internal logic is coherent, there are no factual errors and yet it doesn't work. It doesn't produce what it should produce in the reader. And diagnosing that is enormously more difficult, because there are no logs. There's no error message. There's only an intuition that something fails, and the task of articulating what exactly without having a system to tell you.

It's the same process as collecting feedback from a user about functionality that technically works but doesn't solve what it should solve. The reader who reads a scene and doesn't feel it is the user who uses a feature and something doesn't fit although they can't explain what. In both cases, the problem is in the other person's experience when receiving it. And in both cases, that information only appears when someone from outside comes into contact with what you made.

But it was AI that helped me detect one of the novel's most important problems.

In a conversation about the book's rhythm and tension, Claude identified that the antagonist, built over more than twenty chapters exclusively through an investigation carried out by other characters, reached the climax without the reader having had a single direct experience with him. The body was missing. The presence was missing. I added brief scenes that changed what it feels like to reach the end. And the origin of that intervention was, essentially, a code review: someone who reviews your pull request before deploy and tells you there's a structural problem you don't see because you've been inside the code too long.

That complicates the distinction that seemed clear. In the app, AI wrote and reviewed the code. In the novel, it wrote and reviewed the text. In both cases it occupied roles we normally associate with people: the developer and the editor. And in both cases its contribution was real. But also in both cases what the AI was doing was operating within the project, within the gap between intention and result: accelerating, pointing out, executing. When the application or book reaches readers/users I'll continue discovering distances between what I built and what the other experiences when receiving it. In the end, creating product and, perhaps also writing fiction, is an exercise in shortening that distance, iteration after iteration, without the certainty that it will ever close completely.

Technology solves more and more steps of the process and technical execution. What remains is the ability to build something, expose it, listen and course correct.

Both projects remain open. The novel needs more body. The app needs an economic model that works. Both look quite similar to what I imagined at the beginning. But there was no predetermined path to get here. What there was was the decision to define, at each moment, the appropriate process to move forward.

Building things consists of knowing where you're going and deciding, at each moment, what is the appropriate process to get closer.

–

Do you like thrillers and want to be a betatester for my novel?

Write to me and I'll send it to you.

–

Follow me on LinkedIn to stay updated on new posts.

–