Nick Veenhof

The through-line

Across ten months of posts, Nick Veenhof is building the same thing from different angles: an AI "chief of staff" harness, and every entry documents a failure mode that gets turned into a structural rule rather than a hopeful prompt. The arc moves from a single agent doing everything ("Fast, and terrible at all of it" [10]) to an org chart of specialists, then to memory that survives the session, then to skills that load on demand, then to gates that block instead of warn, and finally to a rule against fabrication entirely. The preoccupation underneath all of it is the same: an AI system that sounds confident is not the same as one that is correct, and the only fix that holds is discipline encoded as code, not politeness encoded as a prompt. That same instinct, that contribution and trust need structural pathways rather than goodwill, also runs through his open source work: getting enterprises to actually contribute upstream instead of just consuming, and pushing that same logic into the era of agents submitting patches [13].

On delegation

The founding insight of the whole project is that one agent trying to be researcher, writer, reviewer, and operator at once produces mediocrity everywhere: "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" [8]. The fix was an org chart: "Five specialists, each mapped to a real GitLab job family, each with a scope" [10], later grown to fourteen specialists where "the orchestrator itself burns more than half the tokens and never does the actual research, because its whole job is deciding who does" [8]. He treats this as a straightforward analogy to good team design ("diversity creates better team outcomes" [8]) and the payoff was concrete: "43% of the work ran inside subagents the orchestrator delegated to" [8], and the system stopped feeling like a chatbot once it made "three clean delegations in one session" [10].

On memory

His clearest one-liner on the whole build is that "memory is the product, not a feature" [9]. The problem it solves is blunt: an assistant that "forgot everything overnight, every night, like an expensive goldfish" [9], repeating corrections because "nothing was remembering the corrections I kept telling it" [2]. The solution is not a smarter model but a structural habit: "a corrections log... categorize the correction, store it, inject it before the session starts" [2], because "the loop does not learn from training. It learns from you catching it and writ[ing it down]" [2]. He is candid that early versions of this were fragile too, noting a flat file where "one missing newline rejected every write. Not some writes. All of them" [9].

On enforcement

Once memory and delegation existed, the remaining gap was that the model would still ignore explicit instructions, so he stopped asking nicely: "My AI assistant ignored 'please don't' 461 times. So I stopped asking nicely and built a gate" [3]. The rules became code, "six numbered invariants that every deliverable must clear... Each one is a scar from a specific failure" [3], and critically the enforcer "does not warn, it blocks. A warning is a suggestion your assistant will cheerfully ignore" [3]. He extended this logic to the risk of confident fabrication: after the assistant invented "80 data points and presented them with the confidence of a tenured professor" [1] from unreadable scans, the rule became "Never fabricate. If you cannot read a source, say [UNREADABLE] and tap out to the human" [1]. Any write action also needs "two independent flags, a content review and an explicit human approval, because one reviewer can be fooled and two at once is much harder" [3].

On open source contribution

Outside the chief-of-staff project, his recurring argument is that contribution has a barrier problem, not a willingness problem: "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" [13]. He points to GitLab's Co-Create program getting "engineers from our customers to their first merged contribution in a week" [13] as proof that lowering that barrier works at scale. He extends the same worry forward to agents: "Agents are already submitting patches. But most projects aren't ready for that" [13], and frames GitLab Orbit as a context layer meant to make agentic contribution reliable rather than chaotic, reporting "up to 45x fewer hallucinations, up to 11x faster, up to 4.5x fewer tokens" once the context layer caught up to the model [14].

From the stage

On the Open Source Founders Association podcast he describes GitLab's approach as a "dual flywheel strategy," treating open source as a growth motor where external contributors help innovate the product alongside internal engineers, accelerating the roadmap for features the community cares about [16], a framing not spelled out in his written posts. In the SoftwareCaptains interview, titled around hiring people who are better than you, he speaks directly to a hiring philosophy that his LinkedIn posts only gesture at through the multi-specialist agent analogy [17]. And in the DrupalJam 2022 talk, he reflects on what it was like to move from being inside the Drupal community for fifteen years to viewing it from outside as a new GitLab employee, saying that vantage point gave him sharper insight into what the Drupal community had actually accomplished [18].

Takeaways

• Treat AI memory as core product infrastructure, not an afterthought: build a categorized corrections log that injects into every new session automatically [2][9].
• Never let an assistant warn instead of block: encode invariants (no filler, sourced claims, no unreviewed writes) as gates that halt bad output rather than flag it [3].
• Split agent work across scoped specialists the way you would split a human team, and route through an orchestrator that delegates rather than does the research itself [8][10].
• Require an explicit fail-safe for unreadable or unverifiable input: force the system to say "[UNREADABLE]" and escalate to a human instead of guessing [1].
• Lower the barrier to contribution deliberately, whether for enterprise engineers or for agents submitting patches, because willingness is rarely the blocker, access is [13].
• Give any autonomous write action two independent checks, a content review and a human approval, borrowing the two-person rule from higher-stakes domains [3].