HN user
They may only have bought themselves 6 more months of time given their purported burn rate
If they had only ~6 more months they (+auditor) had to issue a warning. The 6 is not a hard number, AFAIK, but surely a point where it must be reported.
So honestly, I doubt it's the case.
Well, the EU regulated USB-C and it affected the whole smartphones world.
It is time to standardize EV batteries like wheels: 5-10 mainstream types & competition on quality vs. price vs. range.
Regulator help is needed here.
Makes sense - This is very similar to fine tuning a down stream task in encoder-decoder architecture (~Bert style)
Was just reading the title and thinking it's a new and upgraded image gen model from Google.. Anyone else?
If the premium models are just about 10% better - that could justify the price vs. self hosting a ~0.5-1T open weights model.
Remember that utilization of these huge racks will not be 24h/7, and these are usually not GPU intensive shops that would train models on the spare compute. With prices of 100-200k USD and north with ~2 years lifetime, that would be hard to justify financially.
Self hosting could easily amount to ~1000 USD a month amortized across many developers. In rush hours - there will be hard rate limits.
Would that 1500-1000=500$ monthly USD justify the 10% decrease in "AI Productivity" ? I guess not. In most cases.
For everyone that asks me around, I'd say that in short term, unless there's a really good reason to self host these coding assistant models, then the big 2/3 coding assistants providers are the better choice.
No one got fired from licensing claude code.
NixPad++
But don't block on the name, you could release it under NejneobhospodařovávatelnějšíPad++ and people will download.
It'll be easy search & replace later once you settle on a name
Are they just copy/pasting their entire ticket description into Claude Code and having it iterate until they land on something that works?
"Their ticket" = that was AI generated. After which they will wait their AI generated PR be checked by an automated AI QA that will validate against the AI generated spec.
It feels like important metric of "corporate AI adoption" should be how effective the human in steering the AI.
IF THE HUMAN ISN'T EFFECTIVE, THE HUMAN NEEDS TO GO.
I already can't remember jq syntax. Naming this jg just means I'll type one, instinctively use the other's syntax, and get an error anyway. It's a DX trap.
But I will admit, the new syntax makes a lot more sense.
An intelligence satellite - which is not a super common utility nations have - will locate where the aircraft _was_ X hours ago, or at least many minutes ago. A constantly updated missile with a rather simple GPS tracker would benefit A LOT from a live location of its target.
There are incredible authors who happen to be dyslexic, and brilliant mathematicians who struggle with basic arithmetic. We don't dismiss their core work just because a minor lemma was miscalculated or a word was misspelled. The same logic applies here: if we dismiss the semantic capabilities of these models based entirely on their token-level spelling flaws, we miss out on their actual utility.
Treat LLMs as dyslexic when it comes to spelling. Assess their strengths and weaknesses accordingly.
Will that protect you from the agent changing the code to bypass those safety mechanisms, since the human is "too slow to respond" or in case of "agent decided emergency"?
Yes, and even holding couple of cartridges for different scenarios e.g image generation, coding, tts/stt, etc
There are so many use cases for small and super fast models that are already in size capacity -
* Many top quality tts and stt models
* Image recognition, object tracking
* speculative decoding, attached to a much bigger model (big/small architecture?)
* agentic loop trying 20 different approaches / algorithms, and then picking the best one
* edited to add! Put 50 such small models to create a SOTA super fast model
In 20$ a die, they could sell Gameboy style cartridges for different models.
Great write-up! There are so many directions you can take it to:
* By training on user data, you can source specific model data images, and then train & classify the airplane model. It might require another model, where only the bbox will be the input, together with distance/calculated measurements of the object ("pixel size"), and the orientation of the plane (side? front? belly?).
* Provide alerts/notification of special aircrafts like helicopters, military, airforce-1, etc'
* When bbox is detected, you can run super-resolution upscaling on the photo/stream of images
This is a perfect example of a "bug" actually being a requirement. The travel industry faced a similar paradox known as the Labor Illusion: users didn't trust results that returned too quickly. Companies intentionally faked the "loading" phase because A/B tests showed that artificial latency increased conversion. The "inefficiency" was the only way to convince users the software was working hard. Millions of collective hours were spent staring at placebo progress bars until Google Flights finally leveraged their search-engine trust to shift the industry to instant results.
Is it? I hope I won't step on somebody's else toes: GenAI would greatly help cover existing functionality and prevent regressions in new implementation. For each tool, generate multiple cases, some based on documentation and some from the LLM understanding of the util. Classic input + expected pairs. Run with both GNU old impl and the new Rust impl.
First - cases where expected+old+new are identical, should go to regression suite. Now a HUMAN should take a look in this order: 1. Cases where expected+old are identical, but rust is different. 2. If time allows - Cases where expected+rust are identical , but old is different.
TBH, after #1 (expected+old, vs. rust) I'd be asking the GenAI to generate more test cases in these faulty areas.
Hey, cool initiative!
Worth mentioning in the title that it's CPU-only: >1200 tokens/s on a single thread is impressive.
Have you considered doing optimization iterations like nanogpt-speedrun? Would be interesting to see how far you can push the performance.
How would you recommend using this for working with multiple agents? I'm thinking about scenarios where you might have several AI coding agents (or automated processes) that need to work on different branches simultaneously without stepping on each other's toes.
Any recommended workflow for coordinating multiple agents? For instance, handling naming conventions, cleanup strategies, or preventing race conditions when multiple agents try to create worktrees at the same time?
This seems like it could be really powerful for that use case, especially with the hook system for per-worktree setup.