

The main value I found from Copilot in vscode back when it first released was its ability to recognize and continue patterns in code (like in assets, or where you might have a bunch of similar but slightly different fields in a type that are all initialized mostly the same).
I don’t use it anymore though because I found the suggestions to be annoying and distracting most of the time and got tired of hitting escape. It also got in the way of standard intellisense when all I needed was to fill in a method name. It took my focus away from thinking about the code because it would generate plausible looking lines of code and my thinking would get pulled in that direction as a result.
With “agents” (whatever that term means these days), the article describes my feelings exactly. I spend the same amount of time verifying a solution as I would just creating the solution myself. The difference is I fully understand my own code, but I can’t reach that same understanding of generated code as fast because I didn’t think about writing it or how that code will solve my problem.
Also, asking an LLM about the generated code is about as reliable as you’d expect on average, and I need it to be 100% reliable (or extremely close) if I’m going to use it to explain anything to me at all.
Where I found these “agents” to be the most useful is expanding on documentation (markdown files and such). Create a first draft and ask it to clean it up. It still takes effort to review that it didn’t start BSing something, but as long as what it generates is small and it’s just editing an existing file, it’s usually not too bad.
This would infuriate me to no end. It’s literally the definition of a data race. All data between threads needs to either be accessed through synchronization primitives (mutexes, atomic access, etc) or needs to be immutable. For the most part, this should include fds, though concurrent writes to stderr might be less of an issue (still a good idea to lock/buffer it and stdout though to avoid garbled output).