Clarity does not equate to genericity. I am regularly struck by clear writing that is both lucid and powerful without resorting to ten-dollar words or tortured syntax.

The fact that AI text is often so easily spotted is a clear sign that so-called 'slop' is not the same as a writing style focused on brevity and understanding over florid meanderings.

Many people without dementia show amyloid plaques in their brains in autopsies. It's becoming more accepted now that there are multiple interrelated causes after decades pursuing the simplistic amyloid plaque theory.

The article is bordering on irresponsible.

Just fucking use the language your colleagues can understand and support for the next few years.

Just fucking use the language with the framework and tooling you need to get your job done efficiently and effectively, and one at the appropriate level of abstraction for the project.

Just fucking use the language which AI agents can read and write well, because we're in the End Times and this stuff matters.

Just fucking use the language with great testing and CI/CD support because you'll be spending longer supporting your code than writing it.

The skill is choosing well, and a key realisation is that it's never a one-size-fits-all thing. That's why an article like this is less than helpful, gosh darn it.

It looks to be that the demo has been fixed since I initially looked. Testing today showed much improved performance.

The maps are pretty, but the per-tile build constraints of the WFC build approach means that pretty unnatural generations end up happening because non-local influence is difficult to take into account. I think this may be OK for games where you discover tiles one at a time, but for a full map generator it's not great, and better solutions exist. Red Blob Games did a writeup of a noise-based method which looks superior imo. You can use moisture-tracking approaches for rivers, lay roads, bridges and other artificial elements in a separate pass, and it will likely end up faster and more robust. I think WFC is an interesting programming problem, though, so it was likely fun to implement.

Nonetheless, this was an excellent write-up and impressive demo.

Free climbing is a high-risk pursuit. A free climber goes on occasional expeditions where they solo a route, but before then, they train with others, have spotters and partners during route practice, and whole communities to provide help, support and emergency contact should things go wrong. Alex Honnold doesn't just rock up to a mountain (if you'll forgive the pun) and solo it every day for months on end.

It's very difficult to just put everything aside and focus on a singular task for the amount of time it takes to complete a significant software project. Once the initial enthusiasm wanes, keeping going can be a real challenge when you're on your own. The OP's concerns are absolutely valid and deserve respect.

Of course, Microsoft is also at this with its Copilot programme for laptops, where an onboard Neural Processing Unit has to be a particular speed to qualify. This lets you do local AI things like content-aware image snipping, text summaries and...er, Recall.

As to whether Apple will come out of this looking good or not, I think they're currently regretting rolling out a shitty initial AI offering, and will get better with the next release. It'll be like Apple Maps. Or the butterfly keyboard. Or any number of other broken version 1 Apple things.

An interesting question is to whether Apple Intelligence can be cancelled or pared back now the landscape is so AI dominated, i.e. will the lack of AI offerings be seen as a competitive disadvantage, or are people so sick of AI by now that it isn't a factor.

And there being only one gas station.

And the guy having not objected to the exact same bumper stickers for the last 15 years.

Visa have said this is because of 'enhanced risk' caused by this content, but they've been fine with it up to now. It's only because of the Australian group's censorious actions that they've decided to act. That's the frustrating thing, at least to me.

Whether they have the legal right to do it or not, it's still a dick move.

(If you'll forgive the pun.)

OpenEXR was designed for modularity, allowing efficient access to individual layers or channels. This is crucial in VFX workflows where only specific passes (like normals or diffuse) might be needed at any one time. This access is possible because EXR stores channels separately and supports tiled or scanline-based access.

The custom compression method Aras proposes - using meshoptimizer on 16K pixel chunks, followed by zstd as a second compressor step - achieves significantly faster decompression and better compression speeds than EXR ZIP, HTJ2K, or JPEG-XL lossless. However, it trades off random access and requires decompressing the entire image at once, which increases memory usage. Individual frames for a VFX production can be multiple gigabytes (i.e. dozens of 32-bit layers at 4K resolution).

The author's proposal is still compelling, and I wonder if a variant could find its way into some sort of archival format.

I do a similar loop with my use of AI - I will upload code to Gemini 2.5 Pro, talk through options and assumptions, and maybe get it to write some or all of the next step, or to try out different approaches to a refactor. Integrating any code back into the original source is never copy-and-paste, and that's where the learning is. For example, I added Dexie (a library/wrapper for accessing IndexedDB) to a browser extension project the other day, and the AI helped me get started with a minimal amount of initial knowledge, yet I learned a lot about Dexie and have been able to expand upon the code myself since. If I were on my own, I would probably have barrelled ahead and just used IndexedDB directly, resulting in a lot more boilerplate code and time spent doing busywork. It's this sort of friction reduction that I find most liberating about AI. Trying out a new library isn't a multi-hour slog; instead, you can sample it and possibly reject it as unsuitable almost immediately without having to waste a lot of time on R&D. In my case, I didn't learn 'raw' IndexedDB, but instead I got the job done with a library offering a more suitable level of abstraction, and saved hours in the process.

This isn't lazy or giving up the opportunity to learn, it's simply optimising your time.

The "not invented here" syndrome is something I kindly suggest you examine, as you may find you are actually limiting your own innovation by rejecting everything that you can't do yourself.

You also say that you want a solution more integrated with Windows, yet your UI is in SFML and your screenshots look nothing like a native Windows application.

Your project website doesn't render correctly on non-wide screens.

You are using a font which won't render many Unicode filenames correctly, e.g. Japanese or Chinese characters.

You have given no thought to accessibility or localisation.

You argue that Everything doesn't work with non-NTFS drives. That's incorrect - you can add them manually. See https://www.voidtools.com/faq/#how_do_i_index_a_fat_volume . You can also add Network Drives, NAS volumes etc.

Everything will run as non-administrator, but it will be unable to index NTFS properties. This is an OS-level restriction. You will face the same when you attempt to read these properties. The same goes for accessing protected folders - you just skip them.

You mention that you also want to feature file encryption and file transfer features in the same application. You are taking on too much here; each of the three features (file search, file transfer and file/folder encryption) is challenging and could take months to years to develop on its own. There are already accomplished apps satisfying these needs. Why would anyone use your solution over 7-zip?

You have no tests. If you want to feature encryption or file transfer, you will need an extensive test suite. Users will not be happy if your tool deletes or mangles their files.

Looking at your "Da-file-encrypter" repo, you don't seem to have any knowledge about how to actually encrypt files - you are doing an XOR against the bytes of the key, which is derived from the same bytes each time. Please NEVER ROLL YOUR OWN encryption strategy. Even the experts get it wrong. Instead, use a proper cryptography library. If you take anything away from this, please let it be that - never implement your own encryption.

Voidtools' Everything has an API and people have used that to integrate with launchers like PowerToys Run. It may be better to use the API and to add the features you think it is missing. It is very unlikely you will be able to beat its performance.

Judging by your licence and the Donate button on your website, you seem to have recently switched licences and want to make money out of this. In my personal opinion, that's not a good look for a project in this state.

Yes, inefficiency and bureaucracy suck. No, the answer is not to scrap it all without knowing what the hell you're doing and "just wing it", which is exactly what Musk and co are doing. Strangely enough, the solution is probably a compromise. Compromise takes two sides actually talking to each other, with people familiar with the matter present, and an acceptance that the goal is to make the process better without negatively impacting important things like security, safety and data integrity.

Please forgive the tone of this message, but I can't help wonder how many thousands of people are going to die because of the effective abolishment of USAID and other programmes.

"I learned that I need to stay firmly in the driver’s seat when tackling new tech."

Er, that's pretty much what a pilot is supposed to do! You can't (as yet) just give an AI free reign over your codebase and expect to come back later that day to discover a fully finished implementation. Maybe unless your prompt was "Make a snake game in Python". A pilot would be supervising their co-pilot at all times.

Comparing AIs to junior devs is getting tiresome. AIs like Claude and newer versions of ChatGPT have incredible knowledge bases. Yes, they do slip up, especially with esoteric matters where there are few authoritative (or several conflicting) sources, but the breadth of knowledge in and of itself is very valuable. As an anecdote, neither Claude nor ChatGPT were able to accurately answer a question I had about file operation flags yesterday, but when I said to ChatGPT that its answer wasn't correct, it apologised and said the Raymond Chen article it had sourced wasn't super clear about the particular combination I'd asked about. That's like having your own research assistant, not a headstrong overconfident junior dev. Yes, they make mistakes, but at least now they'll admit to them. This is a long way from a year or two ago.

In conclusion: don't use an AI as one of your primary sources of information for technology you're new to, especially if you're not double-checking its answers like a good pilot.