Skip to content

Instantly share code, notes, and snippets.

@sogaiu

sogaiu/2026-tidbits.md

Last active June 15, 2026 02:45
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save sogaiu/ae6960e10c5b51f6d100cdcc61268683 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save sogaiu/ae6960e10c5b51f6d100cdcc61268683 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
2026-tidbits.md

2026-07-03

2026-07-02

2026-07-01

  • Project Glasswing: what Mythos showed us - Grant Bourzikas

    Some of what we describe above is not entirely unique to Mythos Preview. When we ran other frontier models through the same harness, they found a fair number of the same underlying bugs, and in some cases they got further than we expected on the reasoning side too.

    ...the model organically pushes back on certain requests - much like the cyber capabilities that made it useful for vulnerability hunting, the model has its own emergent guardrails that sometimes cause it to push back on legitimate security research requests. But as we found, these organic refusals aren’t consistent - the same task, framed differently or presented in a different context, could produce completely different outcomes...

    ...It's a harness that helps you achieve the final outcomes. The first steps to building a harness are simple, as you can ask the model to help, which is what we did.

2026-06-30

2026-06-29

2026-06-28

2026-06-27

2026-06-26

  • Blue Team, Red Team (1/3) - Terence Tao

    In the field of cybersecurity, a distinction is made between the "blue team" task of building a secure system, and the "red team" task of locating vulnerabilities in such systems. The blue team is more obviously necessary to create the desired product; but the red team is just as essential, given the damage that can result from deploying insecure systems.

    The nature of these teams mirror each other; mathematicians would call them "dual". The output of a blue team is only as strong as its weakest link: a security system that consists of a strong component and a weak component (e.g., a house with a securely locked door, but an open window) will be insecure (and in fact worse, because the strong component may convey a false sense of security). Dually, the contributions to a red team can often be additive: a red team report that contains both a serious vulnerability and a more trivial one is more useful than a report that only contains the serious issue, as it is valuable to have the blue team address both vulnerabilities. (But excessive low-quality reports can dilute attention from critical issues.)

    Because of this, unreliable contributors may be more useful in the "red team" side of a project than the "blue team" side, though the blue team can still accommodate such contributors provided that the red team is competent enough to catch almost all of the errors that the contributor to the blue team might make. Also, unreliable red team contributions only add value if they augment the output of more reliable members of that team, rather than replace that output, and if their output can be effectively filtered or triaged by more experienced red team members. (1/3)

  • Blue Team, Red Team (2/3) - Terence Tao

    (The blue team / red team distinction extends beyond cybersecurity to many other disciplines as well. In software engineering, for instance, "blue teaming" might correspond to the generation of new computer code, while "red teaming" would consist of such tasks as quality assurance and testing of such code. In mathematics, "blue teaming" could involve coming up with speculative ideas to solve a math problem, while "red teaming" checks the arguments for formal errors, and also raises heuristic objections to a blue team approach being viable. (See also my discussion about "local" and "global" errors in mathematics at On “local” and “global” errors in mathematical papers, and how to detect them).

    I like to refer to these two teams in mathematics as the "optimists" and "pessimists"; in my experience, the strongest collaborations arise when there is a roughly equal split between the optimists and pessimists in the collaborations. (Depending on the collaboration, I myself have sometimes played the optimist, sometimes the pessimist, and sometimes a mixture of both.) (2/3)

  • Blue Team, Red Team (3/3) - Terence Tao

    Many of the proposed use cases for AI tools try to place such tools in the "blue team" category, such as creating code, text, images, or mathematical arguments in some semi-automated or automated fashion, that is intended for use for some external application. However, in view of the unreliability and opacity of such tools, it may be better to put them to work on the "red team", critiquing the output of blue team human experts but not directly replacing that output; "blue team" AI use should only be permitted up to the capability of one's "red team" to catch and correct any errors generated. This approach not only plays to current AI strengths, such as breadth of exposure and fast feedback, but also mitigates the risks of deploying unverified AI output in high-stakes settings.

    In my own personal experiments with AI, for instance, I have found it to be useful for providing additional feedback on some proposed text, argument, code, or slides that I have generated (including this current text). I might only agree with a fraction of the suggestions generated by the AI tool; but I find that there are still several useful comments made that I do agree with, and incorporate into my own output. This is a significantly less glamorous or intuitive use case for AI than the more commonly promoted "blue team" one of directly automating one's own output, but one that I find adds much more reliable value. (3/3)

2026-06-25

lg-model-number-decoder-ring

2026-06-24

2026-06-23

2026-06-22

2026-06-21

2026-06-20

  • Factoring Your Code - grug

    next strategy very harder: break code base up properly (fancy word: "factor your code properly") here is hard give general advice because each system so different. however, one thing grug come to believe: not factor your application too early!

    early on in project everything very abstract and like water: very little solid holds for grug's struggling brain to hang on to. take time to develop "shape" of system and learn what even doing. grug try not to factor in early part of project and then, at some point, good cut-points emerge from code base

    good cut point has narrow interface with rest of system: small number of functions or abstractions that hide complexity demon internally, like trapped in crystal

    grug quite satisfied when complexity demon trapped properly in crystal, is best feeling to trap mortal enemy!

    grug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along with experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build skill in seeing, patience

    sometimes grug go too early and get abstractions wrong, so grug bias towards waiting

    big brain developers often not like this at all and invent many abstractions start of project

    grug tempted to reach for club and yell "big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!"

    but grug learn control passions, major difference between grug and animal

    instead grug try to limit damage of big brain developer early in project by giving them thing like UML diagram (not hurt code, probably throw away anyway) or by demanding working demo tomorrow

    working demo especially good trick: force big brain make something to actually work to talk about and code to look at that do thing, will help big brain see reality on ground more quickly

    remember! big brain have big brain! need only be harness for good and not in service of spirit complexity demon on accident, many times seen

    (best grug brain able to herd multiple big brain in right direction and produce many complexity demon trap crystals, large shiney rock pile awaits such grug!)

    also sometimes call demo approach "prototype", sound fancier to project manager

    grug say prototype early in software making, especially if many big brains

2026-06-19

  • AI Assistance Reduces Persistence and Hurts Independent Performance

    People often optimize for long-term goals in collaboration: A mentor or companion doesn't just answer questions, but also scaffolds learning, tracks progress, and prioritizes the other person's growth over immediate results. In contrast, current AI systems are fundamentally short-sighted collaborators - optimized for providing instant and complete responses, without ever saying no (unless for safety reasons). What are the consequences of this dynamic? Here, through a series of randomized controlled trials on human-AI interactions (N = 1,222), we provide causal evidence for two key consequences of AI assistance: reduced persistence and impairment of unassisted performance. Across a variety of tasks, including mathematical reasoning and reading comprehension, we find that although AI assistance improves performance in the short-term, people perform significantly worse without AI and are more likely to give up. Notably, these effects emerge after only brief interactions with AI (approximately 10 minutes). These findings are particularly concerning because persistence is foundational to skill acquisition and is one of the strongest predictors of long-term learning. We posit that persistence is reduced because AI conditions people to expect immediate answers, thereby denying them the experience of working through challenges on their own. These results suggest the need for AI model development to prioritize scaffolding long-term competence alongside immediate task completion.

2026-06-18

2026-06-17

2026-06-16

2026-06-15

  • Nice man pages
    • Manned.org - many systems, multiple versions
    • ManKier - only linux, but toc-ish feature, nice formatting, "explain a command", and more

2026-06-14

2026-06-13

  • open-slopware - "Free/Open Source Software choosing to use and/or support LLM usage/AI, as well as alternatives and tips to requesting better policies or forking."
  • llm-afflicted-software - "Free/Open Source Software tainted by LLM developers/developed by genAI boosters, along with alternatives."
  • No-AI - "This is a list maintained by the Starlight Network team of software that has a No-AI policy or has pledged not to use or implement anything in regards to Generative AI."
  • slopfree-sofware-index - "A list of open-source projects that reject AI-generated code"

2026-06-12

  • Copyright Lawsuits

    Many creators see the AI industry's current training practices as large-scale copyright infringement. These are the ongoing lawsuits brought against generative AI companies.

2026-06-11

  • AIMania

    This repository is a collection of resources that might help with avoiding gen AI. It was written by coders for coders, as an attempt to help others as an unpaid volunteer effort. You'll likely find mistakes, please fix them.

    The primary purpose is to provide information, fast and reliably. We link to other projects and try to always provide the data sources. Even though this repository is primarily meant for developers, it may still provide useful information for "casual" people.

    • WHY

      This document tries to summarize why you might want to avoid generative AI. The focus is on well-sourced, substantiated complaints based on actual studies, to illustrate that the concerns regarding generative AI aren't purely an uninformed opinion or random gut feeling.

2026-06-10

2026-06-09

  • AI generated Code or Rewrites violate FOSS-Licences. Talk at FOSS Backstage Berlin

    I travelled to Berlin to speak at FOSS Backstage about our MG case and AI-generated code with Dr. Andreas Kotulla. Turned out: every question from the audience was about the Chardet case - a piece of LGPL-licensed software that had been rewritten and translated using Claude Code, then relabelled under an MIT licence.

    Can we simply forget about copyright - whether commercial or FOSS - and rewrite any software we want to use, free of obligations? Under the pre-AI legal framework, a rewrite would constitute a new, independent work if it bore no resemblance to the original in terms of structure, sequence, and organisation (SSO) under US law. Under European law, we would look at the software's architecture as the non-literal expression of the original. It is entirely possible to transform software through successive processes until the new SSO or architecture bears little resemblance to the original — but the process itself would still produce a derivative work.

    My prediction: Even where the resulting code appears completely novel, courts will scrutinise the process rather than the output and ask where the human intervention lay. If every material decision was made by an LLM trained on the original work, I expect courts will find infringement.

2026-06-08

2026-06-07

2026-06-06

2026-06-05

2026-06-04

2026-06-03

  • Lack of systemd - Dr. Mike Murphy

    The majority of Linux distributions have adopted systemd as their runtime initialization system and service manager. Had the systemd developers simply focused on an initialization and service management system using a loosely coupled, highly cohesive design, there might not be any advantage to omitting it from the system. However, the systemd developers instead decided to add unrelated functionality that goes far beyond system initialization and service management. This functionality is all over the place in terms of scope, including network management, DNS resolution with a history of security vulnerabilities, a totally unnecessary Network Time Protocol client, bootloader management, and even a replacement for home directories that allows them to be mounted in arbitrary locations for the subset of users who actually need this “feature.” The lead author of systemd also hasn’t done the project any favors by his dismissive attitude toward security vulnerabilities, leading to the project receiving the lamest vendor Pwnie Award in 2017 for making software that is easy to compromise.

    Linux systems using systemd have experienced various bugs and other kinds of breakage over the years. A major issue with the tightly coupled, non-cohesive design of systemd is that it is a massive code base that exceeded 1.2 million lines in 2019 and has only grown since. Most or all of this code runs as the root user with elevated privileges, making it a ripe target for exploits and attacks. A great deal of it also runs as PID 1 on the system, which is an especially privileged process started by the Linux kernel. If PID 1 crashes, the Linux kernel panics, resulting in a hard system lockup. Both software bugs and exploits against systemd are thus excellent candidates for launching denial of service attacks.

2026-06-02

2026-06-01

2026-05-31

2026-05-30

  • The biggest advance in AI since the LLM - Gary Marcus

    Claude Code, an impressive and possibly game-changing “coding agent” for programmers to write code faster is the single biggest advance in AI since the LLM.

    And the thing is, Claude Code is NOT a pure LLM. And it’s not pure deep learning. Not even close.

    ...

    The source code leak proves it. Tucked away at its center is a 3,167 line kernel called print.ts.

    print.ts is a pattern matching. And pattern matching is supposed to be the strength of LLMs.

    But Anthropic figured out that if you really need to get your patterns right, you can’t trust a pure LLM. They are too probabilistic. And too erratic.

    Instead, the way Anthropic built that kernel is straight out of classical symbolic AI. For example, it’s in large part a big IF-THEN conditional, with 486 branch points and 12 levels of nesting — all inside a deterministic, symbolic loop that the real godfathers of AI, people like John McCarthy and Marvin Minsky and Herb Simon, would have instantly recognized.

2026-05-29

2026-05-28

2026-05-27

2026-05-26

2026-05-25

2026-05-24

2026-05-23

2026-05-22

2026-05-21

2026-05-20

2026-05-19

2026-05-18

  • AI Cybersecurity After Mythos: The Jagged Frontier

    TL;DR: We tested Anthropic Mythos's showcase vulnerabilities on small, cheap, open-weights models. They recovered much of the same analysis. AI cybersecurity capability is very jagged: it doesn't scale smoothly with model size, and the moat is the system into which deep security expertise is built, not the model itself. Mythos validates the approach but it does not settle it yet.

2026-05-17

2026-05-16

2026-05-15

2026-05-14

2026-05-13

2026-05-12

2026-05-11

2026-05-10

2026-05-09

2026-05-08

2026-05-07

2026-05-06

2026-05-05

2026-05-04

2026-05-03

  • Excerpt from "Project Oberon"

    While my eyes were glued to the colorful display, and while I was confronted with the evidence of my latest inadequacy, in through the always open door stepped my colleague (JG). He also happened to spend a leave from duties at home at the same laboratory, yet his face did not exactly express happiness, but rather frustration. The chocolate bar in his hand did for him what the coffee cup or the pipe does for others, providing temporary relaxation and distraction. It was not the first time he appeared in this mood, and without words I guessed its cause. And the episode would reoccur many times.

    His days were not filled with the great fun of rectangle-pushing; he had an assignment. He was charged with the design of a compiler for the same advanced computer. Therefore, he was forced to deal much more closely, if not intimately, with the underlying software system. Its rather frequent failures had to be understood in his case, for he was programming, whereas I was only using it through an application; in short, I was an end-user! These failures had to be understood not for purposes of correction, but in order to find ways to avoid them. How was the necessary insight to be obtained? I realized at this moment that I had so far avoided this question; I had limited familiarization with this novel system to the bare necessities which sufficed for the task on my mind.

    It soon became clear that a study of the system was nearly impossible. Its dimensions were simply awesome, and documentation accordingly sparse. Answers to questions that were momentarily pressing could best be obtained by interviewing the system's designers, who all were in-house. In doing so, we made the shocking discovery that often we could not understand their language. Explanations were fraught with jargon and references to other parts of the system which had remained equally enigmatic to us.

2026-05-02

2026-05-01

2026-04-30

  • Project Oberon - Niklaus Wirth and Jürg Gutknecht

    Comments about plans to prepare a second edition to this book varied widely. Some felt that this book is outdated, that nobody is interested in a system of this kind any longer. "Why bother"? Others felt that there is an urgent need for this type of text, which explains an entire system in detail rather than merely proposing strategies and approaches. "By all means"!.

    Very much has changed in these last 30 years. But even without this change, it would be preposterous to propose and construct a system competing with existing, worldwide "standards". Indeed, very few people would be interested in using it. The community at large seems to be stuck with these gigantic software systems, and helpless against their complexity, their peculiarities, and their occasional unreliability.

    But surely new systems will emerge, perhaps for different, limited purposes, allowing for smaller systems. One wonders where their designers will study and learn their trade. There is little technical literature, and my conclusion is that understanding is generally gained by doing, that is, "on the job". However, this is a tedious and suboptimal way to learn. Whereas sciences are governed by principles and laws to be learned and understood, in engineering experience and practice are indispensable. Does Computer Science teach laws that hold for (almost) ever? More than any other field of engineering, it would be predestined to be based on rigorous mathematical principles. Yet, its core hardly is. Instead, one must rely on experience, that is, on studying sound examples. The main purpose of and the driving force behind this project is to provide a single book that serves as an example of a system that exists, is in actual use, and is explained in all detail. This task drove home the insight that it is hard to design a powerful and reliable system, but even much harder to make it so simple and clear that it can be studied and fully understood. Above everything else, it requires a stern concentration on what is essential, and the will to leave out the rest, all the popular "bells and whistles".

    Recently, a growing number of people has become interested in designing new, smaller systems. The vast complexity of popular operating systems makes them not only obscure, but also provides opportunities for "back doors". They allow external agents to introduce spies and devils unnoticed by the user, making the system attackable and corruptible. The only safe remedy is to build a safe system anew from scratch.

    Turning now to a practical aspect: The largest chapter of the 1992 edition of this book dealt with the compiler translating Oberon programs into code for the NS32032 processor. This processor is now neither available nor is its architecture recommendable. Instead of writing a new compiler for some other commercially available architecture, I decided to design my own in order to extend the desire for simplicity and regularity to the hardware. The ultimate benefit of this decision is not only that the software, but also the hardware of the Oberon System is described completely and rigorously. The processor is called RISC. The hardware modules are decribed exclusively in the language Verilog. The decision for a new processor was expedited by the possibility to implement it, that is, to make it concrete and available. This is due to the advent of programmable gate arrays (FPGA), allowing to turn a design into a real, functioning processor on a single chip. As a result, the described system can be realized using a low-cost development board. This board, Xilinx Spartan-3 by Digilent, features a 1-MByte static memory, which easily accommodates the entire Oberon System, incuding its compiler. It is shown, together with a display, a keyboard and a mouse in the photo below. The board is visible in the lower, right corner.

    The decision to develop our own processor required that the chapters on the compiler and the linking loader had to be completely rewritten. However, it also provided the welcome chance to improve their clarity considerably. The new processor indeed allowed to simplify and straighten out the entire compiler.

2026-04-29

2026-04-28

  • AB29.3.2 ALGOL Colloquium - Closing Word - Niklaus Wirth in 1968 (Transcription by dcreager)

    "So why have you chosen to teach PL/1?", I asked. "I used to teach Algol, where things weren't ideal, but a lot better in those respects. But pressure was mounting to teach a language which the students could readily use after leaving the haven of school. Employers don't ask "do you know the principles of programming?", but rather "do you speak FORTRAN?". In order to avoid making this step backwards, I chose PL/1, which first seemed to be a satistory compromise."

    ...

    What hampered progress even more, was the fact that a goal had never been specified with sufficient clarity.

  • Snakes...why did it have to be snakes? - Indiana Jones in 1981
  • Python! - Matthias Felleisen in 2024

    As of Fall 2025, Northeastern’s College of Computer Science will replace the existing curriculum with a set of new courses, starting with Python in the first year. ... I now understand. But we really need to teach Python and loops and assignment statements as early as possible.

    Why?

    Because everyone else does it, and it’s what our teaching faculty wants to teach.

2026-04-27

2026-04-26

  • Extract from Chapter 3 of "The Dawn of Everything"

    Perhaps the real question here is what it means to be a ‘self-conscious political actor’. Philosophers tend to define human consciousness in terms of self-awareness; neuroscientists, on the other hand, tell us we spend the overwhelming majority of our time effectively on autopilot, working out habitual forms of behaviour without any sort of conscious reflection. When we are capable of self-awareness, it’s usually for very brief periods of time: the ‘window of consciousness’, during which we can hold a thought or work out a problem, tends to be open on average for roughly seven seconds. What neuroscientists (and it must be said, most contemporary philosophers) almost never notice, however, is that the great exception to this is when we’re talking to someone else. In conversation, we can hold thoughts and reflect on problems sometimes for hours on end. This is of course why so often, even if we’re trying to figure something out by ourselves, we imagine arguing with or explaining it to someone else. Human thought is inherently dialogic. Ancient philosophers tended to be keenly aware of all this: that’s why, whether they were in China, India or Greece, they tended to write their books in the form of dialogues. Humans were only fully self-conscious when arguing with one another, trying to sway each other’s views, or working out a common problem. True individual self-consciousness, meanwhile, was imagined as something that a few wise sages could perhaps achieve through long study, exercise, discipline and meditation.

2026-04-25

2026-04-24

2026-04-23

  • Attacking UNIX Systems via CUPS, Part I - Simone Margaritelli

    Entirely personal recommendation, take it or leave it: I’ve seen and attacked enough of this codebase to remove any CUPS service, binary and library from any of my systems and never again use a UNIX system to print. I’m also removing every zeroconf / avahi / bonjour listener. You might consider doing the same.

2026-04-22

2026-04-21

2026-04-20

2026-04-19

2026-04-18

2026-04-17

2026-04-16

2026-04-15

2026-04-14

2026-04-13

2026-04-12

2026-04-11

2026-04-10

  • Tony Hoare (1934-2026) - Jim Miles

    One final note I would like to share from these meetings with Tony is perhaps the most intriguing of what he said, but also the one he delivered with the greatest outright confidence. In a discussion about the developments of computers in the future - whether we are reaching limits of Moore's Law, whether Quantum Computers will be required to reinvigorate progress, and other rather shallow and obvious hardware talking points raised by me in an effort to spark Tony's interest - he said 'Well, of course, nothing we have even comes close to what the government has access to. They will always be years ahead of what you can imagine'. When pressed on this, in particular whether he believed such technology to be on the scale of solving the large prime factorisation that the world's cryptographic protocols are based on, he was cagey and shrugged enigmatically. One wonders what he had seen, or perhaps he was engaging in a bit of knowing trolling; Tony had a fantastic sense of humour and was certainly capable of leading me down the garden path with irony and satire before I realised a joke was being made.

2026-04-09

2026-04-08

2026-04-07

2026-04-06

2026-04-05

2026-04-04

2026-04-03

2026-04-02

2026-04-01

2026-03-31

2026-03-30

2026-03-29

  • Clinejection — Compromising Cline's Production Releases just by Prompting an Issue Triager - Adnan Khan

    Cline is an open-source AI coding tool that integrates with developer IDEs such as VSCode and its many forks. Users can download Cline through the VS Code Marketplace or OpenVSX. Since Cline is an open-source project the team uses a GitHub for development. On December 21st, 2025, Cline maintainers added an AI agent to triage issues created on the repository. This AI agent ran within a GitHub Actions workflow and ran with broad privileges. You might be able to guess where this is heading…

    Between Dec 21st, 2025 and Feb 9th, 2026 a prompt injection vulnerability in Cline’s (now removed) Claude Issue Triage workflow allowed any attacker with a GitHub account to compromise production Cline releases on both the Visual Studio Code Marketplace and OpenVSX and publish malware to millions of developers!

2026-03-28

2026-03-27

  • Democratizing AI Compute - Chris Lattner - seems like nice background - could be better with the terminology but hard to do when someone is trying hard to market their stuff :)

2026-03-26

2026-03-25

2026-03-24

2026-03-23

2026-03-22

2026-03-21

2026-03-20

2026-03-19

Did the court find that AI training constitutes “reproduction” under German copyright law?

Yes. Following Article 2 InfoSoc Directive, the court held that a reproduction exists “in any form and by any means.” Even a fixation through numerical probability values qualifies, as long as the work can later be perceived through technical means. The court considered the model parameters to embody the protected expression.

...

Did the court consider any other exemptions or implied consents by the authors?

No. The court stated that training AI models is not an ordinary or expected use of a work to which authors have implicitly consented. The acts were therefore unlicensed. Furthermore, the court found that the use was not justified by quotation, parody or similar limitations to copyright.

Who did the court find to be responsible for the AI outputs?

The court determined that responsibility lies with OpenAI. The company selected the training data, built and operated the system, and determined its architecture. User prompts merely trigger the model’s internal processes and do not create independent liability.

2026-03-18

2026-03-17

2026-03-16

2026-03-15

2026-03-14

2026-03-13

2026-03-12

2026-03-11

2026-03-10

2026-03-09

2026-03-08

2026-03-07

2026-03-06

2026-03-05

2026-03-04

  • Speech in Acceptance of the National Book Foundation Medal for Distinguished Contribution to American Letters - Ursula K. Le Guin

    To the givers of this beautiful reward, my thanks, from the heart. My family, my agents, my editors, know that my being here is their doing as well as my own, and that the beautiful reward is theirs as much as mine. And I rejoice in accepting it for, and sharing it with, all the writers who’ve been excluded from literature for so long — my fellow authors of fantasy and science fiction, writers of the imagination, who for fifty years have watched the beautiful rewards go to the so-called realists.

    Hard times are coming, when we’ll be wanting the voices of writers who can see alternatives to how we live now, can see through our fear-stricken society and its obsessive technologies to other ways of being, and even imagine real grounds for hope. We’ll need writers who can remember freedom — poets, visionaries — realists of a larger reality.

2026-03-03

2026-03-02

2026-03-01

2026-02-28

2026-02-27

2026-02-26

2026-02-25

  • To Think or Not to Think: The Impact of AI on Critical-Thinking Skills - Christine Anne Royce, Valerie Bennett

    1. Promote Active Engagement With Scientific Data

      Rather than letting AI generate answers, ask students to interpret AI-generated data themselves. Also within this area, ask students to engage in hypothesis testing through additional research and evidence-based reasoning and determine if they see emergent patterns. If planned properly and modeled for the students so that they can practice this type of use, AI becomes not just a source of information, but also a means of engaging with scientific inquiry on a deeper level. An example would be taking a typical lab or assignment and having students find data to support or refute an argument about what they found. This data gathering could be related to water safety, diseases, or pathogen rates where they live.

    2. Use AI to Facilitate Scientific Argumentation

      Encourage students to use AI as a tool to gather evidence for debates or scientific arguments. Ensure that students then “fact check” the information that was provided for accuracy. A second strategy would be to provide AI with information—i.e., a map of a path that a hurricane is on—and then present two explanations for the path, one that is meteorologically accurate (always double-check yourself) and one that is plausible, but inaccurate. Provide these explanations to the students and ask them to determine which one is on target and why.

    3. Require the Use of Claim, Evidence, and Reasoning (CER)

      Phenomenon-based learning places students in the role of scientists, encouraging them to ask questions, form hypotheses, and conduct experiments. AI can support this by offering dynamic simulations and interactive environments where students can test their ideas or even provide potential explanations for a phenomenon. Students should still be asked to critically evaluate any information that is AI-generated and explain their own reasoning for an answer.

    4. Frame AI as a Resource, Not a Shortcut

      By framing AI as a resource for exploration rather than a shortcut to solutions, teachers can help students maintain an active role in their learning process. Instead of using AI to provide direct answers, educators can encourage students to use AI as a discussion partner. For example, students can use AI-generated data as a starting point for class debates or group projects. This promotes collaborative problem solving and requires students to evaluate, question, and interpret the information AI provides. Pose thought-provoking questions to students regarding the data, such as “Are there any biases in the data? What are the sources of this data?”

2026-02-24

2026-02-23

2026-02-22

2026-02-21

  • Excerpt from "The Dawn of Everything"

    In this book we will not only be presenting a new history of humankind, but inviting the reader into a new science of history, one that restores our ancestors to their full humanity. Rather than asking how we ended up unequal, we will start by asking how it was that ‘inequality’ became such an issue to begin with, then gradually build up an alternative narrative that corresponds more closely to our current state of knowledge. If humans did not spend 95 per cent of their evolutionary past in tiny bands of hunter- gatherers, what were they doing all that time? If agriculture, and cities, did not mean a plunge into hierarchy and domination, then what did they imply? What was really happening in those periods we usually see as marking the emergence of ‘the state’? The answers are often unexpected, and suggest that the course of human history may be less set in stone, and more full of playful possibilities, than we tend to assume.

2026-02-20

2026-02-19

2026-02-18

2026-02-17

  • LLME - Michael Fogus

    Moreover, as a Socratic partner, LLMs are incredibly frustrating in their inability to move a “discussion” forward. Indeed, the inability to leverage (or even to identify) necessary tension highlights a huge problem in the emergent sycophantic behavior of these tools. A good Socratic partner creates pressure to move toward truth and shared understanding, but LLMs are too sycophantic, lack an awareness of useful tension,4 cannot often identify contradiction, and lack an ability to adhere to the trajectory of a conversation. These traits are poison to my software design process.

2026-02-16

2026-02-15

2026-02-14

  • Excerpt from "The Dawn of Everything"

    If, as many are suggesting, our species’ future now hinges on our capacity to create something different (say, a system in which wealth cannot be freely transformed into power, or where some people are not told their needs are unimportant, or that their lives have no intrinsic worth), then what ultimately matters is whether we can rediscover the freedoms that make us human in the first place. As long ago as 1936, the prehistorian V. Gordon Childe wrote a book called Man Makes Himself. Apart from the sexist language, this is the spirit we wish to invoke. We are projects of collective self-creation. What if we approached human history that way? What if we treat people, from the beginning, as imaginative, intelligent, playful creatures who deserve to be understood as such? What if, instead of telling a story about how our species fell from some idyllic state of equality, we ask how we came to be trapped in such tight conceptual shackles that we can no longer even imagine the possibility of reinventing ourselves?

2026-02-13

  • ChatGPT is bullshit - Michael Townsen Hicks, James Humphries, Joe Slater

    Investors, policymakers, and members of the general public make decisions on how to treat these machines and how to react to them based not on a deep technical understanding of how they work, but on the often metaphorical way in which their abilities and function are communicated. Calling their mistakes ‘hallucinations’ isn’t harmless: it lends itself to the confusion that the machines are in some way misperceiving but are nonetheless trying to convey something that they believe or have perceived. This, as we’ve argued, is the wrong metaphor. The machines are not trying to communicate something they believe or perceive. Their inaccuracy is not due to misperception or hallucination. As we have pointed out, they are not trying to convey information at all. They are bullshitting.

    Calling chatbot inaccuracies ‘hallucinations’ feeds in to overblown hype about their abilities among technology cheerleaders, and could lead to unnecessary consternation among the general public. It also suggests solutions to the inaccuracy problems which might not work, and could lead to misguided efforts at AI alignment amongst specialists. It can also lead to the wrong attitude towards the machine when it gets things right: the inaccuracies show that it is bullshitting, even when it’s right. Calling these inaccuracies ‘bullshit’ rather than ‘hallucinations’ isn’t just more accurate (as we’ve argued); it’s good science and technology communication in an area that sorely needs it.

2026-02-12

  • The GenAI Divide - State of AI in Business 2025 (via archive.org) - MIT NANDA

    Despite $30–40 billion in enterprise investment into GenAI, this report uncovers a surprising result in that 95% of organizations are getting zero return. The outcomes are so starkly divided across both buyers (enterprises, mid-market, SMBs) and builders (startups, vendors, consultancies) that we call it the GenAI Divide. Just 5% of integrated AI pilots are extracting millions in value, while the vast majority remain stuck with no measurable P&L impact. This divide does not seem to be driven by model quality or regulation, but seems to be determined by approach.

    Tools like ChatGPT and Copilot are widely adopted. Over 80 percent of organizations have explored or piloted them, and nearly 40 percent report deployment. But these tools primarily enhance individual productivity, not P&L performance. Meanwhile, enterprisegrade systems, custom or vendor-sold, are being quietly rejected. Sixty percent of organizations evaluated such tools, but only 20 percent reached pilot stage and just 5 percent reached production. Most fail due to brittle workflows, lack of contextual learning, and misalignment with day-to-day operations.

    ...

    The core barrier to scaling is not infrastructure, regulation, or talent. It is learning. Most GenAI systems do not retain feedback, adapt to context, or improve over time.

2026-02-11

2026-02-10

  • Excerpt from "The Dawn of Everything"

    Nonetheless, on those occasions when people do reflect on the lessons of prehistory, they almost invariably come back to questions of this kind. We are all familiar with the Christian answer: people once lived in a state of innocence, yet were tainted by original sin. We desired to be godlike and have been punished for it; now we live in a fallen state while hoping for future redemption. Today, the popular version of this story is typically some updated variation on Jean-Jacques Rousseau’s Discourse on the Origin and the Foundation of Inequality Among Mankind, which he wrote in 1754. Once upon a time, the story goes, we were hunter-gatherers, living in a prolonged state of childlike innocence, in tiny bands. These bands were egalitarian; they could be for the very reason that they were so small. It was only after the ‘Agricultural Revolution’, and then still more the rise of cities, that this happy condition came to an end, ushering in ‘civilization’ and ‘the state’ – which also meant the appearance of written literature, science and philosophy, but at the same time, almost everything bad in human life: patriarchy, standing armies, mass executions and annoying bureaucrats demanding that we spend much of our lives filling in forms.

    Of course, this is a very crude simplification, but it really does seem to be the foundational story that rises to the surface whenever anyone, from industrial psychologists to revolutionary theorists, says something like ‘but of course human beings spent most of their evolutionary history living in groups of ten or twenty people,’ or ‘agriculture was perhaps humanity’s worst mistake.’ And as we’ll see, many popular writers make the argument quite explicitly. The problem is that anyone seeking an alternative to this rather depressing view of history will quickly find that the only one on offer is actually even worse: if not Rousseau, then Thomas Hobbes.

    ...

    As the reader can probably detect from our tone, we don’t much like the choice between these two alternatives. Our objections can be classified into three broad categories. As accounts of the general course of human history, they:

    1. simply aren’t true;
    2. have dire political implications;
    3. make the past needlessly dull.

    This book is an attempt to begin to tell another, more hopeful and more interesting story; one which, at the same time, takes better account of what the last few decades of research have taught us. Partly, this is a matter of bringing together evidence that has accumulated in archaeology, anthropology and kindred disciplines; evidence that points towards a completely new account of how human societies developed over roughly the last 30,000 years. Almost all of this research goes against the familiar narrative, but too often the most remarkable discoveries remain confined to the work of specialists, or have to be teased out by reading between the lines of scientific publications.

2026-02-09

2026-02-08

2026-02-07

2026-02-06

2026-02-05

2026-02-04

2026-02-03

Quicksort-example

2026-02-02

Merge_sort_algorithm_diagram svg

2026-02-01

2026-01-31

2026-01-30

2026-01-29

2026-01-28

2026-01-27

2026-01-26

2026-01-25

2026-01-24

2026-01-23

2026-01-22

2026-01-21

2026-01-20

2026-01-19

2026-01-18

2026-01-17

2026-01-16

2026-01-15

2026-01-14

2026-01-13

2026-01-12

2026-01-11

2026-01-10

2026-01-09

2026-01-08

2026-01-07

2026-01-06

2026-01-05

2026-01-04

2026-01-03

2026-01-02

2026-01-01

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment