SatvikBeri

I'd be really curious to see benchmarks of haiku vs lower effort on bigger models. My own evals found Fable 5.1 at low to be better than Opus 5 on high.

Similarly, you can defeat the Egg Dragon superboss in Lufia 2 by healing before attacking: it starts with 65,535 HP.

I started paying for phones with really good cameras once I had kids and I wanted to take lots of pictures with them. I definitely notice the quality difference in random, off-the-cuff photos (which is the vast majority), though if I have time to set up a bit, cheaper phones produce pictures that look the same to me.

One example that comes to mind is math textbooks – the early textbooks in a field are usually much worse than later ones that come along. To pick on one, I think most people who've read both would agree that the commutative algebra section of Lang's Algebra is much worse than Atiyah & McDonald's Commutative Algebra book, despite covering basically the same ideas, theorems, etc.

I hit it once when I asked a question about whether butterflies remember anything from their time as caterpillars. I've never hit it for coding, but I also don't really do much related to security.

> We can also imagine the application of these models for malicious purposes , including the following (or other applications we can’t yet anticipate):

  *   Generate misleading news articles

  *   Impersonate others online

  *   Automate the production of abusive or faked content to post on social media

  *   Automate the production of spam/phishing content

Seems like the prediction was pretty accurate.

It's trivial to try another agent. You can spend $20 for a monthly subscription and ask it to import all your settings from Claude Code.

I use Julia! I like it a lot, and add type parameters to all application code. But JET.jl does not feel anywhere close to the assurances I can get from a statically typed language (yet)

What statically typed language would you suggest for machine learning and large data pipelines? I don't love Python, but it has by far the largest ecosystem.

Every interview method has some glaring flaws, and I find you mostly have a choice of which flaws you pick.

On my current team, I care a lot about the ability to write fast code. The most important part of my process is a take-home designed to take 2 hours where the main goal is to solve a relatively easy problem as performantly as possible. Answers have varied from 0.2ms – 50ms.

Take-homes have some obvious disadvantages, but overall I find they're better at finding the people we're looking for than just about every other method. But I'm at a small company, hiring for a fairly specialized team. If the situation was different (e.g. I needed to hire 50 people/year) I'd use a much more standard process.

I'm a fairly moderate user, never hit any kind of usage limits, but I used 44 million cache create tokens and 1.5 billion cache read tokens, which ccusage estimates would have cost $990, and calculates the different categories separately.

Not OP, but Dario said on Dwarkesh's podcast 3 months ago that their gross margins are "significantly higher than 50%"

Run rate is annualized revenue based on some recent period, e.g. taking the last month of revenue and multiplying by 12. Revenue (classic) is a historical measure, e.g. revenue in 2025.

Julia does this – you generally write synchronous, single-threaded functions most of the time, and can use code like `t = @spawn foo(b)` to get a Task, and then `output = fetch(t)` to wait for it and get the value.

I like this general approach a lot, it's overall quite nice for Julia's core use case of number crunching, it means you typically make decisions around concurrency at the call sites. Though it does rely heavily on Julia's runtime, and it can be a bit difficult to figure out what's going on under the hood.

I usually aim to have Claude end up with about 500 lines of code after a night of work. Most of what it's doing is experimenting with many different approaches, summarizing them, and then giving me a relatively small diff to review and modify.

The context window has nothing to do with RAM usage and even if it did, a million tokens of context is maybe 5mb.

9-5 Pacific Time

Yes, I've pretty much used Opus exclusively for the last year, except for a brief period when Sonnet was ahead

I've never actually run into the issues that people talk about online, like Claude suddenly getting dumb or running out of usage. So there's just not a lot of incentive for me to shop around. I've used Amp a bit, and it's quite nice, but a bit more expensive without the subsidized subscription.

Re: REPL use, you just use it to run code and look at results. e.g. for TDD – you can modify your code files normally in the IDE, changes get picked up by revise, and then you re-run the tests in the REPL.

For long-running jobs, I basically follow the same process as in any other language: make the functions I want to run, test them locally on a small dataset that runs relatively quickly, then launch them on the remote machines with the full data.

Revise.jl has struct redefinition now, but before that I would just use NamedTuples while iterating, then make a struct when I was ready to move something to production.

`using` is for importing modules, `include` is for specific files. At work, we currently have a monorepo, with one top-level OurProject.jl file that uses `using` to import external packages, and `include` for all the internal files.

It's definitely closer to matlab than python, but it's closer to python than most mainstream programming languages. I ported ~20k lines of python code to Julia over a couple years manually, and for the most part could do line-by-line translations that worked (but weren't necessarily performant until I profiled and switched to using Julia idioms.)

Well, my workflow uses Revise.jl. I develop either in Jupyter notebooks or in the REPL, prototyping code there and then moving functions to files when they're ready. In that context, rapid iteration is fairly fast.

Nowadays I often use Claude Code, working with a Julia REPL in a tmux or zellij session via send-keys. I'll have it prototype and try to optimize an algorithm there, then create a notebook to "present its results", then I'll take the bits I like and add them to the production codebase.

Yes, with unlimited development time I would expect C++ solutions to be as fast or faster. But Julia hits a really nice combination of development speed and performance that I haven't found in other languages, at least for number crunching and data pipelines.

This is 7 years old. Julia is a totally different language by now.

As a quick anecdote, in our take-home interview exercise, we usually receive answers in C++ or Julia, and the two fastest answers have been in Julia.

I actually do this, but that's mostly because our team reviewed all the existing autoformatters for the relatively obscure language we use, and either really hated the formatting or found that they actually introduced errors!

jj has almost 30,000 stars on github. You might not be looking for a different git ux, but plenty of people are!

Yes, but a patient who googled his real name would not find his blog. That was the point.

Are you aware that you can use tmux (or zellij, etc.), spin up the interpreter in a tmux session, and then the LLM can interact with it perfectly normally by using send-keys? And that this works quite well, because LLMs are trained on it? You just need to tell the LLM "I have ipython open in a tmux session named pythonrepl"

This is exactly how I do most of my data analysis work in Julia.

It's totally compatible though, and that's a big selling point. I use jj and nobody else at my work uses it and that has never been an issue.

I use a REPL in tmux. That lets Claude code read/write to it easily, as well as letting me take manual control to investigate.