Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you haven't read the first blog post it's pretty good at explaining the concepts.

https://blog.buenzli.dev/announcing-development-on-flirt/

The demo is particularly good if you can get past ( by the authors own admission ) slow typing speed.

As with everything these days I can see this being even more useful in reviewing agent code.

For example if an agent has spat out a bunch of code that I've reviewed and then I've asked it to make changes, I definitely do not want to review all that code again in the same diff later.



That's a really good point, at the moment I struggle to get past wanting it to create small logical changes that I can commit individually. If I could review them better such as Flirt describes, then maybe I don't care so much, and a big 'create initial implementation' commit becomes more acceptable, for example.


How is this different than simply committing between changes? Or even asking the agent to commit changes as it edits files.


Because I don't review everything between changes, there might be 10 small commits I review and state I am happy with, then I might prompt the agent to perform some small refactors after the review, I don't want the diff to show me everything in those 10 commits again in the diff ( like the usual PR would ) I want it only to show me new stuff.


If you’re happy with it, why not squash and merge it?


That's now how it works though is it? ignoring agents

Junior dev working on feature X

Junior dev makes a lot of commits and creates PR

Senior dev reviews code, spots problems a,b,c but has reviewed all the code at this point. Feature X isn't complete it can't be merged

Junior dev fixed a,b,c now 90% of the already reviewed code might not have changed but the PR doesn't show that.

Now replace junior dev with agent.


That would be pair programming with extra steps if you're just reviewing updates and not the whole patch that is going to be merged (and which is stamped with your approval).


Not sure if it's just my age but pair programming seems to have a different meaning these days.

It used to mean that two developers would literally sit next to each other, one would type and one would review as the person typed, then they would repeat.

I guess in the world of remote working it's just not practical any more.

I certainly wouldn't call, one person reviewing another persons code during the merge process pair programming at all.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: