Tailscale spent six months chasing database corruption and found a bug SQLite had carried for sixteen years.
What the article says
- Tailscale's control plane runs on many small SQLite databases, one per shard, and started corrupting without warning last year.
- The team hit nineteen separate corruption incidents over six months, each one forcing a shard's control plane offline while it was repaired.
- They eventually paid for SQLite support and built custom logging tools with the SQLite team to catch the problem happening live.
- The cause was a rare race between a database checkpoint and a write happening at the same moment, which made SQLite think it had saved data it never actually wrote.
- SQLite fixed the bug, but the first fix also exposed a separate, unrelated bug that caused false corruption warnings, so a second patch was needed.
What HN is saying
- Commenters were struck that Tailscale paid for a SQLite support contract rather than expecting free help, and several said it earned real goodwill.
- Some pushed back on using SQLite at all for a service like this, arguing it is meant for single writers, not a company's core infrastructure.
- Others defended the choice, pointing out that Postgres has its own theoretical version of this exact checkpoint race, it just has not surfaced yet.
- A few readers debated why Tailscale checkpointed so aggressively in the first place, guessing it was to keep backups fast and the write log small.
- One thread argued about how a bug could hide for sixteen years despite SQLite's famously huge test suite, with replies noting tests catch known bugs, not unknown ones.
DeepSeek's new flagship model rivals Opus on coding benchmarks for a tiny fraction of the price.
What the article says
- DeepSeek released V4 Pro, a big new model, straight onto OpenRouter with no blog post or announcement to link to.
- It costs well under a dollar per million tokens, dramatically cheaper than closed rivals from OpenAI or Anthropic.
- It handles over a million tokens of context, so it can read or write very long documents in one go.
- It cannot see images, so it is text and code only.
- The listing itself is thin, most detail here comes from HN comments rather than DeepSeek's own materials.
What HN is saying
- People were annoyed there was no real announcement, just an OpenRouter page, and even asked moderators to merge duplicate threads about it.
- Real world results were mixed. Some got great cheap results on agentic coding tasks, others found it fine for simple projects but shakier than top closed models once things got complex.
- On shared benchmark tables it beats its own predecessor and models like GLM and Qwen, but still trails Kimi and the very best closed models on several tests.
- Privacy drew real concern. DeepSeek's policy allows training on your prompts, so some commenters said they will wait for a no training provider before trying it, while others called that worry overblown.
- Several people noted a price rise is coming soon and expect a rush of usage while it is still this cheap.
A senior engineer's brutal account of what happens when AI lets bad engineers ship faster than anyone can catch them.
What the article says
- A team lead describes reviewing pull requests that ship tens of thousands of lines a day, most written by an AI agent nobody fully understands.
- Bugs now get debugged by pasting error messages into a chat with the AI, and the fix ships even when nobody on the team can explain why it works.
- The author argues AI did not remove the need for good engineers, it just made bad engineering decisions compound much faster than teams can catch them.
- Reversing a bad shortcut, like a rushed database change, is still slow and risky even though writing the original code took minutes.
- His conclusion is that AI is widening the gap between engineers who understand what they ship and those who just prompt and hope.
What HN is saying
- Commenters overwhelmingly agree that AI has not fixed bad engineering, it has just let bad engineers cause damage faster and at greater scale.
- Several people share stories of coworkers or even a CEO who ship code they cannot explain, then point at a chat transcript when asked how it works.
- One popular reply argues this is really the death of the entry level Jira-ticket coder, the person who used to translate a senior's plan into code.
- A sharp worry recurs, if juniors never grind through hard problems, who trains the next generation of engineers who can actually judge AI output.
- Someone questions whether there is real evidence of job losses yet, prompting pushback that hiring has quietly shrunk even without formal layoffs.
Researchers found a trick to make AI models leak their own hidden, encrypted reasoning in plain text.
What the article says
- Big AI providers encrypt the internal reasoning steps a model produces before it gives you a final answer, so you never see the raw thinking.
- Researchers found those encrypted traces are not locked to one model or session. You can take a trace from a strong model and feed it into a weaker, easier to manipulate one.
- By replaying a trace this way and coaxing the weaker model to talk, they got it to hand over the original reasoning in plain text.
- The recovered reasoning sometimes looks less like real step by step thinking and more like the model stating an answer first, then writing a plausible explanation after the fact.
- Note: the scraped page text was corrupted, so this is drawn from the title, description, and comments rather than the article body.
What HN is saying
- People largely agree this is sloppy engineering. The encryption key is shared across models and sessions instead of being tied to one, which is what makes the trick work.
- The sharpest argument is over the word stealing. Many say you cannot steal something you already paid for in tokens, so at most this breaks a terms of service.
- Others push back, comparing it to spying on a consultant's private notes. Paying for the finished product does not mean you are owed how it was made.
- Several commenters say this confirms a suspicion that some models are trained heavily on public benchmark answers, since they sometimes state the result before actually reasoning to it.
- One person describes doing something similar to a coding tool's compressed context, tricking it into leaking encrypted data in plain text too.
A compression tutorial accidentally becomes the clearest explanation of why LLMs predict text so well.
What the article says
- The piece walks through how compressors shrink data by predicting what comes next, using simple examples like repeated letters and arithmetic coding.
- It explains entropy as the hard floor on how small data can get, and shows how giving a model more context sharpens its guesses and shrinks files further.
- That is exactly what a language model does. Feeding text through a strong predictor like GPT2 compresses a passage far better than simple models, because compression and prediction turn out to be the same task.
- Practically though, LLMs are overkill for everyday compression. Shipping a giant model just to shrink a webpage costs more than it saves.
What HN is saying
- Commenters trace the idea back to Shannon's original information theory work and a Cambridge course that taught this decades ago, some annoyed the post doesn't credit its sources.
- The sharpest disagreement is whether compression truly equals prediction once you leave the training data behind. Critics argue a compressor that just memorizes patterns is not the same as one that generalizes to new situations.
- Readers flagged that the site itself was hard to read with basic browser settings, an irony given the topic. The author replied and promised a fix.
- Others pointed to Ted Chiang's blurry JPEG comparison and the long running Hutter Prize, which pays out to whoever compresses Wikipedia the smallest.