GolfNext Engineering

AI unleashed

John Allan Nielsen — Wed, 14 Oct 2026 00:00:00 +0000

I wasn’t AI native when I started at GolfNext in August. I had used GitHub Copilot before, both the autocomplete that suggests the next few lines while you type and the chat where you can prompt it, and I wasn’t impressed. It couldn’t do my tasks for me. At the time I was building an integration against a system whose documentation was private, behind a login, and there was no way to make Copilot read it. So whether it was completing a line or answering a prompt, it was working against an API it had never seen, and I did the actual work myself.

My boss told me I’d be amazed by Claude Code. I thought I’d believe that when I saw it. Then I saw it.

Claude Code isn’t autocomplete, and it isn’t a chat window either. It’s an agent: you give it a task, and it reads the code, runs commands, makes changes and checks its own work. It can even use my browser when I let it, so documentation behind a login is something it can go and read, the same way I would. The wall I hit with Copilot simply isn’t there anymore. In the two months since, the way I work has changed shape around that. These days I’d call it agentic engineering. I spend my time deciding what should be built and checking that it was, and agents do most of the building in between.

Here’s what that looks like on the biggest thing I’m working on.

We have two admin portals. Each has its own backend, its own login and its own database, and club staff who use both log in twice. Merging them into one is on the roadmap, and I’ve written before about the order we chose: a bridge between the two logins first, then one frontend over both backends, then the backends themselves.

The first two steps are done. The frontend of one portal now lives inside the other, the two platforms talk to each other, and feature development carried on in both the whole time. Nobody got a maintenance window. Golf clubs run on this software every day, so there was no planned downtime, and there won’t be any for the rest of it either.

The next step is harder. One of the backends is written in Java, and we’re rebuilding it in Go. Once that’s done, one backend gets ported into the other, and we end up with a single application. Again without stopping feature work, and again without a window.

Most of the code for that won’t be typed by a person. That’s the part people ask about, and it’s the least interesting part. The first decision on any piece of work is its size, because I use agents in three different ways. The backend merge is the large case, and I’ll get there by way of the small and medium ones. What changes between the three is how much of the thinking I hand over, and when I take it back.

Small: can you do this on your own?

For a small task I ask the agent one question before anything else: can you do this on your own?

I don’t say “do this”. I ask whether it can. It reads the code, looks at what the task touches, and tells me whether it’s confident or whether there’s something it doesn’t know. Most of the time the answer is yes, and it does it. Sometimes the answer is “this depends on how X behaves and I can’t see that from here”, which is exactly the sentence I want to hear before it starts rather than after.

A typical one: a bug report about a printer that doesn’t print. The software knew perfectly well something had gone wrong, because it wrote the error to the logs. It just never told the person using it, who got no warning at all and was left waiting for a printout that wasn’t coming. The fix is small and well-bounded: find where the error is caught, and show it to the user instead of only logging it. I asked the question, got a yes, and the agent fixed it on its own.

The question costs nothing, and it changes the failure mode. An agent told to do something will do something. An agent asked whether it can is allowed to say no.

Medium: research first, options second

For a medium task the agent goes first, but it doesn’t build anything. It evaluates the task, does the research (the code involved, the API documentation, how the same problem is already solved elsewhere in our repositories) and comes back with what it found and what it would suggest.

A typical one: a feature request from a club that uses a specific integration. The agent can read the integration, see what it already supports and work out where the request would fit. But it comes back with questions rather than an answer. Is this feasible at all with what the integration exposes? If it is, which part of the integration should be expanded? Or is this one club’s need different enough that it deserves a custom module of its own, rather than bending a shared integration around it?

Those aren’t questions the code can answer. They depend on how many other clubs use that integration, what we’re willing to maintain, and where the product is heading, and none of that is written down anywhere the agent can read. So it can’t complete the task without me, and it shouldn’t pretend it can. What it can do is turn a vague request into a short list of real choices with the trade-offs worked out. Then I start shaping: I pick one, combine two, or throw them all out because the research changed the question.

Large: a couple of hours, before any code

For a large project, and merging two backends while both of them keep shipping features is a large project, I spend a couple of hours planning with the agent before anything gets built.

Part of that is brainstorming. Most of it is me supplying context the agent cannot get on its own:

Architecture. What talks to what, which boundaries have to hold, what the target shape is and which compromises are allowed on the way there.
Technology. What we’re standardising on, what we’re moving away from, and what is off the table.
Purpose. Why we’re doing this at all. Here: club staff should log in once, and we should maintain one system instead of two.
User experience. What the person at the other end will see during every step of the migration, including the steps that are only halfway done.

The plan starts its life in the agent’s context, the running conversation we’ve just spent two hours filling. That’s a fragile place to keep anything. Close the session and it’s gone, and nobody else on the team can see it while it lasts.

So the last thing the planning session does is write it out, as tasks in our task system rather than a long document. Each task gets its subtasks, and the agent records the dependencies between them: what has to exist before a task can start, and what is waiting for it to finish. By the time I close the session, the plan has stopped being a conversation and become something the rest of the team can see, pick up and track.

Before anything runs, the team hears it. We talk it through briefly, and they hear the suggested solution. Those talks are short, because we already agree on most of the direction. Sometimes I also ask a colleague to look at the plan itself for a second opinion, since a plan that only one person and one agent have seen has had exactly one human check.

This is the expensive part, and it should be. Every question answered here is a question an agent won’t have to guess at later. Every dependency written down is a collision that won’t happen when thirty things are running at once.

Execution is the boring part, on purpose

Once the plan exists, executing it is almost an anticlimax. I hand it back to the agent, and it starts subagents (separate agents it launches and coordinates itself, each with its own task) on every subtask whose dependencies are met. Usually somewhere between ten and thirty of them at a time. When one finishes, whatever was waiting for it can start.

Thirty agents in one codebase sounds like a recipe for them tripping over each other. What keeps them apart is the plan. The dependencies written down during planning decide what can run at the same time and what has to wait, so two agents don’t end up building on something that doesn’t exist yet.

This works because nothing that matters is left for the agents to decide. An agent running a well-defined subtask with its context written down next to it is doing exactly the kind of work agents are good at. An agent running a vague task guesses fluently, and you find out which parts were guesses afterwards.

That’s also why I don’t trust the word “unleashed” when people use it about AI. The agents only run loose because the plan is tight.

Did they build what I planned?

When all the agents are done, I first check whether they built what I planned. Did every task actually land, and does the whole add up to the thing we designed, rather than a set of subtasks that each pass their own tests?

Then I review from three directions:

Architecture. Did the boundaries hold? Did anything reach across a seam it shouldn’t, or quietly add a dependency the plan didn’t have?
Code quality. Is this code someone on the team can own next year? Consistent with the rest of the repository, tested where it matters, no clever parts nobody asked for.
User experience. Does it feel right to the person using it, including mid-migration, when half of the system is old and half is new?

Two of those, architecture and user experience, are context I gave the agent at the start, so the review is really checking the work against what I supplied. If it keeps finding the same kind of problem, the fix usually belongs in the next plan.

The clearest catch so far came from the backend rewrite itself, a port from Java to Go. On paper, the agents delivered what was planned: the endpoints were there and did what the old ones did. But the first version was Java written in Go. Where the Java code leaned on a library, the agents rebuilt that library in Go by hand, even when Go’s own standard library already did the job. Dates were the obvious case. Instead of using Go’s time package, which handles them perfectly well, we got a home-made copy of how Java does date and time.

None of that fails a test. It compiles, it runs, it returns the right answers. It’s also code nobody on the team should have to maintain: more of it than needed, shaped like a language it isn’t written in, and unfamiliar to anyone who knows Go. That’s a code quality problem and an architecture problem at once, and you only catch it by asking “is this how we’d build it?” as well as “does it work?”.

The fix went back through the same loop as everything else. I asked Claude how we could get rid of the home-made library and use Go’s standard one instead, without losing anything. That last part was the real constraint. Clients already call those endpoints, and every timestamp they get back has to come out in exactly the same format after the port as before it. A port that is cleaner on the inside and breaks somebody’s date parsing on the outside isn’t finished. It got fixed: the home-made library went, and the timestamps stayed the same.

Where my time went

Add it up, and on a large project the typing has nearly disappeared from my day. What’s left is the two ends: hours of planning at the start, and a careful review at the end. It’s different work, and there’s no less of it. But I get far more done with it.

I think that’s the right way to see AI coding: as a compiler, not as something coming for our jobs. Nobody writes machine code by hand anymore. The compiler took that over decades ago, and it didn’t make programmers redundant. It moved the work up a level, to deciding what the program should do. Agents are the next step up, with one big difference: a compiler doesn’t guess. That’s why the review at the end isn’t optional.

So far, here, the productivity hasn’t turned into fewer people. It’s turned into bigger ambitions. Every team has a list of things clearly worth doing that never beat the next customer request: better internal tooling, features customers would enjoy but never asked for loudly, easier onboarding for the next person who joins. Now we have time for them.

In August, AI to me was autocomplete and a chat window, and I wasn’t impressed. Two months later I’m planning the merge of two backends that can’t be taken down, and handing the plan to 10, 20 or 30 agents at a time.

My boss was right. I was amazed. But the speed of the typing isn’t what amazed me. It was finding out that once the typing stops being the job, the part that’s left, the plan and the review, is the part I’d always rather have been doing.

Feeling like a hot chick

John Allan Nielsen — Thu, 08 Oct 2026 00:00:00 +0000

At the end of September one of our sales managers closed a deal that took almost no time. Peter Selmer, who founded GolfNext in 2012, wrote about it on LinkedIn. The sales manager didn’t have to convince anyone. The club’s members had already done it. They’d used our kiosks at other golf clubs, then came home and asked their own club: “Why not here?”

I commented under the post that golfers asking their own club for GolfNext is the best signal there is. I’ve kept thinking about it since, and this post is the longer version of that comment.

The one everyone wants

So, the title. The hot chick in this story isn’t me. It’s the product.

GolfNext makes software that golf clubs run on, and the part golfers see most is the self-service kiosk: a digital reception that runs around the clock, so a player can pay a green fee, rent equipment or buy from the pro shop without anyone standing behind a counter. As far as we know, nothing else like it exists in golf.

Most software only gets noticed when it breaks. Nobody walks into a building and asks who made the door handles. But golfers use our kiosk at one club, and then they go to the next club and miss it. Then they ask for it. That’s what being attractive looks like for a product: people want it before anybody has pitched it to them.

Peter put the shift in one line: golfers now expect check-in to be fast and simple, and they notice when it isn’t.

What it does to me

The kiosk is something we make ourselves. Colleagues in-house build part of the hardware, and my other colleagues and I build the software that runs on it and everything around it. So when golfers ask for it by name, they’re asking for something we made, and I’d be lying if I said I didn’t feel a bit of that attraction rub off.

It’s a good feeling, and it does something to how I work. When you know people are asking for the thing you make, by name, you want to be worthy of it. A bug that would be a backlog item somewhere else stops being one. A screen that’s fine becomes a screen I’d like to be great. You start reasoning from the player standing at the kiosk at half past five in the morning, because that player is the one who’ll go home and tell their own club about it. Or won’t.

Nobody has to tell me to do my best on a product like that. I want to.

Staying attractive is daily work

Products don’t stay attractive by themselves. We work on it continuously, and most of it comes down to four things.

Easy to use. For the player at the kiosk, and for the staff behind the desk. When a PDF of ball codes that clubs print out started spilling onto two pages, it didn’t wait in a backlog for a month. It was fixed within the hour. Small things like that are the difference between a product people put up with and one they ask for.

Easy to integrate. Clubs already run other systems, and they shouldn’t have to choose between those and us. The easier we are to plug in next to what a club already has, the fewer reasons it has to say “not yet”.

Less dull manual work. Every physical device we have out there, kiosk screens, card terminals, ball dispensers, now joins with a 12-digit code typed in on site, and from then on gets its settings and updates from us. Nobody connects to a device and sets it up by hand anymore. The next step is a small web page where club staff set up a new device themselves, so replacing a broken one takes a parcel and a link instead of several phone calls. Nobody went into this job to type the same settings into the fortieth machine, and nobody at a club did either.

Open when everyone has gone home. This is the one that matters most to me. The kiosk is a reception that doesn’t close. When the last employee has locked up and driven home, a player can still turn up, pay a green fee and play. The club keeps earning outside opening times, and the golfer gets the same convenience they have everywhere else in their life. That only works if the product is reliable when there’s nobody on site to restart it.

And then there’s listening. When a club tells us something is a bug, we usually solve it the same day. Sometimes, though, the thing one club calls a bug is exactly what another club likes. Then we don’t pick a winner. We make it a setting, and each club decides for itself. Everybody stays happy, and club administrators stay in charge of their own setup instead of having to ask us to change it for them. A product that’s self-service for golfers should be self-service for the people running the club too.

Where it’s heading

None of this is about being a nice product for a handful of clubs. In August I wrote Road to glory, our plan for the platform underneath everything, and I said the ambition out loud there: we want this to be the platform the golf industry runs on. Every club, every range, every country that has both.

That post was about the engine: fewer languages, one shape for every repository, a codebase anyone on the team can open and be useful in. I also wrote that the engine can’t create the thing that makes the ambition realistic. Clubs who see the product are amazed by it, and that reaction is the asset. Peter’s Friday deal is that reaction, playing out in a sales meeting.

So the engine matters because of what it lets us do for the people standing in front of the screen. And for that, user experience comes first. Every decision starts from the person using it: the golfer at the kiosk before the first tee time, the staff member who has to explain something to a member, the administrator changing a setting at the end of a long day. If a feature is clever but makes any of them stop and think, it isn’t finished. The best compliment our product can get is that nobody notices it, right up until they’re at a club that doesn’t have it.

That’s the kind of ambition that keeps me going. Not just to grow, but to grow by being the thing people prefer.

Attractive is a promise

There’s a flip side, and I think it’s the important part.

Being the one everyone wants raises the bar. Members who compare clubs will compare us too, and a kiosk that’s frozen at half past five in the morning isn’t just a bug. It’s the moment someone stops asking “why not here?”. The attraction only lasts as long as the product keeps earning it.

That’s what the last part of my comment was about. “We will keep delivering” sounds like the kind of thing you write under a colleague’s post. I meant it as a promise. The sales team can only close deals that fast because golfers already like what they’ve used, and keeping it that way is my job.

It’s a nice job to have. Most days I’m just an engineer fixing a print layout or chasing a bug. But when golfers go home and ask their club for the thing we make, I’ll admit it: for a moment, I’m feeling like a hot chick. And there’s nothing more motivating than wanting to stay that way.

Enter the project manager

John Allan Nielsen — Tue, 06 Oct 2026 00:00:00 +0000

My degree is in management accounting. Not computer science.

It’s the inward-facing kind: financial accounting produces the numbers the outside world is shown, management accounting produces the numbers the people running the thing need in order to decide. Efficiency, planning, budgeting, management — four words that look like four subjects and are really one question asked four ways. Where does a scarce resource go, and how would you know if it went somewhere it shouldn’t have.

Point that at software delivery and the word that changes shape first is efficiency. It stops meaning working faster and starts meaning not spending the same scarce resource twice. And the resource isn’t money, and it isn’t developer hours. It’s attention — the sustained kind needed to read somebody else’s code properly.

My title is Solution Architect and Technical Project Manager. People ask about the first half, and it’s the easy one: I design the architecture for the new services we build, and redesign the parts of what we already run that need it. That’s the work with drawings attached.

Nobody has ever asked me anything about the second half, and it’s the half that decides whether the first one ever ships. An architecture nobody can find the task for, get a review on, or hear about when it’s ready is a drawing. So: the roadmap, task management, GitHub, and how people find out that something has happened.

I’ll give the verdict first, because a post that withholds it to sound balanced is wasting your time. The way we request and get code reviews is a mess — no single place answers the question “what is waiting for me”, and there is no mechanism anywhere in it except people remembering. At one point we had over a hundred pull requests open and marked ready for review. I helped build that. It does not work.

And an accountant would give that pile a less forgiving name than backlog. A hundred finished-but-unmerged changes is inventory: work already paid for in full, from which we have realised nothing, sitting in a warehouse and quietly depreciating as the codebase moves on underneath it. It’s the most expensive thing in the department, and none of it is on anybody’s books.

Getting a review sometimes meant chasing a colleague

Not always, and not everybody. But often enough to notice, and often enough that it became a part of the job I hadn’t expected to be doing.

A pull request is open. It’s small, it’s ready, and it’s been sitting. Everything is where it should be: the branch is pushed, the description says what changed and why, the reviewer is on it. Nothing happens, so I go and ask. Sometimes I ask again.

Some of ours have been sitting for months. Not blocked, not disagreed with, not waiting on a decision. Just open, since spring.

I want to be exact about the failure, because the obvious explanation is wrong. Nobody is refusing. Nobody thinks the change is bad. There is no disagreement anywhere in this, which is what makes it so maddening — it’s pure friction, producing no information and no decision, only delay.

We made writing code cheap

We use coding agents heavily, and this blog has spent several posts being enthusiastic about them. Here’s the invoice.

An agent lets one person keep several things in flight at once. That’s real, and it’s most of the productivity gain. But work in flight isn’t free. Each thread occupies a slot in your head, and the slots don’t multiply just because the typing got faster.

So the throughput of producing changes went up and the capacity for reviewing them didn’t move at all. Reviewing is still one human, reading, at human speed, and it needs exactly the kind of sustained attention that parallel work is designed to break up.

Two things follow, and they compound. More pull requests arrive. And the people who should read them are each holding three threads of their own, which is precisely the state in which somebody else’s branch is easiest to postpone.

I’ve written here before that agents made rewrites cheap to produce and no cheaper to review. This is the same sentence pointed at ordinary work. The bottleneck didn’t disappear when we got faster. It moved to review, and we didn’t move with it.

We never chose

The second cause has nothing to do with AI and everything to do with us.

We have a task system. We have GitHub. We have a chat channel specifically for posting pull requests that want reviewing. All three are correct. All three are in daily use. And a review can legitimately be requested in any of them — as a GitHub review request, as a comment on the task, as a post in the channel, or by turning round and saying it out loud.

Four routes for one request. Each defensible on its own; the combination indefensible.

This is worse than plain chaos, because from every individual angle it looks fine. Each request went somewhere reasonable. Each system is being used as intended. Nobody is doing anything wrong. But no single place holds the answer to “what is waiting for me right now”, so nobody has a queue. They have four partial ones, and assembling the real queue costs more effort than reading the pull request would have.

That’s the whole failure, and it isn’t a tooling failure. Every one of those systems works. We are drowning in not having chosen between them.

The doorbell

Underneath the routing problem is a smaller, meaner one.

A comment on a task notifies nobody. People write a careful comment, on the correct task, with the right detail, and then wait. Nothing happens, because nobody was told. The comment is sitting exactly where it belongs and exactly where nobody is looking.

So my colleagues told me, reasonably: if you need me to read something, tag me. Fair. A mention is what turns a message into a notification — not the message, not the channel, the mention. There’s a trap inside that, too: nobody is notified about their own message, so if you post on somebody’s behalf under your own name, the one person guaranteed not to hear it is you.

I started tagging. It helped. It did not fix it.

A notification is a doorbell, and a doorbell only works if somebody is home. Tag a person who is three threads deep in their own work and you have successfully delivered an interruption they will consciously defer — and a deferred interruption isn’t stored anywhere. It’s gone the moment the next thing arrives.

It would be easy to write this as a complaint about colleagues who forget. That isn’t what’s happening and it isn’t fair. If a process depends on people remembering, the process has already failed — the remembering is load-bearing, and human memory is the wrong material for that. My colleagues are not the defect. A system whose only mechanism is “tag them and hope” is the defect, and I built that system.

“Ready for review” doesn’t mean anything

Go back to that number. Not a hundred pull requests open — a hundred marked ready, which is a hundred assertions that a change was finished and waiting on somebody.

Then this. Somebody picked one up, reviewed it properly, line by line, and approved it. The author’s reaction was that the task wasn’t done: he was still working on it, and had been pushing to the branch while it was being read.

So the approval landed on the previous version. The reviewer spent their attention on code that no longer existed by the time they finished — and unless the repository dismisses stale approvals when new commits arrive, that green tick is now sitting on code nobody has read. Worse than an unreviewed pull request, which at least looks unreviewed.

Nobody broke a rule. That’s the point: there wasn’t one. “Ready for review” was a label anyone could apply at any moment, meaning anything from “this is finished, please read it” to “this branch exists”. A signal that can mean two things means nothing, and a hundred of them mean nothing a hundred times over.

Which also explains the months. A pull request open since spring isn’t one somebody keeps deciding to postpone; nobody is deciding anything about it. It stopped being a request the day it became indistinguishable from the other ninety-nine — after that it’s a row in a list, and a branch quietly ageing against a codebase that has moved on underneath it.

What I got right, and what it didn’t touch

Everything I introduced here comes out of one sentence: each fact appears in exactly one artifact.

What is needed and why lives in the task. What changed and the reasoning lives in the pull request. That a review is wanted lives in the request for it. Why a non-obvious line is the way it is lives in a code comment.

The point isn’t tidiness, it’s cost. The same fact in four places costs the writer, who retypes it, and every reader afterwards, who now has four sources that agreed on the day they were written and have been drifting since. Restating the ticket in the pull request, and the pull request in the chat message, is the single biggest source of bloat in what we produce — and bloat isn’t a style problem. It’s why nobody reads any of it.

Where that has worked is documents. Task descriptions cap at forty lines, structured as Problem, Expected, Acceptance criteria. Pull request descriptions cap at 250 words, and a trivial change gets five lines and no headings: no test counts, no “CI green”, no file inventories, because CI reports its own status and the diff lists its own files. Writing those out again just produces a staler copy of what’s already on screen, and pushes the one thing only the author knows — the why — further down the page.

My favourite, and the one people argue with: when your understanding of a task changes, rewrite the description. Don’t append. No “revised”, no “supersedes”, no dated changelog inside the description. It feels like destroying evidence, and it isn’t — the tool keeps history, the same way git does. The diary version leaves the reader working out which paragraph is still true, which is the exact job the description existed to do for them. A task says what is true now.

That rule works, because it governs where a fact is written, and writing is a deliberate act a convention can catch. It has no grip whatsoever on where a request gets answered. A convention can tell you where to put something. It cannot make anybody pick it up.

Which is the honest shape of my first months here. I wrote rules for the artifacts, because artifacts are the part a newcomer can change alone, and then assumed the human half would follow the documents into order. It didn’t. The documents are genuinely better. The flow around them is the same mess it was, and now it’s a mess with well-formatted contents.

Choosing is subtraction

Choosing sounds like adding a rule. It isn’t. The whole move is subtraction.

One place to ask, and it’s GitHub. A review is requested on the pull request, using GitHub’s own review request. That’s the entire routing decision.

No code review channel. This is the part that costs something, because the channel works — people post there, it’s a reasonable thing to do, and I’m the one who was asking colleagues to use it. It goes anyway. A second correct place to ask is what created the problem, and keeping it because it’s harmless on its own is exactly how we got to four routes. You can’t half-choose.

GitHub wins for reasons that have nothing to do with it being better software. The request lives next to the thing being requested, so there’s no gap between the notification and the work. Its state survives everything — a restart, a holiday, a forgotten mention. And it doesn’t depend on anybody remembering, which is the property every other option lacked.

The task system keeps its job, which is status, not requests. The task moves through its statuses so the board is an honest picture of where development actually is. It isn’t where you ask for a review; it’s where you look to see what’s happening.

Soon the two stop being updated by hand. When a pull request is merged, the task should move from code review to ready for release on its own. That’s the one-fact rule pointed at status instead of prose: whether something is merged is a fact GitHub already owns, and every manual status update is a second copy of it, kept in step by a human who is busy. Copies drift. A projection can’t.

Then the habit: your pull request inbox. GitHub keeps one at github.com/pulls/inbox — everything waiting on you, in one list, with a number on it. Check it often, and specifically check it before you start a new task. That placement does most of the work: it puts reviewing at the moment you’re between things rather than asking you to interrupt yourself, and it means the queue gets shorter every time somebody starts something new instead of longer.

And a pull request stays a draft until its author believes it’s ready to release. Not ready to read — ready to release, with the change already on staging and through acceptance testing. Draft is the default, and a draft costs nothing to open.

That inverts what we had. “Ready for review” used to be the default state, which is why it carried no information and why somebody could approve a version the author was still working on. Make ready a deliberate act and it starts meaning something again — and “am I still pushing to this?” becomes the author’s question to answer up front, instead of the reviewer’s to discover afterwards.

One task, one pull request. If a task needs more than one, it isn’t one task: break it into subtasks and give each of them a pull request. I expect more argument about this than anything else here, and it’s the one I’d defend hardest, because it isn’t really a rule about linking. It’s a decomposition forcing function. The moment you find yourself opening a second pull request against the same task, the task has told you it was too big — and it tells you at the point where splitting it is still cheap, rather than four months later when somebody has to review the result.

It’s also what makes the automation possible. “When a pull request is merged, move the task to ready for release” only means something if a task has one pull request. With three it’s ambiguous, somebody has to arbitrate, and we’re back to a human keeping two systems in step by hand.

For genuinely large work, the parent task gets a feature branch and the subtask pull requests target that branch instead of master. The parent merges once, when the whole thing is done. That gives one place to watch the state of a big piece of work without anybody pretending it was ever a single change.

I should be straight about the tension in that last one. I’ve argued elsewhere for collapsing to a single long-lived branch, and a feature branch is a long-lived branch. The distinction I’d hold is duration and ownership: this one exists for the life of one parent task and is deleted with it, where the development and staging and production branches we’re retiring exist forever and quietly accumulate divergence. That’s a scoped exception rather than a reversal — but it is an exception, and if I find these branches still alive months from now, I was wrong about it.

The weak point is worth naming. Two of these are mechanisms and one is a habit. GitHub as the single route is enforceable, draft-by-default nearly so. “Check your inbox before you start something” is a habit, in a post largely about how the last thing I built on a habit didn’t hold.

What’s different, I think, is that the inbox is an actual queue rather than a request to remember. It has a number, it’s the same number tomorrow, and it doesn’t quietly empty itself when your attention moves. That’s a better foundation than a chat channel you have to think to open. But it’s still a habit, and if it fails it will fail the same way.

What a piece of work actually looks like

A large task arrives, or a small project. Then, roughly in this order:

I design a solution for it. I break that into tasks and subtasks. I check that every application the thing touches can talk to the others in the way the design assumes — which is where most of the unpleasant surprises live, because two systems agreeing in a diagram is not the same as two systems agreeing about a payload. I check it’s secure, at the boundaries where it’s easy to be lazy. And I keep asking whether the result is still worth something to the people who asked for it, because it is entirely possible to design something correct, well-decomposed, secure, and of no value to anybody.

That’s both halves of the title in one piece of work, which is the honest reason they’re on one business card. The design is the architect half. Everything after the first sentence is the project manager half, and it’s longer.

I plan most of it with Claude. Not to write the plan — to interrogate it. I’ll put an approach in and ask what’s wrong with it, ask for the alternatives I haven’t thought of, ask what each one costs. It’s very good at that, and it’s fast enough that evaluating three designs is no longer a thing you skip because you’ve already sunk a morning into the first one.

It has one failure mode you have to actively manage: it is agreeable. Push a mediocre idea confidently and you will often get help making it better rather than a flat “this is the wrong shape”. So when a decision matters, or when I’m genuinely unsure, I take it to a second and sometimes a third colleague.

That isn’t a formality. A model will help me think, and it will not tell me that I’m the third person this year to propose this, or that the last attempt failed for a reason nobody wrote down. Institutional memory doesn’t live in a context window. It lives in the people who were here.

Slicing it three ways

The other initiative is duller to describe and probably matters more: projects get broken into sub-projects, each small enough to actually finish, each with the business involved during it rather than at the end.

The reason isn’t planning neatness. A chunk that takes four months produces exactly one moment where anyone outside the work can react to it, and that moment arrives after every expensive decision has been made. You don’t get feedback, you get a verdict. It produces something else, too, which this post has already spent two thousand words on: a pull request nobody can review. The mountain isn’t only a habit problem. Some of those branches are simply too big to read, and they were too big on the day they were opened.

There’s a second reason, and it’s about people rather than feedback loops.

The plan is long. One language behind everything, the same shape in every repository, two admin portals becoming one — that’s measured in seasons, and I’ve said as much in public. Stated whole, a plan like that motivates nobody. It’s a wall. And we have a plethora of them queued up, each genuinely worth doing, each months deep.

Breaking them down doesn’t make them shorter. The months are still the months. What changes is how often you get evidence the thing is working, and that turns out to be what decides whether people keep going. A dozen multi-month projects is a mood. The same dozen, with the first slice of each finishing inside a fortnight, is something you can hold in your head and keep walking towards, because you can watch it move.

That’s underrated as a reason to plan properly. Not so the plan is correct — it won’t be — but so the distance between “we agreed to do this” and “something happened” is short enough that people stay pointed at it. That’s forecasting rather than planning: you don’t get better by predicting harder, you get better by shortening the interval before reality tells you something. The caution is that a well-broken-down plan is easy to keep following after it stops being right. The slices are small so you can change your mind between them, not so you can stop having to.

This is also the least visible part of the job. I help our product manager build and maintain the roadmap, and most of that work isn’t deciding what goes on it — ideas are not the scarce resource here — but deciding what a line on it is allowed to mean. An entry that can’t finish inside a quarter isn’t a plan, it’s a wish with a date attached. Breaking those entries down until each one is something that can actually complete, and then staying on them until they do, is most of what “making sure we reach our goals” turns out to consist of. It’s unglamorous, and it’s the difference between a roadmap that describes the year and one that predicts it.

What makes this hard is that a slice has to satisfy three audiences at once.

It has to be beneficial for users — deliver something somebody outside the team can use, or at minimum see. It has to be manageable for developers — small enough to hold in your head, review in one sitting, and abandon without grief. And it has to be sensible for the business — a step somebody can say yes or no to, in terms that aren’t about code.

Miss any one and the slicing does nothing. The failure I’ve seen most is cutting along developer-shaped lines, because those are easiest to plan: all the data models, then all the endpoints, then all the screens. Perfectly sensible engineering order, and it produces months of work nobody outside can evaluate, because none of it is a thing yet. You’ve divided the work without dividing the risk.

Two shapes this takes for us.

Release it to ourselves first. A new analytics tool goes to GolfNext employees only, for a week. Then it expands, and what it expands into is shaped by what everybody said. This blog has admitted before that we have no gradual rollout mechanism and that our first real ring is geography — a few nearby clubs, and a recovery plan involving twenty minutes in a car. Staff-first is a ring that sits before that one, costs nothing, and could exist this week. It isn’t a canary deployment. It’s the cheapest possible way to find out something obvious is wrong before a club does.

Refactor a module at a time. Not the whole system, and not an arbitrary slice either: one cut where all three constraints hold at once. The users get something, the developers get a piece they can finish, the business gets a step worth funding. That’s the same discipline as the seams-before-rewrites rule I’ve argued for elsewhere. What’s new is that finding the cut is the work. It isn’t a planning formality you complete before the real job starts.

I’d rather not oversell it. Slicing badly is worse than not slicing, because a bad cut ships half a feature and teaches everyone that incremental delivery means unfinished things. The skill is in where the knife goes, and I don’t think that’s something you can write down as a rule. It’s the part of this job I’d defend as genuinely requiring judgement — which is an uncomfortable thing to admit in a post otherwise arguing that the answer is fewer choices and more mechanisms.

The question underneath all of it

We’re planning to change the architecture and the stack: one language behind everything, one shape in every repository. I’ve written about that elsewhere. What matters here is the reaction. My colleagues agree it’s a good idea. Not grudgingly. They think it’s right.

And almost nothing moved in that direction before Johann and I turned up.

That bothered me for a while, and the lazy explanations are all wrong. It wasn’t permission — this company says yes to an idea in a day, and I’ve had ideas approved here faster than I could have booked a meeting at my last job. It wasn’t ability. And it certainly wasn’t that nobody had thought of it: these are people who know this estate far better than I do, and I’d bet most of what’s in our plan had been said out loud, in some form, years before I arrived.

So why did nothing happen?

Because agreement isn’t a mechanism. A thing everybody agrees about and nobody owns has no way to start. There’s no disagreement to resolve, so no meeting gets called. There’s no customer waiting, so it never wins a Tuesday against something that has one. It doesn’t help that the work looked like an undifferentiated multi-month blob with no early payoff, which is exactly the shape nobody volunteers for — and exactly what breaking it down is for. It simply stays true and undone, and being obviously correct does nothing to move it. You can watch the same effect in a hundred pull requests nobody disagrees with.

Because for most of this company’s history, nobody’s job was bigger than one project. A lot of our software was built by external partners, and they were good at it. But you engage a partner to deliver a thing. Nobody engages a partner to fix what sits between the things. Cross-cutting work has no client, so under that model it doesn’t get built, and thirteen years of it accumulates in the gaps.

Because the people who could have done it are the people everything else queues behind. That’s the bus factor from another side: whoever knows a system best is who every request for it waits on, so they have the least slack precisely because they have the most knowledge. You don’t restructure an estate from inside that.

And because the year has a shape. Golf is seasonal. The clubs are busy in summer, so we’re busy in summer, and the slack is in winter — which makes the window for structural work narrow, annual, and easy to spend on something louder.

Which brings me to the uncomfortable part, and to the reason for the second half of my title.

What Johann and I brought was not better ideas. It was an empty queue and permission to ask why. A newcomer carries no legacy backlog for their first months, is expected to ask stupid questions, and hasn’t yet internalised any of the local “that’s just how it is”. That’s a real resource with a short shelf life; every week here spends a little of it.

So the project manager half isn’t there to impose process on people who were doing fine without it. It’s there to own the things everyone agrees with and nobody has. Somebody has to convert agreement into a task with a name on it, and that turns out to be a job rather than an afterthought.

Is any of it more enjoyable? The documents are. A task you can read in a minute, a pull request that tells you why instead of what, and a great deal less retyping of things already written down somewhere else. The review flow is not more enjoyable. It’s diagnosed, which is not the same thing, and every fix above is at most a fortnight old.

Which is why the queue is an uncomfortable thing to write about. It’s the same failure as the one I’ve just spent four paragraphs explaining, in my own area, on my watch.

Everybody agrees those hundred pull requests should be reviewed.

One day in Ry

Johann Böhler — Fri, 02 Oct 2026 09:00:00 +0000

It’s a little after nine in the evening, and I’m connected to a kiosk at a golf club, patching it by hand. When it’s done I’ll connect to the next one. There are quite a few of them left.

We’ll get back to that. I’ve been at GolfNext for eight weeks, and every time I tried to write about them I ended up with a list. So instead I’ve folded eight weeks of real moments into a single day at the office in Ry, from the first coffee to the last kiosk. Nothing below happened on one day. All of it happened.

07:40. What colour is it today?

Before I leave for work there’s one decision to make, and it’s mostly made for me. We have company t-shirts in different colours, and on three days a week we all wear the same one: blue Monday, green Wednesday, black Friday. This day is folded together from eight weeks, so I can’t tell you which shirt I’m wearing. Possibly all three. Either way, at GolfNext Black Friday comes every week.

07:50. Coffee, and an idea said out loud

The coffee machine is where most things start here. Somebody says “what if we just…” and by lunch there’s a branch. Sometimes an idea from the morning is live within 24 hours. Nobody has to approve you trying something. Code review and the release process still apply, but the distance between “what if” and “it’s running” is short, and everyone knows it. John wrote a whole post about this, the culture of enthusiasm, and he’s right.

My favourite example has a silly name, which I’m allowed to say because I made it up. All you can Ball. At a driving range you normally buy a bucket of balls. With All you can Ball you buy a time window instead, and one code dispenses again and again until your time runs out. Each portion is sized by the time you have left, so nobody empties the machine in minute one and then stands around for fifty-nine minutes looking pleased with themselves.

Then, over another coffee, the next thought. Why have bucket sizes at all? Long-press the card terminal and balls flow for as long as you hold it, like a fuel nozzle. I call it the beer-glass effect: people stop when it looks full. Peter, who founded the company in 2012, loved it. It’s still an idea. Ideas are cheap here, which is exactly why so many of them turn into something.

09:30. Someone walks over

This is the part I didn’t expect to matter as much as it does.

Hjalte walks over. A PDF of ball codes that clubs print out is spilling onto two pages. Not a crisis. The kind of thing that sits in a backlog for a month because it’s never quite the most important thing.

John fixed it within the hour.

Another evening, members at a club get charged guest prices. I sit down with one of our external developers, we find it together, and it’s fixed within the hour. Those external colleagues built the kiosks, the booking flows and the payment integrations, and kept them running for more than a decade before any of us showed up. Having them and us in the same conversation is the best of both.

11:00. The phone call

Late morning I notice a kiosk at one club has gone offline. I mention it. Hjalte doesn’t open a ticket. He picks up the phone and calls the club.

They hadn’t noticed yet. They were glad we called.

From then on, that’s the rule: when we see something wrong, we call. It’s a tiny thing, and it works because the person who sees the problem and the person who knows the club are in the same building.

12:00. Down the desk

Max joined at the end of August to look after the mobile app players use. On his first day I told him the app was his: do whatever you think is best, I won’t second-guess you. He started with the unglamorous part, taking the app’s TypeScript errors from 134 to zero and its lint errors from 264 to zero, and getting automated tests running on real phones. None of that is visible to a golfer. All of it makes the next feature safer to ship.

13:00. The wall boards

After lunch everyone ends up in front of the TVs.

They arrived a while ago, delivered alongside somebody else’s pallet of cat food, which went back. One evening, unasked, I built a dashboard for them with Claude. Latest releases. What’s live where, because support had asked. Open pull requests. A heartbeat from every device out in the field. Balls dispensed per club today versus the same day last week. And a random programming meme, because a dashboard without a joke on it is just a spreadsheet on a wall.

The next day Peter kept stopping in front of it. Mostly at the ball numbers, watching clubs overtake each other as the day went on. A day later the CEO sent over sales slides to add. It’s become the screen we stand around with coffee, which is more than I can say for any dashboard I’ve built before.

14:30. The twins

In the afternoon John and I both open a pull request for the same feature: choosing which version of the software a kiosk runs. Neither of us had told the other. Same idea, same day, two implementations.

We merged the two. It isn’t the first time we’ve done something like that. We call each other the twins now, because we keep arriving at the same place from different directions. If two people who didn’t talk to each other end up in the same spot, it’s probably a good spot.

That feature belongs to the biggest thing I’ve built here, the fleet service. It’s one system that knows every physical device we have out there, kiosk screens, card terminals, ball dispensers, and manages them from one place. A device joins once with a 12-digit code typed in on site, gets its own identity, and from then on takes its settings and its version from the service instead of from someone fiddling with it by hand. We switched it on overnight in September, with clubs closed. By morning every club kiosk had joined. The only holdout was our own demo unit in Sweden, which had been set up twice and complained that a device with its ID already existed. Of course it was the demo unit.

Hjalte has a better name for the enrolment part. He calls it the 1-Click installer. Nobody has to connect to a device and set up its environment by hand any more. A 12-digit code, and the device is ours. That’s how we’ll ship from now on. The next step, and we’re close, is a small web page where staff at a club set up a new device themselves, which I suspect will be the fun kind of setup. And replacing a broken device won’t take several phone calls. It’ll take a parcel and a link.

15:00. Someone else’s clock

Mid-afternoon, a message from a club in Portugal: their ball dispenser opens about an hour late, every single morning. Nobody had touched the schedule. It turned out the dispenser was mixing up its own time zone with Denmark’s, and so was every dispenser outside Denmark. Money had the same habit. Prices assumed Danish kroner with two decimals, which had to change before a club in the UK could take pounds, and before our kiosk in Iceland could go live at all, because the Icelandic króna has no decimals. Now time and currency come from the club, not from wherever our office happens to be.

16:00. The news

Late in the afternoon one of our longest-serving colleagues tells the team something they’ve been hearing. Players have started going to their clubs and asking whether they can get GolfNext’s devices. Because they’re so easy to use. Because they’re convenient.

For me that landed harder than any metric on the wall. So much of our work only gets noticed when something goes wrong. Meanwhile, somewhere, a golfer is standing at a counter asking for the thing we make.

18:00. The day that ran long

Which brings us back to the evening. This part is from my third week.

I’d been chasing a bug where kiosks sometimes froze. I wanted more detail, so I made the kiosk pause before it exited, just long enough to write a crash log. What I hadn’t accounted for is how kiosks update: the updater closes the app, swaps the files, and only waits so long. My pause made the app too slow to close. Updates kept getting cut off, and around 94 kiosks started restarting in a loop. Updates only run when a kiosk is idle on its home screen, so nobody was thrown out halfway through buying a round. It was still 94 kiosks going round in circles. And the crash log didn’t even help me find the freeze.

The awkward bit was that I couldn’t just ship a fix. The update logic that runs is the one already sitting on the kiosk, the same one that was broken.

It took about two hours to stop the bleeding by freezing the update the kiosks were pulling. Then came the rest of the evening, the scene at the top of this post: connecting to kiosks one at a time and patching them by hand so the next release would stick.

It did.

08:00, the next morning

I came in braced for jokes. There weren’t any. Our product manager wasn’t worried. People were glad someone had put the hours in.

There’s a German saying, wo gehobelt wird, fallen Späne. Where wood gets planed, shavings fall. We’ve done a lot of planing in eight weeks, roughly 650 merged pull requests between John, Max and me, and that night was one of the shavings. It also left something useful behind. Kiosks now give up after three failed update attempts and keep the version they have. And the night is the reason the fleet service rolls things out the way it does: a new version goes to a few kiosks first, and once it works, it goes to the rest. If something’s wrong, a kiosk goes back to its previous version from a setting. That’s the part of the evening I’m proudest of.

Why the building matters

On the last Friday of September, John and I walked out to the car park together and agreed it had been a big week. “It’s quite noticeable what we bring to the company.”

I’ve thought about why, and I keep coming back to the building, or really to how short the distances in it are. The PDF that gets fixed within the hour because someone walked over. The phone call that happens because the person who spotted the problem is sitting next to the person who knows the club. The feature built twice because two people think alike, and merged because they sit together. The good news that reaches the whole team at once, in the same room.

It’s also what Friday mornings are for. For half an hour we all sit round one table, in black shirts, with rundstykker, Danish breakfast rolls, and talk about our weeks. The distances don’t get any shorter than that.

Tomorrow there’ll be another coffee, and somebody will say “what if we just…” I can’t wait to hear what it is.

Our agents drank all the coffee

Johann Böhler — Sat, 26 Sep 2026 09:00:00 +0000

There’s an xkcd about the best excuse a programmer ever had, and for most of my career it was a documentary. You pushed a commit and walked to the kitchen. You watched the coffee machine grind. You drifted outside to where the smokers stood, because that’s where the real decisions got made, and you came back. Still running. The build was the only break anyone was allowed to take.

xkcd #303, “Compiling” by Randall Munroe, CC BY-NC 2.5

You know the feeling. You have a fix. It’s small, it’s ready, all it needs is a green tick. CI says twenty minutes. So you do the sensible thing and start something else, and by the time the run finishes you’re deep in that. You look after lunch. It’s red: a flaky test, or a conflict with something that merged in the meantime. You fix it, push, wait again, and get back to it tomorrow. A one-hour change has taken two days, and almost none of that time went into the change. All you wanted was to pass the checks and move on.

This year the build got new company at the coffee machine: our coding agents. In September they were waiting eighteen minutes for every run. Here’s how that became about three, for the same money, and what we found at the end of the queue once the machines stopped being the excuse: us.

Who waits for CI now

Most of our team now works with coding agents, Claude in particular. A typical developer here has four or more agent sessions going at once.

Each of those sessions works in a loop. It writes the change, pushes it, waits for CI (continuous integration: the robot that builds and tests every change), reads what failed, fixes it and pushes again. Only when the checks are green does a person review it, with CodeRabbit as an extra pair of eyes, and a person merges it and decides when it reaches production.

That turns CI from something a person checks once or twice an hour into something every agent on the team waits for, all day. On GitHub Actions we went from 48 runs per working day in June to 375 in September. Merged pull requests went from around 140 a month in the spring to 583 in September. GitHub bills by the minute, and the bill went from about $29 in June to $135 for September, with a few days still to go.

Then our main web application got slow, because we had written a lot of tests. In one week in September, while we built a new admin API, the suite grew from about 3,900 tests to about 9,600, most of them tests that boot the whole application and talk to a real database. A typical pipeline run went from under six minutes to eighteen, and a bad one took twenty-seven. Jobs weren’t stuck in a queue. The machine had two CPUs, two and a half times as much work, and we had just told it to run eight test processes at once.

A pull request here typically gets two CI runs before it’s done, and a quarter get four or more, mostly follow-up pushes rather than failures. At eighteen minutes a run, that’s over half an hour per change before a person even looks at it, and with four or more sessions per developer, at least four changes are always at the coffee machine.

Not a VPS

A colleague was the first to say it out loud: this is slowing all of us down. Their suggestion was a VPS, a rented virtual server. Rent a big one, install GitHub’s runner software (the agent that picks up CI jobs) on it, done. It would have worked.

I still didn’t love it. A self-hosted runner is a pet. Somebody patches it, keeps Docker healthy on it, installs the right languages and versions for every repository that uses it, empties the disk when a build fills it, and notices when it’s down on a Saturday. I’d rather nobody on a team our size spent their week on that. So I looked for something hosted instead, but first I fixed the tests.

Fixing the tests, then the machines

The first fix was plain engineering, and it did most of the work. The tests already ran in parallel, but with a lot of waste around them: every test worker built its own copy of the database, the database carefully saved every write to disk as if it mattered, and the same code was compiled again in every process. So the test database now lives in memory, it’s built once and copied to each worker, and the suite is split into four jobs that run at the same time. The split is deliberately dumb: count the tests in each file, weigh the slow kinds heavier, and hand the files out heaviest first to whichever job has the least so far. The four jobs don’t finish at quite the same time, and timing-based weights are the obvious next step.

Database setup went from 76 seconds to under 30, the tests needed half the compute, and on GitHub’s standard machines the pipeline was down to about five minutes. But each of the four jobs now pays for its own setup, so billed minutes per run stayed at about 21, what the slow pipeline had cost. We waited about a quarter as long for the same bill.

The day the test fixes landed, I signed up for a trial at Blacksmith, the hosted option with the easiest setup. Blacksmith sells what GitHub sells, a machine that runs your GitHub Actions jobs, except you can pick bigger and faster ones. You don’t install anything. You change one line per job:

runs-on: blacksmith-4vcpu-ubuntu-2404   # was: ubuntu-latest

Right after signing up I asked Blacksmith to run our jobs in their EU region. CI should only ever see test data, never a club’s or a golfer’s. In case someone slips up, the machines sit in the EU anyway. They switched it within a day. There’s no deal behind this post: we did the trial and now pay the normal price. If we ever want to leave, it’s the same one line back.

With the four test jobs on Blacksmith, the pipeline has run 62 times since. The median is 2.8 minutes, and nine runs in ten finish in under 3.7.

Tuning and splitting took a typical run from eighteen minutes to about five. The machines took it from five to under three, and part of that is simply more cores, because two CPUs became four. I didn’t test GitHub’s own four-core runner, which exists and costs $0.012 a minute, twice its two-CPU rate, so some of this gain is money any GitHub customer could spend.

What changed, and what didn’t

I expected the whole loop to collapse. So I measured it, comparing pull requests from the slow week with the five days since the switch.

The part CI controls did collapse. From opening a pull request to its first green run took a median of 17.5 minutes in the slow week. Now it’s 3.1. That’s the wait every change pays before review, and it’s five times shorter.

The part I thought would follow didn’t. When a run fails, the time until the next green one is a median of about half an hour, before and after (only a handful of cases each week, so read that loosely). Faster machines couldn’t touch it. Fewer than one pull request in ten goes red, and the few that do mostly sit until a person picks them up, sometimes not until the next morning. The agents rarely hand CI something broken. The slow part of our loop is now us.

What it costs, and two lessons

One pipeline run of the main web application used to bill about 21 minutes on GitHub’s two-CPU machine, roughly 13 cents. On Blacksmith the same run bills about 16 minutes, most of them on the bigger machines, and comes to 12 or 13 cents depending on how you round. The same money, then, for a run under three minutes instead of five, or eighteen before we touched the tests.

Blacksmith for September so far: $12.68 of usage, $12 of which the free allowance covers. We owe them 68 cents.

Splitting buys time, and you still pay for every minute. Every job pays for its own setup: checking out the code, installing dependencies, starting the database. GitHub bills each job by the minute, rounded up, so ten one-minute jobs cost ten minutes and feel like one. That’s worth it for a pull request somebody is waiting on. For a nightly job nobody watches, keep it in one piece.

Look at ARM early. At Blacksmith an ARM minute costs over a third less than a standard Intel or AMD (x64) one, and moving CI there doesn’t change what you ship. We’ve only tried it on one repository so far, and it won’t fit everywhere: our Android app has to stay on x64 because Google’s Android build tools don’t run on Linux ARM.

Moving the rest

We have nearly fifty active repositories, and I don’t want each migration to depend on someone understanding that particular pipeline. So I wrote the process down as a skill for Claude, a runbook it follows step by step when it moves a repository over. It measures before and after, over several runs rather than one lucky one. It checks that caches actually restore; one of ours never once had, and nobody had noticed. And it tries ARM where nothing rules it out.

Five repositories run on Blacksmith so far. One started there. Three, including the main web application, went over with Blacksmith’s own migration wizard plus some help from me, and one was moved end to end by the skill. The early numbers for the others look good, from slightly faster to roughly twice as fast, but they rest on a handful of runs each.

Leave the pipeline faster than you found it

Nobody throws a party when CI works. When it’s slow or flaky, everyone is annoyed as hell. It’s a bigger part of the job than we like to admit, and it gets slow without anyone deciding it should: a few tests at a time, until one week it takes eighteen minutes and everyone has quietly started working around it.

So I treat it the way I treat code, with the boy scout rule: leave the pipeline better than you found it. Whenever I’m working in a repository, I look at how long its CI takes and whether its caches work, and if something is obviously slow, I fix it while I’m there.

With an agent, that costs almost nothing. I point one at the repository and let it read the past builds, find the slow steps, try a change, measure it, keep what got faster, drop what got worse, and go round again. It runs in the background while I work on bugs and features, and it barely takes any of my attention. The skill writes that loop down. I’d like it to become everyone’s habit, not just mine.

Back to the coffee

The test suite is still growing, so one day the pipeline will be slow again. With any luck, whoever notices will fix it before the coffee is ready. Somewhere, I assume, the smokers are still making the real decisions. I just can’t blame the build for joining them anymore.

99% excitement, 1% concern

John Allan Nielsen — Thu, 03 Sep 2026 00:00:00 +0000

I was watching a movie on a Saturday evening with my laptop open on the table next to me. Every so often I’d glance over, read a few lines, and go back to the film. Claude Code, Anthropic’s terminal coding agent, was rewriting the entire frontend of one of our applications from Vue to React.

Not a component. The frontend. Every screen the application has, which is tens of thousands of lines.

I’d given it a narrow job and narrow permissions: build a proof of concept, in its own corner, touching nothing that mattered. Nobody had asked me to do this. It was a thing I wanted to know the answer to.

On Monday I showed it to our tech lead. He was genuinely excited, took the proof of concept into the real repository, spent a pass cleaning up its foundations, and shipped it. Within a day or two the old frontend was switched off.

GolfNext, where I work, builds the software golf clubs run on: bookings and memberships, the self-service kiosks that work as a reception desk when nobody’s behind the counter, the payment side of the driving range, which is the practice area where you pay for a basket of balls and hit them. I’d been there four weeks. The application I rewrote is one club staff sit in front of all day, so when it breaks, someone at a club is standing at a desk with a customer in front of them.

Before this I spent years at a much bigger company, which is most of the point.

A company let a four-week employee’s weekend experiment replace a staff-facing frontend inside a week. That’s the part I still find surprising, and the AI is the least of it.

Why a rewrite at all

Since the rest of this post spends a while on why good ideas stall elsewhere, it’s only fair to give the reason for this one up front.

It isn’t that React is better than Vue. Our mobile apps are already React Native, and if the desktop application we ship ever moves to a web interface, React would be the single framework behind every frontend at GolfNext, web or desktop. One set of idioms instead of two, one dependency tree, and one answer to a question rather than two that both half-apply.

The other reason is less flattering to talk about and matters more day to day: coding agents are noticeably better at React than at Vue. There is far more React in the world, so far more of it went into the training. If we’re going to build software the way we now build it, there’s an argument for standing where the tools are strongest.

What would have happened at my last job

Nothing, or close to it. But not for the reason you’d probably guess.

My last job was a large enterprise and I want to be fair to it: it wasn’t drowning in bureaucracy. There wasn’t a thicket of committees to get an idea through. What there was instead was a small number of senior developers who had been there a very long time, held most of the decisions, and were comfortable with the way things already were.

Nothing had to be formally refused, and mostly nothing was. A proposal only had to fail to interest the two or three people whose agreement it needed, and then it quietly didn’t happen. That’s a harder wall than a process, because a process at least tells you what to do next.

The deployment story had the same shape. Releases were largely manual, and the ability to perform one — along with the access you’d need to diagnose anything when it went wrong — sat with a handful of people. If you weren’t one of them, your work stopped at the point where it needed something only they could do, and then it waited. Not out of malice. It was how the permissions had settled over the years, and nobody whose day it improved had a reason to change it.

So the honest version of the contrast isn’t speed. It’s how much of what you already know how to do you’re actually permitted to do. At GolfNext, the person who reviewed my weekend experiment was also the person who could ship it. Where I worked before, that would have been two different people, and a queue.

How an idea gets a yes here

Two paths, and neither of them has an approval step.

The first is a conversation. Someone says the thing out loud, whoever’s in the room agrees it’s worth doing, and it gets done. No document. The second is a task in our tracker, which is the same thing with a title and an assignee so it doesn’t get lost.

There’s no third path where the idea goes away to be evaluated. Worth being precise about what that does and doesn’t mean: the gate we don’t have is the one that decides whether an idea is allowed to be tried. Code review and the release process are still exactly where you’d expect them.

Most of the ideas come from our founder, who started the company in 2012. He has more of them in a week than the team can build in a month, which could easily be exhausting and mostly isn’t, because the flow runs in both directions and an idea from a developer gets the same reception his do. I’ve brought several since I started, and not one of them got the treatment I was braced for.

Our tech lead wrote something close to this on this blog two weeks into his own job — he’d arrived braced for friction and found almost none of it. Four weeks in, from a different chair, I’d say the same. The difference is that I’ve now got a story concrete enough to argue with.

The reception isn’t just approval either, and that’s the part I hadn’t expected. Show something to our founder, our product manager or our CEO, and inside a minute one of them is building on it out loud: what could sit on top of this, what else it could be used for, where the value to the company would actually land. You arrive with a thing you made and leave with three things it could become. That’s a good feeling, and it’s also a reason to turn up prepared: an idea here grows the moment you show it, so it pays to have thought about where it could go before somebody else does.

The turnaround is the part I still haven’t adjusted to. Sometimes an idea in the morning is live within twenty-four hours. Sometimes it’s two weeks. It’s rarely a quarter.

The part I don’t want to gloss over

“An AI rewrote a staff-facing frontend and we shipped it two days later” is either good engineering or a story that ends badly.

So, the details.

The agent could create, and that was the whole of it: no editing or deleting anything that already existed, all of it off in its own corner. Nothing it produced was one merge away from a golf club’s Monday morning.

Then a human read it. Our tech lead clicked through every view — there aren’t that many, twenty or thirty with some forms and modals, half an hour of clicking — and concluded it looked good enough to replace the old application without breaking anything. What he didn’t have was years of history with this codebase; he’d been there about as long as I had. So the review wasn’t institutional memory. It was somebody who knows what a healthy React codebase looks like reading this one before it went anywhere near a club.

Where he did spend his time was the foundation rather than the behaviour: getting the look back closer to the application we were replacing, putting Biome in, settling how directories and files get named, and taking apart the places where the agent had stacked fifty Tailwind classes onto a single div — restructured, then a lint rule so it can’t come back. A human should still be able to read the thing. That’s the work that makes it safe to add functionality to, instead of building the next floor onto something already leaning like the Tower of Pisa.

That review is the actual safety mechanism in this story, not the model and not my prompt. Not the tests either, because this frontend never had much of a suite. That was already true before the rewrite. The rewrite just made it matter more.

It was also frontend-only. Same API, same data, nothing touched on the payment path.

What we don’t have is a gradual rollout, and this blog has already admitted as much: our customers are physical places, so the first ring is geography, and if a release goes badly at a nearby club the recovery plan is twenty minutes in a car. That’s a real safety net, and I’m not going to call it a canary deployment.

The thing I’m still carrying is that nobody has read every line of that code the way you read code you typed yourself. A rewrite that looks finished is the most flattering output an agent produces, because the gaps are omissions rather than bugs, and an omission doesn’t show up in a demo. I expect to keep finding them for a while. So far nothing has broken at a club.

The plan the weekend belonged to

Nobody had asked for that rewrite. It was the first piece of something longer I’d been sketching, and what decided the timing was mundane: I looked at how much of my Claude Code allowance was left for the month. Unused tokens don’t roll over. Capacity I hadn’t spent was capacity GolfNext had already paid for, and spending it cost the company nothing at all.

So I spent it. Over that stretch I started proofs of concept for most of our applications, all of them in one language with one code structure, to find out what a unified stack would actually look like instead of arguing about it in the abstract. Exactly one of them, the React frontend, has reached production. The rest are still proofs of concept, and I’d rather say that plainly than let this read as a migration that’s already happened.

We run two admin portals, each with its own backend and its own login. They serve different purposes, but there’s no good reason for them to be separate applications, and I genuinely don’t know why they were built that way — it predates me by years. What I do know is that every developer here and everyone in management agrees there should be one. The cost of having two lands on the people using them: club staff log in twice.

The plan is to end up with one. First an auth bridge, so a single set of credentials works across both. Then the merge itself: one frontend and one navigation, with both backends still running behind it. Only then the backend, replacing the two services with one, so there’s a single language and a single code structure under the whole portal instead of two of each.

There’s a reason that road is worth walking now rather than in two years. The ambition here isn’t modest. We’re in eighteen countries today, the plan involves a good many more, and a lot more users behind them. Much of that arrives through integrations: every club already runs some management system, and our position is to work with whatever they have rather than ask them to throw it out. Each one of those is another system to speak to and another set of assumptions to keep straight.

Two portals, two backends and two authentication schemes is survivable at the size we are now. It’s exactly the kind of thing that stops being survivable when things go well. So the argument for doing the unglamorous structural work is that there’s still slack to do it in, and that’s also why “let’s unify the stack” is met with excitement here rather than a request to justify it. Everybody already knows what’s coming.

That’s a long road rather than a sprint, and most of it hasn’t happened yet. Getting the frontend onto React was the groundwork for all of it, the thing that had to be true before any of those steps could start, which is why that was the experiment I picked for a Saturday evening. Step two was showing the whole plan to the people who would have to live in it.

Where the 1% went

Our tech lead was pushing in the same direction and wanted the rest of our frontends on React too. Management’s reaction to the whole package — the portals, the backend, the frontends — was, in round numbers, 99% excitement and 1% concern.

I want to be precise about the 1%, because it wasn’t what I expected. I’d braced for cost, or for risk to customers. What they were worried about was how the existing developers would feel.

These are people who have been building this software for years, in a stack they chose, and two of us — both of us about a month in the door — were proposing to change it. That’s the right thing to be concerned about, and it’s the concern that never shows up in an estimate.

So we ran a brainstorm with the team, and held our own opinions back until everyone else had spoken.

That’s harder than it sounds. We already had our proposal written down. Every time somebody drifted towards it the tempting move was to jump in and agree, which would have ended the discussion and turned everything after it into consent rather than input.

When we finally put ours on the table, nobody disagreed. The portal merge and what follows it they were actively excited about. The React standardisation itself they were only fine with, and that’s the more interesting half of the sentence: it’s the part that replaces the stack they had chosen, and “fine with” strikes me as an entirely reasonable thing to feel about that. Nothing in the proposal changed as a result, which is the least satisfying way for a meeting to go well, and I’d rather report that than dress it up. We’re working in that direction now.

Enthusiasm from management is easy to come by here. That’s a feature, and it’s most of why the twenty-four-hour turnaround exists at all. Enthusiasm from the people who have to live in the code every day is the one you have to earn, and the only reliable way I know to earn it is to shut up for the first half of the meeting.

Enthusiasm asks for discipline

I don’t want to leave this as a post about how nice it is here, so let me say what the environment actually demands, because it isn’t nothing.

A place that says yes in twenty-four hours only works if what you put in front of it deserves a yes in twenty-four hours. None of the proposals in this post were sketched in the meeting they were presented in. Our tech lead and I have spent a lot of hours together on plans and architecture, going through them properly before anyone else saw them, and separately we each did our own reading first. Most ideas I’ve brought here were researched before they were presented, not while they were being discussed.

The weekend proof of concept is the clearest case. Its purpose wasn’t to produce code. It was to take the riskiest assumption in a plan and settle it before asking anybody to commit to the plan. That’s preparation dressed up as a hobby.

This is the part I’d underline for anyone who thinks an enthusiastic culture sounds comfortable. When there’s no gatekeeper you have to convince, there’s also nobody checking your thinking for you. The rigour a process would have forced on you has to come from you instead, and it has to arrive before the meeting rather than after it. Enthusiasm doesn’t lower the bar for professionalism. It moves the bar onto you.

Which makes this a particular kind of place to work rather than a straightforwardly better one. If you’re ambitious, and you enjoy doing the preparation properly, it’s the best environment I’ve worked in — what you can get done is bounded by your own thinking rather than by somebody’s approval queue. If you’d rather have a process tell you what’s next and a committee share the weight of being wrong, I think you’d find it uncomfortable.

If you’re weighing up a place like this: the fastest thing about GolfNext isn’t the tooling or the agents. It’s the distance between having an idea and being allowed to try it.

You do have to be careful what you think about on a Saturday evening. It might be in production by Tuesday.

My brother from another mother?

John Allan Nielsen — Wed, 02 Sep 2026 09:00:00 +0000

I interviewed for the job Johann has.

Tech Lead at GolfNext — the company that builds the software golf clubs run on: booking a round, the till in the pro shop, the machines out on the practice range. It has been doing that for over a decade, mostly with developers working remotely, and the team that has kept it running has been here far longer than either of us.

I went through the process and I wanted the role. The feedback arrived as two things at once: they were going with somebody else, and they wanted to create a new role for me, because they had been impressed enough not to let it end there. That is not a rejection you get very often.

So the man who got the job I’d applied for became the man I would be working next to. He started on the Monday. I started on the Tuesday — one day behind, which is close enough to zero.

His title is Tech Lead. Mine is Solution Architect and Technical Project Manager. Read those two out loud and try to say where one stops and the other starts. Nobody had drawn that line, and as far as I can tell nobody was planning to.

So I turned up to a job I was genuinely excited about, and inside the excitement was a knot I didn’t say out loud for a while.

On our second day working together, Johann told me we were like twins. He has said it many times since, and it’s become a running joke between us — the title of this post is my half of it. But I want to be honest about what came before the joke.

What I was actually worried about

Four questions, in the order they kept arriving.

Would we agree? Not about tabs and spaces. About the things you can’t do twice: which stack we standardise on, whether you rewrite or refactor, what gets rebuilt first when everything has a claim to being first.

Could we work together at all? I had never met him. Not a former colleague, not a friend of a friend, not someone whose work I’d seen. A stranger with an adjacent mandate and the same start month.

What happens the first time we fundamentally disagree? Two people with overlapping remits and no boundary is fine while they agree. It’s a coin toss the day they don’t, and there’s no process to appeal to, because there is no process.

And the one I didn’t say out loud: was one of us supposed to quit? We had been candidates for the same chair a few weeks earlier, and one of us hadn’t got it. Companies do sometimes hire two senior people into adjacent roles and let the situation resolve itself. Nobody told me that was happening. Nobody told me it wasn’t, either, and in week one you don’t have the standing to ask.

Why that wasn’t paranoia

Two simultaneous senior hires into a small team is an unusual move, and it isn’t obviously a good one. The team already had people who had maintained this software for years. Now it also had two newcomers, arriving a day apart, both of whom were going to have opinions about the technical direction — and neither of whom had earned a single hour of credibility inside the building.

I also came from somewhere that taught me what an unresolved question about who decides does to a codebase over time. I’ve watched decisions collect around whoever has been there longest, and I’ve watched perfectly good ideas quietly fail to happen because they never interested the right two people. Arriving into a place where the deciding was undefined between me and a man I’d never met, my instinct wasn’t optimism. It was: this could go badly, and it could go badly slowly, which is worse.

One thing did work in my favour, and I didn’t expect it. He’d already published a letter to himself on this blog, before his own first day, laying out what he was walking into and the goals he was setting himself. I’ve read it since. Reading somebody’s stated compass before you’ve had a single real conversation with them is a strange kind of head start — you know what they say they want to be like, and you get to watch whether it holds. One line in it does most of the work: hire excellent people, and then trust them. You can’t write that in public and then spend your first month collecting territory.

A month in

We have spent a lot of the last month in front of the same problems: what this estate actually consists of, what has to be true before anything else can happen, what the first real move should be.

The uncomfortable part is that it keeps going the same way. He describes the shape of a problem and it’s the shape I’d have drawn. I bring what I think the first step has to be and it’s the step he’d already picked. Two people forming the same picture of a company neither of them knew a month ago, independently, is either a very good sign or a shared blind spot, and from the inside those look identical.

It also made the credibility question smaller in a way I hadn’t predicted. One newcomer with an opinion about the direction is a newcomer with an opinion. Two newcomers who arrived separately and reached the same conclusion is at least an argument.

So the honest report from the first month is that the thing I was braced for hasn’t happened, and the alignment has been close enough to be faintly suspicious.

What happens instead of disagreement

Within a few days we were quizzing each other on preferences for more or less everything. Tools. Branching. How much process a small team should carry. When you rewrite something and when you leave it alone. What a good pull request looks like. How you treat an estate you didn’t build. The answers kept matching — not roughly, almost every time.

And when we actually work on something, it isn’t a collision. One of us pitches an idea, the other comes back with a suggestion that makes it better, and that version is the one we take. I honestly don’t know whether that counts as disagreeing, and I’ve decided not to care what it’s called, because what comes out the other end is better than what either of us walked in with.

I’m not going to pretend that settles the hard case. A month is not long, and I can’t report from a conflict I haven’t had. But it would be overcorrecting to describe what’s happened so far as conflict merely deferred. It looks like two people upgrading each other’s work, which is a different thing entirely.

The part I hadn’t accounted for is how much easier the job is with a colleague who is exactly as ambitious as you are and pointed in the same direction. I’d braced for a rival. What I have is the person I check my thinking against before it leaves the building.

Different angles, same target

The overlap I was worried about hasn’t materialised either, and not because anybody negotiated it away. We never sat down and divided the territory. It divided itself, by angle of attack.

In practice that means we are usually pointed at the same problem from different sides. One of us is deep in security while the other rewrites the architecture for a big project. One of us takes a large new feature on the payments side while the other is down in a hardware integration. Same destination, two approaches, and almost no surface where we get in each other’s way.

What surprises me is how little coordinating that takes. There’s no standing sync where we carve up the week. We each know roughly what the other is doing and, more importantly, what the other is doing it for, so the split falls out of the work instead of out of a meeting. I’d have predicted the opposite: two people with undefined remits should need constant coordination to stay out of each other’s way.

And that, I think, is what keeps the twins joke alive without either of us maintaining it. We keep arriving at the same conclusion from opposite directions.

Was one of us supposed to quit?

No. And the longer I look at how it was handled, the more I think management made the right call.

Two people came out of that process. Instead of taking one and sending the other away, they took both and built a role for the second — which only makes sense if you are honest about the size of what needs doing. There are more repositories in this company than there are weeks in a year, four products serving real venues, and a decade of technology decisions that were all reasonable when they were made and don’t add up to one coherent estate now. Every part of that needs somebody with time to think about it, and I have not once, in a month, run into a shortage of things to own.

So the thing that looked from the outside like two people competing for one chair turned out to be a company deciding it needed two. The knot I arrived with came from reading it the first way. A month in, the part I’d have called the risk — the two of us — is the part working best.

So: brother from another mother?

Provisionally, yes — with the question mark left where it is on purpose.

A month of turning out to think the same way about a company we both just met is genuinely the best professional surprise I’ve had in years. It’s also only a month. The thing that would actually earn the phrase is the first decision only one of us can make, handled well, with the team watching. Ask me again after that.

What I’d say to anyone walking into the same setup: the worry is reasonable and worth naming out loud earlier than I did. Two senior people with no boundary between them is a real risk, and we get on is not a plan for it. But the failure mode I’d braced for — two newcomers quietly competing over the same ground — needs a shortage to feed on. In a place with this much undone, there isn’t one.

One dissent, for the record

I should correct something, in the interest of accuracy. There is exactly one thing we disagree on.

Our task tracker and our wiki. My position is that they are sub par. Johann’s is that they are absolutely horrible. We have been over it more than once, from opposite directions as usual, and we arrive at the same destination — something has to change — by way of a genuine and so far unresolved difference of opinion about how much contempt is warranted on the way there.

So the record stands. Two newcomers, one undrawn boundary, a month of agreeing about architecture, process, rewrites, branching and what makes a good pull request. And one open dispute, about adjectives.

Delete the setup guide

Johann Böhler — Thu, 27 Aug 2026 00:00:00 +0000

Think about the last time you cloned a repository you’d never worked in before.

You read the README. It told you to install a JDK, and you had the wrong one, so you went and found the right one. It told you to install Node, and the version file said 18 while the lockfile clearly wanted 20. Somewhere near the bottom there was a line saying cp .env.example .env and then, in a smaller font, fill in the values. Fill them in from where? From a colleague. So you asked in Slack, someone pasted you a block of KEY=value lines, and now a production-adjacent credential lives in a chat history forever: searchable, backed up, exported to whatever compliance tool the company bought last year.

Nobody set out to build that. It’s what happens when the instructions live in a document instead of in the repository.

I’m the tech lead at GolfNext, a Danish company that builds software for golf clubs, and my first post on this blog was an inventory of what I’d walked into. Sixty-eight repositories, four product lines, thirteen years of accumulated technology choices: Java and Maven and Spring, Kotlin and Gradle, Node, Python, PHP, JavaFX, React Native. Starting work in one of them cold took somewhere between two and six hours depending which one you picked, and I set myself a target of five minutes from clone to running code.

This is the first serious attempt at that. Two tools, both by the same person, jdx. mise puts the right tools on your PATH, fnox puts the right secrets in your environment, and those are the two halves of one problem. mise is boring and widely used. fnox is neither of those things yet, and I’ll come back to that. What’s interesting is what falls away once both are in place, and what it does to the coding agents I have running in these repositories all day.

It’s mise as in mise en place, the kitchen thing. Pronounced “meez”, /miːz/, one syllable, no -uh on the end. You want that settled before you say it out loud in a meeting. fnox is easier: Fort Knox with most of the letters knocked out, so “eff-nox”, and the name tells you what it’s for.

Half one: the tools

If you’ve used nvm or pyenv you know the shape: declare a version, cd in, get that version. The difference is that mise doesn’t care what the version is of.

# .mise.toml
[tools]
java = "21"
maven = "latest"
node = "lts"
python = "latest"
gitleaks = "latest"

That’s a JVM, a build tool, a JavaScript runtime, a Python and a secret scanner (gitleaks) in one file, installed by one command, on your PATH only inside this directory tree. Add mise activate to your shell profile and even the command goes away: cd into the repo and the tools are there, cd out and they aren’t. It also sets the environment variables that go with them, so JAVA_HOME points at the JDK this project pinned rather than whatever your operating system decided last.

“Version manager” undersells this, and I want to be specific about why. The expensive part of a polyglot estate is the switching, not any single stack. You spend a morning in a Spring service, then move to an Android repo, then a small Python tool, and each hop is a chance for your shell to be wrong in a way that produces a confusing error rather than an obvious one. In one of our repositories a newer system JDK doesn’t fail loudly. It breaks a mocking library during tests, several layers down, with a message that has nothing to do with Java versions. That’s an hour of somebody’s life, and you pay it again every time a new person joins or a laptop gets replaced.

A per-language tool can’t help, because the problem is between languages.

One nuance you may as well steal instead of discovering. We deliberately let some of those versions float: latest for the scanner, lts for Node. What a build is made of is pinned in the CI workflow, and that pin is the one dependency automation watches and raises pull requests against. If we pinned the same versions in .mise.toml as well, we’d have two places to keep in step, and one of them would quietly fall behind. We know this because it had already happened, a .mise.toml claiming Node 22 while all four workflows said 24. Only one file gets to be authoritative, and it’s the workflow.

The JDK is the exception, pinned hard in both places on purpose. A wrong major version there is exactly the mocking-library failure above, and I’d rather keep two files in step than rediscover that error at four in the afternoon. Everything else floats.

The part I didn’t expect to care about

Every repository has a handful of things you do to it: build it, test it, run it, format it. In a Maven project that’s mvn spring-boot:run -Dspring-boot.run.profiles=local. In a Gradle project it’s ./gradlew and a task name with four words glued together. In a Node project it’s whatever the scripts block says this week. None of it is hard. All of it is something you have to look up when you’re in an unfamiliar repo, which is exactly when you have the least patience for looking things up.

mise lets you put those verbs in the same file as the tools:

[tasks.build]
description = "Package the artifact"
run = "mvn clean package -B"

[tasks.test]
description = "Full test suite (integration tests need Docker)"
run = "mvn clean test -B"

[tasks.serve]
description = "Run the API on http://127.0.0.1:5001 (starts the stack first)"
depends = ["stack:up"]
run = "mvn spring-boot:run -Dspring-boot.run.profiles=local"

[tasks."stack:up"]
description = "Start the local database and the mocks. Idempotent"
run = "docker compose up -d --wait"

So the interface becomes mise run build, mise run test, mise run serve. In the Android repository next door the same verbs sit on top of Gradle instead, and one of them wraps a four-word task name I still can’t type from memory. Doesn’t matter. mise tasks lists what a repository can do, with descriptions, and the answer is in the repo rather than in a wiki page that stopped being true in 2023.

Two small conventions have earned their place. A bare verb is the common case and verb:qualifier narrows it: test and test:signer, stack:up and stack:down and stack:clean. There’s also always an escape hatch task that wraps the underlying build tool directly, so anything the curated list doesn’t cover is still one command away:

[tasks.mvn]
description = "Any Maven command, with this repo's JDK and environment"
run = "mvn"

That escape hatch matters for the second half of the story.

Half two: the secrets

This is the part I actually wanted to fix.

The .env.example pattern is so common that it reads as a best practice. It’s a convention that gave up. Look at what it asks of a team.

A new developer copies a file of empty keys and then has to source real values from somewhere the repository can’t tell them about. In practice that means a person, which means a chat message, and now a secret exists in a second system with different retention rules and different access control than the one you chose on purpose. When a value rotates, every laptop holding the old one is silently wrong until someone notices, and the failure usually shows up as a confusing 401 rather than a message saying “your credential is four months stale”. When a new secret is added, everyone else’s .env is incomplete and nobody is told. And the file itself sits in your working directory in plaintext, one bad git add -A away from being committed, which is why every repository that uses this pattern also has a .gitignore line that somebody could delete.

The alternative isn’t complicated. Put the values in a secret store you already trust, put references to them in the repository, and let each developer’s own identity decide whether they resolve.

That’s fnox. Here’s the stage config for a service, committed, with no values anywhere in it:

# fnox.stage.toml
env = "exec"

[providers]
store = { type = "…" }

[secrets]
DB_PASSWORD    = { provider = "store", value = "DB_PASSWORD",    if_missing = "error" }
PAYMENT_API_KEY = { provider = "store", value = "PAYMENT_API_KEY", if_missing = "error" }
SIGNING_KEY    = { provider = "store", value = "SIGNING_KEY",    if_missing = "error" }

The type is the only line that’s specific to you, and I’ve left it blank on purpose, because which store you use is the least interesting decision in the whole setup. fnox speaks to Vault, 1Password, SOPS, and the managed secret stores of the big clouds. We took the one our provider already gave us, for the boring reason that we were paying for it and it already had access control we trusted. Everything else in the file is the same whichever way you go.

What that file buys:

The repository documents its own secrets. Every name a service needs is listed in one place, in git, with review history. New secret? It’s in the file, it arrives with git pull, and the next run either finds it or fails loudly because of that if_missing = "error". Nobody has to be told anything.

Rotation stops being an event. Change the value in the store; every machine picks it up on its next run. There’s no fleet of stale copies.

Access goes back to being an authorization question. Whether you can run against a given environment is decided by your identity in the secret store, not by whether someone remembered to forward you a file. Revoking someone becomes a permissions change instead of a hope that they delete a file.

And there’s a dry run. fnox check tells you whether every declared secret resolves for you, without printing any of them. It’s the fastest possible answer to “is it me or is it broken”, which is the question that eats onboarding days.

Then one deliberate restraint. That env = "exec" line means secrets are never injected into an interactive shell, only into the environment of a child process fnox launches. fnox will happily do the other thing; there’s a mode that puts everything into your shell the moment you enter the directory. We don’t use it. I don’t want every process started from that directory to inherit production-adjacent credentials, and that includes editors, and it includes the coding agents I have running in there most of the day. Scoping secrets to fnox exec -- is the whole difference between “the build can see the signing key” and “everything on my machine can see the signing key”.

That last part is what I’d underestimated. With nothing on disk and nothing in the shell, a secret only exists inside a process that something deliberately started, which turns “what can the agent reach” into an ordinary permission decision. Deny it fnox and the handful of tasks that call it, allow it everything else, and it can read the repository, build, test and format without a credential ever entering its context.

Then the hole, which I’d rather name than have someone else name for me. fnox reads the store as me, using credentials that are sitting on my machine regardless. An agent with a shell doesn’t need fnox at all; it can query the store with the provider’s own CLI. Denying fnox on its own closes the front door of a building with no walls. What does the real work is that the same allowlist doesn’t include that CLI, and that what’s within reach from a dev machine is stage rather than production. An agent that can edit .mise.toml can also write itself a task that shells out to anything. The deny rule is a fence, not a proof.

But hold it against what it replaces: a .env file sitting in the working directory in plaintext, readable by anything that can call cat, which is every agent anyone has ever run. Runtime-only injection plus a deny rule is, as far as I can tell, about as good as this currently gets.

Where the two halves meet

Individually these are two decent tools. Together they remove a category of manual step.

Because mise tasks are just commands, a task can be fnox exec -- something:

[tasks.gradle]
description = "The escape hatch from earlier, now with the build secrets loaded"
run = "fnox exec -- ./gradlew"

[tasks.secrets]
description = "Check that every build secret resolves for you"
run = "fnox check"

[tasks."serve:stage"]
description = "Run locally against stage secrets (needs cloud access)"
depends = ["stack:up"]
run = "fnox -c fnox.stage.toml exec -- mvn spring-boot:run"

Now mise run gradle :app:assembleRelease is a signed release build, and the person running it never types the word fnox, never learns which of the build’s inputs are secret, and never holds a copy of any of them. Nobody has to remember which commands need secrets. The task knows.

There’s one in there for anyone who lives in an IDE:

[tasks.ide]
description = "Launch the IDE with the build secrets in its environment (macOS)"
run = 'fnox exec -- open -na "Android Studio" --args "$PWD"'

An IDE knows nothing about any of this, so a build started from inside it can’t sign. Launch the IDE through fnox and its Gradle inherits the environment. It’s one line, and it’s the difference between a working release build and a signing error nobody can explain, so it stays in the file. I don’t reach for it much myself: most of my day is a terminal, a prompt and an agent doing the typing. That’s a preference, not a recommendation, and the task is there for whoever wants the other thing.

Then there’s the split by environment. One file each, the same variable names in all of them, different values behind those names:

fnox.toml         # local
fnox.stage.toml   # stage
fnox.prod.toml    # production

A task points at the file it needs. Anything that belongs to an environment goes in that environment’s file, so nobody can pair stage credentials with local settings by accident.

The local one is the file I’d point at if you only read one. It declares almost no secrets, because everything a local run needs already has a harmless default committed in the repository: a local database, a mock in front of anything external, obviously fake keys for the paid services. A fresh clone boots and serves for someone with no access to the secret store at all, and anything that would reach a real provider fails authentication rather than doing something expensive. Access buys you stage. It isn’t the price of entry.

Committing references means scanning for values

Committing secret references only works if you’re sure nothing real ever slips in beside them. So the same setup carries a scanner, and mise installs it without anybody being asked to:

[tools]
gitleaks = "latest"

[hooks]
postinstall = "git config core.hooksPath .githooks"

mise trust is the first thing anyone runs, and the first mise run after it installs the toolchain, which is also what fires the postinstall hook and points git at a directory holding a pre-commit secret scan. It arrives as a side effect of the step they were taking anyway, rather than a separate instruction that people skip.

The hook scans staged content only, so it’s fast, and if mise isn’t on the PATH it skips with a loud warning instead of failing. A GUI git client’s environment is often minimal, and blocking someone’s commit over a PATH problem is a good way to teach them to pass --no-verify forever. CI scans the same commits again after the push.

And the deployments

People tend to assume this bit works differently than it does.

Our deployed environments don’t run fnox. The platform they run on reads the same values from the same store itself and hands them to the process as ordinary environment variables. No application code knows about any of this. Nothing in the runtime imports a library, and no build has to be told which environment it’s for.

That’s deliberate. The store is the source of truth. fnox is how a human reads that truth, with their own credentials, on their own machine, and the deployment reads the same truth with the machine’s identity. The two never diverge, and the application on both sides just sees environment variables like it always did.

What it doesn’t fix

The honest version, then.

You still have to install mise, and put mise activate in your shell profile. That’s a real setup step and I’m not going to pretend it away. It’s one step, it’s the same step in all sixty-eight repositories, and it never goes stale, which is three things the paragraph it replaced could not say.

Docker is still yours. mise installs tools, not daemons. Our local stacks need containers, and the first-run experience for anyone without Docker configured is still a manual step and a download measured in gigabytes. Same for Xcode, which remains its own weather system.

Getting the tooling right removes the stupid part of a cold start. It does nothing about the hard part, which is understanding what the service actually does. That’s still reading code, and it still takes days.

You’re adding two dependencies to every developer’s day. mise is mature and widely used. fnox is young. We’ve committed real workflows to it, and if it stalls we’d be doing a migration. I think that’s a reasonable bet: the file is declarative, the values live in a store we’d keep either way, and the fallback is a shell script that reads the same parameters. But it is a bet, and pretending otherwise would be dishonest.

One line in that config deserves a careful review. fnox can be told to run a command that logs you in to the store when your session has expired, which is genuinely convenient and also means a committed config file now specifies something that executes on every reviewer’s laptop. Review that line the way you’d review a CI workflow.

There’s also a failure mode with a misleading error. Point the provider at the wrong account and what comes back is “not found”, which reads like a missing secret rather than a wrong identity, and sends people looking in entirely the wrong place. Both of our files carry a comment naming exactly which account the credentials have to resolve to.

Where we actually are

Two repositories fully on fnox. A handful more on mise. Sixty-odd to go, most of which will never need the secrets half at all.

I haven’t put a stopwatch on it and I’m not going to invent a figure I didn’t measure. The shape of the answer is clear enough though. On a machine that’s been through this once already, with mise installed and the toolchain cached and Docker running, a clone to a serving API is under a minute. Comfortably. What’s left of the old two-to-six hours is all first-time-on-this-laptop cost: downloading a JDK, pulling images, installing mise itself. You pay that once, rather than once per repository, and that second part is the whole difference from where we started.

In the repositories where this landed, the setup section of the README went from a list of things to install and a paragraph about asking a colleague down to this:

mise trust          # once, to allow this repository's config
mise run serve

Two lines, and the second one is the one you wanted anyway. The first is mise asking whether you actually trust a config file that’s about to install software and set environment variables, which, given that this file can now run commands on your machine, is a prompt I’m glad exists.

The pattern generalises well past our particular stack, which is why I think it’s worth writing down rather than filing as an internal chore.

Then delete the setup guide, because it’s finally lying about how much work there is.

Road to glory

John Allan Nielsen — Thu, 13 Aug 2026 14:00:00 +0000

Ask a small company where its work actually waits and the answer is almost never capacity. It’s routing.

A change gets described in one sentence, everyone agrees it should happen, and then it sits — because the repository it lives in has exactly one person who can confidently open it. Not because they’re guarding it, but because they’re the only one who knows this project wants a JDK three majors behind the last one you used, and that what looks like the entry point stopped being the entry point in 2021.

We have over seventy repositories at GolfNext, built over thirteen years in half a dozen languages, and for a fair number of them that count of people is one. It’s the subject of this post; everything else is downstream of it.

“Road to glory” is an ambitious name for a plan whose first three steps are boring. The title isn’t ironic: the ambition is for this to become the platform the golf industry runs on, worldwide, and boring is what an engine for that is made of.

The number that actually hurts

Our tech lead has written here about the state of the estate, and I spent my first two weeks finding out which repositories could still start on a fresh machine. Neither account was a complaint. Over seventy repositories is what thirteen years of shipping working software to real golf clubs looks like, and the tidying is only possible because the product works. But there’s a failure mode in it they didn’t name directly, and it’s the one that decides how fast this company can grow.

When a codebase has one maintainer, three things are true at once, and none of them are that person’s fault.

The work queues behind them. Everything that touches that system waits on the one calendar it can wait on. Fine at three things a quarter. Ruinous at three a week.

The knowledge never leaves their head. Not because they’re unwilling to share it, but because nothing takes it out. Documentation doesn’t: people write about the parts they found interesting, which are by definition not the parts a newcomer gets stuck on.

Nobody can check their work. A review by somebody who can’t run the code is a review of the diff’s spelling.

Put those together and you get a system technically owned by the company and practically owned by a person. We have several. So does every company this age.

There’s a second-order cost I only understood by living through it: when a newcomer hits something broken, they cannot tell whether the repository is broken or they are. I lost days to a local database that turned out to be impossible to build from scratch — four migrations, in a chain of 251, that could not run against a fresh import — and for most of those days I assumed I was the problem. That’s the natural assumption in your first fortnight, and nobody could have corrected me, because everyone already set up had a database that predated the break. Eventually I stopped assuming it was me, and fixed it migration by migration.

That tax lands only on new people, which is exactly why it’s invisible to the people who could remove it. It’s also one of the cleaner arguments for this plan: when every repository behaves the same way, a newcomer has a control group. If this one differs from the last five, it’s the repository that’s wrong.

And it scales the wrong way. We’re in eighteen countries with more than four hundred venues and the plan involves a good deal more of both, so a bus factor of one doesn’t stay put as you grow — the same person simply becomes the bottleneck for more things.

What “different” costs, itemised

It’s easy to say a mixed stack is expensive and hard to say where the money goes. Here is where it goes, in the order I’ve actually felt it.

Switching. Move between three repositories in a morning and you pay a small tax at each hop: which build tool, which version, which command, which idioms. Individually trivial. It’s the frequency that gets you, and the frequency is a function of how many different shapes you own.

Integrations. This is the one that matters most to our business and gets discussed the least. Our position in the market is that a club keeps its own hardware and its own management system and we work with what they already run. That means every new partner is another integration, and the cost of an integration is roughly the work itself multiplied by how strange the codebase you’re putting it in happens to be. Write the fifth one into the same shape as the first four and it’s a fraction of the price. Write it into a codebase with its own conventions and you pay the archaeology again.

Onboarding. A new engineer has to learn the company once, and then learn each system separately. The second part is where the weeks go. If every system has the same shape, learning the second one is nearly free, and that’s the difference between a new person being useful in a fortnight and being useful in a quarter.

Review. Standardisation is what makes a real review possible for more than one person. If I can run your code, I can disagree with it.

Agents. Our tech lead has written that the repositories where he trusts a coding agent most are, without exception, the ones somebody has already tidied. That matches my experience exactly. An agent working in a clear, consistent structure produces something you can use. An agent in an unfamiliar one guesses fluently, and you spend your afternoon working out which parts were guesses. Consistency isn’t just nice for humans anymore. It’s the thing that decides whether half our tooling works.

Sameness of shape beats sameness of language

Here’s the part I’d argue with anyone about, because it’s the bit people get backwards.

“Lean tech stack” gets heard as “fewer languages”, and fewer languages is only about a third of the benefit. The three things that decide whether you can walk into an unfamiliar repository and be useful are, roughly in order:

Is the file structure the same? Does a given kind of thing live at a predictable path, under a predictable name, in every repository?
Are the verbs the same? Can you build, test and run it with the commands you used in the last repository?
Is it the same language and framework?

Number three is the one that gets the headline and it’s the least important of the three. I’ve moved between two Java services with completely different package structures and it was harder than moving between a Java service and a TypeScript one that were laid out identically.

Numbers one and two are also enormously cheaper to fix. The verbs we’ve already largely solved: mise puts a repository’s toolchain and its commands in a file in the repository, so build, test and run mean the same thing everywhere they’ve been applied, whatever’s underneath. That was our tech lead’s work and it’s the highest return-on-effort thing anybody has done here.

File structure is the other one, and it’s the one I’d put real effort into, because it’s what you use before you’ve read a single line. You don’t find code by reading it. You find it by guessing a path. Where every repository agrees on where the handlers live, where the database code lives, where the tests live and what the files are called, that guess is right first time, and a search that worked in one repository keeps working in the next. Where they disagree, every repository is somebody else’s filing system and you open four wrong files before the right one — which is most of what the first hour in an unfamiliar codebase actually consists of.

It’s also the cheapest of the three to fix, because it requires no rewrite at all. It’s an agreement, plus the patience to apply it to the file you already have open. Our tech lead did exactly that when he took the React proof of concept into the real repository: a pass on how directories and files get named, before anything got built on top of it. And it’s the part an agent feels most, for the same reason you do — it locates code by predicting where the code should be.

Which is a useful thing to know, because it means most of the benefit of a lean stack is available before you’ve consolidated a single language. It also means language consolidation should be justified on its own merits rather than borrowing the credit for the other two.

Two and a half days → three minutes

So far this is an argument, and arguments are cheap. Here’s why I believe it.

At a previous job I spent a long stretch restructuring about 250,000 lines of code. Not a rewrite. Same language, largely the same logic, reorganised: where things live, what is allowed to depend on what, and what shape a change has to be to fit.

Before it, a simple task — the ordinary recurring kind that makes up most of a week — took two to three days. Afterwards I got curious enough to time myself on one, and it came out at three minutes.

I should be precise about that number, because it’s the kind of figure that gets repeated until it turns into a lie. Three minutes was one task, timed once. Others were five minutes, or ten. What changed wasn’t that every job became a three-minute job. It was that the unit changed: work counted in days was now counted in minutes, and none of it went back.

Even the cautious end of that is a ratio nobody should believe about themselves, so here’s what it actually means. Nobody got a hundred times better at programming. The work itself had always been small — a few minutes of typing, buried under everything that wasn’t the work: finding where the change belonged, reading enough of the surrounding code to be sure, working out what else touched it, and then the part that never appears on a timesheet, which is being frightened of breaking something you don’t understand and moving slowly on purpose because of it.

The restructuring didn’t make the work faster. It deleted everything that wasn’t the work.

That also tells you which tasks collapse and which don’t. Genuinely novel work, where the hard part is deciding what the thing should do, took about as long afterwards as before; structure doesn’t help you think. What collapses is the recurring shape — the fifth integration, another field on a form, the endpoint that looks like the eleven next to it. In an estate like ours, that’s most of the queue.

The result I’d actually point at

Then the part I hadn’t predicted. Frontend developers started picking up backend tickets.

Nobody asked them to. When every service is laid out the same way, the barrier turns out to have been structural rather than a matter of knowledge. That’s the most useful evidence in this post because it isn’t self-reported: a productivity figure is something you say about yourself, and crossing a boundary you’d avoided for years is something you do. It moved the number this post opened with, without hiring anyone.

One more thing, because this blog writes about coding agents constantly and it would be easy to read all of that as an AI story. There was no AI in it. None. Every minute of the gain came from where the code sat and what was allowed to depend on what — which means the payoff isn’t contingent on agents continuing to get better, or on us using them well. Structure paid before any of this existed. What agents do is multiply it, most of all in the repositories that already have it. If they stalled tomorrow the argument in this post would be unchanged.

I want to reproduce that here. Different company, different estate, same mechanism. That refactor is also where this post’s title comes from, and it’s why I can write a plan this confident about work that hasn’t happened yet: I’m not predicting an effect, I’m expecting one I’ve already stood in the middle of.

What the engine is for

A post about making developers more productive can be read the wrong way, so let me close that reading off myself. This is not about needing fewer developers. Nobody here is doing it so the same work can be done by fewer people, and if that were the plan I wouldn’t be writing a blog post about it. The developers here are good. They built a product that works in eighteen countries, under constraints I never had to live with, and losing any of them would set this back rather than forward.

The reason is growth, and I’d rather state the size of it than be coy. We are not trying to get somewhat bigger. The goal is for this to be the platform the golf industry runs on — every club, every range, every country that has both — and the reason that’s sayable out loud rather than embarrassing is that the demand side is already turning up. Clubs who see the product are, in my experience so far, genuinely amazed by it. That reaction is the asset. Nothing in this post creates it, and nothing in this post can substitute for it.

What we don’t have is the engine to serve it at that size. The product is good; the machinery that builds, integrates and supports it is thirteen years of accumulated decisions, and that’s the part that breaks first if demand arrives faster than the team can absorb it. We’re not building the product — it exists, and people who had nothing to do with building it are impressed by it. We’re building the thing underneath that decides how many clubs, how many countries and how many integrations a small team can carry at once. Amazed customers are what got us to more than four hundred venues in eighteen countries. What decides whether the number after that has another zero on it is whether the eleventh integration costs what the first one did.

Which is why the part of this I care most about getting right isn’t the language. It’s that the people who’ll have to live in the result want to.

React on the front, Go behind it

What you’re looking for when you finally do pick a language, then, isn’t the most powerful one. It’s the one that hands you the other two for free.

The target is two languages.

Every interface is React. Web is React and TypeScript, mobile is React Native, and that includes the interfaces sitting on hardware — the kiosk screen a player stands in front of at half five in the morning is a screen like any other. That was already half-true before anyone decided it, because our mobile applications are React Native, and it became true in practice when one of our frontends went from Vue to React and shipped. The rest follow.

Everything behind those interfaces is Go. Not “the new services” — everything. The web backends, the public API, the integrations, and the desktop point-of-sale application, which becomes a Go core with a React interface instead of the JavaFX application it is today. Whether a thing runs in a data centre or on a till in a pro shop stops being a fact about what language it’s written in.

I’m not going to argue the languages here. Go against the alternatives is a post of its own, and the honest summary is that the specific choice matters considerably less than the fact that there is one — which is the argument this entire piece has been making. Worth being plain about one thing before the next section, though: Go is not what we have most of. Java, PHP, Node and Kotlin all have more running code behind them today, and that’s a real cost rather than a detail.

What the decision buys is two things, and they’re worth separating because they get blurred together in every post like this one. The first is developer experience, which is most of what this post is about and which comes down to the number at the top: how many people can open a given repository and be useful in it.

The second is performance, and there I want to be precise rather than sloganeering, because “simple stack, therefore fast” is not an argument. What it does mean is two specific things. One is footprint: what a process costs to start and to keep running, which is a real number on kiosk hardware and a real line on a cloud bill. The other is that performance work is gated on comprehension — you cannot fix the slow thing in a system nobody can hold in their head, and most systems are slow in a place their maintainers stopped looking at years ago.

One sub-decision genuinely isn’t settled. A Go core with a React interface on the desktop needs a shell to host that interface, and we haven’t picked one. The shape is decided; the mechanism isn’t, and it isn’t urgent, because the desktop application is nowhere near the front of the queue.

The shot we’re not taking

On most courses there’s a hole where the ambitious line goes straight over the water. The big-bang rewrite is that shot: freeze the old thing, build the new one beside it, switch. Quickest if it comes off — and the graveyard is full of companies that spent two years shipping nothing while their competitors shipped features.

We’re laying up. Four rules.

New work is built in the target shape. The only free rule, and the one that does most of the work over a year: every new service is a repository that never needs converting.

Rewrite only what you were opening anyway. Conversion is cheapest when somebody is already paying to understand the system. Working software nobody needs to change isn’t a problem; it’s an asset with an ugly logo.

Seams before rewrites. Two admin portals, two backends, two logins. Not a rewrite into one: an auth bridge first, then a single frontend over both backends, then the backend consolidation. Each step separately shippable, and separately abandonable.

Structure and verbs first, everywhere; language last, selectively. The cheap two-thirds is available in every repository today, including the ones that will never be converted.

Then the thing I’d rather write down than be caught not having thought about: it gets more varied before it gets less. Go isn’t a language we have much of, so for a couple of years the estate holds Java, PHP, Node, Kotlin and Go. Convergence arrives last. If you want to argue with this plan, argue there — it’s the weakest point in it, and the only defence is that the four rules exist to make that interval survivable.

One caution rather than a rule: agents have made rewrites cheap to produce and no cheaper to review. A rewrite that looks finished is the most flattering thing they make, because its gaps are omissions, and an omission never shows up in a demo.

What this actually costs

The plan has a bill and I’d rather itemise it than have somebody else do it.

Monoculture is a real risk, not a rhetorical one. Two languages everywhere means two sets of blind spots, two dependency ecosystems whose bad weeks are now everybody’s bad week, and a team that gradually loses the reflex of asking whether the usual tool is the right one.

The strongest form of that objection is the right tool for the job, and in general I agree with it. But it’s an argument about problem spaces, and ours is one problem space. Take the labels off our systems and they are all doing recognisably the same work: accept a transaction, talk to a device or to a partner’s API, and put a record somewhere it can be trusted later. There’s no machine-learning workload here pulling towards Python and no signal processing pulling towards C. The variety in our estate corresponds to no variety at all in the problems it solves, which is the tell that it’s accident rather than design. Nobody picked half a dozen languages as a hedging strategy.

So the risk is real and worth naming, and the mitigation is that “standard” has to mean a strong default with a documented way to argue, not a rule. The day a genuinely different problem does turn up — and in a company doing more with AI every quarter, it might — that argument has to be winnable, or the default has quietly become a rule after all.

Consolidation can be a way of avoiding product work. Structural work is satisfying and legible and it produces no customer value on the day it lands. The discipline is that every step has to be justified by something it unblocks. The portal merge is justified because club staff log in twice. The React standardisation is justified because it’s the precondition for everything after it. If a step can’t name what it unblocks, it isn’t ready.

It replaces work people are proud of. This is the one management raised when we presented the plan, ahead of cost and ahead of customer risk, and they were right to. Nobody wants to hear that the thing they built well, under the constraints they actually had, is now the old way. We ran the brainstorm with the whole team and deliberately held our own proposal back until everyone else had spoken. Nobody disagreed. The parts about merging the portals people were genuinely excited about; the standardisation itself people were fine with, which is a reasonable thing to feel when it’s your choice being replaced, and I’d rather report that accurately than upgrade it.

And it will take longer than this post makes it sound. Golf clubs are busy in summer, so we’re busy in summer. The platform goes quiet over the winter and that’s when the structural work has room. This is a plan measured in seasons.

How we’ll know it worked

Not by a diagram. By four things you can actually check.

How many repositories have exactly one person who can confidently ship a change to them. Today that number is uncomfortable. It’s the headline metric for this entire plan and it’s the only one I’d defend as being about the company rather than about engineering taste.

How long from clone to running code, on a machine that’s been through it once. That was two to six hours when our tech lead measured it in August, depending which repository you picked. In the repositories mise and fnox have reached, it’s a command.

The ambition behind that number is blunter than the number itself, so I’ll put it the way we actually say it: getting a codebase running locally should be as close to idiot-proof as we can make it. Not because anyone here is an idiot — the opposite. If starting a repository takes cleverness, that cleverness is being spent on the wrong thing, and it gets spent again by every person who arrives after you. Clone it, run one command, get a working system with a database, test data and an account to log in as. Anything standing between those two points is a defect, whether or not it’s in a tracker.

What the second integration costs relative to the first. If we do the structural work and the fifth partner integration still costs what the first one did, the work didn’t do what we said it would.

And what a new engineer can do at the end of their second week. Not “has read the codebase”. Has shipped something to a club.

That last one is the whole plan compressed into a sentence, and it’s the reason for all of it. Everything in this post — React on the screens, Go behind them, the folder layouts, the auth bridge, the one command that means the same thing in every repository — exists so that the answer to “can you pick this up?” stops depending on which repository we’re talking about.

And the reason to care about a question that small is that its answer caps everything above it. A club somewhere decides we’re the best thing they’ve seen this year, and from that moment the only question that matters is whether we can build what they need while they’re still excited about it. Doing that four hundred times is a product. Doing it four thousand times is an engine.

So here’s the version I actually believe, written down where you can hold me to it.

Two years from now, a developer who joined last month picks up an integration with a management system in a country we don’t sell in yet. They have never opened that repository. They clone it, mise run serve fetches the toolchain and brings the thing up, the Go handlers are where Go handlers always are, the React screens are laid out like every other React screen we own, and the tests pass first time. By Thursday it’s live at a club that had never heard of us in the spring. Nobody in the building thinks this is remarkable.

That’s the whole ambition. Not a heroic quarter — a Thursday.

Multiply that Thursday by every developer we have and every country that has golf in it, and you get a company that ships as fast as it can think, in an industry that has never once had software moving at that speed. The product that amazes people already exists; we didn’t have to invent it and I can’t take credit for it. What we’re building now is the only thing standing between that product and every club on earth that would want it — and we’d rather build it before somebody else works out that this is the race.

So: glory is a big word, and it’s the right one. A course record isn’t one miraculous shot — it’s eighteen ordinary holes played by somebody who has stopped losing strokes to the rough. We’re not lining up the hero shot over the water. We’re removing every place the ball can get lost, and then we’re going to play the round of our lives.

Which in practice is as unglamorous as it sounds, and I’d rather finish there than on the metaphor. React on every screen and Go behind every one of them. The same folder structure in every repository, so you can guess a path before you open the tree. One command that builds any of them. Secrets in a store instead of a chat message. Over seventy repositories converging on a single shape — and a company that can then take on the hundredth without anybody having to be brave about it.

In the jungle

John Allan Nielsen — Thu, 13 Aug 2026 13:00:00 +0000

I started at GolfNext at the beginning of August. Somewhere in the onboarding, between the accounts and the hardware, was a task with my name on it: get every codebase running locally.

Not read them. Run them. Clone the repository, install whatever it wants, start the thing, and watch it come up on your own machine.

It reads like something you hand a new person to keep them busy for a day. It ran through most of my first two weeks, it produced the most useful map of this company I have, and it turned into a fair amount of repair work nobody had asked for, because several of those repositories could not start at all.

In my first week alone I worked in a Vue admin panel, an Android app that runs on a self-service kiosk, a Java backend, and a desktop point-of-sale application that ships as a Windows executable.

That’s the shape of the company. GolfNext builds the software golf clubs run on — booking and paying for a round, the till in the pro shop, the unattended machines out on the practice range — and after more than a decade of doing it there are seventy-one repositories in our GitHub organisation. Mostly TypeScript, JavaScript and Java, with PHP behind them, and then a few one-offs: Kotlin, HCL for the infrastructure, shell.

None of that is unusual for a company this age, and none of it is a complaint. It exists because people shipped a decade of working product under real constraints, and the tidying up I’m about to describe is only possible because the product already works. It does mean every repository is a small patch of jungle, though. Two things were genuinely hard, and neither of them was the actual programming: working out which of seventy-one repositories the thing I needed even lived in, and then working out how to start it. The second one was the assignment.

What the jungle charges

Big obstacles are interesting, and you remember them. The jungle charges you in small identical amounts instead, over and over.

You clone something and the build fails because your JDK is one major version off. You fix that and the build tool wants a different one. You move to a web project and the version file says one Node while the lockfile was built against another. Somewhere there’s an environment file to fill in, and the values live with a colleague. Each of those is fifteen or twenty minutes, none of them teaches you anything, and you pay them again on the next machine and again for the next person who joins.

None of that was any one repository’s fault. It was the absence of a shared answer: every Java application had settled on its own JVM version, and every web project on its own Node version, each pinned in practice by whatever happened to be current the last time somebody set it up, with nothing ever going back to reconcile them. The dependencies underneath drifted the same way — the same libraries sitting at different versions in different repositories — so what you learned getting one repository to build didn’t transfer to the next one.

And getting any of them to run locally was its own tax, payable in a different currency each time. The clearest case: two of our Java desktop applications are the same kind of program, built for the same job — one builds with Gradle, the other with Maven. Neither repository records a reason. At some point I stopped taking notes and asked the question out loud, which is the question this whole post is really about: where is the standardisation? Not as a complaint. As a genuine question about how an estate ends up holding two answers to a problem that only has one.

One person, one application

There’s a structural reason for this, and I think it explains most of what I found. For most of this company’s life the software was built by remote developers, working at a distance from other countries and, as far as I can tell, largely on their own: one person, one application, start to finish. If you are the only one who will ever build a thing, declaring its toolchain in the repository buys you nothing. You already have the toolchain — it’s on your machine, and it’s correct because it’s yours. Conventions converge when people have to work inside each other’s repositories, and for years almost nobody did.

I’d add a softer theory, and I want to be clear that it is one. Distance isn’t only geographic. Working across countries, time zones and second languages makes the cheap conversations expensive — the ones where two developers notice in passing that they’ve solved the same problem differently and settle on one way of doing it. Nobody has to disagree for an estate to diverge. It’s enough that the conversation is never quite convenient. None of which is a criticism of anyone who worked here before me; it’s roughly what I’d expect that arrangement to produce, and I’d probably have built the same jungle in their position.

All of that has a name, and it’s the oldest joke in the industry: works on my machine. Nobody here says it with a shrug, and nobody was defending it — but it’s what the estate had quietly organised itself around. If every machine that builds a given repository is already configured, then the configuration doesn’t live in the repository. It lives in a few people’s heads and in their shell history. Onboarding a new person means reading it back out of them, and it is never complete, because the parts they do automatically are exactly the parts they forget to mention.

The repository that cannot start

The worse case is the repository that cannot start at all.

In one of our backends the local development profile — the configuration that points the application at a database on your own machine — had been deleted months earlier, and nobody noticed, because nobody who was already set up ever needed it. Clone it fresh and you get a data-source error that tells you nothing about why. Underneath that sat something worse: a database migration written years ago that won’t let the schema finish until it has called out to a third-party service, one this codebase can no longer reach. So a genuinely fresh local database could not be built at all, on any profile.

Neither of those was in a tracker. They aren’t bugs in the ordinary sense, and nobody did anything wrong to create them. They’re what a repository drifts into when no fresh machine is ever the one being tested — and you only find out on the day somebody joins, or somebody’s laptop is replaced, when the whole bill arrives at once.

Two hundred and fifty-one migrations

The hardest one to start was our GolfMore admin panel — the back office club staff log into, which serves the public API out of the same codebase. PHP and Symfony, MySQL underneath, and a decade of schema history sitting on disk: a 114 KB base dump to import first, then 251 migration files to run on top of it.

The documented way to get a local database was exactly that. Import the dump, run the migration chain, get a working schema. It does not work, and hasn’t for years, because four migrations from 2022 and 2023 cannot run against a database built that way:

One drops the bookkeeping table left over from the migration tool the project used before Doctrine, which a fresh dump import has never had.
One throws unconditionally in its postUp(), because it calls addSql() on a migration that is already frozen.
One references a table several months before the migration that creates it.
One declares AUTO_INCREMENT on a column with no key, which MySQL refuses, so it has never been able to run at all.

Nobody is at fault here in an interesting way. The combined effect is the problem: the one path a new developer is told to take is the one path that’s broken, and everybody already set up has a database that predates it, so nobody else ever hits it.

How a chain rots

How it got this way I can only guess at, and I’d rather say that than pretend otherwise. My best guess is that at some point the schema in production was changed by hand. The fourth of those defects is nearly proof of it: MySQL has never accepted an auto-increment column that isn’t a key, so that migration cannot have run anywhere, ever — and yet the table it describes exists everywhere the application runs. Something other than the migration chain put it there. The same explanation covers the forward reference: if that table already existed on the machine where the migration was written, referencing it worked fine there, and only a database built strictly from the chain would ever notice.

Two other mechanisms need no villain at all. One is the base dump. It’s a snapshot, and if it was refreshed at some point later than the migrations that follow it, then importing it and replaying the chain stops being the history that actually happened — you’re now asking old migrations to redo what the dump already contains, or to drop what it never had, which is exactly the leftover bookkeeping table. The other is dependency upgrades. The migration that throws in its post-run hook was presumably legal the day it was written, and a later version of the migrations library made that call illegal. Nobody re-runs the old end of a chain, so a change like that lands silently and waits for whoever builds a database next.

Which is the general shape of the thing. A migration chain only ever gets tested at its head. The tail is exercised by exactly one kind of event — somebody building an environment from nothing — and if that hasn’t happened for a few years, nothing anywhere tells you it has rotted.

Was it me or the code?

What made this slow wasn’t any one of those four. It was not knowing, for a good while, whether the problem was the code or me. A new person with a failing command has no way to tell a broken repository from their own missing knowledge, and the default assumption — the polite one, and usually the correct one — is that it’s you. So you re-read the README, check your versions, throw it away and start from a clean clone, and lose an afternoon proving something that was never true in the first place.

Once I accepted it was the chain, the method was dull and it worked. Run the migrations up to the version where they stop. Work out what that one needed and couldn’t get. Write the patch by hand, mark that version as done without running it, and carry on to the next dead end. I did that a handful of times, each round a little faster than the last, until the whole chain ran end to end without breaking anything.

Then I wrapped the resulting list of hacks in a single mise task, which is the only part anybody else should ever have to see — and the reason starting this thing locally now feels like a breeze instead of an archaeology project.

What one command hides

What I did about it is not elegant. One task, mise run db, starts the container and then asks the database a single question: does the migrations table exist? Everything after that hangs off the answer.

If the table is there, this is an existing database: migrate it forward, assert it ended up current, done. If it isn’t, the task imports the dump and walks the chain in stages, stopping at each broken migration to do by hand the one thing that migration can’t do for itself. Create the leftover bookkeeping table so the migration that drops it succeeds. Add the column the throwing migration would have added, then mark that migration applied without running it. Stand up a stub of the table that doesn’t exist yet, just long enough for the forward reference to resolve, and drop it again afterwards. Create outright the one table whose migration can never execute. Then run the remainder normally, verify the schema is up to date, and print the test login.

I’d rather have fixed the four migrations. That’s a bigger job than it looks, because they’re part of a chain every deployed environment has already run, so touching them means being certain what each of those environments actually has. So the workaround is what shipped — with the root causes written up, and a note above the block saying the whole thing can be deleted once they’re fixed. Ugly and documented beats elegant and imaginary. The failure mode I care about is the next person spending two days rediscovering all four.

The result is the part I’d defend. On a machine with nothing but mise and Docker, one command brings up the panel, the API, a schema at the right version, and an account to log in as. Re-running it is safe. And mise run db:reset throws the database away, so you can prove the whole thing works from empty — which is the real test, and the one nobody had been in a position to run.

What the count multiplies

Two costs don’t just repeat with the repository count. They scale with it.

The first is dependency bumps. In that same week I bumped an HTTP client by hand in two frontends, a JSON library in a third repository and a PDF library in a fourth: four branches, four pull requests, four review cycles, and nothing learned by anybody. The usual case for automating that away is security. At seventy-one repositories it’s arithmetic.

The second is branch topology. Some repositories still carry a branch each for development, staging and production, with changes travelling between them by merge. From that week I have a commit of my own whose entire message is “Fixed merge conflict error”. Every long-lived branch is another place the same change exists in a slightly different state. We’re moving to one, where a merge deploys to staging and a published release deploys to production, and nothing is left to reconcile.

The machete

Two tools do most of the cutting, and neither of them was my idea — our tech lead brought both in during his own first weeks. mise declares a repository’s toolchain — and the commands you run against it — in a file in the repository, and fnox does the same for the references to its secrets. The repository commits pointers; the values live in a managed store that grants access per person, rather than in a file somebody pastes you.

The Android app got its Java and Gradle versions pinned. The backends got Java and Maven pinned. Several repositories got a README that was true again, and a CI workflow where there hadn’t been one.

The one I liked most was the desktop application. It ships as a Windows executable, and it now cross-builds from Linux through a task defined in the same file that pins its toolchain — hiding a toolchain I’d otherwise have to learn before touching a one-line change.

To be honest about the coverage: that’s a handful of repositories out of seventy-one. It’s less a programme than a habit a few of us keep picking up.

What the machete doesn’t cut

All of that shortens the distance from clone to running. It does nothing whatever to the distance from running to understood.

My most recent feature is a super-admin screen — the one our own staff use to manage the internal accounts that get into the back office. List them, create one, and since this week, edit one. A form, a table, a couple of calls.

Nothing in the repository documented what those calls expected. The contract did exist, as a published API document sitting outside the codebase, so the types came out of that rather than out of guesswork. A slightly undignified way to obtain a contract, and a much better one than reading the existing client code and hoping whoever wrote it had got it right.

Then the document contradicted itself. One endpoint is described as returning every account. The response it declares is a single account. Both statements sit in the same file, and I couldn’t settle which was true by calling the thing, because I didn’t have credentials for that environment.

So the client code I wrote accepts a list, or a single object, or an empty body, and always hands back an array. Three tests, one per shape, and one manual pass through the screen itself. The alternative was to pick the shape I thought most likely and fail loudly on the other, which would have converted a documentation ambiguity into an outage. The shape of that code is an ambiguity I couldn’t resolve, and the only way anyone will know that later is that I wrote it down beside it.

The edit form produced three more. A password field the API doesn’t return as empty, so the form has to open blank and send nothing unless someone types a new one — round-tripping whatever came back would write nonsense over a perfectly good credential. Roles matched on their stored identifier, so a change has to carry that identifier; send the new role without it and the account quietly ends up with two. And a save that treats a row left out of the payload as unchanged rather than deleted, so there’s no way to remove one through it at all, which is why that delete control is disabled instead of sitting there pretending to work.

Each of those is one comment at the site, explaining why the code is the shape it is.

Where the agents fit

I’m generally enthusiastic about coding agents, so here’s another commit from that same week. Its entire message is “revering claude slop” — my typo, my commit, reverting what an agent had produced.

That commit doesn’t dent the enthusiasm so much as locate it. An agent is only as good as the ground it stands on. Point one at a repository with a clear structure and a pinned toolchain and tests that actually run, and the output is usually something you can work with. Point one at a repository where none of that is true and it will guess, fluently and confidently, and you’ll spend your afternoon working out which parts were guesses.

Which means the tooling work and the AI work aren’t two projects. Every pinned version and every honest README raises the floor under everything an agent does in that repository afterwards, and the repositories where I trust an agent most are, without exception, the ones somebody has already tidied.

Two distances

The distance from clone to running is a tooling problem, and it compresses beautifully. It goes from an afternoon to one command that’s spelled the same everywhere, and it compresses again for the next person.

The distance from running to understood does not compress. No config file will tell you that an endpoint’s summary and its schema disagree, or that a migration from years ago is holding your database hostage over a service it can’t reach. What helps there is slower and less satisfying: read the API’s own description of itself rather than the code somebody wrote against it, and when you end up writing defensive code, write down what you were defending against.

That second distance is most of the job. The value of streamlined tooling isn’t that it makes the job smaller. It’s that you arrive at the real work with your twenty minutes and your patience intact — and the way in is starting to be the same in every repository.

As for the task: everything I pointed myself at did eventually come up, and several of them only after being repaired first. That’s the part I hadn’t expected from an onboarding chore. It looks like it exists to teach the new person the estate, and it does do that. What it actually produces is a list of everything that had quietly stopped working while nobody was looking.

Which is, as I understand it, the job. Johann, our tech lead, and I arrived within a day of each other at a company whose product works and whose technical foundation grew one application at a time, because that’s what the arrangement that built it asked for. Bringing structure to that, and making it scale past the size we are now, is what the two of us are here to do — not as a cleanup project with an end date, but as the standing work. Everything above is week one of it.

And the ambition behind it isn’t tidiness. We want to build the engine that can carry this product worldwide — the software golf clubs run on, in as many countries as will have us — and the only thing that ever earns a position like that is customers who are amazed by what they get. Structure and scale are how you stay able to deliver that when there are ten times as many of them. A foundation that can’t scale doesn’t fail loudly. It just quietly caps how good the product is allowed to become.

Four products, sixty-eight repositories

Johann Böhler — Wed, 12 Aug 2026 00:00:00 +0000

I started at GolfNext on Monday the 3rd of August, at 8:00. I’d pictured a quiet office and twenty minutes of standing around. Most of the team was already in and in a good mood about it. I’d brought a cheesecake, which we ate after lunch, because I’ve been in Denmark long enough to know that turning up with cake is not really optional here.

Peter, who started the company in 2012, had Claude open before I’d found my desk, working through the accounts and permissions I’d need. Small thing to notice on a first morning. It told me more than an onboarding deck would have.

The first post on this blog was a letter I wrote to myself before I’d signed anything, full of predictions about a company I’d visited once. This is where I hold it up against what’s actually here. Most of what follows isn’t really about me though. It’s the company I want to describe: what we build, what sits underneath it after thirteen years, and what we’re planning to do about that.

What GolfNext builds

If you’ve never thought about the software a golf club runs on, here’s the shape of it. A club is a small business wearing several hats at once. There’s a pro shop, a driving range, memberships, a booking system, and more and more often a simulator bay or two. The booking system handles tee times, which, since I had to learn this myself, have nothing to do with tea. A tee time is the slot a group is booked to start their round on the first hole, and the whole day at a club is arranged around that grid.

Historically each of those hats arrived as its own box, from its own vendor, with its own software attached. Buy the dispenser, get the dispenser company’s system, whether or not it suits how you run your club.

Our position is the opposite of that. Your hardware and your infrastructure stay yours, and you stay free to pick the software that fits. We want to be open to any integration, so whatever management system a club already uses to run its tee times, the aim is to work with it rather than ask them to throw it out. Freedom to choose, power to connect.

Self-service kiosks. A digital reception that runs around the clock. Green fees, rentals, pro shop purchases, all without someone standing behind a counter. As far as we know it’s the only one of its kind in golf. A club gets fewer staffed hours and keeps earning outside opening times. A player gets the same convenience they already have everywhere else in their life.

Driving range payments. Payments on the range that work with any ball dispenser brand. That compatibility is the product. The dispenser belongs to the club, or to whoever sold it to them, and being able to sit on top of all of them is the whole selling point. Cards, apps, wallets, PIN codes, with real-time analytics behind it. In a lot of places the range still runs on cash, and this is where demand is growing fastest right now. More than 500 million balls a year go through it. That’s a lot of slices.

Voucher management. Issuing, distribution and redemption, all digital, from a single ticket up to a full sponsor package.

Simulator management. Automated access control, so a simulator only runs during a paid session. No more time theft, better utilisation.

Where that adds up to today: 400+ venues, 18 countries, 350,000+ active users. Founded in Denmark in 2012 and still very Danish, which is also why I walked out of my first day having decided to get serious about my Danish.

The stack, without the polish

Sixty-eight repositories. JavaFX on the desktop side, PHP, Vue, React, React Native, Spring, Java, Kotlin. All of it on AWS.

Written out like that it looks like indecision, and it isn’t. Thirteen years, four product lines, hardware sitting in the field, and for most of that history the software was built by external partners who were good at their jobs. Every project picked what made sense on the day it started, and most of those calls were reasonable ones. What never happened is anybody going back afterwards to make the choices agree with each other.

So, the honest state, because I said in the letter I’d write these things down rather than smooth them over.

A good share of those sixty-eight repositories hadn’t been touched in years and were never archived. Forks, spikes, one-off tools that outlived their reason. I started archiving in the first week, slowly, because for most of them I didn’t yet know what I was looking at, and not knowing is a much better reason to leave something alone than to delete it.

In the code you can read the generations. Several package structures inside the same language, none of them wrong, all of them different. An AGENTS.md written for Codex and a CLAUDE.md written for Claude, sitting in the same repository, describing the same project, disagreeing about it. A README.md documenting a version of the system that doesn’t exist anymore. A runtime that went end of life a while back and is still running. And a release process that’s properly good for some of our tools and a snowflake for others, where part of it lives in a pipeline and part of it lives in somebody’s head.

Security sits at the top of the pile. Of the twenty-nine engineering practice items I’ve written down so far, five are marked high priority, and all five are security. That’s not a discovery about GolfNext in particular. It’s what thirteen years of shipping tends to look like anywhere nobody has recently been paid to go and look.

Since I made a prediction about all this from the outside, I owe you the result. It’s roughly where I expected it to be, and I mean that as a fair outcome rather than a complaint. This is thirteen years of continuous delivery by people shipping features that customers actually needed, on deadlines, with the priorities they were handed at the time. You’d find much the same picture at most companies this age, and I’d rather be the person who tidies it than the person who tuts at it. The one prediction that landed exactly was the dull one: I’d guessed from outside that the repos would be under-automated, and they are. That’s my opening.

The part I got wrong

I’d braced myself for the products to be the weak spot. Companies carrying a stack like ours often have shipped-anyway software on top, the kind where you can feel the deadline in the interface.

That’s not what’s here. The products are good. There’s room in all of them, obviously. But the thing I keep noticing in meetings is that everybody reasons from the customer’s side first, including people with no engineering background at all. What does the player standing at the kiosk at half five in the morning actually experience. What does a club manager have to explain to a member when something goes wrong.

That instinct is hard to retrofit into a team. Package structures can be refactored and READMEs can be rewritten, and both of those are just work. Teaching a group of people to care about the person at the other end is a different order of problem, and we don’t have it.

What we started in week two

Two integrations landed almost immediately, and they’re the same bet in different clothes. The platform is only open if it actually connects to the systems clubs already run.

teeControl is a management system a lot of clubs use, and we’re integrating it so it works through our kiosks. First impressions are good. First impressions are also cheap, and there’s a fair way to go from here. We need proper test systems. We’ll probably have to adjust some of our own flows to fit theirs. There are decisions still to settle on both sides. That’ll be a process rather than a sprint, and I’d rather say so now than write a triumphant post about it in week two.

Lightspeed is a player-facing app we want to support as a payment option. Peter had already built a first version before I arrived, and taking it over was my excuse to get my hands into real code here for the first time. Ten thousand lines, read end to end, then run and poked at until I understood what it was doing. That produced a list of bugs and a stack of follow-up stories, which is what reading anything carefully produces. The more useful outcome is that it’s in my head now as well as his.

And Verifone terminals on the desk, which is the regular reminder that a lot of our software ends in a physical object somebody has to touch.

The approach John and I settled on is to skip the big upfront specification. John is the other developer, though that undersells him, since he’s as much solution architect and project manager as engineer. Get a test instance, build against it, let reality write the documentation. Two weeks in I don’t know these systems well enough to write a good spec, and pretending otherwise would just produce a document we’d quietly stop reading by September.

One small thing worth passing on to anyone thinking about working somewhere like this. I spent my first few days being patient about access, on the assumption there was a process I was supposed to wait for. Then I said out loud that this was more or less what I’d been hired for, and could I please just have it. Half an hour later I had AWS. The waiting was entirely my own invention.

How we ship

The most interesting problem of the first two weeks wasn’t inside a repository. It was working out how changes get out to customers.

I spent a Friday on proper detective work. CloudWatch logs on one screen, a downloaded database snapshot on the other, lining transaction states up against what the code believes should have happened. Somewhere in there I found forty commits that had never been pushed anywhere. This is the unglamorous half of bringing knowledge in-house. Credentials are the easy part. Rebuilding an understanding of what the system actually does takes a lot longer.

We don’t have a gradual rollout mechanism today. What we do have is customers who are physical places, and a handful of them are a short drive from the office. So the first ring is geography. A few nearby clubs get the new version first, and if it goes wrong the recovery plan is twenty minutes in a car with a spare terminal in the boot. That took about five minutes of conversation to arrive at, because once you notice where the customers are it’s a fairly obvious move. It’s not what I’d draw on a whiteboard. It’s available this week, and it buys enough confidence to keep shipping while the proper thing gets built.

Learning the game and the words for it

On day three I played the first round of golf of my life, with colleagues. Seven or eight shots a hole. Never a ten. We didn’t lose a single ball all round, which I’m told is the more impressive statistic for a beginner. Nobody wrote down a score.

I’d recommend the general version of that to anyone joining a company whose domain they don’t know. Not golf specifically. Going and doing the thing the software is about.

The week after, John and I sat down for what turned into the most useful two hours of week two: agreeing what we call things, before three systems each invent their own word for the same concept. Nine holes is a loop. Stroke index ranks the holes by difficulty. There’s rating category. None of this is exotic if you play golf, and all of it is invisible to an engineer who has never stood on a tee box, which two weeks ago was me.

Getting the vocabulary right early costs almost nothing. Getting it wrong costs you three services, three names for one thing, and a translation layer nobody set out to build. I did run one check I’d suggest to anyone doing this: I had Claude verify “loop” on its own, because it smelled to me like a word engineers invent and then talk themselves into believing is domain language. It came back as real golf. Using the model to check our own vocabulary, rather than to write code, is one of the better uses I’ve found for it so far.

Twenty-nine items, and where this is going

The improvement list lives in ClickUp now, mostly so I can stop carrying it around in my head. Twenty-nine items, all still in the backlog, grouped roughly into repository standards and conventions, security and secrets, CI/CD and testing and dependencies, infrastructure and data, architecture direction, and AI and agents.

The first thing we’ve actually rolled out is the least exciting item on the whole list. mise, which pins and installs the right language versions per project, so you clone a repo and the correct Java turns up on its own. With that many technologies spread across that many repositories, the tax you pay all day long is switching between them, and that particular tax is avoidable.

The goal hasn’t changed since the letter. Build a landscape where context is cheap to pick up. If a new engineer, or a fresh AI session, can understand a service quickly, work can start immediately, by whoever picks it up. If they can’t, every task starts with archaeology. Everything on that list of twenty-nine sits downstream of that one sentence.

The scorecard

Which brings me back to the letter, and the promise to mark my own homework in public.

Stay on the keys. Held. Two terminal fixes shipped, pull requests reviewed, and I’ve taken ownership of one of the apps. I’m still building, which was the condition I set before I accepted the job.

Rebuild the understanding, not just the access. Mostly. The CloudWatch afternoon, the database snapshot, the Lightspeed handover: that’s the right shape of work. What I can’t claim yet is being able to release anything in the stack without asking somebody.

Candor in the open. Held, and easier than I expected, mostly because the room here makes it easy.

Now the other half.

Goal one slipped. “Make the work visible” was first on the list and this blog was supposed to be how. Every post before this one was written before I’d signed the contract, which turns out to be the easiest possible time to write about a company. Then I actually started, and for two weeks there were things in front of me that mattered more than a blog post. I’m not going to call that a crisis. I did write that if it went quiet I should treat it as a warning sign, so: noted.

The cold start is nowhere near five minutes. I set myself five minutes from clone to running code and told future me to go and time it. I haven’t timed it properly, which is its own small failure. I’ve cloned enough of these repositories by now to give a fair estimate though. Somewhere between two and six hours depending which one you pick, call it four on average. Getting the iOS build running took most of a day of Xcode, pods and emulators. mise is the first real step at closing that, and a step isn’t a number.

The shared AI kit is item twenty-nine of twenty-nine, and that part is on purpose. In the letter I called it the thing that turns “AI-first” from a slogan into shared tooling. Two weeks in I can see why it can’t come first. A shared kit built on top of sixty-eight inconsistent repositories would mostly just encode the inconsistency. Foundation first, kit second, and I’d defend that order. What I won’t pretend is that the order is free. Until we get there, I’m getting a lot of leverage out of a setup I’ve spent a year tuning that nobody else here has yet.

And the days ate the space to think. I wrote that the creative, playful time isn’t a reward you earn once the serious work is done, that it is the serious work. Two weeks in, it’s the first thing the calendar takes. One thing helps here, and it’s specific to this industry: golf is seasonal. Clubs are busy now, so we’re busy now. The platform goes quiet over the winter, and that’s when the toolset for the 2027 season gets built. Having a shape to the year is more useful than I expected it to be.

The thing I got most wrong is also the one I’m happiest about. I turned up braced for friction. I expected to have to earn access, argue for scope, make a case for every change. Almost none of that was there, and what resistance I did meet in the first fortnight I’d brought with me.

Two weeks isn’t long enough to conclude much. Ask me again in the winter, when the clubs go quiet and we find out what we actually do with the time.

Making Claude Code shut up (and other customizations that earned their keep)

Johann Böhler — Wed, 24 Jun 2026 10:00:00 +0000

The first thing I did with Claude Code was make it talk less.

Claude Code is Anthropic’s terminal coding assistant — you talk to it, and it reads, writes, and runs code in your project. Out of the box it’s polite. “Certainly! I’d be happy to help you with that. The issue you’re seeing is likely caused by…” I read fast, I pay per token, and I don’t need the warm-up. I switched that off. I run a community plugin, caveman, that strips responses to the bone: no articles, no pleasantries, every bit of technical substance intact. “Bug in auth middleware. Token expiry check uses < not <=. Fix:” — and then the fix.

It takes adjusting. Some of those compressed sentences make you stop and read twice; a fragment can carry more meaning than it first lets on, and you spend the saved second decoding it. But the trade lands well in my favor. I get to the point faster, the context window fills slower, and if a line is genuinely unclear there’s always the escape hatch: ask it to expand. It never minds.

That mode is the smallest possible example of the thing this whole post is about. Claude Code out of the box is generic. It’s built to be reasonable for everyone, which means it’s optimal for no one. The leverage isn’t the model itself — you can’t change how good it is, only which one you run. The leverage is in bending the tool around your own loop.

The trap

Customization isn’t free, and I want to be honest about the bill. You can pour weeks into a setup nobody else can read, including future you.

The tools that took configurability furthest are the ones everyone reveres: vim and git. Deep, powerful, endlessly tunable. And, I’d argue gently, not actually that accessible. The depth is both the point and the price. Vim is the only tool I know with a meme about how to quit it — that should tell us something.

I hear the objection most about git: “but git is so easy.” Is it, though? It’s easy right up until your first real merge conflict, or the afternoon you rebase the wrong thing and quietly rewrite your own history with no clean way back. Yes, you can see where you’re trying to get to. So can someone holding the box for a fifty-thousand-piece puzzle, the finished picture printed right there on the lid. Seeing the goal is not the same as the path being accessible. Those are different claims, and we keep mixing them up.

Here’s the belief, stated plainly instead of as a complaint: a great tool should be as accessible as it can possibly be, and then, having earned that, offer infinite depth to anyone who wants to dig. The accessible part is the whole job, not a consolation prize for beginners. Depth is the bonus you add on top.

My bar for any Claude Code customization is one question: would I hand this to a teammate without an hour of briefing? If the answer is no, it usually doesn’t survive. My stack stays simple and stupid on purpose. Here’s what’s left after that filter.

What earned a slot

The terse output mode. Covered above. The single highest-leverage change, because it touches every response. Less to read, fewer tokens burned, longer-lived context.

The statusline. This matters more than it sounds. I usually have several things going at once, and I lose track of where I am — which repo, which task, how much budget I’ve got left. My statusline shows it all in one strip: the model I’m on, how full the context window is, where I stand against my 5-hour usage limit (Claude Code caps how much you can run in any rolling five-hour window), and my current directory. No clicking, no guessing. I glance down and I know my situation. For anyone juggling more than one thing at a time, it’s the cheapest sanity I’ve bought.

The settings layer. This is where it gets personal, and where the options never end. My config plays a sound when Claude finishes so I can look away and get pinged back. It fires OS notifications. You can have it log the purpose of each session, track tokens and cost, whatever you decide is worth knowing. There’s no “right” setup — the point is that the hooks exist (little commands the tool runs automatically at set moments, like when it finishes) and you bend them to your purpose. Mine is “tell me when you’re done.” Yours might be something else entirely.

None of these is clever. That’s the point. Each one removes a small, daily friction, and none of them needs explaining.

The actual wiring

The sound is a Stop hook in settings.json:

"hooks": {
  "Stop": [{ "hooks": [{
    "type": "command",
    "command": "afplay ~/.claude/sounds/done.mp3",
    "async": true
  }]}]
}

async: true so it never blocks the session, and afplay is just the built-in macOS player — swap in whatever you like.

The statusline is barely more than that. Claude hands your script a blob of JSON on every render; the script prints a line. You point at it once:

"statusLine": {
  "type": "command",
  "command": "bash ~/.claude/statusline.sh"
}

and the script reads whatever fields it cares about off stdin:

input=$(cat)                                                  # session state, as JSON
model=$(jq -r '.model.display_name'                          <<<"$input")
ctx=$(  jq -r '.context_window.used_percentage // 0 | floor' <<<"$input")
fh=$(   jq -r '.rate_limits.five_hour.used_percentage // 0 | floor' <<<"$input")
dir=$(  jq -r '.workspace.current_dir'                       <<<"$input")

From there it’s just drawing strings. Mine renders a little colored bar for each percentage — green, then yellow, then red as it fills — and right-aligns the path, so the strip ends up looking like this:

Opus 4.8  xhigh  · CTX ████░░░░░░ 38%  · 5h ██░░░░░░░░ 21%        ~/dev/golfnext

(xhigh there is just the reasoning-effort level I keep the model at.) That’s the whole thing. No framework, no dependency to keep current. A shell script and a JSON blob.

What I won’t automate

More automation isn’t always a win. Some of it just moves the cost somewhere you can’t see, and those are the ones I leave switched off.

You can wire Claude to lint and format every file the moment it edits it. Sounds tidy. It’s the opposite. If a hook reformats a file right after the model touched it, the model’s picture of that file is now stale — so the next time it works there, it has to re-read the whole thing to catch up. You’ve traded a clean diff for a slower, token-hungrier session. I’d rather it just run the linter once, at the very end, when the thinking is done.

Same logic on automatic model fallback. You can have it silently switch to a smaller model when your first choice is busy. I don’t want that. I pick a model deliberately, usually because the task needs the bigger reasoning model — the one that pauses to work a problem through before answering. If it’s overloaded, I’d rather come back in two hours and write “pick this up again” than have something quietly hand my hard problem to a model that can’t carry it. Convenience isn’t worth a worse answer I didn’t notice I was getting.

The window should be a non-event

People talk a lot about managing the context window — compacting it (having the tool summarize the conversation so far to free up room), watching it, nursing it along. I try to never be in that conversation.

The way I avoid it is structural: push the heavy lifting onto subagents — separate helper instances of Claude Code, each with its own private context — and keep the main thread clean. A subagent goes off, burns its own context reading and searching, and hands back the short answer. The main session stays light. Done right, I almost never reach for compaction, because I never let the window get full in the first place.

But here’s the honest part: I think the fact that any of us has to know this is a smell. Nobody should need to understand context windows to start being productive with this tool. It’s a current limitation wearing the costume of a skill. A few years from now I’d bet it’s abstracted away entirely, and we’ll talk about it the way we talk about managing our own RAM — which is to say, we don’t. I optimize around it today, and I try not to mistake working around a limitation for something worth teaching.

Can I prove it? Not with numbers. I don’t have a clean before-and-after, and I distrust anyone who quotes a tidy percentage for this. What I have is a feel: the window fills slower, the budget stretches further, sessions stay light longer. It’s subjective, and I’d notice the moment it was gone.

How to find your own

The hard part isn’t configuring anything. It’s knowing what’s even possible.

Claude Code moves fast — it feels like ten new commands a week. So fast that the model itself can’t keep up. I’ll ask it about a real slash command — “what does /goal do, can you explain?” — and it has no idea the command exists. There’s something funny about that: the most capable thing I work with often can’t tell you about features that shipped after its training cutoff. It’s behind on itself, in the most literal way. You can’t just ask the model what it can do. You have to go look — read the changelog, skim a guide, point it at the open web where the fresh stuff actually lives.

The next thing I want to try isn’t a setting at all. I keep half a dozen projects in flight, so I’m going to build one small meta-repo: a single place that points at all of them, that anyone — not just me — can navigate. Same instinct as everything else here: if it only works for me, it doesn’t really work.

That’s the whole filter, in the end. Take the two or three things that kill a real, repeated friction. Leave the rest, however clever it looks. The goal was never the most elaborate setup. It was the one you’d still be happy to hand to someone else.

The Loop Debate Is a Bad Word for Autonomy

Johann Böhler — Wed, 24 Jun 2026 00:00:00 +0000

There’s a genre of post going around right now. You’ve probably seen it. “I don’t write prompts anymore — I design loops.” “Loop engineering is the new prompt engineering.” I read these closely — I’m trying to learn this as fast as anyone, and the people writing them are usually well ahead of me. But I keep coming away with the same itch: I can’t quite map the word onto what I actually do all day.

I run Claude Code most days. For people who haven’t met it: Claude Code is Anthropic’s coding agent — you give it a task in the terminal and it reads files, writes code, runs tests, and iterates, instead of just handing you a snippet to paste. The capability is real and I lean on it hard. What trips me up is the vocabulary, so I tried to ground it.

I did the boring thing: I tracked everything. Every real task I ran through Claude Code got two numbers next to it — what it cost in tokens, and a rough estimate of what the same work would have cost by hand, in time. A month of rows. It’s the least glamorous artifact imaginable, and it’s the thing that finally made the “loops” debate click into place for me.

What clicked — for me, at least — is that a lot of the argument is about the wrong word. “Loop” isn’t the thing. Autonomy is. And autonomy doesn’t arrive as a switch you flip; it arrives one task at a time, which, if you were around for the last big architecture argument, should feel oddly familiar.

“Loop” is four different things

Part of why the debate feels muddy is that “loop” is doing at least four jobs at once, and people argue past each other because they’re each holding a different one.

There’s the agent loop — think, act, observe, repeat. This is just how an agent works. It reads the situation, takes an action, looks at the result, decides what’s next. It has always existed. It’s not a technique, it’s the definition.

There’s Ralph — the bash hack. It’s the community’s name for the crudest possible loop: wrap the agent in a literal while loop in your shell and let it re-run the same prompt until it declares itself done. (The name is just folklore; the technique is the point.) Crude, occasionally effective, the duct tape of autonomy.

There are the features — slash-commands like /loop and /goal, baked into tools like Claude Code. They wrap that same idea in something more controlled than a bash one-liner.

And there’s “loop engineering” — the philosophy. The discourse. The posts.

Four different altitudes, one word. No wonder it’s confusing.

But here’s the thing they all share, the line every one of these repeats in its own dialect: goal, verification, stop condition. That trio is the actual substance. Everything else is which layer someone happens to be staring at.

Make it concrete. Take the most boring useful thing I automate: addressing review comments on a pull request.

Goal: resolve every review comment on this PR.
Verification: CI is green, and every comment thread is actually addressed — not “I think I fixed it,” but the check passes and the thread is closed.
Stop condition: no open comments left, or it hits an iteration cap and hands back to me.

That’s a loop. It’s also just a task with a clear definition of done and a rule for when to quit. The trio is the whole game.

And notice what makes that example work: a machine, not me, can tell whether the goal is met — the check is green or it isn’t. That’s what I’ll keep calling verification — an automatic, judgment-free signal that the work is actually done. Hold onto the word. How much of it a task has is the thing that decides everything later.

It’s not loops. It’s autonomy.

Here’s the part it took me a while to see. Read those three criteria again — goal, verification, stop condition — and ask: does anything in them change based on whether I press enter between each step, or a harness (the script or tool wrapping the agent) does it for me? No. Nothing. The goal is the goal, the verification is the verification, the stop condition is the stop condition; they’re identical whether a human advances each iteration or a script does. The only variable is who turns the crank between steps — and that isn’t a question about loops at all. It’s a question about autonomy: how much you trust the thing to keep going without you in the chair.

Which makes sense once you see how little there is to a loop — near enough, it’s this:

while not done:
    observe()              # look at where things stand
    act_toward(goal)       # take the next step
    done = verified()      # the stop condition: is the goal actually met?

That’s the whole thing. So “should I be designing loops” is a bit of a category error — the loop is trivial, a while and an if. The hard parts hide behind the word, and there are two of them. The first: how far are you willing to step back from a running process? That’s trust. The second, the one I almost never see named: once you do step back, where does the thing actually run, and can you afford to run it there? That’s infrastructure — and unlike trust, it isn’t really up to you yet, because the cheap, standard place to run autonomous agents doesn’t exist.

What the work actually costs

That second question — can you actually afford to run it — is the one nobody seems to blog about, probably because almost nobody thinks to measure it. So I did. My day-to-day with Claude Code is attended — I run it on my own machine, with me in the chair. But the number I wanted was the other one: what the same work would cost metered, pay-per-token, the way you’d have to pay to run it in the cloud without me babysitting it. That’s the expensive lane, and it’s the one that decides whether unattended is even on the table. So for a month I logged the metered cost of every real task, next to an honest estimate of how long it would have taken me by hand.

Two hundred and twenty tasks. About $1,360 in metered cost — and, by my own estimate, close to 540 hours of equivalent by-hand work. Five hundred and forty hours is the better part of three months of full-time engineering. It went out the door in one.

Put any reasonable number on an engineer-hour and that metered $1,360 stands against work worth twenty to forty times as much — around thirty at a normal loaded rate, counting salary plus overhead rather than take-home. I don’t need the multiplier to be exact: halve my hour estimates if you think they’re generous and it’s still an order of magnitude.

The shape of the spend matters as much as the size. The median task cost $2.45. Two-thirds of everything came in under five dollars — bug fixes, small features, flaky-CI config, dependency bumps. The expensive runs are rare and they’re the meaty ones: a full feature, built end to end, lands in the tens of dollars, and the biggest single rows are features in the $40–55 range. Stack several rounds of review on one of those and a complete change lifecycle can clear $100. Those are the outliers, not the norm.

The part that decides where to start: I tagged the rows that are pure review-and-fix work — addressing PR comments, fixing a failing build, resolving conflicts. That whole category was under a tenth of the total spend — most tasks a few cents to a couple of dollars, half of them under a dollar. And it rarely needed much from me. The comments are bounded, the fix is usually local, and the verification is already wired: the build is green or it isn’t. It’s the most checkable, lowest-judgment part of the cycle, which makes it the obvious first thing to let run on its own.

The real money leak isn’t the price of any one task. It’s churn — runs that burned effort on something that didn’t need it. A change that should have cost twenty dollars cost a hundred because I let it grind on a problem I should have just steered it through. That waste, not the per-task price, is the thing worth engineering against.

The scary number is mostly a metering artifact

There’s a version of this where someone sees that monthly total and recoils. “You spent how much on an AI?” And I get it — $1,360 a month is a genuinely alarming figure.

But it’s mostly an artifact of how it’s counted, not of what the work is worth — and it isn’t even what I pay. The $1,360 is the metered figure I measured. My actual bill is the flat subscription I run this on: a mid-tier “Max” plan, used at a normal pace — not a hammer-everything-through-the-model, let-me-Google-that-with-Claude-too pace, just steady real work — about €110 a month, call it $120. Same keystrokes, same output, same month of work; the metered figure is roughly ten times the subscription one, purely because of how it’s billed.

And here’s the bit that quietly defuses the whole cost panic: you work attended anyway. You’re sitting there. You’re steering. The expensive, unbounded, “oh god what is it doing” scenario is the unattended one — the agent grinding away on its own while the meter spins. Which is exactly the thing you’re least ready to trust in the first place.

So the two big worries — “it’s too expensive” and “I can’t let it run on its own yet” — turn out to be the same frontier seen from two sides.

So what do you actually build?

Not an autonomous loop — not yet, and not for most of it. What I build instead is a human-triggered chain of skills, where “skill” just means a named, reusable task you can hand the agent, like a saved command. One of mine babysits pull requests: after I open a PR I kick it off, and it watches for the things that need a response — a new round of review comments, a failing build — and works them until the PR is green or it hits something it can’t handle and taps me on the shoulder. I start it; it doesn’t start itself.

The interesting part is what doesn’t run the model. The watching is a plain shell loop polling GitHub every few minutes for a handful of cheap signals — open unresolved comment threads, the CI status, whether the PR’s been approved — and it only wakes the agent when that set actually changes:

# the watcher is dumb and free — no model in this loop
while pr_is_open; do
    signals="$(unresolved_threads)::$(failing_ci)"   # cheap GitHub calls
    if [ -n "$signals" ] && [ "$signals" != "$last" ]; then
        wake_agent "$signals"     # the only line that spends tokens
    fi
    last="$signals"
    sleep 600                     # 10 min; an idle PR costs nothing
done

The agent only spins up when that set changes, and even then it does the bounded thing — read the new threads, fix the worthwhile ones in the working tree, tell a “my code is broken” build apart from an “infra fell over” one — then goes back to sleep. The expensive part, the model, sits gated behind the cheap part, a script that knows how to read a status. That gating is most of the trick to keeping these things affordable.

Mine is the pragmatic version, though, not the gospel one. Point it at someone else’s repo and it needs real guardrails. A PR comment is untrusted input, which turns an open watcher into a prompt-injection surface: someone can leave a comment steering the agent toward something that has nothing to do with the PR, or just spam comments to keep waking it and quietly run up the bill. Past the toy stage you’d want a classifier deciding what’s even worth acting on, and an escalation path — an OS notification, a Slack ping, a ticket — for the things it shouldn’t touch on its own. But you can get a surprising distance on the raw signals alone; “open, unresolved comments plus CI status” is already enough to be genuinely useful.

And the shape generalizes. Another one I keep meaning to finish: a weekly job that scans the open Dependabot and Renovate pull requests, merges and tidies the boring ones where nothing real has to change, and escalates the rest — the bumps that need an actual refactor, or where an API might break under you. Same skeleton every time: a cheap trigger, a bounded job, and a clear line where it hands back to a human. Building those loops, and the small toolkits around them, is quietly becoming its own kind of software engineering — less “prompt the model,” more “design the harness the model runs inside.”

Two rules I’d carve in stone before building any of it. First: release is not a job for the model — it’s your CI/CD. Don’t teach an agent to do the thing your pipeline already does for free, deterministically, with an audit trail; that’s not autonomy; it’s reinventing a solved problem. Second: monitoring is not a job for the model — it’s Sentry and Grafana. Don’t pay a brain to watch a dashboard; wire the alert back to a trigger so the agent gets handed the problem only when something has actually broken. And whatever you build, cap the fix loop — a hard iteration limit plus a human “good enough, ship it” gate — or that $20 fix quietly becomes a $100 one while you’re at lunch.

None of this is timidity. Human-in-the-loop is simply how you start: you loosen the leash one iteration at a time, as your own skills sharpen and, more importantly, as your verification gets good enough that you’d trust the result without standing over it.

We’ve had this exact argument before

If all of this feels familiar, it’s because we ran the entire play a decade ago. It was called microservices, and I was there for it. Quick recap if you missed that era: around 2014, teams started chopping big single applications — “monoliths” — into lots of small, independently deployable services. The loud argument was how small they should be.

The froth is identical. Back then the unanswerable question was “how small is a microservice — can it be 200 lines?” Today it’s “Ralph or /goal, and how many agents?” In both cases it’s a community sizing-debating its way through a thing before anyone yet knows what actually matters.

The good practice predated the name, too. We were splitting systems by domain — clean seams, owned boundaries — long before anyone said “microservices.” And the agent loop plus a verification harness existed long before anyone branded it “loop engineering.” The name showed up and took credit for work people were already doing.

And then it settled. The honest retrospective on microservices isn’t “we revolutionized everything.” It’s “we mostly kept building the way we already built, with cleaner seams.” Most teams went from a monolith to two or five services, not one to two hundred overnight. The change was real and it was undramatic, because most of what we built was already small.

But here’s the correction that actually matters, the part the sizing-debate missed at the time. For microservices, the real delta was never the pattern. It was the substrate. Containers, then the cloud, then Kubernetes made small, independently deployable services cheap and standard to run. The pattern was downstream of the infrastructure — and the infrastructure showed up to meet it.

For loops, we’re only halfway there. The capability substrate has arrived, and it’s the model. One row on my sheet is a feature I’d have budgeted two days of hand-work for, delivered for about fifty dollars. That was flatly impossible two years ago, at any price, with any loop. The loop didn’t change; the thing inside it got good enough to trust with real work. That’s the containers moment — the raw capability landing.

What hasn’t arrived is the rest of the stack. There’s no cheap, standard, safe place to actually run autonomy unattended — no equivalent of the managed cloud and Kubernetes that turned “I have a small service” into “and here’s the obvious, affordable place to run it.” Nothing yet says “let this agent grind on its own overnight without it costing a fortune or going off the rails.”

So: the model is the containers; the Kubernetes hasn’t been built yet. And “loops” — the philosophy, the sizing wars — is the nanoservices froth all over again: the “how absurdly small can we make it?” overreach, playing out on a stack that’s still missing its bottom half.

Autonomy is granular, not a switch

Which brings me back to where I started. You don’t flip from “I watch everything” to “it runs itself.” Nobody went from one service to two hundred in a weekend, and nobody sane is going from attended-everything to autonomous-everything either.

The leash comes off one verifiable task-class at a time, gated by exactly one thing: how checkable the verification is. It’s already happening. A PR-watcher that auto-fixes failed builds is the leash already off — on a narrow, bounded, machine-checkable class where the cost of being wrong is low and a green check tells you the truth. Meanwhile feature design and production changes stay leashed for a long time, maybe forever, because the verification is judgment and judgment doesn’t fit in a CI check.

So when you read “I design loops, not prompts,” understand where it’s coming from. It’s not a lie. But notice who tends to say it: people at the big AI labs — the ones building these models — or with effectively unlimited token budgets, or both. For them the missing substrate isn’t missing; the meter doesn’t apply the way it applies to you. “Just run loops” is a perfectly honest description of their reality. It’s frontier-reporting: true where it’s reported from, with the best tooling and the most checkable problems, sold as a universal prescription it isn’t yet for anyone working against a real budget.

So I’m not tuning out the debate — I’m tuning out the word. I build the attended chain, harden my own skills and verification, and let each task-class earn its slack one check at a time. That’s the part I can act on today, while the rest gets argued out.

Which is the same move that turned out right with microservices: clock the froth, let the sizing wars run, and keep shipping the boring version that actually works.

A clean machine

Johann Böhler — Tue, 23 Jun 2026 00:00:00 +0000

In the last post I set myself a goal for the first ninety days: a five-minute cold start. Fresh laptop to running code in under five minutes — clone the project, run it locally, hit a live endpoint, pass the tests, all before your coffee goes cold. The shortest honest path from a new hire’s first morning to their first real contribution. That’s the on-ramp I want to build for the team at GolfNext, the Danish golf-tech company I’m about to join.

Before I can hand that to anyone else, I owe it to my own machine. A new job means a new MacBook is on the way, so I pointed the same goal at myself first.

The two-year-old bookmark

About two years ago, a dotfiles repo rolled past in my GitHub timeline — the feed of what the people you follow are working on. It belonged to Manuel Brandstetter, a former colleague and one of the best engineers I’ve worked alongside. He took over as lead of scrumlr.io, the open-source retrospective tool I helped build, after I left inovex, the German consultancy where we’d worked together. So when his setup scrolled by, I stopped to look. No grand pitch, just there in passing: everything that makes a laptop his laptop, version-controlled in one place. I remember thinking, clearly and out loud, “I should do that.” Then I didn’t. For two years.

If you’ve never kept dotfiles: they’re the small config files that quietly shape your machine. Your shell setup, your editor settings, your git config — the dozens of little preferences you’d otherwise rebuild by hand, from memory, every time you get a new computer. A dotfiles repo puts them under version control so the machine becomes reproducible instead of hand-crafted and forgotten.

The reason I never got around to it is the boring one: it always felt like an afternoon I could spend on something more urgent. The thing about a brand-new laptop, though, is that it removes the excuse. You’re going to set the machine up anyway. You may as well set it up once, properly, in a way you never have to repeat.

The audit I run every December

There’s a habit I’ve kept for years. Somewhere in the quiet week around Christmas, I sit down and audit my tools. Am I still using the best thing for each job, or just the thing I happened to pick three years ago and never questioned? It’s usually a solo afternoon — reading changelogs, half-remembered Hacker News threads, a bit of “what’s everyone else using now.”

This year had a running start. A few weeks earlier I’d gone looking for something like nvm, but for every runtime, not just Node: Python, Go, Java, the lot. I found mise, which does exactly that, and swapping a drawer full of per-language version managers for a single one was the most satisfying thing I’d done to my setup in months. That small win, I suspect, is what quietly tipped a two-year-old “I should do that” into “do it now.”

So this year I ran the audit as a conversation instead. I pointed Claude — Anthropic’s AI assistant, the same one I’ll be building with at work — at my current setup and asked the blunt version of the question: what here is dated, what’s missing, what would you change, and why. Then I let it research and argue its case.

I kept the result honest by making it a diff. The old setup stayed on my main branch; the reviewed one went on a branch I called cleanup. So every recommendation was a line I could read, accept, or reject, not a black box rewriting my machine while I wasn’t looking. That framing mattered more than I expected. A review you can read line by line is a review you actually trust.

Two things came out of it: a way to treat the whole machine as one repo, and a short list of tools I’d been silly to skip.

chezmoi: the machine as a repo

The manager is chezmoi. It tracks your dotfiles in a git repo and renders them onto any machine you own — chez moi, fittingly, French for “at my place.”

What sold me over a plain folder of symlinks is the model. The files in the repo are the source of truth; you apply them to write the real files into your home directory. Edit, preview the diff, apply, commit. It templates (one file can adapt to a work machine versus a personal one), and it keeps secrets out of the repo entirely — my SSH keys stay inside 1Password, handed to git on demand, never written to a file chezmoi could accidentally commit.

The part that finally delivered on the two-year promise is the bootstrap. On a clean Mac, the whole machine comes back from three commands:

brew install gh chezmoi
gh auth login                              # sign in to GitHub in the browser
chezmoi init --apply bitionaire/dotfiles   # clone + render everything into place

That last line clones the repo, installs my shell framework, lays down every config file, and runs a set of first-time setup scripts. One naming convention does most of the magic: a file called dot_zshrc in the repo becomes ~/.zshrc on the machine. dot_config/ghostty/config becomes ~/.config/ghostty/config. The dot_ prefix is just chezmoi’s way of writing a leading dot without confusing your file browser. Once that clicks, the repo reads like a mirror of your home directory.

The tools the review actually changed

I already ran oh-my-zsh with the powerlevel10k prompt. The review pushed three additions hard, and was right about all three:

Ghostty — a fast, modern terminal. I’d been on the macOS default for years out of pure inertia. Ghostty is quicker, themeable in a plain text file (which means chezmoi can track it), and renders the powerline glyphs my prompt uses without a separate Nerd Font install.
fzf — a fuzzy finder, and the one that changed my day-to-day most. Ctrl-R turns shell history from a blind up-arrow hunt into a live fuzzy search. Ctrl-T drops a file path into whatever you’re typing. Pipe anything into it — git branch | fzf — and you get an interactive picker for free.
zoxide — a smarter cd. It learns the directories you actually use and lets you jump by a fragment of the name. z dot lands me in my dotfiles repo from anywhere on the machine, no matter how deep it’s buried.

None of these are exotic — they’re tools a lot of terminal-heavy people already swear by, and I’d simply never sat down to add them. Wiring them in is a few lines of shell config:

# fzf — fuzzy finder (Ctrl-R history search, Ctrl-T file picker)
command -v fzf >/dev/null 2>&1 && eval "$(fzf --zsh)"

# zoxide — smarter cd (`z ` jumps by frequency + recency)
command -v zoxide >/dev/null 2>&1 && eval "$(zoxide init zsh)"

Automating the parts I used to click through

A fresh Mac isn’t just dotfiles. It’s an afternoon of downloading apps, dragging them to Applications, and clicking through the same System Settings toggles you’ve set on every Mac you’ve ever owned. That’s the part the review automated, and it’s the part I’m proudest of.

Apps come from a single Brewfile — a manifest Homebrew reads to install everything in one shot:

brew bundle --file=Brewfile   # installs every CLI tool, app, and App Store entry

One file lists the command-line tools, the desktop apps (1Password, Firefox, Ghostty, Docker, the editor), and even Mac App Store purchases. New machine, one command, twenty-odd apps install themselves.

Then there are the macOS settings. chezmoi runs setup scripts on first apply, and one of them is just a list of defaults write commands — the scriptable side of System Settings. A taste:

defaults write -g KeyRepeat -int 2                            # fast key repeat
defaults write -g ApplePressAndHoldEnabled -bool false        # hold a key to repeat it
defaults write com.apple.finder AppleShowAllFiles -bool true  # show hidden files
defaults write com.apple.finder _FXSortFoldersFirst -bool true  # folders on top

I’d set every one of these by hand on every Mac for a decade and never thought to write them down — now they’re a file. It isn’t total. Apple deliberately blocks scripting the security-sensitive bits, so granting accessibility permissions and signing into iCloud stays manual. But the dozens of little toggles that used to eat an afternoon now take seconds, and I’ll never have to remember them again.

A good review cuts as much as it adds

The surprise was how much the conversation talked me out of. A tool audit isn’t only about new toys; it’s about noticing the cruft you’ve been carrying.

So the cleanup branch deleted things. The handful of older version managers I’d accumulated, plus a hand-installed Python, all folded into the one mise I’d adopted a few weeks before. A shortcut I’d wired up to work around an old Docker quirk that’s since been fixed — gone. A tangle of work-versus-personal git config I’d accreted across jobs, flattened back to a single identity. Each of those was a small decision I’d made years ago for a good reason, then never revisited once the reason expired.

That’s the real value of doing this with a sparring partner. Left alone, I tend to add. Asked to justify each piece out loud, I finally removed.

What I’m taking from it

The impressive part wasn’t that an AI can write a config file — everyone knows it can now. It was the review. It didn’t hand me a generic “best setup”; it looked at mine, asked what I actually do all day, and argued for changes that fit, with the reasoning attached so I could push back where it was wrong. Less a tool than the December audit I already run, with someone knowledgeable sitting across the table.

And it closed a loop. The five-minute cold start I want to give the GolfNext team is this same thing, scaled up: a new person, a new laptop, and a short path to real work without a week of setup tax. I built the personal version first.

So if you’ve got your own “I should do that” bookmark gathering dust — a repo that once scrolled past in your timeline, maybe — this is your sign. Wait for the next clean machine. Then set it up once. Two years late still beats never.

References

The tools and docs worth bookmarking, roughly in the order they show up above:

chezmoi — dotfiles manager. Start with the quick start and the user guide.
Homebrew and the Brewfile / brew bundle — install apps and CLI tools from one manifest.
oh-my-zsh — Z shell framework, with the powerlevel10k prompt theme.
Ghostty — fast, config-as-text terminal.
fzf — command-line fuzzy finder.
zoxide — a smarter cd that learns your habits.
mise — one version manager for node, python, go, and the rest.
1Password SSH agent — keep private keys out of the repo and off disk.
The repo that started it: Manuel Brandstetter’s dotfiles.

P.S. — a Dock trick that has nothing to do with dotfiles

One freebie for the Mac users who made it this far. It has nothing to do with any of the above, but it’s the kind of small thing that’s quietly pleased me for years: you can drop blank spacers into the Dock to break your apps into clusters. Same defaults write trick as the rest of the post. Run it once per spacer you want:

# full-height spacer (run again for each extra one)
defaults write com.apple.dock persistent-apps -array-add '{tile-data={}; tile-type="spacer-tile";}' && killall Dock

# half-height spacer (run again for each extra one)
defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="small-spacer-tile";}' && killall Dock

Drag the spacers around like any other Dock icon, or drag one off the Dock to remove it. Tiny thing. Makes a crowded Dock feel organized.

A letter to myself, before day one

Johann Böhler — Mon, 22 Jun 2026 00:00:00 +0000

“I may have something of interest to you, Johann. Would be great to connect 👍🏼.”

That’s the whole message. It arrived on LinkedIn out of nowhere, from a recruiter named Joe — which, given how often these things come in under a borrowed first name, might even be his real one. No company, no role, no details. The kind of message you’d normally archive without a second thought.

This one ends with me leaving a job I like, at a company I have nothing bad to say about, for a company whose name Joe wouldn’t even tell me. I had to find that out myself. Well — myself, and an AI.

I’m writing this before my first day of work. I haven’t signed the contract yet; I don’t even know my start date. Writing the company blog before I officially have the job sounds backwards. Maybe it is. I’m doing it anyway, because I’m carrying around more thoughts than I can hold, and because I want a record — something to read back in six months and hold up against whatever actually happened.

So this is two things at once. The story of how a two-line message turned into a job, and a letter to a future version of me.

A confession before we start: I’ve never written a blog post in my life. I’m starting now on purpose — writing pins down ideas that are otherwise just vapor. So here I am, thinking out loud.

From three breadcrumbs to a company

I asked Joe what his message was about. It turned out to be a Lead Engineer role at a small but established company: the first cornerstone of an AI-first development team — one that builds software mostly by directing AI instead of typing every line by hand. Joe wouldn’t name it. He gave me breadcrumbs instead — Danish sports tech, around since 2012, 400+ venues across 18 countries.

So I handed the breadcrumbs to Claude, Anthropic’s AI assistant. In seconds it named the company: GolfNext, in Ry, a short drive from where I live in Denmark. They make the self-service kit golf clubs run on — more on that later.

That little exercise is more or less the job description. If you can point an AI at three vague clues and have it reconstruct the company behind them, that’s the work. So I replied with a fully AI-generated message, openly labeled:

“Full disclosure, Joe: this reply is AI-generated. Felt fitting for an AI-first pitch — and yes, I let the agent do the detective work too. 😄”

They wrote back. A few days later I drove out to Ry and spent an hour at the GolfNext office, and by the time I left I knew I wanted it. The tell was the first thing they said when I sat down: “Let’s just have a chat here and talk openly.” No theater.

Before committing, I wanted to know exactly what I’d be walking into, so I asked. Thomas Herskind, who runs product at GolfNext, sent over an overview of the systems they run today. I read it and wrote back with everything I thought was worth doing first, point by point. It ran long. Very long.

Thomas’s reply was six words. “Congrats on your first novel, Johann!”

I laughed out loud. You learn a lot about a place from how it teases you before you’ve even signed.

The 70 ideas before this one

None of which explains why a two-line message with no details got my attention in the first place. For that, I have to rewind a few months — and first tell you who’s writing, since this is the internet.

I’m a generalist. A full-stack engineer who never minded picking up whatever a project happened to need. Sixteen years in: a lot of backend, a lot of web apps, a few years leading a team, and co-creator of scrumlr, an open-source tool teams use to run retrospectives — those meetings where you look back at what went well and what didn’t. I’ve never been the engineer who loves technology for its own sake. What pulls me is the other end of the wire: the user, the design, the value, the thing that makes somebody’s day a little easier. And getting there without a lot of detours. That’s the CV in a paragraph. The itch is the part it can’t carry.

I’d had an itch for a while to build something of my own. Anything that might grow into a business, really — and an excuse to push Claude as far as it would go and find out how much real software it could actually build. The first project came out of a pet peeve I’d carried across jobs. Release notes — the “what changed” list that’s supposed to be for the people using the software — keep getting dumped into commit messages, the terse notes developers leave each other. “Upgrade ESLint to version 10.” Who is that for? So I built a small product that lets you write proper change entries in plain language, right next to the code, and hand them to the product managers who should own them. Built from scratch in about two weeks — the parts users see, the backend behind them, the pipeline that ships updates on its own. All of it, with AI doing most of the typing.

That felt good enough that I got greedy and reached for something much bigger: an agent that keeps software projects alive. Maintaining them, extending them, mostly on its own, with the release-notes tool as its first patient. That’s where I hit a wall, and the wall taught me more than most of my finished projects did.

Some of it was scope. I’d wrapped a full product around something that should have started as a small experiment. But the deeper lesson was about the tool. Today’s AI is genuinely brilliant at a blank page, and at small, well-bounded changes. It gets shaky the moment you ask it to tear into big chunks of core logic. It starts to hallucinate — confidently inventing things that aren’t there. It never quite cleans up after itself. Old context lingers and creeps back into the next attempt. A build that ambitious needs a clear plan for how you’ll get there before you write a single line, and holding that plan together on my own, in stolen evenings and weekends, just wasn’t something I could pull off. That project is parked, not buried.

So I changed tactics. I put Claude to work as a sparring partner on smaller things, the kind I could finish in a couple of weeks. I’d pitch an idea; it would go research the market and, more often than not, come back with the same answer — crowded, already funded, don’t bother. Painful. Also useful.

After about 70 of those, I stopped pitching and asked the obvious question: so what should I do? The answer was refreshingly blunt. Stop hunting for a clever product. Find someone with a real problem and help them build a software-driven process around it that saves them serious time. And since it knows how I work, it sketched out roughly what that would look like. A few months later, Joe’s two lines landed in my inbox — and the role behind them, once I asked, turned out to be a near-perfect match for that sketch. The message with no details was the thing I’d been told to go find.

What it’s actually about

High time I told you what I’d actually found. GolfNext builds self-service tools and hardware for golf clubs — picture a ball dispenser members work themselves at the range, or a system that takes the fiddly, error-prone business of selling and redeeming vouchers and makes it calm. For years, capable external partners built most of that software, and it carried the company a long way. The shift now, as they laid it out to me, is that GolfNext wants the engineering know-how to live inside the company: a team that understands the whole landscape from the inside, for the kind of steady, long-term growth that comes from owning what you depend on. No verdict on the people who built it so far — just the natural next step for a company that plans to be around for a long time.

I’m one of the first pieces of that. The brief: absorb the landscape — the same one Thomas previewed in that overview — take over development bit by bit, and before long help build a team around it.

Here’s a confession that sounds odd in an engineering blog: I’ve barely written code by hand in months. Call it half a year on my own projects, a couple of months at work. Not because I stopped building. The building just moved up a level. More of my day now goes into directing AI, reviewing what it gives back, and designing the guardrails that keep its output safe and correct. It’s where the craft is heading — and it’s exactly the team GolfNext is asking me to build. Nobody can honestly tell you where all this lands; the ground moves every few weeks. But the direction is clear enough to point at, and pointing at it is the job.

That’s the what. Before the how, there’s a goodbye I owe.

Leaving a good thing

First, the honest part nobody enjoys writing. Saying yes here means leaving Salling Group — one of Denmark’s largest retailers — and I don’t want a single word of this read as a complaint. Salling was the perfect first step when I landed in Denmark: a real culture, people who genuinely look out for each other, work I’m proud of. I shipped things that mattered, under deadlines with no room for error, next to engineers I learned plenty from. I made good friends there. Part of me is sad to go.

The reason I’m moving isn’t a flaw in the place. It’s a difference in what I’m built for. At a company that size, every decision gets weighed by a lot of thoughtful people, which is exactly how a big retailer earns and keeps people’s trust. But it means being close to the wheel is rare, and steering quickly rarer still. I want the wheel. I want to point at a direction and move. That itch is most of why I started building things on the side in the first place, and it’s precisely what this new role hands me. Leaving a good thing for the right reason is still leaving a good thing. Both are true at once.

The goals I’m setting for myself

Now for the how. The wall I hit on that side project is the whole reason the goals below look the way they do. If AI is strongest inside clear boundaries, the answer isn’t to prompt harder. It’s to build a landscape where the boundaries are obvious — where context is cheap to hand over, where a change is easy to scope small, where the guardrails catch what the model gets wrong before a human has to. Because that’s where I think this is all heading: the scarce resource in software becomes how fast anyone — human or AI — can pick up a context they’ve never seen. If a new engineer and a fresh AI session can both understand a service quickly, work can start immediately, by whoever picks it up. If they can’t, every task starts with archaeology. Most of what follows is really about that one sentence.

One disclaimer that matters: I haven’t started yet. These are the standards I’ll hold myself to, not decisions I get to make alone — the order and the priorities get worked out with the people who’ve been running these systems for years.

Make the work visible. This blog is goal one. When you’re building knowledge inside a team, the worst thing you can do is lock it away in private channels and individual heads. Writing it down in the open forces clarity, pulls in good people, keeps everyone honest. So it exists now. Future me: if these posts went quiet, take it as a warning sign.

Rebuild the understanding, not just the access. Taking over from an external team isn’t really about collecting credentials and passwords. It’s about rebuilding the understanding from the inside. So: every account checked and put in my name, every doc read and sharpened until I can operate and release anything in the stack without phoning a friend. That’s the unglamorous half of the ninety days, and it’s the half everything else waits on.

Build a landscape everyone can build in. This is the one I care about most. Concretely:

A five-minute cold start. Fresh laptop to running code: understand the project, run it locally, hit a live endpoint, pass the test suite, all in under five minutes. It’s the on-ramp to building and testing, not a rulebook for how to write code. Future me, this one is measurable — go time it.
Docs that live right next to the code, so context is one directory away instead of one Slack message away.
Automation for anything we’d otherwise do by hand twice.
Technical debt paid down where it’s genuinely in the way — not a spring clean, just the things standing in the road.
A shared kit of prompts and presets for the AI, so everyone starts from the same proven setup instead of rebuilding it each time. That’s what turns “AI-first” into actual shared tooling instead of a slogan.

The point isn’t to be the only people who can build. It’s to be the quality gate that turns a rough idea into something you can trust, and the helping hand that makes building safe and easy for everyone else.

Stay on the keys. I said this to Joe before I’d said it to anyone at GolfNext, because it would save us both time. I’ve led a team before, twenty-four people, and I stepped back to building on purpose. “If ‘Lead’ means setting technical direction while still building, I’m very in. If it means drifting away from the code, I’m the wrong guy.” That line started as a filter for the job. It’s a goal now. Future me: if you’ve drifted, you know what to do about it.

Hire excellent people, and then trust them. Not in the first ninety days, and not my call alone, but it’s where this is headed, and it shapes the early calls. A small team of excellent people needs almost no process. Keep the bar high even when you’re short-handed. That part, at least, isn’t me projecting my reading list onto them: when hiring came up in Ry, they told me they’d rather run short-handed for a few months than bring in the wrong person just to add capacity. It told me more about the place than any pitch could have. Hand people context instead of approvals. Judge the work, not the noise. Default to yes, and stop to debate only at the doors you can’t walk back through. And leave room — real room — to spitball, to argue, to build things that might not work. The creative, playful time isn’t a reward you earn once the serious work is done. In this line of work, it is the serious work.

A compass, not a rulebook

The goals are the plan. Underneath the plan sits a compass, and it’s worth showing you, because it’ll shape how I steer.

What I won’t show up with is a manifesto. I don’t believe a culture can be written into existence. It grows out of its environment and the people in it, day by day, in a thousand small moments nobody writes down — which is why it can only be led by example, never enforced. We’ll work out GolfNext’s actual values together, in the doing. And I mean together in both directions. I’ll arrive with convictions — this post is full of them — but I expect to be changed as much as I change anything, and to pick up ways of working I haven’t even considered yet.

Part of it I owe to inovex, the German consultancy where I spent seven years — the longest stretch of the sixteen. They had a triangle — Employees, Customers, Economy — and they meant every corner of it: fair pay, the freedom to choose the right tools for the job, sane and agile ways of working, genuine care for the people doing the work. Most of that I still hold to. My own emphasis just sits a little differently. Where their triangle puts employee happiness, mine puts Craft. Not because happiness doesn’t matter, but because I’ve come to think it grows out of doing great work together, rather than being something you can aim at head-on.

So the three points I steer by are Customer (the aim — solving the problem people would genuinely miss), Craft (the swing — building it well, and getting better by building it), and Capital (the long game — staying healthy enough to finish the round, and keeping the knowledge in the house so nothing important lives in a single head). Lean too hard on any one and you slice; get all three swinging together and the ball drops.

What I’ve been reading, and what I took from it

A fair number of the goals above — the high bar, the trust, the near-absence of process — I got from No Rules Rules, Reed Hastings and Erin Meyer’s book on how Netflix is run. The argument, compressed: push talent density up until you have a team of excellent people, use candor to keep them honest with each other, and then start taking the rules away — because most rules exist to stop bad outcomes from average performers, and once you haven’t got those, the rules cost more than they save.

The bit I keep coming back to is the expense policy. It comes down to a single instruction: act in the best interest of the company. That looks like a policy about receipts. It isn’t. It’s a statement about who’s responsible. A rulebook hands you an answer somebody else worked out once, for a situation that might not be yours anymore. One instruction hands you the goal and makes you work out the answer for the situation you’re actually standing in. That’s more weight to carry. It’s also what makes you a real part of the thing instead of an executor of other people’s decisions — and it’s where creativity and initiative come from. You don’t get an unexpected good idea out of somebody following steps.

The part that has to be practiced. None of that works without candor, and candor doesn’t come free — for anyone. The pull toward smoothing things over is universal, and caring without saying the thing is the failure mode that feels kind and isn’t. Take away the rules and keep the politeness and you don’t get freedom. You get a team quietly drifting, with everyone guessing.

So I read Radical Candor as well, Kim Scott’s book on exactly this — useful feedback needs both halves at once: you have to actually care about the person, and you have to actually say the thing. Hence this commitment, in writing, where anyone can hold me to it: expect me to be very clear about what I think, what I’ve decided, and why — including when the answer is that I got it wrong.

And yet — not a culture you can copy. One caveat over all of it. I don’t want to import Netflix’s culture wholesale. It grew out of a particular company, in a particular market, at a particular size, and plenty of what makes it work there doesn’t travel. The book’s famous sharp edge travels worst of all: the keeper test, where anyone a manager wouldn’t fight to keep is let go with a generous severance. I’d leave that part behind entirely. Talent density earned by hiring carefully is a different thing from talent density maintained by cutting — and an edge that hard has very American roots. It’s not how I’d want a small team in Denmark to feel. There’s just as much worth taking from how good people at companies like Google or Apple have built and run their teams — and those cultures disagree with Netflix’s in places, on purpose. Ours will be its own thing — worked out in Ry, not copied in from California. The real test of any of this is what everybody does when nobody’s enforcing anything.

Which lands back where the expense policy started. Don’t adopt somebody else’s rulebook. Adopt the habit of asking what’s genuinely best here, right now, with the people we’ve actually got — and stay willing to change the answer when the situation does.

A note to future me

By the time you read this, you’ll know everything I don’t. The start date. Whether those first ninety days went to plan. Which of these goals survived contact with reality, and which were sweetly naive. Some of it will look obvious in hindsight. Some of it will look funny.

I wanted it written down before the job could start shaping my answers — while it’s all still conviction, before it hardens into experience.

Thomas already joked that my first long reply to him read like a novel. Consider this post the sequel. Longer, and this time public. Let’s see how close I got.