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