Think back to the last new project your team started. How long between “we’re doing this” and the first line of code that actually mattered? A day? A week?
And more importantly: how much of that time went into decisions you had already made - somewhere else, in another repo, six months ago? Which folder structure. Which linter config. How CI runs. How auth works. How it deploys. Every one of those questions had an answer in your organization already. You just discussed them all again, from scratch, because there was nowhere to copy the answer from.
That is the moment a golden path exists to eliminate. My argument: starting a new project should be the most boring hour in engineering - and in 2026, boring is not just pleasant. It is a safety mechanism.
From components to whole projects
Back in 2020 I wrote a three-part series here about using hygen to scaffold Vue components. The pitch was simple: stop hand-writing the same component skeleton, generate it from a template, and every component in the codebase starts consistent.
Six years later I am making the same argument one level up. Instead of generating a component, you generate an entire project - frontend, backend, infrastructure - from template repositories with the conventions, the CI pipeline, and the security defaults already baked in. The principle never changed; only the unit of scaffolding grew.
The industry has a name for it now: the golden path - the opinionated, supported, automated route for building and shipping a service. One project structure. One CI setup. One deployment story. Zero decisions required to get moving.
Boring means “already decided”
“Boring” gets a bad reputation. Here it means something precise: when a new project starts, all the plumbing decisions are already made, and nobody spends creative energy re-deriving them.
What that buys you:
- Speed to the first real commit. The interesting work starts on day one, not day five.
- Consistency across repos. Every project looks familiar, so moving between them costs nothing. Onboarding stops being per-project.
- Security and quality by default. The non-root container, the linting rules, the dependency audit, the branch protection - shipped in the template means present in every project, including the throwaway one nobody reviewed.
- Fewer forgotten steps. The stuff that gets skipped under deadline is exactly the stuff a template already did for you.
And this is not theoretical. Teams that invest in a well-designed golden path see voluntary adoption above 80%; teams that treat it as an afterthought struggle to get past 20%. Nobody has to mandate a good path - people take it because it is genuinely the easiest route.
What belongs in the template - and what must not
The most common way to ruin a golden path is to put too much in it. A fat template rots, and a rotting template is worse than none because people copy stale decisions forward. Keep it thin and deliberate:
Belongs in:
- Project structure - the folder layout everyone already agreed on.
- Tooling config - linter, formatter, editor settings, engine/runtime version pin.
- CI pipeline - or better, a call to a shared reusable workflow, so the logic lives once (the same DRY argument I made for CI and for auth).
- Security defaults - non-root container, no debug endpoints, generic error handling, secret scanning.
- A README skeleton - the questions every project must answer, waiting to be filled.
Must not:
- Business logic. The moment a template contains domain code, it starts drifting from every project that used it.
- Anything that changes often. Fast-moving details belong in a shared package you can version, not in a snapshot copied at birth.
- Configurability for hypothetical needs. A template with fifteen options is a framework, and now you maintain a framework. YAGNI applies here more than anywhere.
The test I use: would I be comfortable if this line were identical in twenty repos two years from now? If not, it belongs in a versioned package, not in the template.
The part that changed in 2026: agents follow paths too
Here is why this old idea matters more this year than it did last year.
AI radically lowered the cost of starting. A service that took a week to scaffold now takes an afternoon - an agent can stand up a project, wire the CI, and open a PR before lunch. What AI did not lower is the cost of the sprawl that follows. Ten services scaffolded in ten different shapes, faster than any architecture conversation can keep up with, is not velocity. It is debt with better tooling.
An agent asked to “create a new service” will do one of two things: follow your paved road, or invent its own. Left to itself, it invents - plausibly, confidently, and differently every time. A golden path is the machine-readable version of your conventions. Point the agent at the template and the conventions come along; skip it and you are reviewing a fresh architectural opinion in every PR.
That is the reframe I would offer any team standardizing right now: templates are not bureaucracy, they are how you steer the machine. They were nice-to-have when humans typed everything. They are load-bearing when agents generate it.
Paved road, not prison
One important guardrail on all of this, because standardization curdles fast if it turns into policing:
- The path is the easiest route, not the only one. If a project genuinely needs something different, it should be allowed to leave - with a reason, not a permission slip.
- Keep it alive. A scaffolding wizard that ran once and was never updated is the classic failure mode. When the path improves, existing projects should be able to adopt the improvement - which is exactly why versioned shared packages beat copy-paste.
- Let the exceptions teach you. If three teams leave the path at the same point, the path is wrong there. Fix the road, do not scold the drivers.
The marked trail
Walk into a national park and you will find marked trails - blazes on trees, gravel underfoot, bridges over the streams that would otherwise soak your boots. Nobody built them to stop you from exploring. They exist because thousands of people walked this terrain before you and learned exactly where the ground is unstable, where the river is uncrossable, and where the beautiful view actually is.
You are entirely free to leave the trail. Experienced hikers do it all the time, on purpose, with the right gear. But they leave it knowing they left it - and they return to it when the bushwhacking stops being worth it.
A golden path is that marked trail. It does not exist to constrain your creativity; it exists so you spend your energy on the summit instead of on figuring out where to put your feet. And now that we have tireless machines walking these trails alongside us - fast, capable, with no memory of the terrain - laying down clear blazes is not bureaucracy.
It is how everyone, human and agent alike, ends up walking toward the same view.