A tiny software change can take seconds to write and hours to land. Somewhere between keyboard and production, it meets the contemporary office obstacle course: a red test that has nothing to do with the change, a merge queue with the temperament of a nightclub doorman, and logs that offer several thousand lines of clues without the discourtesy of an answer. Eli Schleifer has built his latest company around that interval. Trunk lives in the ungainly space after code is written and before everyone can trust it.
It is a revealing place for him to end up. His career has passed through some of the software industry's grander stages: Microsoft, a consumer-video startup acquired by Google, YouTube, and the self-driving operation at Uber. Yet his recurring subject is not spectacle. It is friction. He is interested in the minutes that vanish while a capable person waits for a system to explain itself.
At Trunk, where he is founder and CEO, the product vocabulary is prosaic by design: merge queue, flaky-test detection, failure analysis, CI health. These are the tools around the work, which means they are easy to ignore when they behave and impossible to ignore when they do not. Schleifer's pitch is that developer experience should not be a private luxury reserved for companies rich enough to build an internal tools empire.
An eye for the interface, a mind for the system
Schleifer studied Visual Arts and Computer Science at Columbia College from 1998 to 2002. That pairing has followed him neatly. One discipline asks what a person sees; the other asks what the machine must do. At Directr, the consumer startup he co-founded, the problem was filmmaking. The app helped people assemble video with guidance rather than confront an empty timeline. Google acquired the company in 2014, and Schleifer went on to lead engineering work associated with the YouTube Director suite.
Before that sale, he had already held engineering leadership roles at Microsoft. After Google came a different scale of interface: an autonomous vehicle and the sprawling technical organization required to make it behave. Schleifer ran the Autonomy Systems team at Uber's Advanced Technologies Group. His name appears on patents involving communications with autonomous vehicles, a reminder that his developer-tools argument was formed inside systems where software was attached to consequences in the physical world.
The contrast between Google and Uber became useful evidence. At Google, elaborate internal developer systems could make an enormous codebase tolerable. At Uber ATG, engineers could spend days getting a change landed when comparable machinery was missing. One environment had power tools; the other could leave people swinging hammers at problems that repeated every day.
“Make it faster.”Eli Schleifer, on his goal as an engineer
The business hiding in the wait
Trunk was formed in 2021 with a broad promise: help teams check, test, merge, and monitor code without turning each step into a separate expedition. The company raised a $3.5 million seed round backed by Andreessen Horowitz, then announced a $25 million Series A led by Initialized Capital in 2022. The financing was large enough to prove investor appetite. The more interesting evidence was the mundane familiarity of the problem.
Consider a flaky test. It passes, fails, and passes again without a meaningful change. A developer pushes an unrelated feature, sees red, opens the logs, retries the job, and waits. In isolation the episode is annoying. Across hundreds of engineers and thousands of pull requests, it becomes a tax. Trunk's product tracks test history, groups recurring failure patterns, and can quarantine a known flaky test so its signal remains visible without blocking unrelated work.
The editor is getting faster. The middle of the route is where delay compounds.
Merge queues address another coordination problem. Two changes can each pass their tests against the current main branch, then collide when both land. A queue retests changes in the order they will be merged. Trunk's version tries to parallelize the work when changes do not touch the same parts of the codebase. The object is not speed as theater. It is fewer moments when an engineer must become a part-time traffic controller.
Schleifer's writing tends to make these irritations vivid. He has called flaky tests “productivity-sapping vampires.” He has argued that commit messages on temporary pull-request branches are largely useless when teams squash those branches into one clean change. In June 2026, after a Chrome-extension test hung for a minute, retried, and hung again, he turned test timeouts into a morality play: they rise because raising them is cheap, while lowering them appears risky. Trunk released a monitor to spot that inflation.
▶ Watch the interview
The bottleneck moved
AI coding tools sharpen his argument. If producing a draft of code becomes cheaper, the scarce resource moves. More code creates more pull requests; more pull requests create more tests, merges, failures, and decisions about what is safe. The editor accelerates while the outer loop becomes crowded. Schleifer describes the engineer less as a typist and more as a conductor of automated systems.
He is not sentimental about the old process. In a 2026 essay, he argued for “code first” engineering: when a plausible interface can be generated in moments, teams can prototype before turning every decision into a design artifact. In another, he told a staff product manager that AI raises the value of taste. Being able to generate a screen or a function is less distinctive; knowing what deserves to exist, where users will stumble, and when the result is good becomes more valuable.
Keep the codebase close to the feeling of a fresh project: adaptable enough that a useful idea takes a day, not two weeks.
That word, taste, circles back to Columbia's visual-arts half. Schleifer's public career refuses the tidy split between aesthetic judgment and systems engineering. Directr reduced the intimidation of making a film. YouTube Director turned a complicated creative process into a guided product. Trunk removes the procedural debris around changing code. Each concerns a tool and the confidence of the person using it.
The virtue of boring code
There is a comic modesty in one of Schleifer's more useful technical positions. Trunk once celebrated cleverness, he wrote in 2025. Now it was rebuilding parts of its codebase to be “boring and vanilla.” Clever architecture can be necessary when performance or a genuinely novel problem demands it. Elsewhere, it becomes a private language spoken by the person who invented it and resented by everyone who inherits it.
Conventional code is also easier for AI assistants to read and modify. The machine benefits from the same thing a new teammate does: familiar patterns, plain boundaries, fewer surprises dressed as elegance. For a founder selling sophisticated infrastructure, choosing boringness is less paradoxical than it sounds. Reliable plumbing permits a livelier house.
His listed favorite hobby is woodworking, which provides an irresistible analogue without requiring mythology. Wood has grain. Joints must fit. A beautiful object can still wobble. The craft rewards patience and punishes flourishes that ignore structure. Schleifer's public GitHub adds a more electronic kind of tinkering: among the repositories is a Python project for turning an HTTP request into a Sonos doorbell chime. The corporate job title says chief executive. The weekend evidence says he still enjoys making the system do the thing.
“We all love to code. It's why we became engineers.”Eli Schleifer, writing about Trunk's purpose
A company against babysitting
By 2025, Trunk's flaky-test product had moved out of beta. By 2026, Schleifer was speaking about an even more crowded engineering future, with several agentic coding threads running at once and developers keeping track of work across tools and browser tabs. He described the experience as bonkers and bizarrely fun. The delight is genuine; so is the coordination problem.
His aspiration for Trunk can be stated without fireworks. He wants a large, mature codebase to retain some of the adaptability of a small new one. When a product manager asks for a feature, the distance between “a day” and “two weeks” is often not typing. It is accumulated complexity, brittle checks, slow pipelines, and the fear that touching one thing will upset six others.
There is no final victory over that tendency. Software grows, organizations grow, and every convenience can harden into process. Schleifer's bet is that the surrounding system can keep pruning the delay. A healthy tool disappears into the working day. The test fails for a reason. The queue moves. The engineer keeps the thread of thought. In a business devoted to noisy red boxes, success looks wonderfully quiet.