Stack Overflow: A year in moderation

-

On the 13th March, last year I was elected as a Stack Overflow moderator. I am using this opportunity to thank everyone who who voted for me back then.

It has been an interesting year. The "Chinese curse" kind of interesting, but I can't talk about that too much.

The world is flooded with AI slop, and everyone and their dog is using it. And Stack Overflow users are no exception. Low-reputation users, high-reputation users, the magical song of AI is too hard to resist.

Literal thousands and thousands of users have posted AI answers, thinking they will get away with it. Thousands and thousands have failed.

When someone asks me why am I so skeptical about AI?

The answer is really simple: I have seen it all. I know what it can and what it cannot do. And while it is certainly a useful tool when used carefully and for specific purposes, most of the time it is a huge time waster.

Responsible use of AI is a rare occurrence on the site. I think I can count the number of cases where AI was used on Stack Overflow in a responsible way, using my hand. In all other cases, it was not.

Because of that and the harm such answers pose to the site's quality, Stack Overflow has a very strict AI policy. Any post where AI is used in any way is subject to removal. Even if you use it only for grammar and rephrasing of the content you wrote, such use is not allowed. The reason is simple. Moderators cannot verify the accuracy of each and every AI answer, and doing selective deletions would take too much time.

See: Policy: Generative AI (e.g., ChatGPT) is banned and What is this site’s policy on content generated by generative artificial intelligence tools?

If you get tempted to use AI when posting on Stack Overflow or any other site in the Stack Exchange network, please, please, please: just don't.

Comments

Post a Comment

Popular posts from this blog

Assigning result to a function from asynchronous code

-
One of the more common problems that comes up in multi-threading, especially when refactoring existing code, is assigning a result obtained from asynchronous code. In other words, how do you write a function that will return some value, and calculate that value in a background thread? Basically, converting the following code: function GetData(...): string; var Data: string; begin Data := LongTask(...); // assign result of a long-running task to a function Result := Data; end; To this one: function GetData(...): string; var Data: string; begin TThread.CreateAnonymousThread( procedure begin Data := LongTask(...); end).Start; // assign result of a long-running task to a function Result := Data; end; Now, the above code will compile, but it will not achieve the desired functionality. Even if we ignore its thread safety issues (the background thread writes to the Data variable and that can interfere with assigning it to the function result), the funct...
Read more

Celebrating 30 Years of Delphi With a New Book: Delphi Quality-Driven Development

-
Image
This year, on February 14th, Delphi celebrates its 30th birthday. Over the past three decades, Delphi has proven to be a robust and versatile development environment, empowering developers to build high-performance applications with ease across multiple platforms: Windows, Linux, Android, iOS, and macOS.  As we commemorate this milestone, I am also introducing a new book to help guide you into Delphi's fourth decade: Delphi Quality-Driven Development. Useful to lone developers and vast teams alike, this book aims to demonstrate a variety of essential practices and techniques for making high-quality, testable code. There is a 25% sale going on until the end of February for the Delphi Quality-Driven Development ebook, and there you can also get an additional discount on other books if you add them to your order. To all my fellow Delphi developers: May your code compile quickly, your memory be manageable, and your code testable.   Delphi Quality-Driven Development Book A practica...
Read more

Hello Old New Leaky Friend

-
Image
Developers that extensively use interfaces in Delphi probably know about a long-standing issue with the compiler, where interface parameters declared as const or [ref] will cause a memory leak if a reference-counted object instance is constructed directly at the call site. Illustration: Sandra Prasnikar        Specifically, the following code would create a leak: procedure LeakTest(const Intf: IInterface); begin end; procedure Run; begin LeakTest(TInterfacedObject.Create); end; begin ReportMemoryLeaksOnShutdown := True; Run; end. The problem arises because the compiler does not create a hidden interface reference that would properly initialize the reference counting mechanism and keep the object instance alive during the call. In other words, such an object would never be assigned to a strong interface reference. Because const and [ref] parameters don't trigger reference counting, if there is no other code within the called routine, the obj...
Read more