Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build Wide, Ship Narrow

adapt.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Build Wide, Ship Narrow

#11

Post by sandeepkd »

smashed wrote: 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.

Re: Build Wide, Ship Narrow

#12

Post by moezd »

I see references to Pascal intensifying these days. Something like "Sorry I didn't have time to make it shorter".

Producing massive changes in a codebase has never been impressive. LoC has always been a bad measure of progress, and yet, modern frameworks, popular tooling and haphazard business logic almost dictates that you blurt out as many LoC as possible. Software engineering wasn't supposed to be this verbose.

Re: Build Wide, Ship Narrow

#13

Post by mey »

moezd wrote: post #12

I see references to Pascal intensifying these days. Something like "Sorry I didn't have time to make it shorter". Producing massive changes in a codebase has never been impressive. LoC has always been a bad measure of progress, and yet, modern frameworks, popular tooling and haphazard business logic almost dictates that you blurt out as many LoC as possible. Software engineering wasn't supposed to be this verbose.

I am most proud of the code I have deleted from projects and the code I have never written.

Re: Build Wide, Ship Narrow

#14

Post by cavisne »

smashed wrote: 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

Re: Build Wide, Ship Narrow

#15

Post by bluegatty »

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.

The experimental efforts help you work through those.

Once you've worked through it - toss them aside and then let the AI plan based on the scratch work.

The tangled stuff is in scratch space, that's what it's for.

And critically: it costs almost nothing.

The power of AI is not the 'nits and small bugs' - it's the firehose of scratch branches it can let loose in where it doesn't have to worry about PRs, reviews.

Once it's all figured out, then the path to the solution is actually relatively clear - and it can be 'planned out' and just done.

Re: Build Wide, Ship Narrow

#17

Post by mirmor23 »

bluegatty wrote: post #15

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…

> The power of AI is not the 'nits and small bugs' - it's the firehose of scratch branches it can let loose in where it doesn't have to worry about PRs, reviews.

> Once it's all figured out, then the path to the solution is actually relatively clear - and it can be 'planned out' and just done.

it is important to be clear about what this buys: quick coding and testing primarily.

the mental effort needed to design, manage the constraints and all other essential workflows to bring about a professional product is still present.

Re: Build Wide, Ship Narrow

#18

Post by bluegatty »

mirmor23 wrote: post #17
bluegatty wrote: post #15

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…

> The power of AI is not the 'nits and small bugs' - it's the firehose of scratch branches it can let loose in where it doesn't have to worry about PRs, reviews. > Once it's all figured out, then the path to the solution is actually relatively clear - and it can be 'planned out' and just done. it is important to be clear about what this buys: quick coding and testing primarily. the mental effort needed to design, man…

I don't agree on 1, partly yes on 2.

What it buys is a clear path through the mess without having to make it.

I'm saying: 'figure out the design and constraints by discovering them ... instead of trying to 'one-shot' them as a human'.

By the time you've run the gambit 100 times - you can synthesize the learning into something that's nearly complete.

Let the AI figure out the constraints, you just guide that. It can't do it in conversation, it takes a lot of iterative prodding.

But yes you have to decide where to steer it, and this only works for certain kinds of engineering at a certain scale.

Re: Build Wide, Ship Narrow

#19

Post by seer »

smashed wrote: 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,…

Actually I think it is the other way around - since very few people would ever read commit histories - maybe if something really bad happened and we need to trace the audit trail ~once a month or something per team.

But LLMs can traverse that tree at will in seconds and mine valuable info. Commits description value in my experience has shot up dramatically _with_ heavy LLM usage - they are forgetful and commit messages are just the right place to keep “context that might be needed, but not worth adding to the documentation corpus” - they are the “how did we get here” to the “current state” of docs files and code comments.

Re: Build Wide, Ship Narrow

#20

Post by jondwillis »

bluegatty wrote: post #18
mirmor23 wrote: post #17

Earlier quoted context omitted.

> The power of AI is not the 'nits and small bugs' - it's the firehose of scratch branches it can let loose in where it doesn't have to worry about PRs, reviews. > Once it's all figured out, then the path to the solution is actually relatively clear - and it can be 'planned out' and just done. it is important to be clear about what this buys: quick coding and testing primarily. the mental effort needed to design, man…

I don't agree on 1, partly yes on 2. What it buys is a clear path through the mess without having to make it. I'm saying: 'figure out the design and constraints by discovering them ... instead of trying to 'one-shot' them as a human'. By the time you've run the gambit 100 times - you can synthesize the learning into something that's nearly complete. Let the AI figure out the constraints, you just guide that. It can't…

Trauma dump/sign of the frothy times:

I got fired back in June for protesting against trying to “design everything up front” (by adding more slop plan docs alongside the hundred of others that my tiny team was charged with producing per month) and instead opting to explore the problem space through code/experimentation. In actuality, I just asked to be remote again. I was burnt out and they were looking for an excuse to fire me.

Post reply on HN