killcoder

It's the same asynchronous stream pattern we're used to dealing with in regular software engineering. We have a fixed thread pool, lots of work that can be scheduled concurrently. Since these are streams, we can do the compute incrementally to reduce the time-to-first-byte/token/response.

Since so many tool calls are inherently asynchronous, and subagent task decomposition can be modelled as such, the IO streams can be oversubscribed, and incoming responses can be priority queued.

On the intelligence front, it's incredible how much better frontier models perform when you just interrupt them every so often and go 'is that the best you can do?', or re-iterate instructions, or repeat the overall goal. I find instruction following _so poor_, especially for 'presentation layer' aspects. Yet if I ask the model to rewrite its last response, it does so perfectly. Why can't the model do this 'internally' and save me having to say 'try again'!

Just because the 'model' is autoregressive doesn't mean the system as a whole needs to present a single stream of immutable text.

I had a bit too much fun with the tokenisation diagrams / animations. The raw text is provided to an Astro component, which tokenises it, and forms the individual DOM elements of the tokens. I find it really hard to read 'tokenised' text, I figured some consistent colouring would help. The 'Probabilities' component is a trivial grid, but all the other components support 'word wrap'.

I ended up writing a 'responsive design aware graph colouring solver'.

Multiple screen widths, 'desktop' and 'mobile' are 'simulated', forming an adjacency graph of tokens that touch. Colours are then greedily allocated, then optimised per page over a few hundred iterations, swapping allocations to enforce minimum hue distance between touching tokens at those common screen sizes. The optimising value function prioritises even distribution of colours, because it looks nicer than maximal hue difference.

Originally I naively outputted the palette styles per component, but found the css post processing optimisers didn't handle that as well as I'd have thought. So then I wrote a little 'CSS compiler' that takes the high level palette and timing concepts of the animations, and optimally merges rule declarations.

The start of the post really relies on the animation occurring while fully in view, so I set up some IntersectionObservers that do the 'please scroll' text.

I tried my best to have it all work when JS is disabled on the client. I tried to get the 'hovering' to be CSS-only, but found the JS solution much more performant.

The DAG diagrams are formed with this neat Needleman-Wunsch algorithm from the bioinformatics field. The Astro component accepts several 'examples' then aligns common subsequences, producing the CSS grid and the 'basic SVG' on the server. The responsive nature meant I had to move the final 'allow' generation to the client.

Some browsers seem to throttle the token animations sometimes but I haven't figured out what causes that. This is my first time leaning hard on CSS variables.

The joint state and federal government relief and cleanup package is worth AUD $102.5 million dollars.

I hope the public receives that comparison at every opportunity.

The old website was frankly excellent, the only problem was it didn't have HTTPS support. I would have happily upgraded that part of the system for the cost of a cup of coffee if I'd had an opportunity to submit for the tender!

The new website is significantly more difficult to navigate (for me, a seasoned tech user). The primary thing Dad's everywhere use it for (the weather radar) now requires scrolling to the _bottom_ of the page, and zooming in from the 'map of Australia' to the region you live in. It used to be like, a click to go from home page -> state weather radar with all the info you needed.

https://www.abc.net.au/news/2025-11-23/bureau-of-meteorology...

If you want to read our local news about it.

> [BOM] said the cost breakdown included $4.1 million for the redesign, $79.8 million for the website build, and the site's launch and security testing cost $12.6 million.

Absolutely stupid, even those numbers are outrageous. They say it's part of some 'larger upgrade package', prompted by a cyber attack in 2015.

https://www.abc.net.au/news/2015-12-02/china-blamed-for-cybe...

But politicians over here love to blame cyber attacks when technical blunders happen. We had a census a couple years ago and the website fell over due to 'unprecedented load' or maybe it was a 'DDOS attack'? The news at the time couldn't decide who to blame!

Welp, I hope this gets as much world-wide attention as possible so they can be embarrassed and do better.

But they're claiming it's more token efficient, so me switching my usage to the new model should _free up_ capacity.

https://cookbook.openai.com/articles/openai-harmony

The main process really shouldn’t be used for anything except setup. Since it controls gpu paints amongst other things, blocking on it will cause visible stuttering and a bad user experience.

https://www.electronjs.org/blog/electron-internals-node-inte...

https://www.electronjs.org/docs/latest/api/structures/web-pr...

Separately the IPC lets you do zero copy in some circumstances via Transferable objects such as ArrayBuffers. Structured cloning is efficient but not zero copy, and json serialisation shouldn’t be used (since structured cloning is easily available).

Source: https://www.electronjs.org/docs/latest/api/structures/web-pr...

The other main difference is Electron bundles a known set of APIs, given the known Chromium version. There’s such a huge variance of supported features across the embedded web views.

We’ll probably do a series of power consumption / range tests later on, let me know if there are any setups in particular that you’d be interested in seeing test cases for.

Raw data, firmware and post processing scripts are here on GitHub:

https://github.com/Scottapotamas/embedded-wireless-latency-e...

I think there has been evolution in the underlying data computation side of things, but there are still unsolved questions about 'visibility' of graphical node based approaches. A node based editor is easy to write with, hard to read with.

https://electricui.com/docs/components/LineChart

https://electricui.com/docs/operators/aggregations

Our product, Electric UI, is a series of tools for building user interfaces for hardware devices on desktop. It has a DataFlow streaming computation engine for data processing which leans heavily on TypeScript's generics. It's pretty awesome to be able to have examples in our docs that correctly show the types as they flow through the system. I certainly learn tools faster when they have good autocomplete in the IDE. Twoslash helps bring part of that experience earlier in the development process, right to when you're looking at documentation.

Our site is built with GatsbyJS, the docs are a series of MDX files rendered statically, then served via Cloudflare Pages. We use the remark plugins to statically render the syntax highlighting and hover tag information, then some client-side React to display the right tooltips on hover.

We build a Twoslash environment from a tagged commit of our built TypeScript definitions, from the perspective of our default template. The Twoslash snippets as a result have all the required context built in, given they are actual compiled pieces of code. The imports we display in the docs are the actual imports used when compiling from the perspective of a user. It bothers me when docs only give you some snippet of a deeply nested structure, and you don't know where to put it. Even worse when it's untyped JS! Using Twoslash lets us avoid that kind of thing systematically.

The CI system throws errors when our docs snippets "don't compile", which is very helpful in keeping our docs up to date with our product. Nothing worse than incorrect docs!

We use React components extensively, and I'm not really happy with our prop reference tables which use Palintir's Documentalist. Our components are increasingly using complex TypeScript generics to represent behaviour. The benefits in the IDE are huge, but the relatively dumb display of type information in the prop table leaves something to be desired. I'm most likely going to replace the data for those tables with compile-time generated Twoslash queries.

My only complaints have been around absolute speed of compilation, but I haven't dug deep into improving that. I just set up a per snippet caching layer, and once files are cached, individual changes are refreshed quickly. After all, it's invoking the full TypeScript compiler, and that's its biggest feature.

Overall I've been very happy with Twoslash, and I'm looking forward to refactoring to use this successor and Shikiji (the ESM successor to Shiki), hopefully it improves our performance. The new Twoslash docs are look great, a huge improvement on when we started using it.

https://github.com/Voultapher/sort-research-rs/blob/main/wri...

Discussion here:

https://news.ycombinator.com/item?id=38528452

This post by orlp (creator of Pattern-defeating Quicksort and Glidesort) was linked to in the above post, and I found both to be interesting.

The plugins system has been extremely valuable to us, and the hoisting / peer dependency behavior has been consistently correct, where other package managers have caused bugs.

It's used in the aho-corasick and regex crates. It now supports SIMD acceleration on aarch64 (including Apple's M1 and M2). There are some nice benchmarks included in the PR demonstrating 2-10x speedups for some searches!

I'm searching for songs like Anotherclock by Parcels.

The first one is this ambient electronic song, the next is some reggae, which don't feel very similar to Anotherclock to me.

How does it determine acoustic similarity?

https://news.ycombinator.com/item?id=37545040

Thank you for your kind words!

> I don't comprehend how you made no mistakes on the journey after drafting the PCBs and writing drivers.

As jacoblambda said below, it's about making mistakes recoverable, and failure modes graceful. Scott put a hell of a lot of effort into planning and design, making sure in the end we could get what we needed out of the hardware. During the process, there's a constant stream of problems that are fixed or worked around in pursuit of the end goal. One nice thing about this kind of project is the scope is fixed and known, and scope creep won't happen. We can build safe guards for attaining the known scope instead of predicting future scope creep. Originally we wanted a turbidity sensor in there as well, but we just didn't have the time to get it working.

On one of the boards we reflowed, something happened with the solder paste (it was probably a bit old) and it started exploding (in a small way), sending components flying across the board. Scott had to jump in with tweezers and put stuff back in real time on the hot plate. Unfortunately I had the macro shot set up for the other side of the board so I didn't get to capture it.

Shooting the top down macro shots, it would take literally 6+ minutes for the rig to stop wobbling visually in the footage, so every top down shot is 6+ minutes of swaying footage before the action. It took so long we only did a couple of these shots.

We thought it would be very dark underwater, and brought a camera that could do 12800 ISO base, but it turned out it was actually surprisingly bright on the day, and we ended up way down at ISO 640 for the shoot.

We couldn't get the camera to focus underwater when zoomed to a focal length of 70mm, so there's a whole setup of footage that just didn't work. But since everything had already been shot at 35mm, it wasn't a big deal in the scheme of things.

The camera rig was incredibly buoyant underwater, I had to steal weights from our other divers just so I could get neutrally buoyant.

> Why not make "the perfect espresso machine" or "the perfect bike" or whatever? Why not, with your skills, make a thing and fucking sell it?

I think I can sum up my personal drive as "I like making things", essentially no matter what the thing is, be it hardware or software. I saw that "inventor" character in the movies, and that's who I wanted to be growing up. In most engineering jobs you'd probably be happy to spend 20% of your time making stuff, with the other 80% spent in paperwork. We're trying our best to flip those percentages for ourselves.

We've worked on several projects with hardware together over the years. From multicopters, to camera gimbals, to an entire space ship set for a short film. Time and time again, we found ourselves building user interfaces from scratch, and that was amongst the hardest parts. So we figured maybe there's a business here, and we started Electric UI - tooling for engineers to build user interfaces for their products, both during development and for production. Selling software must be easier than hardware, right?

It turns out it's unfathomably difficult to market products effectively to the right audience, especially if you don't have millions of dollars to blow on targeted advertising. We're constantly seeing the success stories of good marketing and we intrinsically don't see the thousands of shots that didn't work out. There's just a lot of luck involved, hitting the right people at the right times, even assuming you have perfect product-market fit.

We figured our best chance is to go back to our roots and just build stuff that we find interesting, and document the process. Hopefully people will come along for the ride, and other engineers out there will see our user interface software and the next time they're building something that could use a UI, they'll think of us.

It was also a nice excuse to get some macro shots of the PCB assembly process, including some nice footage of solder paste melting and the interesting surface tension interactions.

(I can't seem to get the videos to render in a format that iOS Safari will play, if anyone knows the ffmpeg incantation, please let me know, nothing I've tried has worked on my iPhone...)

sirrandalot on YouTube used the Cycles path tracing renderer in Blender to create a virtual camera setup that acts like a film camera. Light rays pass through modelled lenses, individual colour film layers are simulated in shaders.