jmalicki

Now you spend all day in meetings getting alignment, and a half hour prompting Claude to let it rip.

For math classes there is not a single correct answer, it's worse in that regard than many other fields.

Answers are proofs, not numbers, and there is a ton of nuance, and it is incredibly hard to grade.

It's not as easy as judging the quality of a computer program written as an assignment.

(Some random internet user pasted me things that were clearly from my ChatGPT session, he identified me because it had links to my github). So it wasn't a hallucination, it appeared to be some sort of KV cache leakage, though I obviously don't know the true root cause of the bug.

I've had this happen with ChatGPT too.

Exactly what the quote is about!

And that's a critique of the original article... that the broader "S&P 493" isn't showing gains might be for the reasons you describe.

> is that not measurable?

It was not on a level that nudges GDP growth for a long time. The irony is that maybe the productivity didn't increase until book publishing plummeted, since enabling a lack of physical books was a huge productivity win.

This isn't a debate about whether industries improved. When you look at GDP, do you see an uptick in GDP or not?

The original quote was often seen as a paradox. At least one major interpretation of the original quote is that "the computer revolution is so obviously helping the economy, that if it doesn't show up in GDP, is it even a meaningful measurement, and how can we fix that?"

But it is very fitting to discuss that quote - the original article discusses multifactor productivity, the same relevant measurement, and earnings of the S&P 493. There are two ways to interpret it - is AI not increasing productivity, or are we not measuring productivity, and is there "dark matter" somewhere in the economy that is not being properly measured?

> the person who said that obviously never checked on book and magazine and newspaper typesetting

That's one of the "everywheres" the author of the statement was talking about, which is the point - you could see every part of the economy seemingly improved, but it did not show up at the macroeconomic measurement level.

It was until the 2000s that computers caused an uptick in measured productivity at the GDP level, though.

Economics isn't a zero-sum game.

If companies can better understand their customers so they can give me products that better fit my needs, or inform me of products I couldn't have known about otherwise, that's a win for everyone.

I'm assuming they mean Scala doesn't have the tortured Haskell IO monad.

> Cough IRC, email

Luckily the first, and increasingly the second, are being replaced by Slack!

You can get ZDR for OpenAI models through AWS Bedrock or Azure without OAI ever touching your data.

OpenAI never even gets the data, those orgs get to host OAI's model as local within their datacenters, OAI never touches it - you still have to trust Google, MS, Amazon, but I would trust any of them before OAI directly.

Are there keywords to search for to read more? This is the first time I've heard about this! This is super interesting, what are a few well known other stable matches people deeper into this talk about?

Both... even subagents inheriting the context window doesn't cost a huge amount if the context window was never that large, but yes orchestrating/conducting/managing multiple agents is even better though higher thought cost (but the newer claude agents are really good at this in my experience, part of why I am using Claude a lot lately despite the models being more expensive that ChatGPT's for the same performance when taken alone).

Whenever I see my main agent do a compaction, that to me is a clear sign I didn't have it delegate bounded tasks enough.

Use more subagents.

The longer your chat gets, the slower and more expensive it gets.

Subagents are expensive but they scale way closer to O(n) than O(n^2).

Have some agents make bug reports/feature requests/roadmaps (linear is very AI friendly), others coordinate, others work on grinding out an individual ticket.

If there is a good ticket-level description, it's a waste of time IMO to have a main agent do it, that should be an agent with fresh context that will do it better faster (the shorter the context, the better models are at using the context they're given).

Because tesla has always been selling dollars for $0.50. Investing in their product lines doesn't help them, it's always been a grift and a shell game. Some great products have come out of it, but the valuation has never been one where selling more products helps the business, unless it can lead to the hype train.

Wouldn't that be amazing, to get greater competition and progress? You seem to be implying there's some negative.

I have not personally reviewed the benchmarks, but recall seeing a post where a Linear SVM with bag-of-words features outperformed Jev on many simple NLP classification tasks, like the ones you cite. You don't even need embeddings!

> unable to make a bespoke model targeting the specific problem?

There is a fixed cost (and some maintenance) to e.g. fine tuning ModernBERT.

Maybe once you include all of that it might be a half-day to a day of engineering time to set everything up in a maintainable fashion.

For Jev, it takes all of 30 seconds of prompting. And it's not that much more expensive to deploy vs. a BERT model.

By reading, not generating, text.

I worked at one company hire a part-time CFO. Apparently part time execs are thing - late in their career and established and successfully to think about retiring, but don't want to get out of the game completely. Or to be e.g. a CFO for 3-4 startups at once. Not sure if that exists for sales, but I thought it was a neat idea.

It's common for VCs to do the same as "entrepreneur in residence"

Translate the proof to lean and verify it.

If the proof isn't trivially translatable to lean, is it actually a good proof?

Things that, in 2026, are trivial to automate grading of.

So you're saying you strongly support software patents?

That query is completely safe!

The migration will just fail with no harm done.

You don't need source anymore. Have Claude Code look at the binary and write a new program.

That's not at all true.

There have been tons of applications for this. People were using earlier LLMs like BERT for classifiers long before LLMs became viable chatbots.

> Because I feel running the code will always be slower than a single agent generating it.

That is very not true for many cases. Agents generating code are usually painfully slow, finding workflows that replace that reasoning with running code usually speed things up in my experience.

I wish that was more programmable.

You can pay for higher cache time, you can pay for NVMe KV cache for an hour that can just be reloaded, etc., at a lesser tier you can pay for the KV cache to be stored on a network store (I guess I'm unclear if that last tier would be cheaper than recomputation, not even 100% sure of the NVMe with direct GPU<->storage DMA) depending on your model settings.

It's entirely possible a game manages paging VRAM badly. But allowing the game more flexibility isn't a problem with a larger BAR, it's that the game is stupid and gets dumber the more VRAM you give it.

If a program runs slower when you give it more RAM, the problem isn't giving more RAM.