I helped do the video recording and the website for the 2013 International Forum on Quality & Safety in healthcare that was held in London at the Excel Center.
One of the talks there was from Qantas Senior Check Captain David Evans, "Teamwork Under Duress" there, which was all about that flight and what happened.
It was an amazing talk, and I have a huge amount of respect for the job that airline pilots do.
I just used it on a Apple M4 MacBook Pro with 48GB RAM with llama.cpp and Pi to help diagnose an infinite looping request in a React Server component on a Next.js application.
After about 10+ hours of digging, it has apparently found a bug in the Next.js framework, with an example app that replicates the bug, and a fix for now to disable prefetch in the Link component.
I had in my prompt asked it to discover the root cause of the bug and propose a fix, but I did not expect it to dig this deep.
I am eyeing one of these specifically for this use case, could you please post roughly what kind of tokens per second numbers you get for text generation for this 27B model?
Using the 4bit quant on an M1 64GB I'm getting ~65 tps for prompt processing and ~11 tps token generation using oMLX to serve the models and pi as a harness.
Prompt submitted at 18:52:54 BST on Sunday 16th August 2026, and finished at 04:05:27 BST on Monday 17th August 2026.
Last print out from the llama.cpp server logs:
881.42.815.480 I slot print_timing: id 2 | task 110233 | prompt eval time = 2742435.76 ms / 134911 tokens ( 20.33 ms per token, 49.19 tokens per second)
881.42.815.483 I slot print_timing: id 2 | task 110233 | eval time = 6312248.28 ms / 5804 tokens ( 1087.57 ms per token, 0.92 tokens per second)
881.42.815.483 I slot print_timing: id 2 | task 110233 | total time = 9054684.04 ms / 140715 tokens
881.42.815.484 I slot print_timing: id 2 | task 110233 | graphs reused = 114795
881.42.820.381 I slot release: id 2 | task 110233 | stop processing: n_tokens = 140714, truncated = 0
In the local minor league hockey games near me the power play (the man advantage resulting from a penalty) is usually sponsored by an electric company. The announcers say things like "..and with that cross-check they're on a TXU Energy Power Play!"
And corporate UX/Design teams are eager to modernize those cards; yes they're already flat, but canary yellow is so last century and some glass effects or abolishing the rounded corners will be the next thing.
“Looks like this is a card. He already has a yellow (sponsored by Qatar Airwaves), and may be looking at his second. YES! he is receiving is second yellow, this time sponsored by Universal Studio, and here is the red card. Sponsored by Red Bull. He is leaving this game and his team mates one down.”
Second commentator: “It is true, Red Bull gives you wings. In this case, the wings only take you to the shower room.”
I follow a local team and don’t really follow the larger picture, but injuries are sponsored, i always thought that would produce a perverse incentive.
EDIT: not sure why i’m getting downvoted, they post up the injured player on the screens with a private medical company prominently displayed.
I have tried to cancel a newspaper subscription in the UK a few times, which is only possible by telephone, and they have a serious churn-reduction program in place where I end up getting a major discount on the subscription.
> Our hypothesis is simple: session logs are now the most important artifact in software development, and should be stored alongside the code itself in the repository.
Pi.dev has a feature where you can export the session as a html file and look at it later. I foresee that potentially you could store this in the same Git repository and get the benefit of reviewing how a particular code change came about during a session with an agent.
I guess the next step would be having the coding agent save that session context automatically in a folder in the git repository rather than requiring a human to export it.
This startup also seems to be operating in a similar space to tangled.org - moving code repos into a decentralised hosting environment.
I will make another update by the end of this week that contains what I call "brain checkpoints" that will make it easier for developers to debug and understand AI reasoning.
The idea is after a task has been finished, you would commit lessons, notes, and "brain checkpoints" that are designed to live with the code.
entire cli maintainer here: the entire cli does exactly this, with support for agent native clis but also pi or opencode. We take the raw session logs, put it in the repo with a stable link to the commit, and then you can render it in the cli or see it in on entire.io.
Meditation is great, but there might also be other options available when it comes to dealing with the effects of context switching.
For me, I find the Pomodoro technique really effective, but there's a key caveat, which is that you try to focus on one thing at a time (which flies in the face of using multiple AI agents working on x number of things at the same time).
Another angle to explore is how much of the process of software development that we do manually can we automate, particularly the parts that still require human input (like code reviews). That may also help with reducing the cognitive load.
>Another angle to explore is how much of the process of software development that we do manually can we automate, particularly the parts that still require human input (like code reviews). That may also help with reducing the cognitive load.
Get your vibe coded software with zero human reviewers away from the public infrastructure.
- Unit tests
- End to End testing with Cucumber and Puppeteer (or Playwright these days)
- Code Coverage analysis
- Lint and formatting checks
- Tools like knit to remove unused code
- Security checking tools like Synk and Socket
- Size checking
If you look at what those tools do, they automate aspects of reviewing PRs. The question then becomes - what still gets done manually, and are there ways to automate that.
https://www.getyarn.io/yarn-clip/0def6aed-0b5b-4856-874a-d97...
reply