Nick Veenhof

Nick Veenhof's public thinking over the past year clusters around one central conviction: that open source and AI are not opposing forces but the same infrastructure problem viewed from two angles, and that the barrier to both is almost always human process, not technology. Whether he's talking about contributor programs, agentic coding, or building his own AI chief of staff, the throughline is the same: systems fail when they lack structure, memory, and clear roles, and they succeed when someone deliberately designs for delegation, context, and trust.

His open source convictions are the most consistent and long-standing part of his voice. Nineteen years in, starting in Drupal and now running GitLab's enterprise contribution programs, he keeps returning to one diagnosis: "most companies use open source every day but never contribute. Not because they don't want to. Because the barrier of entry is often too high" . His answer at GitLab has been the Co-Create program, which gets customer engineers "to their first merged contribution in a week" , and he frames this as proof that the fuel of open source is contribution, not consumption. This is why standing at the Nasdaq opening bell mattered to him less as a market moment than as a community one: "when I look at that ticker I see every person who filed a merge request, opened an issue, or fixed a typo in the docs. The bell rang for them too!" . It's also why he was drawn to the UN Open Source Week, describing a room "full of governments, maintainers, and policymakers treating this as real infrastructure policy" , and why he ran for a Linux Foundation Silver Director seat, explicitly naming AI as "the next version of this problem" for open source projects that "aren't ready for" agents "already submitting patches" .

That last point is where his two big themes fuse. He doesn't treat AI as a threat to open source or to software engineering, but as an accelerant that exposes unsolved structural problems. On GitLab Orbit, he's blunt that raw model capability wasn't the bottleneck: "The model did not get smarter. The context layer finally caught up" , with results he cites concretely: "up to 45x fewer hallucinations, up to 11x faster, up to 4.5x fewer tokens" . The lesson he draws is that "agentic coding is fast" but "speed without grounded context isn't velocity, it's chaos" . He repeats a version of this insight after hearing Steve Yegge speak at GitLab's R&D offsite, taking away that "the more work agents solve, the more work will be created and the more humans we will need to shepherd them," and that "agents must have a knowledge ledger and git is a crucial piece of that puzzle" . He's also willing to name the cultural friction directly rather than paper over it: "The software engineering field still hasn't fully digested the cultural change that AI brought onto it. Time to get over the grief and grasp that future and opportunity with both hands" .

The clearest, most granular articulation of his thinking comes from his own "Building a chief of staff" series, a multi-part real-time account of building an AI agent system for himself, and it reads like a working engineer's field notes rather than a pitch. He starts from failure: "My AI assistant tried to do everything. It was, predictably, mediocre at almost all of it" , and diagnoses it in organizational terms rather than technical ones: "nobody can be a researcher, a writer, a reviewer, and an operator at once, and expecting a single agent to pull it off is optimism with a token budget" . His fix was structural, not a bigger model: an org chart of specialists mapped to real job families, because "here is what a chatbot cannot do for you. It cannot decide your 11am calendar prep belongs to an analyst, not a writer" . He backs this with numbers from his own usage, noting that across roughly 2,350 sessions "43% of the work ran inside subagents the orchestrator delegated to" and that "the orchestrator itself burns more than half the tokens and never does the actual research, because its whole job is deciding who does" .

Memory is the second pillar of that same project, and he treats it almost as a moral issue rather than a technical one. He recounts a system that "forgot everything overnight, every night, like an expensive goldfish" , and a formatting instruction ignored three times in a row, landing on a conclusion he states flatly: "memory is the product, not a feature. You can wire up the smartest model on earth, but if it forgets your formatting rules, a colleague's name, or last month's failed pattern, you are retraining it every morning" . Later in the series he extends this into how skills should work, describing them as "a workflow, defined as a prompt, loaded on demand" that "tells the agent which tools to call, in what order, with what constraints, before it reasons about anything," while stressing "the model brings the thinking. The skill brings the context" .

Taken together, his positions form a coherent practical philosophy: capability isn't the constraint, structure is. Whether the subject is enterprise contribution programs, government policy on maintainers, or his own AI agents, he keeps pointing at the same fix, which is designing explicit boundaries, delegation, and persistent context so that effort compounds instead of repeating. His tone throughout is unmarketed and specific, favoring concrete numbers and blunt self-critique over hype, and his own summary of the moment could stand as his general takeaway: agentic work "must have a knowledge ledger" , and the organizations, human or artificial, that build one will be the ones that actually get faster.