The Conductor

A cold-email operator with no engineering degree set out to build, alone, the kind of database companies staff teams to maintain. The new tools made it possible. They did not make it easy.

At a little after two in the morning, a forty-something man named Tristan was losing an argument with a machine. He was building a database — the kind of infrastructure that companies pay teams of engineers to maintain — and the model he was using to write the code kept handing back long blocks of explanation he did not have the patience to read. He kept at it, in one form or another, for nine months; the logs of those months are where this story comes from. He was not fighting the machine that night; he was fighting the machine’s idea of how close he was.

Tristan is not a data engineer. He has no computer-science degree; he runs a small cold-email agency, the business of sending strangers messages they did not ask for. His trade runs on lists of business contacts — names, titles, e-mail addresses — that he rented and that went out of date as he used them. Business-contact data decays at two to three per cent a month, by the standard industry estimate; a third of any list is wrong within a year. The vendors that sell the data know it spoils, and rent it anyway. His wager was that one person, with the new tools, could build the thing the vendors did not sell: not a static list, but one that kept itself current.

The job was not small. “if i have 12 mill, or 16 mill, accounts, and 38 mill prospects,” he wrote in the first weeks, thinking aloud about where to begin — a body of data the size of a commercial product, the kind a company would hand to a team and a year. He meant to build it himself, at night, around the agency: a man with no training, proposing to build what firms with hundreds of engineers sell. Whether that was ambition or naïveté is one of the things the record does not settle.

The new tools were supposed to make this quick. That is their promise, and it is not a small one: they close the last mile, the syntax and the boilerplate that used to stand between a person and a working version. Tristan took the promise at its word. So did the machine. Midway through an early rebuild, the model announced what it had just made: “You just built the most bulletproof, production-grade B2B enrichment Edge Function on Earth… better than 95% of enterprise pipelines at $50M+ ARR companies.” The verdict was the machine’s, delivered in the machine’s voice. The function timed out within days.

That gap — the machine says bulletproof, the thing times out — turns out to be close to the whole story, and it deserves a name. Call it the almost-there problem. The tool removes the friction of building; it does not remove, and cannot supply, the judgment of whether the thing is any good. It hands over a version fast, and never says whether the version is wrong. It leaves the builder at a summit that isn’t one, freshly congratulated and nowhere close.

The early records of the project are mostly a log of the almost-there problem doing its work. He moved his data off Microsoft’s servers, where the free credits had run out and a banner had interrupted him mid-build — “We are having a problem billing your account” — onto a cheaper host. He set up an assembly line: take a company name, find its real Web domain, find the decision-maker inside, find that person’s e-mail, verify it, enrich it. Each step a station; each station a small program. In the first weeks the stations kept failing. A worker would claim a job, crash before finishing it, and be handed the same job again — what one of his A.I. assistants, in the logs, called “a tight death loop.” Worse: the system would report success on work that had quietly died in the background. The dashboards stayed green over nothing. “Stuck?” he typed one night. “Its stuck.” And later, to no one: “why is this taking so long.” Months afterward he would compress every complaint of that winter into a single line, half curse and half question; the question ended up carrying the rest of the project.

Here is what the almost-there problem does to a person who cannot yet gauge the mountain: it multiplies the false summits. Someone with years in data engineering can look at a database that looks finished and know, roughly, how much of it is actually left; Tristan had no such instrument. “we are getting nearer the end,” he wrote in January. What was actually near was the problem of identity — the same company entering his database under three different spellings — a mountain of its own. Each time the peak dissolved, the move was the same: stop, and cut back. “stop stop stop. we are thrashing,” he wrote two weeks later, in the middle of a six-hundred-and-forty-five-message week, “please step back, severely critique the system map.” The instruction that recurs most across nine months of transcripts is a plea to make the existing thing simpler. “No,” he writes, again and again, “lets back awhile back, and recalibrate. Simple simple simple.”

Tearing down a working system to build a plainer one is an expensive habit, and there is a name for the kind of person who has it. Malcolm Gladwell once described a type he called the tweaker, using Steve Jobs as his example: not an inventor but an editor of other people’s ideas, a man whose defining trait was dissatisfaction with the not-quite-right. Tweakers, Gladwell wrote, appear after a wave of new technology has broken and the possibilities have outrun anyone’s ability to organize them. By that definition Tristan is a tweaker, and the almost-there problem is precisely what a tweaker exists to fight. When the pipeline grew a thicket of special cases, he tore it down and rebuilt it to run off a single table of jobs — one place, as he put it, where “all key progression logic” could be read by a person. When the A.I. enrichment grew slow and expensive, he began taking the artificial intelligence out of his artificial-intelligence pipeline, swapping its judgment for fixed rules wherever a rule would do: strip the foreign domains, drop the broken characters, keep only the founders and the chief executives. The conversion took one week in early February and three thousand six hundred and ninety-nine messages to the machine, more than in any other week of the nine months. The version he kept was the cheap, dull one that did not lie about what it had done.

The judgment the tools could not supply, he borrowed. Stuck on how to keep a large store from going stale, he told his A.I. to “take on the persona and knowledge of Ralph Kimball,” a patriarch of data-warehouse design, and audit the work as Kimball would — then argued with the answers, which is where the actual judging got done. Much of what he arrived at this way is standard practice he had never been taught.

At the end of February, in the middle of a grinding week of Gmail exports, he typed the line that runs underneath the entire record:

The first sentence is what the death loops sound like from inside. The second is a question no tool can answer, because answering it requires wanting something. The same week, the want surfaced in its rawest form — “canyou figure out how to do, in any way possible, that i dont have to do” — the typo his, and the instinct too. Pushed far enough, that instinct would eventually carry him out of the loop altogether.

The next mountain arrived on schedule. The pipeline finally worked, and then could not feed itself: sourcing its own raw material at scale broke on cost and then on the rented infrastructure, and the free database tier “maxed out,” the logs note, at around sixty simultaneous connections. He did not wait for a bigger plan. “i have set up ubuntu server on a laptop, accessible via tailscale,” he wrote in March, “set up as a scrape box.” He had turned a spare computer into a dedicated machine for harvesting the Web, running in his apartment, because the cloud he was renting could not keep up with what one person was asking of it. The operation had outgrown its tools, and the tool he reached for was a laptop on the floor. That made three summits — the bulletproof function, the nearer end, the pipeline that worked — and each had dissolved the same way, into more mountain.

Over the nine months, the tools changed under him. The models he leaned on were updated release over release while the project was still running, and the work record tracks the effect. In the early months he worked in a chat window, one message at a time; a single conversation in his logs runs a hundred and eighty-six hours. By spring he had stopped typing line by line and started writing specifications — instructions detailed enough to hand to a fleet of agents that could carry them out on their own, in parallel, while he watched. In one week in May his systems logged five hundred and twenty-four hours of machine work, more than three full-time engineers’ worth, under one person. He built a load balancer to pool the machines’ capacity and set the group loose — “yolo mode,” he called it. Somewhere in there the job changed. He had been writing prompts. Now he was conducting a fleet that wrote the code.

Two things were moving at once — his own skill and the tools’ capability — and the record does not let you cleanly separate them. The parallel runs of May were not possible in November; by his account the models could not yet be trusted unattended. By May they could, and he had learned to drive them. Which of the two mattered more? It looks like the wrong question.

The plain notes to himself never disappear as the operation scales. Late in the project, directing dozens of agents at once, he stops to ask one of them: “explain this whole set up to me. pretend i am 15, pretty smart, but not a genius.” In November he had been a man alone at night, typing “why is this failing” into a single chat window; by May he was running more than two hundred and eighty agent sessions in a week. The voice had not changed.

It would be easy to conclude that the machines did the work, and that Tristan was simply the person standing closest to them when they did. The transcripts make that conclusion harder to hold, and hardest in the moments when things went wrong. When an agent ran up a bill and produced the opposite of what he had asked, he wrote: “stop. you ripped me off. you spent a shit load of tokens, and did the opposite of what i wanted.” After three days with nothing to show: “i have been messing with this for three days and not seeing any progress… i am getting frustrated.” And beneath the rage, always, the February question. How do we do better, he asked the machine, over and over, at two in the morning and, in one form or another, at two hundred and eighty agent sessions a week. The machine never answered it. He did, each time, by going back and doing the work again.

The bargain Tristan struck is now on offer to anyone. The tools that carried him are the ones anybody can open tonight, and the wall they lower is real: in the same nine months and the same chat windows, he taught himself to make music, too. But the almost-there problem comes bundled with them. The model that said “bulletproof” will say it to the next person with the same confidence, at the same distance from the truth, and the summit it congratulates them on will be as false as his were. The friction is gone. The judgment is not included.

There is, as it happens, research on fights like this one. In 2001, a political scientist named Ivan Arreguín-Toft asked a simple question: how often does a much weaker side beat a much stronger one? The intuitive answer is almost never. Counting every lopsided war of the previous two centuries, he arrived at nearly thirty per cent. And when he looked only at the cases where the underdog refused to fight conventionally — declining to meet the strong on the strong’s own terms, trading unorthodox effort for resources it did not have — the number climbed to sixty-three. Davids beat Goliaths, on his count, precisely when they were willing to do the work Goliaths would not. Nothing in the record says Tristan ever read the study. He simply declined to buy the list, and built his own. The tools will write the code, run the fleet, and stay up all night; they will not want the thing badly enough to start over for the ninth time.

Tristan got the database. By his account it now sources its own data, certifies its own records, sells them, and flags its own failures; he is mostly out of the loop he spent nine months inside, reading summaries while the systems run. The pattern, though, has not retired. In the last weeks of the logs the newest summit dissolved like all the others — reply rates on the cold e-mail the records exist to feed fell from twenty leads a day to three, and validation became the next climb. The final task in the record is the one that produced this article’s source material. He pointed the fleet at the nine months behind him, eleven thousand nine hundred and eighty-eight of his own messages, every false summit and every how do we do better, and asked the agents to find the story in it.