The first version of Kyle Carberry’s future arrived over dial-up. In Bruno, a small town in Saskatchewan, the internet was less an invisible utility than a negotiation with distance. Carberry tinkered with computers, acquired software by methods he now describes with cheerful bluntness, and eventually discovered that games were not sealed objects. They could be opened, altered, and made to do impolite new things.
Call of Duty supplied the first practical curriculum. He copied and adapted other people’s code to run modded lobbies. Minecraft widened the lesson. Servers needed plugins, plugins needed builders, and the builders could be anywhere. Before high school, Carberry had met John Andrew Entwistle and Ammar Bandukwala online. They spent marathon stretches on Skype making game-server tools, three children in three distant places behaving like a tiny distributed engineering team before anyone thought to call it one.
The work contained a recurring irritation. They wrote software locally, then pushed JAR files to remote servers to see it run. Build here, execute there, upload again. The steps were ordinary enough to escape notice. Carberry noticed. Why should the place where software is written be separate from the place with the compute to run it?
The originating inconvenience
An upload problem becomes a company
Coder was founded in Austin in 2017, but its actual beginning was that question. Carberry and his friends had already spent years making assorted internet tools because they loved software and wanted to start a company. The commercial answer did not arrive fully dressed. Their first approach imagined a friendly consumer product, a sort of collaborative cloud desk for code. It could launch quickly, work in a browser, and summon far more compute than a laptop could carry.
The premise was bold and the market was instructive. Individual developers liked the magic, but large organizations had the sharper problem. Their engineers wrestled with inconsistent laptops, slow onboarding, security rules, and projects that required serious compute. Coder moved toward enterprise users and self-hosted infrastructure. The product changed shape without abandoning the original observation: the laptop could be a window rather than the workshop itself.
Carberry remained unusually close to the machinery. “I’m primarily a programmer,” he said in 2024, “that’s mostly what I do, which is apt for the name of the company.” His public GitHub account reads like the workbench of someone uninterested in being reduced to a title. Alongside the main Coder repositories sit experiments in terminals and isolated agentic development. Founder and CTO are accurate. Programmer is the word he reaches for.
“I’m primarily a programmer though, that’s mostly what I do, which is apt for the name of the company.”Kyle Carberry, 2024
A public workshop
The code became the calling card
One early release put the full experience of Visual Studio Code in a browser. That work developed into code-server, a project whose appeal was wonderfully legible: your familiar editor, reachable from somewhere else. It earned a large open-source following and gave Coder something no enterprise brochure can manufacture, a population of developers who had already used the idea.
Open source, for Carberry, is more than a free tier with the lid removed. It is a cultural x-ray. Engineers considering a job can inspect the code and the pull requests. Customers can see how the product is made. People who dislike the choices can quietly leave before everyone wastes an afternoon interviewing one another. He calls it putting the cards on the table.
This frankness extends to his engineering tastes. He prefers explicit names: write “server,” not “srv,” because a saved syllable is a tiny debt charged to every future reader. Keep abstractions ordinary. Resist the reflex to split a comprehensible system into a parliament of microservices. Consistency matters because code is read under pressure, and ambiguity is a tax that compounds.
His phrasing can be severe and funny at once. Everything that is not writing code, he has said, is “kind of garbage.” The list includes machine setup, hostile configuration files, meetings, and any delay that ejects a programmer from concentration. His analogy is domestic: imagine building a table but having to run to the hardware store five times because the parts keep disappearing. By the fifth trip, nobody feels like a craftsperson. They feel like a courier.
Freedom with a control plane
The disappearing desk
The cloud-development pitch can sound like an argument for taking tools away. Carberry makes the opposite case. He uses Linux and the i3 window manager, and he wants to keep them. An environment in the cloud should be neutral about the editor, operating system, terminal, and keybindings at the edge. Centralizing compute should enlarge developer choice, not replace it with a laggy corporate desktop.
This is why he objects to traditional virtual desktops. When a keystroke appears hundreds of milliseconds late, the security team may be content, but the person typing has been handed a very small daily misery. Coder tries to separate the governed environment from the interface. Infrastructure teams define reproducible workspaces with Terraform. Developers connect with their preferred editors. Source code and compute remain where the organization can control them.
The balance is less glamorous than an editor demo and more consequential. A developer can start with the right dependencies instead of spending days assembling a laptop. A regulated company can keep code inside its infrastructure. A powerful remote machine can do work that a thin client cannot. Idle resources can be shut down. The desk remains personal; the engine room becomes shared and programmable.
Carberry’s ideas about management rhyme with his ideas about infrastructure. He distrusts authority that exists only as a title. The strongest leaders, in his experience, usually become informal leaders first; colleagues already follow their path before the organization labels it. “Being a leader is not being someone’s boss,” he says. “It’s being able to lead someone somewhere.”
At Coder, even appreciation has a lightweight protocol. In an internal channel called #thanks, colleagues can give one another taco credits, each redeemable for five dollars. The sum is modest. The public signal is the point. Help becomes visible, peers reward peers, and gratitude need not wait for a manager’s quarterly performance vocabulary. A good day may pay for lunch.
The same room, new occupants
Then the agents arrived
AI coding tools did not invalidate the cloud-workspace thesis. They made it more literal. A coding agent needs a repository, tools, libraries, credentials, network rules, compute, and somewhere safe to execute whatever it writes. Letting every agent improvise that environment on a personal laptop is less a strategy than an invitation to discover new varieties of chaos.
Coder has widened its focus from human-only development to environments where people and agents can work under the same policies. The company credited Carberry with writing much of Blink, an early autonomous coding-agent project. Its current products emphasize self-hosted execution, auditability, permissions, and the ability to bring different agents into infrastructure the customer controls.
In April 2026, Coder announced a $90 million Series C led by KKR, with Qube Research & Technologies, Uncork Capital, and existing investors participating. The notable detail was not simply the amount. Two participating firms were customers using the platform in their own development organizations. The old Minecraft lesson had reached a peculiar maturity: the remote machine was no longer merely a place to run the code. It was becoming the governed room in which both human and artificial programmers could do the work.
There is a temptation to frame this as a clean march from boyhood tinkering to inevitable success. It was messier. The consumer idea changed. The enterprise arrived. Editors endured when some expected them to vanish. AI shifted from autocomplete toward agents. Carberry’s useful habit was not prophecy. It was keeping one question alive through each turn: what unnecessary obstacle stands between a builder and the thing they are trying to make?
His own advice is to be wary of “problem predictors,” people who build elaborate defenses against troubles that have not appeared. Let many problems emerge, he argues, because reality is cheaper than speculation. It is a surprisingly relaxed doctrine for an infrastructure engineer. Yet it fits. Coder exists because one small, real annoyance appeared repeatedly, on actual servers, to children who were busy making something else.
Carberry now lives in New York, a deliberate exchange of small-town quiet for metropolitan velocity. His personal site still introduces him as a “Former Minecraft kid.” It is both joke and résumé. The game servers supplied his collaborators, his first distributed systems, and the inconvenience that became his company’s central idea. Plenty of founders spend years inventing a tidy origin story. Carberry has the better artifact: an old upload that took too long.