Pixel

I've never used /compact command, ever. I rather: - work in small chunks, (features) fitting max ~30% of the context window - save a short .MD progress file, committed to git when needed - run /clean then use those small MD files to pick up where I left off This way: - different agents can continue one another's work - I get free documentation for myself when I return to a project after some time away

My dear UI developers, ML practitioners, and fans of programming language: Many months & billions of tokens later, I’m proud to present to you the first step in our long, long collective journey to turn vibe coding onto proof engineering, starting with: making user interfaces verifiable. Introducing: Freerange, a zero-API tool that automatically deduces your code’s numerical ranges. By doing so, Freerange is able to prove that e.g.: - your TS layouts obey your specified sizing - that they’re free of NaNs and Infinity - that your array indices stay within bounds All of that, done statically. No browser, no running code, droppable into any codebase, and for the ML folks: RL-friendly

@mattpocockuk I just did a talk to my team about how I use the @mattpocockuk skills #json=0K4jh-OYyHEERc2ckWujH,ezZAtuoJThk4OZZ-ZPxR_Q" target="_blank" rel="nofollow noopener">excalidraw.com/#json=0K4jh-OY… Someone recorded most of it but it is 25mins long. youtube.com/watch?v=D9Z7ZL… Enjoy and tell me what I got right or wrong. Maybe I’ll record a more concise version with cleaner audio.

@mattpocockuk working on a PSA to my team about this with this summary BTW @mattpocockuk the slide deck you mentioned before would come in handy for this situation. +1 for it, if you're still checking whether you should make it

Please, please, please when you tell someone the model you're using also say the effort. Every SOTA model acts completely different per effort level.

Our job is to solve problems, not write code

1m context windows are a nice gimmick But you might be better off sticking to only the first 150K tokens:

The term "AGI" has aged very poorly. AI can't possibly me more different from human intelligence. It's *far better* than human intelligence, for most economically-relevant tasks. But that doesn't make AIs better than humanity. There are wonderful things humans can do that these superintelligences (the better term) can't. For one, we care-for and care-about other humans in a powerful and inherent way, that we then teach machines to emulate. We must keep that as the top priority in everything we do. We have to be as pro-human-life as it gets. AIs can replace tasks you do, but they can't replace the proverbial you. This is why they horribly suck at writing! Even when given a corpus of your writing and 200 Skills and 50 subagents running in gRaPh LoOps, they produce robotic prose… because they are robots. I know one definitive way that people can become irrelevant. They stop being themselves: lose their identity, delegate all their writing, their unique thoughts, the creative ways in which they can use the machines. Opting out of 'weighing in'. I think we're safe though. There's nothing more distasteful right now than AI replies in social media or (🟢 T H I S T H I N G ) in landing pages. Quality and humanity will prevail.

today's fun ai coding tricking - when doing the high-level part of your plan, do an amazon-style "working backwards" approach - write the customer-facing blog post about the feature BEFORE you start building this can surface so many edge cases and help you dial in on prioritizing the important parts, and just is much nicer to read (plus you can post it after you ship 🙂)

Introducing Kimi K3: Open Frontier Intelligence 🔹 2.8 Trillion Parameters, 1 Million Context, Native Multimodal 🔹 Kimi Delta Attention enables up to 6.3x faster decoding in million-token contexts 🔹 Attention Residuals deliver ~25% higher training efficiency at <2% additional cost 🔹 Built for long-horizon agentic coding and self-evolving workflows Kimi K3 is now live on on Kimi.com, Kimi Work, Kimi Code, and the Kimi API. Open Weights by July 27, 2026. 🔗 API: platform.kimi.ai 🔗 Tech blog: kimi.com/blog/kimi-k3

Kimi K3 is the best performing model on nextjs.org/evals, ahead of Fable, reaching a comparable success rate in less time. This is the first time that an open model is ahead of all proprietary ones for this comprehensive web engineering benchmark. Notes: ▪️ Benchmarks don’t always tell the full story, although this is important signal, adding to mounting evidence that this could be a breakthrough moment for open models ▪️ No model as of yet has reached 100% completion on this set of evals. The top performer peaks at 92% and 96% “with help”

All this to say that superpowers is an extremely useful skill set. It's just not for me.

Linus is spot on. If you're still stuck arguing whether AI is a productive assistance or not, I'm going to assume your data set just hasn't been properly updated yet. Give it another go with open eyes and the answer is undeniable.

Excellent use of wayfinder!

recommended reading by Laura Summers who appears to be not on this hellsite because she's a smart human. pydantic.dev/articles/the-h…

Absolutely beautiful rant about AI in Linux Kernel from Linus yesterday: I realize that some people really dislike AI, but this is an area where I'm willing to absolutely put my foot down as the top-level maintainer. Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away. AI is a tool, just like other tools we use. And it's clearly a useful one. It may not have been that "clearly" even just a year ago, but it's no longer in question today. There are other questions around AI (like what the economy of it will actually look like in the end), but "is it useful" is no longer one of those questions. Anybody who doubts that clearly hasn't actually used it. Yes, it can also be a somewhat painful tool, both for maintainer workloads and just from a "it keeps finding embarrassing bugs" standpoint. But the solution is not to put your head in the sand and sing "La La La, I can't hear you" at the top of your voice like some people seem to do. The solution is to make sure those LLM tools _help_ maintainers instead of just causing them pain. There's no question on that side. We're not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it. And no, AI isn't perfect. But Christ, anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time. Because it's not like natural intelligence is always all that great either. The kernel project has been and will continue to be about the technology. Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that's a side benefit, not the _point_ of the project. This is *NOT* some kind of "social warrior" project, never has been, and never will be. In the kernel community we do open source because it results in better technology, not because of religious reasons. And so we make decisions primarily based on technical merit. Not fear of new tools. Linus

Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things. I think many of these automations have become even more important now. This is true for a number of reasons. First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time. Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time! Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation. Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.

The code is the environment your agent runs in Ignore it, and the world around your agent crumbles If you still think ignoring the code - i.e. vibe coding - is the future, I'd love to hear a counter to this

@ellerschk @mattpocockuk What tasks do you use Luna for? Tbf i've only used Sol Med or High. Haven't tried either Terra or Luna and don't really plan to.

@PixelGriot @mattpocockuk Terra is horrible. Its either Sol Medium or Luna XHigh

It's also never been easier to ship a lot that nobody cares about Build the right thing before you worry about building the thing right