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

21–30 of 37 posts

Re: Build Wide, Ship Narrow

#21

Post by jurgenburgen »

seer wrote: post #19
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 messag…

> 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.

It’s worse than that IMO. In over 10 years I’ve yet to have seen a team that even knows how to rebase, asking them to investigate commit logs or bisecting would be like teaching a cat to bark. Insisting on “good commits” (or even worse, conventional commits which is a poor solution to the wrong problem) is just adding bureaucracy where it’s least needed.

Re: Build Wide, Ship Narrow

#22

Post by k3liutZu »

cavisne wrote: post #14
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

[flagged]

Re: Build Wide, Ship Narrow

#23

Post by bluegatty »

jondwillis wrote: post #20
bluegatty wrote: post #18

Earlier quoted context omitted.

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…

Im sorry to hear that, keep your head on straight.

Re: Build Wide, Ship Narrow

#24

Post by thenthenthen »

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,…

Cast a wide net, focus on the most promising deals?

Re: Build Wide, Ship Narrow

#25

Post by seer »

jurgenburgen wrote: post #21
seer wrote: post #19

Earlier quoted context omitted.

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 messag…

> 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. It’s worse than that IMO. In over 10 years I’ve yet to have seen a team that even knows how to rebase, asking them to investigate commit logs or bisecting would be like teaching a cat to bark. Insisting…

Surprisingly enough I’ve encountered both kinds - people who don’t care a lot and despise any “mandatory commit rules”, and people who care _too much_ spending company time making their commits “perfect” which then nobody reads.

I think it’s like with code formatters - now we have a tool that does the tedious thing on its own and unlocks human creativity where it is warranted… at least in the ideal case.

Re: Build Wide, Ship Narrow

#26

Post by eru »

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,…

> Somehow, I think heavy LLM users don't really care about a clean git history / changesets? May be if the project or existing workflow you are bound to requires it you will do the extra steps but really I don't see it being done much.

Some do, some don't. Yes, it depends on a lot of what wider organisation you are trying to fit into.

Re: Build Wide, Ship Narrow

#27

Post by WillAdams »

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.

Cue the classic instance of Bill Atkinson writing "-2000 lines":

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

Re: Build Wide, Ship Narrow

#28

Post by bquaresma »

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,…

> Are you really going to review these small changes?

Yes! Now that the code is well structured, it's much easier for me to review. Of course, I'm not too nitpicky. I mainly focus on architectural changes that may have drifted from the initial spec or anything unexpected. I use those moments to understand what led to the implementation and what could be improved.

Those reviews usually teach me something, or I identify a gap that can be addressed by adding more context for the agent, usually in AGENTS.md.

I also spend some time checking whether the tests actually cover the scenarios I care about. When I come across a test and don't understand why it's there, it's usually a good signal that I should pay closer attention to that area.

Ultimately, what's most important to me is feeling confident when deploying changes, especially larger ones, to production.

Re: Build Wide, Ship Narrow

#29

Post by bquaresma »

seer wrote: post #19
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 messag…

This is a great point that I hadn't considered, and it's definitely valuable. I've used APM systems that track errors by version, Sentry being one of them, and I've found it very useful when those errors include context about which commit introduced the issue. It makes it much easier for both me and the LLM I'm using to identify and understand the root cause.

Re: Build Wide, Ship Narrow

#30

Post by bquaresma »

andreareina wrote: post #5
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,…

> Are you really going to review these small changes? So far the example I saw from agents are terrible. Full of drive-by, unrelated changes here and there. Mostly harmless or OK changes, but not focused. What I'm getting from tfa is that the point is to fix exactly this. Changes get packaged into focused changesets that make sense together. I've done this manually when working on a hairy feature, not splitting it in…

That should work well too.
Post reply on HN