@anto.pt

I'd call this approach "vibe fuzzing".

This will give you a lot more confidence in your code and will allow you to find very niche bugs that would be very hard to find with conventional testing.

Every bug you find in the AI code you ask the AI to fix, and you carefully fix yours.

The AI code will quickly become a fever dream/garbage fire, but you don't care since it's not code you'll ever run in prod.

The big advantage is that it's very likely to have bugs that are different from yours.

The best fuzzing is, in fact, differential fuzzing. The issue is that you rarely have a reference implementation for your problem.

This is where AI comes in.

You vibe code the alternative implementation and you leave it in your tests, to compare against yours.

As we discussed today, Sec-Fetch-Site should do most of the work for us 😊

I still have to change its color, dammit XD

Companies will realize that it is better (aka cheaper) to have a slower programmer that is more precise than an LLM-driven developer.

Also, I prefer to use channels or a sync API when there's a chance to parser while you lex. It's easier to parallelize and handle cancellation

I didn't want to overcomplicate things and add too much new stuff.

No specific reason, it was just an example. I can think of a use for both approaches :)

github.com/empijei/gote...

I'm working on it: by benchmarking just the queues it looks like the ring does indeed cause a lot less allocations, but it still is remarkably slower on most benchmarks than slices.

Yeah that is what puzzles me. I guess we've collectively gotten hardware and compilers makers to make terrible code go fast.

Done: blogtitle.github.io/go-advanced-...

Thanks again Roger for your usual very insightful tips :)

I'll add a comment to the post about this