eeperson · HackerTrans

4 maanden geledendiscuss

Sorry, perhaps I should have been clearer. They don't grow completely out of making bugs (although they do tend to make fewer over time), they grow out of making solutions that look right but don't actually solve the problem. This is because they understand the problem space better over time.

eeperson

4 maanden geledendiscuss

Everybody produces bugs, but Claude is good a producing code that looks like it solves the problem but doesn't. Developers worth working with, grow out of this in a new project. Claude doesn't.

An example I have of this is when I asked Claude to copy a some functionality from a front-end application to a back-end application. It got all of the function signatures right but then hallucinated the contents of the functions. Part of this functionality included a look up map for some values. The new version had entirely hallucinated keys and values, but the values sounded correct if you didn't compare with the original. A human would have literally copied the original lookup map.

eeperson

6 maanden geledendiscuss

> If you're in a project where buggy behavior wasn't introduced so much as grew (e.g. the behavior evolved A -> B -> C -> D -> E over time and a bug is reported due to undesirable interactions between released/valuable features in A, C, and E), then bisecting to find "when did this start" won't tell you that much useful.

I actually think that is the most useful time to use bisect. Since this is a situation where the cause isn't immediately obvious, looking through code can make those issues harder to find.

eeperson

6 maanden geledendiscuss

> I know a lot of people want to maintain the history of each PR, but you won't need it in your VCS.

I strongly disagree. Losing this discourages swarming on issues and makes bisect worse.

> You should always be able to roll back main to a real state. Having incremental commits between two working stages creates more confusion during incidents.

If you only use merge commits this shouldn't be any more difficult. You just need to make sure you specify that you want to use the first parent when doing reverts.

eeperson

6 maanden geledendiscuss

I've heard people say before that it is easier to reason about a linear history, but I can't a think of a situation where this would let me solve a problem easier. All I can think of is a lot of downsides. Can you give an example where it helps?

eeperson

8 jaar geledendiscuss

I've set this up before. How many video cards are you trying to use to connect these monitors? I've always had it just work if you are only using one card. In the past I've had to invoke xrandr with the --setprovideroutputsource flag (or was it --setprovideroffloadsink ?) to get multiple monitors to work with multiple video cards. Note, this only works with the open source drivers and you must be using an X server that supports randr 1.4.

comments