another_twist

Amazon simply doesnt have the motivation or the DNA to do groundbreaking innovation especially one thats R&D heavy like machine learning. They are good with distributed systems but are quite bad at almost anything else. We are talking pure software here without the commerce arm.

Wow. Cant you sue for wrongful termination ? I am assuming this was considered and not followed through. What are the legal details here ?

Good to see leaders stand up for what they believe in. Soemtimes I simply do not understand this obsession with controlling the internet by European countries. So ridiculous.

Regulatory capture begins.

I am on the 25 dollar plan and I never even come close to hitting the weekly limit. Still manage to ship quite a bit. Not sure how folks hit their Claude limits. I have handle on the codebase though.

Umm, observability ? I think the article means to say how do you know the agents arent talking nonsense to each other if you use a multi-agent system. Here again a thin layer of o11y would do the trick and also hooking into the wider ecosystem. Thats without having to bother with a proxy.

Took me a while to get used to sealed and I didn't quite see the use. But AI seems to love it for Java so I gave it a go and now I get it. Its like a really good access control mechanism esp if you use DI and want to deprecated some stuff. Apart from ofcourse the pattern matching - which comes in handy for event driven messages where payload shape changes.

Not only is this a huge market, this is a very very good step in the right direction for mozilla. Plenty of integrations can be done browser natively such as phishing site blocking (thats likely the most demanded one). Access controls at this level can also make up for short comings in Web based tools. Not to mention their focus on privacy which benefits the average user. Love it !

LLMs consistently produce better quality code and miss less edge cases imo. I think its ridiculous to assume people don't care about quality. Its also really hard to measure quality so subjective debates around it never end. In the dnd, if LLM produces an output I can understand, I'd rather delegate and move on.

I think its perfectly fine to have AI write and review code but someone needs to keep track of the business logic. Otherwise its difficult to debug what happens when things break or when context misses a few older assumptions. We go into an infinite loop with LLM writing, reviewing, documenting, designing and validating software one feature after the other but right now, we are context limited. Plus if LLM ever gets stuck, it's hard to prompt it away unless somebody understands the output.

> Do you feel like you're getting good value for money if you solve a millenium problem at a fourteen million dollar loss?

Yes you do. If we factor in wages assigned to skilled mathematicians who have worked on this problem, then the 14m for a 1mUSD prize is good value. Also, once things are solved, it on to applications where even more value could potentially be generated. Here its 1m USD simply because theres a proze assigned to it. But once these solution are used in applications, the yield is calculated on the 14m RnD cost. Which (depending on the application) is a good investment.

I am okay with companies shilling their tools. Ultimately I'd want my employer to buy good tools that make our lives easier specifically wrt debugging which I genuinely hate. However this post could have been a better walk through about what Claude found, what was the exact root cause and how it can be fixed instead of the generic Anthithesis found it in 15m.

This is an interesting direction. I wonder if Open LLM models can help with this sort of thing.

I think its also about tolerance for failure. For software that must not fail or where reliability commands a premium you would be wise to invest in formal methods. Core systems at aws for example. For throwaway CRUD code its just easier to try iterations on the problem and call it a day. Its not about respect just RoI.

Wtf does Palantir have to do with AI. Nobody at Palantir can train an LLM from scratch or even fine tune.

This is the thing. You "spend" lines of code, you dont produce it. The produced part is the outcome - a functional feature, stability improvements, some business outcome. Measuring productivity with LoCs is like measuring output with cash burn.

Same sentiment here. B-tier hit factory stuff is easy to catch and easier to ignore and move on from. Also happy to recognize a fellow Stevie Wonder fan.

I want to use shad-CN but instead end up defaulting to Mantine everytime. Its just so much faster than having to remember which contexts to wire in.

Been a fan of searX for a while. Not sure if this is the same thing but there were plenty of hosted versions too.

i am not sure if a lean port is important. TLA+ could do with a bit more TLC (pun intended) with regards its devEx.

Also congratulations to the author, I'll try and reproduce this over the weekend.

> high availability / redundancy, hosting, backups, business continuity, audits, someone to grill when there is a leak.

All but one of these is a tech problem though.

No, he replaced older workers with new cheaper ones. Can't say that out loud or it might lead to lawsuits.

What was the compostion of folks let go by Cloudflare ? How many working in profitable lines ? How many in loss leaders ? How many engineers ? How many supporting business functions ?

I mean this students parents were likely big donors. That would explain a lot.

I've noticed laziness in claude repeatedly. It sometimes takes the shortest way out even when asked explicitly to do the "right" thing.

Is it just me that I simply don't care ? I never one-shot these tasks, always provide a breakdown and always give the AI straightforward tasks that would take too much typing. The approach seems to work just fine regardless of the model. If it gets stuck, I usually take over and do the task myself. Also allows me to plan for throughput rather than latency - i.e. start 2-3 small tasks in parallel and do 1 complicated task or planning myself. It works whether I use codex or claude. I lean more towards codex since its cheaper. Even aider gets good results this way.

Underrated advice here.

I guess the question is who is your customer or more specifically who's your buyer, who's your user and where do they hang out ? Also how do people find out about you product ? Distribution takes time, so I think its important to gauge interest upfront rather than commit to building first.

In general, the answer usually is to find people in your own network. If you go by that funnel the first thing you need is a network. LI is great at this. The next thing is to see who in your network is worth talking to. Find out whether the pain-point that you recognized resonates with them. A LI blast to your network might work as well to give you a bit of credibility. One thing that is cited often that does NOT work is spamming people asking for their time to learn about a problem. Nobody ever got back to me wit this method. But asking people in your own network for warm intros almost always works.

I dont think the Spring ecosystem is bad. In fact, its one of the more stable frameworks. Even spring AI which is built for AI agents a new use-case is very intuitive if you take time to learn its abstractions. Usually doesnt take more than a day of reading docs and writing some try-out code. The thing I really like about Java is the stability of its packaging ecosystem. Maven is XML (yuck) but is okay with the IDE integrations. Gradle has advanced features often missing in Python / Go such as build caching. The OOP stuff is also good because it scales with very large code bases. In, fact frontend esp React adopted a functional style which leads to complexities associated with hooks. A mixed approach is usually better. Overall, the only bad thing are the multiple unnecessary abstraction layers which are a pain in any language. Rest of Java is quite good.

GPT doing a great job summarizing and providing a counter:

what's they key thesis here and the argument ?

*Key thesis:* When technology eliminates meaningful performance differences between products, industries shift from competing on *engineering and function* to competing on *brand and status*. The Swiss watch industry after the quartz crisis is a clear example: mechanical watches stopped being valuable tools and became *luxury symbols whose value comes mainly from branding, scarcity, and signaling wealth*.

*In one sentence:* The essay argues that when technology makes functional differences between products disappear, industries shift from engineering competition to branding competition, and the modern luxury watch market illustrates how that transformation works.

---

If you want, I can also explain *why this essay is controversial among economists and designers*—there are a few big assumptions in the argument.

And the counter A few places the argument is debatable (even if it’s persuasive as a narrative):

It treats “brand” and “engineering” as mostly opposed. In practice, luxury buyers often do pay for engineering (finishing, durability, serviceability, movement architecture), and those technical choices can reinforce brand rather than fight it. The tension is real, but not always zero-sum.

It downplays other drivers of the Swiss recovery. The rebound isn’t only “they discovered brand.” Things like Swatch’s role in recapitalizing distribution/production, industry consolidation, improvements in manufacturing, and globalization of luxury demand can explain a lot of the late-1980s revenue surge alongside marketing.

The “artificial scarcity = managed asset bubble” framing is provocative but contestable. Scarcity can be interpreted as: capacity constraints, quality control, long-term brand stewardship, or channel strategy—not necessarily “bubble management.” It may function bubble-like in resale markets, but that doesn’t prove intent or fragility in the way financial bubbles work.

Some claims are asserted more than demonstrated. Examples: Rolex “abandoned research” after ~1960; “only three survived as independents”; “most brands are owned by six holding companies”; “they rebuy hundreds per year.” These might be true in broad strokes, but the essay uses them as load-bearing supports without showing evidence in-text (beyond a couple notes).

The design-history claims are simplified. Watch size and shape trends aren’t only branding; they’re also driven by changing tastes, ergonomics, manufacturing norms, sport/tool styling, and shifting notions of masculinity. “Big = cheap historically” is directionally true in some eras, but not a universal law.

The gender section is especially shaky. “Women never really went for mechanical watches” and the steam-engine analogy read like overgeneralizations—there are strong counterexamples (and cultural variation) that complicate that story.