we're so back

we're so back watching youtube videos about it being over. It's so cooked/back.

We are constantly in a state of Schrödingers cat, at the same time, it’s so over and we're so back.

It's so obvious that it takes years and years of hands-down coding experience to be able to guide those tools properly. One big downside in this particular case - if a human had to spend 3 months debugging this for 10h a day, the org would gain a ton of insight. They would probably be able to fix a similar issue in 1h tops next time, bring arguments to the table during meetings, interesting ideas would pop randomly in their head during showers etc. One of the biggest features we invented in my company, which made us (not me) a truckload of money was born by me having to struggle through a complex problem for a month, and a week later having an interesting idea around it. If I just used codex back then, we'd miss that opportunity 100%.

In the end Linus trovalds has the correct perception, he said it's a bubble, but it also has potential but much less than people think it has.

I also would like to point out something that Prime left out that seems extremely important to me : that the AI had MONTHS of thinking of context on the issue - by that, I mean that by reading the github history, it had access to all the research and discussion that Mitchell (an experienced engineer) had with other maintainers. It did the "annoying" part very well, but Mitchell said "the other models didn't go and look at the GTK code". And I think that's a MASSIVE detail. Because it feels like outside the "model improvements", we're back to the exact initial problem of AI : It is non-deterministic, and maybe even the xtra high codex would not reliably go and make the conclusion that the GTK code was the problem. Not only that, but this issue happens with a GH conversation that DOES mention the link between the issue between GTK and the bug at hand. Now let's imagine this ENTIRE problem with no deeply-understanding engineer having a discussion beforehand that the AI can read about the problem ? I'm sure if you bruteforced somehow the entire context of all the gtk files, you could get somewhere, but you'd need to know the context needs this, and with the variety of bugs and dependencies in a project, are we just going to use millions of tokens per request in the future to have these immense contexts that anyway dilute the reasoning ? Like, there's a massive jump between "it's so over for engineers" and this. And it looks like an AMAZING tool that can do things that require an immense amount of time and determination to a human fast. But is it solving the problem ? Can it do anything like this reliably ? And I don't think the answer is anywhere close to a yes. Not to mention the additional bugs in the actual code. I think without Mitchell, this would just be an unfixed bug, AI or not. And it's a big distinction to make.

I think this is a great example of AI being actually useful. The problem I think is people are pursuing speed at the expense of quality, and these are the people who are championing it replacing coding. If we used this to assist instead of replace people, we could get much better results instead of slop.

Do you realize that once your skills are atrophied enough, finding and fixing those "simple bugs" will be impossible.

'just put the code in the bag' and 'Dario take the wheel' made me spit a mouthful of White Monster on my vibing device

I have made 2 courses for boot! Check out https://boot.dev/prime! And get 25% off

we's so overback