The Meta blog has a good post about their usage of FFmpeg and how their years long fork managed to get merged back into the official repo:

Meta executes ffmpeg (the main CLI application) and ffprobe (a utility for obtaining media file properties) binaries tens of billions of times a day, introducing unique challenges when dealing with media files. FFmpeg can easily perform transcoding and editing on individual files, but our workflows have additional requirements to meet our needs. For many years we had to rely on our own internally developed fork of FFmpeg to provide features that have only recently been added to FFmpeg, such as threaded multi-lane encoding and real-time quality metric computation.

Over time, our internal fork came to diverge significantly from the upstream version of FFmpeg. At the same time, new versions of FFmpeg brought support for new codecs and file formats, and reliability improvements, all of which allowed us to ingest more diverse video content from users without disruptions. This necessitated that we support both recent open-source versions of FFmpeg alongside our internal fork. Not only did this create a gradually divergent feature set, it also created challenges around safely rebasing our internal changes to avoid regressions.

As our internal fork became increasingly outdated, we collaborated with FFmpeg developers, FFlabs, and VideoLAN to develop features in FFmpeg that allowed us to fully deprecate our internal fork and rely exclusively on the upstream version for our use cases. Using upstreamed patches and refactorings we’ve been able to fill two important gaps that we had previously relied on our internal fork to fill: threaded, multi-lane transcoding and real-time quality metrics.

What has changed is my understanding of power asymmetry. Large players can treat patents as a tool to extract royalties and fend off competition, while startups often have no choice but to patent execution paths to protect their work from appropriation or exclusion. When legal leverage outweighs originality or execution, ideology alone does not protect you. Used thoughtfully, patents can act as a shield, not a weapon.

This insight is highly relevant for startups building foundational infrastructure in spaces dominated by large companies with better lawyers than engineers.

In many ways, the fact that startups like us feel compelled to file defensive patents proves Martin’s argument. When a system is designed to reward legal capacity instead of novelty or technical merit, even those who believe deeply in openness are forced to engage with it, not out of conviction, but out of necessity.

– Naresh Jain on Ideological Resistance to Patents, Followed by Reluctant Pragmatism

layout: post date: 2026-02-22 20:40 -0800
title: Using Django ORM Without a Project linkblog: true tags: [db] —

Paulo has a post about using Django ORM Standalone. This is a pretty ingenious idea. You still need to install Django since you need some of the core libraries, but you don’t need to initialize a project, admin, etc. It allows you to do some reverse engineering to generate Django models and then query the data using these models.

[… 81]

LLM Usage is Exhausting

I’m frequently finding myself with work on two or three projects running parallel. I can get so much done, but after just an hour or two my mental energy for the day feels almost entirely depleted

• Simon Willison

I’m used to context switching as part of my job, but I was just telling a coworker that because the LLM can reply within seconds, I find myself in a constant mode of high-intensity concentration. I’m perpetually reviewing code and architecting the next task. It’s the same work we’ve always done, but now it’s on a much more compressed timeline due to the sheer speed of the model. This means that I get tired much more quickly than before.

Salvatore Sanfilippo - creator of Redis - has discussed this as well, noting that he feels immense fatigue after just 4-5 hours of this type of work.

The research paper that Simon links to corroborates this:

AI adoption can be unsustainable, causing problems down the line. Once the excitement of experimenting fades, workers can find that their workload has quietly grown and feel stretched from juggling everything that’s suddenly on their plate. That workload creep can in turn lead to cognitive fatigue, burnout, and weakened decision-making. … Some workers described realizing, often in hindsight, that as prompting during breaks became habitual, downtime no longer provided the same sense of recovery. … While this sense of having a “partner” enabled a feeling of momentum, the reality was a continual switching of attention, frequent checking of AI outputs, and a growing number of open tasks. This created cognitive load and a sense of always juggling, even as the work felt productive.

Salvatore offers two tips to help us avoid burnout:

1. Take the initiative: Show the model what needs to be done and ensure you have a deep understanding of the solution, rather than letting the model figure it out and then trying to reverse engineer what it did during your review
2. One project at a time: Avoid the temptation to parallelize just because the AI is fast. Use the time while the LLM is “thinking” to stay deep in the current codebase. You can still use agentic mode for bug fixing or optimization, but for core work, we need to contribute more to the ideas without fracturing our context.

Now excuse me as I go tell my Claude Code and Codex running instances what to do.

edit: It seems that more folks are also saying the same thing:

I find that I am only really comfortable working at that pace for short bursts of a few hours once or occasionally twice a day, even with lots of practice. So I guess what I’m trying to say is, the new workday should be three to four hours. For everyone. It may involve 8 hours of hanging out with people. But not doing this crazy vampire thing the whole time. That will kill people. – Steve Yegge

And

Teachers told us that we could do a maximum of 3-4 hours of revision, after that it became counter-productive. I’ve since noticed that I can only do decent writing for a similar length of time before some kind of brain fog sets in. – Martin Fowler

Cognitive debt, a term gaining tractionrecently, instead communicates the notion that the debt compounded from going fast lives in the brains of the developers and affects their lived experiences and abilities to “go fast” or to make changes. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.

• How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt

A few days ago, OpenAI published how they scaled using Postgres and Azure.

Now Azure goes into a lot of details into how they improved their infrastructure to support this: TCP congestion control algorithms and a DB re-architecture.

To understand how Azure HorizonDB delivers these capabilities, let’s look at its high‑level architecture as shown in Figure 1. It follows a log-centric storage model, where the PostgreSQL writeahead log (WAL) is the sole mechanism used to durably persist changes to storage. PostgreSQL compute nodes never write data pages to storage directly in Azure HorizonDB. Instead, pages and other on-disk structures are treated as derived state and are reconstructed and updated from WAL records by the data storage fleet.

Azure HorizonDB storage uses two separate storage services for WAL and data pages. This separation allows each to be designed and optimized for the very different patterns of reads and writes PostgreSQL does against WAL files in contrast to data pages. The WAL server is optimized for very low latency writes to the tail of a sequential WAL stream and the Page server is designed for random reads and writes across potentially many terabytes of pages.

But the biggest takeaway is that all you really need is Postgres, after all.

One rainy day 40 years ago, Moylan was headed to a meeting across Ford’s campus and hopped in a company car. When he saw the fuel tank was nearly empty, he stopped at a gas pump. What happened next is something that’s happened to all of us: He realized that he’d parked on the wrong side.

Unlike the rest of us, he wasn’t infuriated. He was inspired. By the time he pulled his car around, he was already thinking about how to solve this everyday inconvenience that drives people absolutely crazy. And because the gas pump wasn’t covered by an overhead awning, he was also soaking wet. But when he got back to the office, Moylan didn’t even bother taking off his drenched coat when he started typing the first draft of a memo.

“I would like to propose a small addition,” he wrote, “in all passenger car and truck lines.” The proposal he had in mind was a symbol on the dashboard that would tell drivers which side of the car the gas tank was on. […]

As soon as they read his memo, they began prototyping his little indicator that would be known as the Moylan Arrow. Within months, it was on the dashboard of Ford’s upcoming models. Within years, it was ripped off by the competition. Before long, it was a fixture of just about every car in the world.

…

“Society loves the founder who builds new companies, like Henry Ford,” Ford CEO Jim Farley told me. “I would argue that Jim Moylan is an equally compelling kind of disrupter: an engineer in a large company who insisted on making our daily lives better.” These days, there are two types of drivers: the ones aware of the Moylan Arrow and the ones who get to find out.

– The Genius Whose Simple Invention Saved Us From Shame at the Gas Station

Mario Zechner has launched pi, a multi LLM provider CLI coding agent.

Here’s a post about how they built it and some of the design decisions behind it.

The most interesting is how the tool doesn’t include a lot of the complex features that are common on these tools now:

pi is opinionated about what it won’t do. These are intentional design decisions to minimize context bloat and avoid anti-patterns.

No MCP. Build CLI tools with READMEs (see Skills). The agent reads them on demand. Would you like to know more? If you must, use mcporter.

No sub-agents. Spawn pi instances via tmux, or build your own sub-agent extension. Observability and steerability for you and the agent.

No permission popups. Security theater. Run in a container or build your own with Extensions.

No plan mode. Gather context in one session, write plans to file, start fresh for implementation.

No built-in to-dos. They confuse models. Use a TODO.md file, or build your ownwith extensions.

No background bash. Use tmux. Full observability, direct interaction.

Over at Simon Willison’s blog, he has posted an amazing retrospective on the evolution of LLMs in 2025.

It’s crazy to think that just last year we were talking about how powerful “prompt engineering” could be, yet no one could have imagined that “agentic” mode would take things to the next level.

The popular styled-components React library has been in maintenance mode for a while and it was officially sunset earlier this year.

The great folks at Sanity, decided to fix year’s long performance issues, to buy everyone time to plan a migration strategy.

Our forks accept this reality. Install, get the performance boost, keep shipping while you plan your real migration. … Stage 3: Actual recovery (This quarter)

• Pick your replacement: vanilla-extract, Tailwind, Panda CSS
• Migrate systematically, component by component
• Delete styled-components forever

https://www.sanity.io/blog/cut-styled-components-into-pieces-this-is-our-last-resort

Matt Levine, from Money Stuff newsletter, covers a major misconception about how companies that go public via Initial Public Offerings, leave money on the table when their stock goes up on their first day of trading.

He quotes a paper How much money is really left on the table? Reassessing the measurement of IPO underpricing

IPO issuers are thought to collectively leave billions of dollars “on the table” by underpricing shares relative to the initial trading price. However, this trading price corresponds to relatively small share volume. Because some investors are more optimistic about the shares’ value than others, the trading price exaggerates the maximum feasible IPO price for the larger IPO quantity. We assess the extent of the mismeasurement by introducing a new measure of underpricing that incorporates both share prices and their associated quantities. Using data from 2,937 IPOs from 1993-2023, our evidence suggests that IPOs are underpriced by substantially less than is commonly believed, perhaps up to 40% less.

It turns out that LLMs are as adept as writing Typescript as I am. Which is to say, not very good at all.

From Armin’s In Support of Shitty Types, he says:

This gets really bad when the types themselves are incredibly complicated and non-obvious. TypeScript has arcane expression functionality, and some libraries go overboard with complex constructs (e.g., conditional types). LLMs have little clue how to read any of this. For instance, if you give it access to the .d.ts files from TanStack Router and the forward declaration stuff it uses for the router system to work properly, it doesn’t understand any of it. It guesses, and sometimes guesses badly. It’s utterly confused. When it runs into type errors, it performs all kinds of manipulations, none of which are helpful.

I’ve experienced this when having Claude Code write some Typescript. It doesn’t understand it and I have to end up fixing the most obscure errors.

It seems that compiled languages might fared better (it’s been a while since I’ve worked with them):

the types that Go has are rather strictly enforced. If they are wrong, it won’t compile. Because Go has a much simpler type system that doesn’t support complicated constructs, it works much better—both for LLMs to understand the code they produce and for the LLM to understand real-world libraries you might give to an LLM.

Mario has a great blog post about the history of the web libraries and frameworks and how complex thing are right now. While it ends up focusing on how “not simple” React ended up being, it’s more a commentary of how building web apps is so challenging.

My answer to that question, surprisingly, stops roasting React and goes the opposite way, defending not only React, but also Angular and jQuery and everything that came before them. I think this code is bad because making a interactive UI where any component can update any other component is simply one of the most complicated things you could do in software. … So, this entire rant about React… it’s not even React’s fault. Neither is Angular’s, or jQuery’s. Simply, whichever tech you choose will inevitably crumble down under the impossible complexity of building a reactive UI.

Great long read that brought back so many fond memories about jQuery and Angular 1. But not Angular 2, I will never forgive what they did to it.

The Pragmatic Engineer has a guest post from Birgitta Bockeler, Distinguished Engineer at Thoughtworks, where they talk about the evolution of the AI ecosystem in developing software.

It’s a really good overview of how we got from “autocomplete on steroids” in 2021, to “autonomous background agents” in only 4 years.

This really clicked for me: generative AI tooling is not like any other software. To use it effectively, it’s necessary to adapt to its nature and embrace it. This is a shift that’s especially hard for software engineers who are attached to building deterministic automation. It feels uncomfortable and hacky that these tools sometimes work and other times don’t. Therefore, the first thing to navigate is the mindset change of becoming an effective human in the loop.

This is spot on. It’s hard to trust the tool when it doesn’t always work, but Burgitta provides some ways to improve this:

• Custom instructions about coding style and conventions, tech stack, domain, or just mitigations for common pitfalls the AI falls into.
• Break down the work first into smaller tasks so that it’s easier execute the right changes in small steps, and you have a chance to review the direction the AI is going in and to correct it early, if needed.
• It’s much more effective to start new conversations frequently, and not let the context grow too large because the performance usually degrades.
• A concrete description which will lead to more success is something like, “add a new boolean field ‘editable’ to the DB, expose it through /api/xxx and toggle visibility based on that”.
• Use a form of memory: A common solution to this is to have the AI create and maintain a set of files in the workspace that represent the current task and its context, and then point at them whenever a new session starts. The trick then becomes to have a good idea of how to best structure those files, and what information to include. Cline’s memory bank is one example of a definition of such a memory structure.

I’ve read this online in multiple places, but it’s great to have it all laid out in one spot.

Will has an interesting idea about how authors can still thrive in the age of LLMs.

Instead, I’ve been thinking about how this transition might go right for authors. My favorite idea that I’ve come up with is the idea of written content as “datapacks” for thinking. Buy someone’s book / “datapack”, then upload it into your LLM, and you can immediately operate almost as if you knew the book’s content.

This is a not necessarily a new idea. Kevin Rose has an article where he creates custom ChatGPTs based on specific books .

What’s interesting about Will’s idea, is the role of the author. Instead of having people upload your book to a chat bot (which most likely has already been illegally trained on), you provide a legal way of doing that.

What is our competitive advantage as authors in a future where people are not reading our work? Well, maybe they’re still buying our work in the form of datapacks and such, but it certainly seems likely that book sales, like blog traffic, will be impacted negatively.

Samurai Jack was one of my favorite shows and this article from Animation Obsessive goes in depth, as to what made it so special (and so avant-garde).

That was a core inspiration for his original Samurai Jack (2001–2004). “There are so many sitcoms, especially in animation, that we’ve almost forgotten what animation was about — movement and visuals,” he told the press after the show debuted. The Samurai Jack crew aimed to “tell the stories visually… tell a very simple story visually.”2 Talking was kept to a minimum. Instead, Samurai Jack would need enough richness and variety in its look and movement (and its filmmaking) to keep people gripped without words.

The very limited talking made it so that you had to pay attention during every single second. I don’t think I’ve ever watched a show, before or after, were that has been the case.

Samurai Jack never reached that level. It was popular, though. And that, according to the cynical view, shouldn’t have been possible. Even with its robots and samurai and demons and zombies, Samurai Jack didn’t really fit with the mass culture of its time.

Time for a rewatch.

Do I program any faster? Not really. But it feels like I’ve gained 30% more time in my day because the machine is doing the work. I alternate between giving it instructions, reading a book, and reviewing the changes. If you would have told me even just six months ago that I’d prefer being an engineering lead to a virtual programmer intern over hitting the keys myself, I would not have believed it. I can go can make a coffee, and progress still happens. I can be at the playground with my youngest while work continues in the background. Even as I’m writing this blog post, Claude is doing some refactorings.

Armin Ronacher

I always love getting to see how movies and tv shows are made. There’s something about how the work of hundreds/thousands of people gets orchestrated into what we see. I find it fascinating. Anyways, with Andor season 2 wrapped up (I love this show), here are a few links about how it got made:

• http://www.youtube.com/watch?v=4EWCzic9z_M
• http://www.youtube.com/watch?v=q2WW2emgxRI
• http://www.youtube.com/watch?v=mO1FZB-Rnxk
• http://www.youtube.com/watch?v=PrAWHkGLn7g
• https://www.youtube-nocookie.com/channel/UCBtHgTjADDZ6D2sFFUyH41A

Quoting Justin Garrison

It takes you about the same amount of time to read this post as the amount of downtime you’d be allowed per week with 99.999% availability

I predicted that software engineering as a profession is bound to decline and be replaced by less technical people with AI that are closer to the business problems. I no longer think that will happen, but not for technical reasons, but for social reasons.

What Changed

I saw people code.

I wrote the initial piece after using Cursor’s agent a few times. Since then the tools have gotten even more powerful and I can reliably one-shot entire non-trivial apps. I told a PM buddy about how I was doing it and he wanted to try and… it didn’t work. Not at all.

What I learned:

1. I’m using a lot of hidden technical skills
2. Yes, anyone can do it, but few will

- Tim Kellog