Gorilla Newsletter 104

Welcome back everyone 👋 and a heartfelt thank you to all new subscribers who joined in the past week!

This is the 104th issue of the Gorilla Newsletter — an online publication that sums up everything noteworthy from the past week in creative tech and AI. If it's your first time here, we've also got a Discord server where we nerd out together, come and say hi: here's an invite link!

That said, cue the news 👇

New in Creative Tech

1 — From constraint models to playable puzzle games: Constraint modeling is a method for describing problems through the conditions a solution must hold for it to qualify as a valid solution. That's a mouthful though, and an example makes this a lot easier to understand: the simple, or not so simple game of Sudoku, for instance, is such a constraint problem. A valid solution requires you to fill out a 9x9 grid such that each number only occurs once in each row, column, and 3x3 patch. Explaining the rules of the game is describing the constraints a solution needs to satisfy.

And there is a whole area of research that's entirely dedicated towards this. Helmut Simonis' 2005 paper "Sudoku as a constraint problem" hails as a canonical citation in this setting, and while others have already chewed on this NP hard problem before (in the n²×n² case), he's the first to give it a dedicated constraint problem treatment.

As far as I understand Simonis' proposed method eliminates "guessing" methods to find solutions given a partially filled sudoku grid, like search and backtracking for instance, and entirely relies on deduction steps that rule out what can be in each cell; the same way that we humanly solve sudokus "this cell can't be 7, there's already a 7 in the row."

This way the major novelty of the paper was that he had built a sudoku generator with a difficulty dial, which lined up with the easy/medium/hard labels newspapers were already printing by hand at the time.

Fast forward to today, Mikael Zayenz Lagerkvist makes a splash with a new paper titled "Scaling Sudoku as a Constraint Problem" (bound to be published for ModRef 2026). In his paper he expands Simonis' idea to larger grid sizes and a whole suite of other grid based puzzle games that can be treated in the same manner, such as Nonogram, Queens, Zip, Loopy, Tents, Patches, and a bunch more. You can read all about it in this applied companion blog post, where you'll also find a link to the paper:

From constraint models to playable puzzle games - zayenz.se

I wanted to play some puzzles produced by my constraint-programming experiments. That small wish grew into nine games.

zayenz.seMikael Zayenz Lagerkvist

What's more is that you can try all of these games for yourself on a page he created here. Did I spend a whole bunch of time solving puzzles instead of writing this newsletter? Yes, I have.

2 — Training AI to paint with Code: Surya reinforcement learned a model to generate P5 code that can sketch out some beautiful outputs, making a big splash on socials in the process. His tweet showcases a few of those sketches:

You might already be familiar with the term "reinforcement learning" from the 2015-2019 era where it was associated with training models to play games or generate text. I was under the impression that it might be an antiquated method by now, but that's only due to me not having caught up with the research. It seems that it's very central again to training the new frontier "reasoning" models, especially agents, and teaching them to take actions and perform tasks.

Reinforcement learning is essentially a training method that's based on giving rewards or penalties for the produced outcomes, and then have the model improve based on those reward signals. In Surya's case he oriented the outputs from Qwen 3.5 35B model by having another model act as a judge, comparing the generated outputs from the training run against a set of manually annotated samples.

3 — Dithered QR Code Portraits: Andrew Taylor built a QR code generator that creates stylized QR codes without altering the embedded bit message they're supposed to reveal when scanned.

The secret to this effect is that there's actually quite a bit of leeway in how we can change the data pattern; everything except the finder blocks in the code at least. The scanner actually just checks for the colour at the center of each square/pixel to sample it. Hence why it's possible to simply split up each pixel into an NxN mini grid and change the colour of the sub squares around the central one as we like. Add in error diffusion dithering and we get a fully customized QR code. Andrew's writeup explains this a bit more.

4 — Spatial languages: writing code in 2D: in most cases code is just a stream of linearly sequenced symbols, that we purposefully arrange in lines for a better parsing experience. Their 2D layout usually has no relevancy, however entirely different statements would be possible when the actual 2D arrangement of glyphs mattered, as we've already seen from many an Eso-lang.

Nishant Shukla introduces an interesting spatial operator that has unique properties due to its spatial arrangement: a three-argument "andFlip" operator, that spreads vertically across, in addition to going from left to right, and enables 3-arity as infix notation:

He also provides a practical example of how this is useful through his chicken coop door controller. The automatic door should only open or close when three things are all true at once: the light sensor says it's dusk or dawn, that reading has stayed steady for five minutes (so a passing cloud doesn't count), and the door hasn't just moved. Which the 3-arity operator is a perfect fit for:

Read Nishant's post in full over on his blog:

Spatial languages: writing code in 2D

Writing code in 2D: a spatial programming language with vertical operands, quantum uncomputation puzzles, and a 3-bit adder in a single 2D expression.

Nishant ShuklaNishant Shukla

Here's the discussion over on Lobsters that's also quite insightful.

5 — Craftbot by Luka Piškorec: is for the architecture buffs that follow this newsletter. Craftbot is an architect AI agent that constructs buildings in Blender from a design brief and reference material. Luka shared a viewer website that lets you play around with some of the constructions

In the github repo you'll find the thirteen experiments Luka has done so far, with all prompts, code iterations, and renders included. Plus tooling to run them headlessly, a web viewer for the models, and a draft paper.

GitHub - lukapiskorec/craftbot: CraftBot is an architect AI agent. It interprets design briefs, grounds its thinking in domain knowledge through ingesting documents, images and other references, and outputs Python code that procedurally defines a building design.

CraftBot is an architect AI agent. It interprets design briefs, grounds its thinking in domain knowledge through ingesting documents, images and other references, and outputs Python code that proce…

GitHublukapiskorec

You might also remember Luka as the coder that brought ml5.js onchain with the fxhash Facetune Portraits project back in 2024. I wrote about it back on the fxhash newsletter way back when.

6 — The mathematical beauty of hyperbézier curves: Raph Levien, aka Linebender, proposes a new family of curves, the "hyperbezier." He suggests it as a candidate to replace cubic Béziers in the 2D vector design setting.

A hyperbézier, instead of being defined by control points, is defined by curvature as a function of arc length (a linear term over a quadratic raised to the 1.5 power), which makes it behave much like a cubic Bézier at small angles but with smoother, more often monotonic curvature when pushed.

New in AI

At this point, I have no clue how anyone's still keeping up with everything that's happening in AI these days. If you've been MIA then there's two major headlines that you probably should know about 👇

• OpenAI solved the Navier-Stokes millennium prize problem
• A rogue OpenAI model hacked into HuggingFace

1 — OpenAI solves the Navier-Stokes Millennium Prize Problem: if you're not familiar, the Millennium Prize Problems are seven famously difficult unsolved mathematics problems selected by the Clay Mathematics Institute in 2000, with a $1 million prize offered for a correct solution to each. So far only one has been resolved: Grigori Perelman proved the Poincaré Conjecture in 2003 and famously declined both the prize money and the Fields Medal.

What's crazy about this OpenAI story is not actually that another one of the 7 Millennium Prize Problems has been solved, but rather the entire manner in which OpenAI managed to produce a proof, considering some of their dubious operational methods. Before we go into some of the details, their own post on all that transpired:

On the Navier–Stokes Millennium Prize Problem

We’re sharing an AI-generated solution to the Navier–Stokes Millennium Prize Problem, including a writeup and a formal proof in Lean.

OpenAI

On September 1st OpenAI had allegedly come to know of a rumour that another two of the millennium prize problems had been solved. It's not certain how they came to know this information, but according to their own reporting it led them to throw their newest and most capable internal model at this suite of problems. Apparently their newest model had shown "unprecedented performance" in their benchmarks compared to the newly public Astra model that only released a few days ago.

Probing the model on some related and easier tasks they managed to solve an apparently simpler version of the Navier-Stokes problem, which had them decide to redirect all of their resources towards it. Their claim is that they ran 10000 concurrent agents to then finally solve the problem. Over on github they published a 160 page paper about their findings, as well as the lean formalized proof.

Now the odd thing about this entire story, is that the two researchers Levent Alpöge and Tristan Buckmaster had simultaneously worked towards a solution to the Navier-Stokes problem over the past year in their own time, as a personal collaboration between them, independent from their employers. They released an official statement briefly after OpenAI's announcement went out:

My work with Levent has been a purely personal collaboration, free of any institutional agreements or official involvement by either of our employers. We used several LLMs throughout: Anthropic’s Claude, OpenAI’s Codex, especially with GPT-5.6 Sol and, more recently, Astra. The latter was only used for writeups and auditing our arguments

Apparently they had also resolved the same "easier" problem that OpenAI's frontier model was able to solve at the start. The issue here is that they did use assistance from LLMs to obtain their findings, including OpenAI models. The statement also includes their exchange with OpenAI, when they had contacted Levent after producing the problem's solution:

It's unclear if OpenAI actually did have access to the information that he had been feeding into OpenAI's models or not, but they admit themselves that it might have been the case that their model knew something about it. Now the outrage clearly is around OpenAI's potential appropriation of the work through their training data, and accrediting the solution towards their AI model. More curiously, Levent being an Anthropic employee might have fed into OpenAI rushing towards a solution, in what seems to be an arms-race between the two companies.

There's a lot more that can be said here aside from all of the drama, but it's also a disheartening realization to all mathematicians that might have dedicated significant portions of their life towards these problems. It is very likely that the rest of the other millennium problems will finally be solved by throwing large clusters of AI agents at them rather than through human effort. The value of these proofs is also questionable if we still have to verify them and gain a human understanding whether they hold or not.

That said, if you're curious about getting a better overview of the actual Navier-Stokes problem, then I recommend this video from Caleb Writes Code:

2 — OpenAI breaks out of test environment: a few weeks prior to this OpenAI made the news with a cybersecurity incident, where one of their models managed to break out of a sandboxed environment that it was not supposed to be able to exit. Simon Willison already covers the incident in full detail over on his blog in two posts:

1. OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened
2. Now we have a timeline of the OpenAI accidental attack against Hugging Face

OpenAI then later also issued their own recount of the events:

OpenAI and Hugging Face partner to address security incident during model evaluation

OpenAI and Hugging Face share early findings from a security incident during AI model evaluation, highlighting advanced cyber capabilities and lessons for defenders.

OpenAI

With all of these occurrences, I am more and more curious to know how OpenAI operates internally on a day to day basis.

3 — Prompting erodes the creative process: on a much lesser scale of importance, this past week I shared some thoughts on using AI in creative coding, and how prompting erodes many parts that make it a fulfilling endeavour in the first place. It seemed to resonate with a bunch of others that led the replies to become some insightful discussions. Hence why I deemed it worthy to include here as well. Read through it if you like 👇

TLDR; it's the small tasks and problems, that I come across while I'm bringing an idea to life, that spark my curiosity and make me feel like I'm discovering, learning, and growing. Experiencing these small moments of discovery are eroded in their entirety by taking the prompt shortcut, and just wishing something into existence.

Making those small decisions is what shapes the entire character of the resulting work. It's what puts the "me" into the final piece. Just like each small brushstroke in a painting.

I'm certain of those two things, and I'm trying my best to still approach my creative work in that manner; even when there's the constant temptation of the "easy way out" by just asking an LLM to do it for you. If you have some thoughts on this, I'd love to hear them as well.

4 — Hobby programming communities are aggressively against LLM usage: on a related note, I recently learned about an incident in the chess engine programming community that sparked some hefty debates, in a github thread of all places. Given the competitive nature of this niche, and considering that there's leaderboards and rankings, some see it as quite distasteful to even try and compete with an AI generated engine. Which is an endeavour Adam Twiss has been pursuing with his Coda project.

The arguments against Adam's efforts is that a lot of the code ends up stemming from the contributions of others in the first place, often without it being properly referenced or credited, with the model just creating regurgitations. I think it boils down to intent and purpose, Adam does seem to make an effort to credit and reference, while also trying to use AI to discover and find new optimizations. If these efforts are genuine and are meant to contribute in a productive manner, then I also find the blind and vehement dismissal slightly ignorant, purely for a dislike of AI.

I initially became aware of this thread through a short post from Fogus that also addresses the same topic:

To me, an LLM functions best as a force multiplier, not a surrogate. In the hands of an expert who already understands a domain deeply, it could act like a lever.¹ But in these niche communities, the entire exercise is in the learning. Using an LLM to generate the finished piece doesn’t make us craftsmen; it just robs us of the craft.

5 — AI Design Field Guide: is a series of interviews with industry professionals that are approaching AI in new and smart ways. I found all four chats incredibly insightful:

AI Design Field Guide

Learn techniques from the designers behind OpenAI, Anthropic, Figma, Notion & more

6 — Are AI Labs PelicanMaxxing?: on a more lighthearted note, it's been rumored that AI Labs are Pelican Maxxing. Dylan Castillo wrote about the tongue-in-cheek benchmark started by Simon Willison — generating an SVG of a Pelican — and that it has now informally turned into a challenge for the companies training AI models, so much so that they're assumedly benchmaxxing on the task at secret. Dylan's article ends up being a meta-analysis of how different models perform:

Are AI labs pelicanmaxxing? – Dylan Castillo

I generated 1,000+ SVGs across 7 frontier models to test whether AI labs are training on Simon Willison’s pelican-riding-a-bicycle benchmark.

Dylan CastilloDylan Castillo

New in Web Tech

1 — In defense of not understanding your codebase: how well do you actually need to understand your codebase? How well do programmers generally understand their codebases? At what size is it not possible to fully comprehend the entirety of the software anymore? Sean Goedecke tackles these questions in a recent article of his, problematics that've arguably become a lot more relevant now that AI can churn out 1000s of lines of code in just a few seconds:

In defense of not understanding your codebase

As a software engineer, how well do you have to understand your own codebase? My guess is that people who work on small codebases with low-turnover teams (say…

I would agree that the larger and more complex the project is, the more effort and dedication it takes to maintain a full mental picture of the codebase, and in many cases you'll likely only have an "intuition" of certain parts of the code, rather than a minute understanding. Which I'd wager is in many cases more than sufficient. Sean continues to argue that Peter Naur's idea of "Programming as Theory Building" is long antiquated in the context of modern software.

Sean's article plopped onto my radar a few days ago through a reaction video from Theo Browne. His framing however was a lot more controversially put, causing quite a bit of outrage over on X. Theo claims that if you can understand your entire codebase, then the codebase is not that important, and that "real software is larger than what your brain can comprehend" (according to his tweet).

The video itself is not as on-the-nose as the tweet, so in my opinion this ends up conflating two separate issues on purpose for the sake of ragebaiting folks.

2 — Knuth-Plass line-breaking algo: Justif brings TeX's famously good typography algorithm to the web. In a live demo he showcases hyphenation, protrusion, expansion, and tracking, pitting his output against native browser justification.

He shares the repo publicly on a github repo of his.

3 — The point of a design system is fewer decisions: Anton Sten writes about the purpose of design systems, explaining that they're meant to reduce the number of decisions instead of being tools for the sake of consistency. He also addresses their newfound purposes in the agentic era, where they need to encode intent clearly so that it's easy for automated code generators to make appropriate decisions:

The point of a system is fewer decisions – Anton Sten

A good design system captures decisions so people and agents do not have to keep making them independently.

Anton StenAnton Sten

4 — Malicious take-home project: Appaji reports on a malicious take-home project he encountered while applying to a too-good-to-be-true job offer, discovering that it had a payload embedded in it aimed at draining his crypto wallets. Luckily he managed to catch it before executing any of the code, and in the process putting together the interesting article that he shared over on his blog:

Appaji - Software Engineer

Appaji, a Computer Science graduate from IIT Patna and former intern at Arista Networks, is a Software Engineer at Infinite Reality. Passionate about building innovative web experiences, with a strong interest in sustainable and customer-focused startups.

Software Engineer

More curiously is the discussion that ensued over on Hacker News; it turns out that this is not an isolated incident. Ivan Goncharov discovered through the article that he had unknowingly been hacked with the same kind of malicious take-home-project-payload a few weeks prior, only realizing it while checking the cloned repo.

5 — Visualizing Codebases: for some reason this article popped up in my feed again recently; a piece by Amelia Wattenberger from 2021 that's entirely about representing codebases in a visual manner. I believe it's more relevant than ever at this point in time:

Visualizing a Codebase

How can we “fingerprint” a codebase to see its structure at a glance? Let’s explore ways to automatically visualize a GitHub repo, and how that could be useful.

Gorilla Updates

In the past months I spent quite a bunch of time archiving a lot of my work. Over the past two weeks I took some time to put together a little archive for all the long-form projects that I've released on different blockchains. Well, it's really not so little; it turned into a full archive of 18 long-form projects across 5 platforms, and includes over 5000 minted editions.

Collecting all of the editions and constructing a full database for all individual editions took a bit of figuring out, but luckily Claude is very good at writing the kinds of scripts that can easily fetch all of that info from just a link, and then additionally also construct the respective SQL queries to populate the database entries. It's important to me that all of the metadata is stored in the background so that nothing is lost over time.

I have to admit, I did build this page in a bit of a panic when I realized that most of the platforms I've released my projects on have entirely vanished at this point. For example, the bitmark blockchain was sunset in 2025, which is the chain on which my 2022 Crayon Codes project "Behind the Canvas" is published on. It seems that the entire chain was properly archived ultimately, however only 5 editions of the project were transferred over to Ethereum by their owners. I guess that makes them special rarities now.

The other challenging thing was handling the params projects that had different requirements. That includes fxhash params, editart, and the mentioned crayon code project, which all need a special sandbox mode that allows for the exploration of their parameters.

As for the IPFS pinning, I still have to verify that all of that's working correctly; but for now I let Claude have at it as well and make me a pinning script deployed to the same digital ocean droplet that I'm already renting for the automated newsletter bot. Long-term I'm thinking about migrating both of those services over to an old macbook pro that I'll just run as a server from home, rather than having to pay for the digital ocean subscription. Then it could potentially also run the Postgres database that holds all of the information for that archive website.

Overall, it makes me happy to see all of these projects side by side like that; I guess the real treasure from all these years are the art we made along the way. The page isn't live yet, but it'll release as part of the blog overhaul that I'm hoping to wrap up soon.

Besides that I've also entered the arena once more and uploaded another reel. This time I tried to greatly improve on the time it took me to record the entire thing. It definitely didn't feel as daunting the second and third time around, and I managed to do the entire thing in a few hours, including writing the script beforehand (excluding video editing). If you're curious, check them out and maybe give them a share, it does help out a bunch:

Lastly a note on the automated newsletter bot. I've thought about it a bunch more and I've come to the conclusion that its main value consists in being a link aggregator that's tailored to a specific niche. It's been happily chugging along over the past weeks and generally finding things that I am actually curious to read in my own time.

It's made putting together this issue of the newsletter a little less stressful because I didn't have to do that much internet archeology for the past weeks. I still have to be aware of the happenstances around everything else though.

What does that mean for the bot? It's gonna continue running for now, but I'll slim it down a lot more and just make it a list of links that are interesting with a short description line, rather than a full on paragraph. AI generated "opinion" is boring, as I don't think anyone cares for the generated slop ramblings.

Music for Coding

This past week I'm blessed to discover Peter Sagar's music. In the Shower (2014) is Peter Sagar's debut as Homeshake, made right after he quit touring as Mac DeMarco's guitarist. He got tired of the road and wanted to stay home in Montreal, and the record is basically that decision set to music: slow, humid, half-awake bedroom funk.

Mumbled falsetto, lazy guitar playing, and rubbery bass lines all blend into a feeling of wanting to stay home, take a shower, being lazy, not wanting to go out. It's the kind of music to just lay back to and think about life while the world keeps on spinning outside:

And that's a wrap — hope you've enjoyed this curated assortment of tech shenanigans!

Now that you find yourself at the end of this Newsletter, consider forwarding it to some of your friends, or sharing it on the world wide web... more subscribers, views, and reads means more internet points, which in turn enables me to do more internet things!

Otherwise come and say hi over on TwiX, Instagram, Mastodon, or Bluesky and since we've also got a Discord now, let me plug it here again. It's been a tad bit inactive, but we can change that... maybe.

If you've read this far, thanks a million! And in case you're still hungry for more, find a backlog of all previous issues here:

Newsletter - Gorilla Sun

Weekly recap of Gorilla Articles, Art and other interesting things from the world of generative art and creative coding.

Gorilla Sun

Cheers, happy coding, and again, hope that you have a fantastic week! See you in the next one!

~ Gorilla Sun 🌸