Rendered at 22:44:52 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
smashed 20 hours ago [-]
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, small clean commits.
That is an interesting idea I guess. AI agents can be used to clean up git histories, not only produce large amounts of code.
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.
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.
seer 16 hours ago [-]
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.
bquaresma 9 hours ago [-]
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.
jurgenburgen 15 hours ago [-]
> 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.
seer 15 hours ago [-]
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.
andreareina 19 hours ago [-]
> 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 into multiple pull requests but rebasing the history into (ideally) atomic commits that make sense sequentially.
bquaresma 9 hours ago [-]
That should work well too.
safety1st 19 hours ago [-]
If the agent's changes are terrible, the first thing I would look at is not the agent itself, but the context: spec, scope and prompting.
We generate an AI branch immediately every time a spec is completed. It then gets a brief review in our team meetings when the spec is introduced. We just take a few minutes to walk through what the AI did and take notes on what was insane and what was a good approach.
#1, this informs us about the actual quality of the spec, if the model did something wrong it will often become evident that the reason was an omission, ambiguity or contradiction in the spec.
#2, it saves the developer a lot of time, because in ~3 minutes we've usually established that at least half the code the model wrote was acceptable for use. Dev tasks look more like "Here's the implementation in concept, but pieces X, Y and Z will require your expertise to formulate a cleaner approach." And since AI tends to do a cleaner job at smaller scoped problems, it tends to be a great help to the dev at this stage too.
If anything I feel this process increases quality, not reduces it. It certainly speeds things up. Most major challenges and problems are immediately exposed by the model's proposed implementation. We don't have to wait for the developer's first cut to discover them. They go into the task knowing exactly what to focus on, and having the uncontroversial parts of their eventual PR essentially "pre-approved." The result is where we would have had to do multiple iterations of a feature, they often come back at the very next meeting having totally nailed it.
smashed 19 hours ago [-]
I was referring to what I observe working with various teams and open source projects using AI, not necessarily best practices or what a curated workflow can produce.
Even before LLMs, most teams don't bother cleaning up. The best you'll see is feature branch getting squashed on merge.
AI is not really a factor here. Teams/orgs that did not care before still won't, only 10x more.
bquaresma 9 hours ago [-]
> 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.
eru 14 hours ago [-]
> 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.
cavisne 17 hours ago [-]
It reads as heavily written by AI
bquaresma 9 hours ago [-]
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.
k3liutZu 15 hours ago [-]
[flagged]
skybrian 20 hours ago [-]
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?
butvacuum 19 hours ago [-]
Messy personal branch, pushed to a feature branch, squashed when merged with dev, bugs found in dev squashed when merged with main.
Seems to be the standard in shops with competent git users and no culure established around other version controll systems. What the commit messages are is fluid. My messy personal ones tend to be "start/end of day commit."
skybrian 18 hours ago [-]
Nowadays I'm just working on personal projects directly on main and 'git push', but my coding agent commits after every change it makes, resulting in a zillion commits. I suppose I could do it on a branch and ask it to make a nice history at the end.
bquaresma 9 hours ago [-]
[dead]
sandeepkd 18 hours ago [-]
+1 on the hard to understand part. Just wondering how this manifests in the code.
bquaresma 9 hours ago [-]
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.
antonvs 19 hours ago [-]
> That was hard to understand.
It was LLM written or heavily LLM processed. This, for example, is 100% LLM:
> Deciding boundaries up front was never about making the build easier. It was about making review possible, and it was the only affordable way to get there. That's the part that changed.
thenthenthen 15 hours ago [-]
Cast a wide net, focus on the most promising deals?
moezd 18 hours ago [-]
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.
WillAdams 12 hours ago [-]
Cue the classic instance of Bill Atkinson writing "-2000 lines":
I am most proud of the code I have deleted from projects and the code I have never written.
bluegatty 17 hours ago [-]
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.
mirmor23 17 hours ago [-]
> 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.
bluegatty 16 hours ago [-]
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.
jondwillis 16 hours ago [-]
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.
bluegatty 15 hours ago [-]
Im sorry to hear that, keep your head on straight.
orishlez 7 hours ago [-]
[flagged]
freditup 18 hours ago [-]
I never understand why companies post AI-written articles like this on their blog and why authors are okay having it attributed to them.
Authors: If you actually put deep thought into the content and then have an AI do the final writing, it immensely devalues your final product. I think this author actually has some good content here but the AI-generated prose does it no favors.
Companies: If your blog is for recruiting purposes (which is often one major motivation), AI slop articles are going to be a big turn off for the best talent.
cadamsdotcom 17 hours ago [-]
Lots of good advice in here for those who want to ship big stuff without slop.
Great round up of the meat and potatoes of engineering in a mature codebase without giving in to entropy.
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, small clean commits.
That is an interesting idea I guess. AI agents can be used to clean up git histories, not only produce large amounts of code.
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.
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.
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.
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.
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.
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 into multiple pull requests but rebasing the history into (ideally) atomic commits that make sense sequentially.
We generate an AI branch immediately every time a spec is completed. It then gets a brief review in our team meetings when the spec is introduced. We just take a few minutes to walk through what the AI did and take notes on what was insane and what was a good approach.
#1, this informs us about the actual quality of the spec, if the model did something wrong it will often become evident that the reason was an omission, ambiguity or contradiction in the spec.
#2, it saves the developer a lot of time, because in ~3 minutes we've usually established that at least half the code the model wrote was acceptable for use. Dev tasks look more like "Here's the implementation in concept, but pieces X, Y and Z will require your expertise to formulate a cleaner approach." And since AI tends to do a cleaner job at smaller scoped problems, it tends to be a great help to the dev at this stage too.
If anything I feel this process increases quality, not reduces it. It certainly speeds things up. Most major challenges and problems are immediately exposed by the model's proposed implementation. We don't have to wait for the developer's first cut to discover them. They go into the task knowing exactly what to focus on, and having the uncontroversial parts of their eventual PR essentially "pre-approved." The result is where we would have had to do multiple iterations of a feature, they often come back at the very next meeting having totally nailed it.
Even before LLMs, most teams don't bother cleaning up. The best you'll see is feature branch getting squashed on merge.
AI is not really a factor here. Teams/orgs that did not care before still won't, only 10x more.
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.
Some do, some don't. Yes, it depends on a lot of what wider organisation you are trying to fit into.
Seems to be the standard in shops with competent git users and no culure established around other version controll systems. What the commit messages are is fluid. My messy personal ones tend to be "start/end of day commit."
It was LLM written or heavily LLM processed. This, for example, is 100% LLM:
> Deciding boundaries up front was never about making the build easier. It was about making review possible, and it was the only affordable way to get there. That's the part that changed.
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.
https://www.folklore.org/Negative_2000_Lines_Of_Code.html
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.
> 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.
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.
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.
Authors: If you actually put deep thought into the content and then have an AI do the final writing, it immensely devalues your final product. I think this author actually has some good content here but the AI-generated prose does it no favors.
Companies: If your blog is for recruiting purposes (which is often one major motivation), AI slop articles are going to be a big turn off for the best talent.
Great round up of the meat and potatoes of engineering in a mature codebase without giving in to entropy.