Reverse-Engineering Human Cognition And Decision Making In A Modern Age

April 13, 2026 by Maya Posch 11 Comments

Cognitive processes are not something that we generally pay much attention to until something goes wrong, but they cover the entire scope of us ingesting sensory information, the processing and recalling thereof, as well as any resulting decisions made based on such internal deliberation.

Within that context there has also long been a struggle between those who feel that it’s fine for humans to rely on available technologies to make tasks like information recall and calculations easier, and those who insist that a human should be perfectly capable of doing such tasks without any assistance. Plato argued that reading and writing hurt our ability to memorize, and for the longest time it was deemed inappropriate for students to even consider taking one of those newfangled digital calculators into an exam, while now we have many arguing that using an ‘AI’ is the equivalent of using a calculator.

At the root of this conundrum lies the distinction between that which enhances and that which hampers human cognition. When does one merely offload tasks to a device or object, and when does one harm one’s own cognition?

Continue reading “Reverse-Engineering Human Cognition And Decision Making In A Modern Age” →

AI For The Skeptics: Pick Your Reasons To Be Excited

April 8, 2026 by Jenny List 20 Comments

It’s odd being a technology writer in 2026, because around you are many people who will tell you that your craft is outdated. Like the manufacturers of buggy-whips at the turn of the twentieth century, the automobile (in the form of large language model AI) is on the market, and your business will soon be an anachronism. Adapt or go extinct, they tell you. It’s an argument I’ve found myself facing a few times over the last year in my wandering existence, and it’s forced me to think about it. What are the reasons everyone is excited about AI and are those reasons valid, what is there to be scared of, and what are the real reasons people should be excited about it?

If We Gotta Take This Seriously, How Can We Do It?

A couple in a horse drawn buggy, circa 1900ish — The futures looking bright in the buggy-whip department! Public domain.

I’ll start by repeating my tale from a few weeks ago when I asked readers what AI applications would survive when the hype is over. The reaction of a friend with decades of software experience on trying an AI coding helper stuck with me; she referenced her grandfather who had been born in rural America in the closing years of the nineteenth century, and recalled him describing the first time he saw an automobile. I agree with her that this has the potential to be a transformative technology, and while it’s entertaining to make fun of its shortcomings as I did three years ago when the idea of what we now call vibe coding first appeared, it’s already making itself useful in some applications. Simply dismissing it is no longer appropriate, but equally, drinking freely of the Kool-Aid seems like joining yet another hype bandwagon that will inevitably derail. A middle way has to be found. Continue reading “AI For The Skeptics: Pick Your Reasons To Be Excited” →

This Week In Security: Getting Back Up To Speed

March 6, 2026 by Mike Kershaw 11 Comments

Editor’s Note: Over the course of nearly 300 posts, Jonathan Bennett set a very high bar for this column, so we knew it needed to be placed in the hands of somebody who could do it justice. That’s why we’re pleased to announce that Mike Kershaw AKA [Dragorn] will be taking over This Week In Security! Mike is a security researcher with decades of experience, a frequent contributor to 2600, and perhaps best known as the creator of the Kismet wireless scanner.

He’ll be bringing the column to you regularly going forward, but given the extended period since we last checked in with the world of (in)security, we thought it would be appropriate to kick things off with a review of some of the stories you may have missed.

Hacking like it’s 2009, or 1996

Hello all! It’s a pleasure to be here, and it already seems like a theme of the new year so far has bringing in the old bugs – what’s old is new again, and 2026 has seen several fixes to some increasingly ancient bugs.

Telnet

Reported on the OpenWall list, the GNU inetd suite brings an update to the telnet server (yes, telnet) that closes a login bug present since 2015 linked to environment variable sanitization.

Under the covers, the telnet daemon uses /bin/login to perform user authentication, but also has the ability to pass environment variables from the client to the host. One of these variables, USER, is passed directly to login — unfortunately this time with no checking to see what it contains. By simply passing a USER variable of “-froot”, login would accept the “-f” argument, or “treat this user as already logged in”. Instant root!

If this sounds vaguely familiar, it might be because the exact same bug was found in the Solaris telnetd service in 2007, including using the “-f” argument in the USER variable. An extremely similar bug targeting other variables (LD_PRELOAD) was found in the FreeBSD telnetd service in 2009, and other historical similar bugs have afflicted AIX and other Unix systems in the past.

Of course, nobody in 2026 should be running a telnet service, especially not exposed to the Internet, but it’s always interesting to see the old style of bugs resurface.

Glibc

Also reported on the OpenWall list, glibc — the GNU LibC library which underpins most binaries on Linux systems, providing kernel interfaces, file and network I/O, string manipulation, and most other common functions programmers expect — has killed another historical bug, present since 1996 in the DNS resolver functions which could be used to expose some locations in the stack.

Although not exploitable directly, the getnetbyaddr resolution functions could still ease in breaking ASLR, making other exploits viable.

Address Space Layout Randomization (ASLR) is a common method of randomizing where in memory a process and its data are loaded, making trivial exploits like buffer overflows much harder to execute. Being able to expose the location of the binary in memory by leaking stack locations weakens this mechanism, possibly exposing a vulnerable program to more traditional attacks.

MSHTML

In February, Microsoft released fixes under CVE-2026-21513 for the MSHTML Trident renderer – the one used in Internet Explorer 5. Apparently still present in Windows, and somehow still accessible through specific shortcut links, it’s the IE5 and Active-X gift that keeps giving, being actively exploited.

Continue reading “This Week In Security: Getting Back Up To Speed” →

Microsoft Uses Plagiarized AI Slop Flowchart To Explain How Git Works

February 19, 2026 by Maya Posch 48 Comments

It’s becoming somewhat of a theme that machine-generated content – whether it’s code, text or graphics – keeps pushing people to their limits, mostly by how such ‘AI slop’ is generally of outrageously poor quality, but as in the case of [Vincent Driessen] there’s also a clear copyright infringement angle involved. Recently he found that Microsoft had bastardized a Git explainer graphic which he had in 2010 painstakingly made by hand, with someone at Microsoft slapping it on a Microsoft Learn explainer article pertaining to GitHub.

As noted in a PC Gamer article on this clear faux pas, Microsoft has since quietly removed the graphic and replaced it with something possibly less AI slop, but with zero comment, and so far no response to a request for comment by PC Gamer. Of course, The Internet Archive always remembers.

What’s probably most vexing is that the ripped-off diagram isn’t even particularly good, as it has all the hallmarks of AI slop graphics: from the nonsensical arrows that got added or modified, to heavily mutilated text including changing ‘Time’ to ‘Tim’ and ‘continuously merged’ into ‘continvuocly morged’. This makes it obvious that whoever put the graphic on the Microsoft Learn page either didn’t bother to check, or that no human was involved in generating said page.

Continue reading “Microsoft Uses Plagiarized AI Slop Flowchart To Explain How Git Works” →

Why LLMs Are Less Intelligent Than Crows

December 10, 2025 by Maya Posch 60 Comments

The basic concept of human intelligence entails self-awareness alongside the ability to reason and apply logic to one’s actions and daily life. Despite the very fuzzy definition of ‘human intelligence‘, and despite many aspects of said human intelligence (HI) also being observed among other animals, like crows and orcas, humans over the ages have always known that their brains are more special than those of other animals.

Currently the Cattell-Horn-Carroll (CHC) theory of intelligence is the most widely accepted model, defining distinct types of abilities that range from memory and processing speed to reasoning ability. While admittedly not perfect, it gives us a baseline to work with when we think of the term ‘intelligence’, whether biological or artificial.

This raises the question of how in the context of artificial intelligence (AI) the CHC model translate to the technologies which we see in use today. When can we expect to subject an artificial intelligence entity to an IQ test and have it handily outperform a human on all metrics?

Continue reading “Why LLMs Are Less Intelligent Than Crows” →

Making The Smallest And Dumbest LLM With Extreme Quantization

October 23, 2025 by Maya Posch 15 Comments

Turns out that training on Twitch quotes doesn't make an LLM a math genius. (Credit: Codeically, YouTube) — Turns out that training on Twitch quotes doesn’t make an LLM a math genius. (Credit: Codeically, YouTube)

The reason why large language models are called ‘large’ is not because of how smart they are, but as a factor of their sheer size in bytes. At billions of parameters at four bytes each, they pose a serious challenge when it comes to not just their size on disk, but also in RAM, specifically the RAM of your videocard (VRAM). Reducing this immense size, as is done routinely for the smaller pretrained models which one can download for local use, involves quantization. This process is explained and demonstrated by [Codeically], who takes it to its logical extreme: reducing what could be a GB-sized model down to a mere 63 MB by reducing the bits per parameter.

While you can offload a model, i.e. keep only part of it in VRAM and the rest in system RAM, this massively impacts performance. An alternative is to use fewer bits per weight in the model, called ‘compression’, which typically involves reducing 16-bit floating point to 8-bit, reducing memory usage by about 75%. Going lower than this is generally deemed unadvisable.

Using GPT-2 as the base, it was trained with a pile of internet quotes, creating parameters with a very anemic 4-bit integer size. After initially manually zeroing the weights made the output too garbled, the second attempt without the zeroing did somewhat produce usable output before flying off the rails. Yet it did this with a 63 MB model at 78 tokens a second on just the CPU, demonstrating that you can create a pocket-sized chatbot to spout nonsense even without splurging on expensive hardware.

Continue reading “Making The Smallest And Dumbest LLM With Extreme Quantization” →

Measuring The Impact Of LLMs On Experienced Developer Productivity

July 11, 2025 by Maya Posch 74 Comments

Recently AI risk and benefit evaluation company METR ran a randomized control test (RCT) on a gaggle of experienced open source developers to gain objective data on how the use of LLMs affects their productivity. Their findings were that using LLM-based tools like Cursor Pro with Claude 3.5/3.7 Sonnet reduced productivity by about 19%, with the full study by [Joel Becker] et al. available as PDF.

This study was also intended to establish a methodology to assess the impact from introducing LLM-based tools in software development. In the RCT, 16 experienced open source software developers were given 246 tasks, after which their effective performance was evaluated.

A large focus of the methodology was on creating realistic scenarios instead of using canned benchmarks. This included adding features to code, bug fixes and refactoring, much as they would do in the work on their respective open source projects. The observed increase in the time it took to complete tasks with the LLM’s assistance was found to be likely due to a range of factors, including over-optimism about the LLM tool capabilities, LLMs interfering with existing knowledge on the codebase, poor LLM performance on large codebases, low reliability of the generated code and the LLM doing very poorly on using tacit knowledge and context.

Although METR suggests that this poor showing may improve over time, it seems fair to argue whether LLM coding tools are at all a useful coding partner.