Live data from Hacker News

Build Wide, Ship Narrow

adapt.com

31–37 of 37 posts

Re: Build Wide, Ship Narrow

#31
post #14
post #2

That was hard to understand. So the idea if I'm not mistaken is to iterate without constraint/move fast and break things (build wide). Demo the work, keep changing. Don't worry about the amount of changes, don't worry about nice commits. You are free to explore and produce as much changes as required. Then use AI agents to clean up the history and produce a nice change set that you can ship in a more traditional way,…

It reads as heavily written by AI

I wrote it myself and used AI to help polish the grammar, as well as improve some of the copy and tone. I also used it to review some of the ideas and claims I made. I can confidently say the content itself was written by a human, while the polishing was done with AI.

Re: Build Wide, Ship Narrow

#32
post #2

That was hard to understand. So the idea if I'm not mistaken is to iterate without constraint/move fast and break things (build wide). Demo the work, keep changing. Don't worry about the amount of changes, don't worry about nice commits. You are free to explore and produce as much changes as required. Then use AI agents to clean up the history and produce a nice change set that you can ship in a more traditional way,…

+1 on the hard to understand part. Just wondering how this manifests in the code.

This was one of the first blog posts I've written in decades. I'm definitely open to improving, though. Unfortunately, the codebase I've been working on over the past few months is private, but I'll see if I can share some real examples from it.

Re: Build Wide, Ship Narrow

#33
post #3
post #2

That was hard to understand. So the idea if I'm not mistaken is to iterate without constraint/move fast and break things (build wide). Demo the work, keep changing. Don't worry about the amount of changes, don't worry about nice commits. You are free to explore and produce as much changes as required. Then use AI agents to clean up the history and produce a nice change set that you can ship in a more traditional way,…

I find that after I implement a bunch of features, I look at the code and do a refactoring pass. It seems like it makes sense to do that kind of feature work on a branch? I don't know that you need to keep the branch history though, so maybe it could entirely rewritten or squashed?

[dead]

Re: Build Wide, Ship Narrow

#34

A bit bewildering but a small variation of this work: do a ton of experimental branches that you just don't merge. It's amazing how the AI can learn from branches that ran up against a wall. I don't think that you need to make wild iterations on the real product, just do it scratch space and 'merge the lessons not the code' This whole 'design up front' never worked well because it baked in to many bad assumptions. Th…

[flagged]

Re: Build Wide, Ship Narrow

#36
I work on a small team maintaining multiple services and this is very similar to our approach. Although I generally find review easier _without_ splitting every PR by backend/frontend. The additional context helps and you don't have to switch back and forth between two sets of files/changes to make sure the interfaces align. Good ol' feature branches are also useful when you have multiple interdependent breaking changes.

P.S. Bruno if you see this please skip the LLM fluff-up next time. It makes it hard to read.

Re: Build Wide, Ship Narrow

#37
Good breakdown. One thing this doesn't solve fully: narrow PRs make each diff reviewable in isolation, but five narrow PRs that each look fine on their own can still interact badly once they're all merged. There need to be checks pre-build, pre-release too amongst others.
Post reply on HN