I have! I agree it's very good at applying abstractions, if you know exactly what you want. What I notice is that Claude has almost no ability to surface those abstractions on its own.
When I started having it write React, Claude produced incredibly buggy spaghetti code. I had to spend 3 weeks learning the fundamentals of React (how to use hooks, providers, stores, etc.) before I knew how to prompt it to write better code. Now that I've done that, it's great. But it's meaningful that someone who doesn't know how to write well-abstracted React code can't get Claude to produce it on their own.
Same experience here! As an analogy, consider the model knows both about arabic or roman number representations. But in alternate universe, it has been trained so much on roman numbers ("Bad Code") that it won't give you the arabic ones ("Good Code") unless you prompt it directly, even when they are clearly superior.
I also believe that overall repository code quality is important for AI agents - the more "beautiful" it is, the more the agent can mimic the "beauty".
> I've seen Claude make mistakes like that too, but then the moment you say "you can modify the calling code as well" or even ask "any way we could do this better?" it suggests the optimal solution.
I agree, but I think I'm less optimistic than you that Claude will be able to catch its own mistakes in the future. On the other hand, I can definitely see how a ~more intelligent model might be able to catch mistakes on a larger and larger scale.
> I expect that adding a CLAUDE.md rule saying "always look for more efficient implementations that might involve larger changes and propose those to the user for their confirmation if appropriate" might solve the author's complaint here.
I'm not sure about this! There are a few things Claude does that seem unfixable even by updating CLAUDE.md.
Some other footguns I keep seeing in Python and constantly have to fix despite CLAUDE.md instructions are:
- writing lots of nested if clauses instead of writing simple functions by returning early
- putting imports in functions instead of at the top-level
- swallowing exceptions instead of raising (constantly a huge problem)
These are small, but I think it's informative of what the models can do that even Opus 4.5 still fails at these simple tasks.
> I agree, but I think I'm less optimistic than you that Claude will be able to catch its own mistakes in the future. On the other hand, I can definitely see how a ~more intelligent model might be able to catch mistakes on a larger and larger scale.
Claude already does this. Yesterday i asked it why some functionality was slow, it did some research, and then came back with all the right performance numbers, how often certain code was called, and opportunities to cache results to speed up execution. It refactored the code, ran performance tests, and reported the performance improvements.
I have been reading through this thread, and my first reaction to many of the comments was "Skill issue."
Yes, it can build things that have never existed before. Yes, it can review its own code. Yes, it can do X, Y and Z.
Does it do all these things spontaneously with no structure? No, it doesn't. Are there tricks to getting it do some of these things? Yup. If you want code review, start by writing a code review "skill". Have that skill ask Opus to fork off several subagents to review different aspects, and then synthesize the reports, with issues broken down by Critical, Major and Minor. Have the skill describe all the things you want from a review.
There are, as the OP pointed out, a lot of reasons why you can't run it with no human at all. But with an experienced human nudging it? It can do a lot.
It's basically not very different from working with an average development team as a product owner/manager: you need to feed it specific requirements or it will hallucinate some requirements, bugs are expected, even with unit test and testers on the team. And yes, as a product owner you also make mistakes, never have all the requirements up front, but the nice thing working with a GenAI coder is that you can iterate over these requirement gaps, hallucinated requirements and bugs in minutes, not in days.
Those Python issues are things I had to deal with earlier last year with Claude Sonnet 3.7, 4.0, and to a lesser extent Opus 4.0 when it was available in Claude Code.
In the Python projects I've been using Opus 4.5 with, it hasn't been showing those issues as often, but then again the projects are throwaway and I cared more about the output than the code itself.
The nice thing about these agentic tools is that if you setup feedback loops for them, they tend to fix issues that are brought up. So much of what you bring up can be caught by linting.
The biggest unlock for me with these tools is not letting the context get bloated, not using compaction, and focusing on small chunks of work and clearing the context before working on something else.
I wonder if this is specific to Python. I've had no trouble like that with Claude generating Elixir. Claude sticks to the existing styles and paradigms quite well. Can see in the thinking traces that Claude takes this into consideration.
I agree! Like I said at the end of the tool, I think Claude is a great tool. In this piece, I'm arguing against the 'AGI' believers who think it's going to replace all developers.
Hi HN - I'm the founder of Stardrift, and we're looking for a founding engineer to join our team of 3.
We are building a world-class travel agent experience. In the future, you won’t book travel by opening ten tabs in Google Flights; you’ll book through a personalized AI assistant that understands everything about you and automatically arranges your trip for you.
You'll tackle everything from optimizing LLM performance and building evals to integrating with APIs for rail and flight networks around the world. We care about moving fast and writing high-quality code; your job will be to take customer feedback and improve our product, working with me & the rest of the founding team.
Hi HN - I'm the founder of Stardrift, and we're looking for a founding engineer to join our team of 3-4. (Fun fact: I got my first coding job through 'Who is hiring?', almost 12 years ago!)
We are building a world-class travel search experience. In the future, you won’t book travel by opening ten tabs in Google Flights; you’ll book through a personalized AI assistant that understands everything about you and automatically arranges your trip for you.
You'll tackle everything from optimizing LLM performance and building evals to integrating APIs like Amadeus and Duffel. We care about moving fast and writing high-quality code; your job will be to take customer feedback and improve our product, working shoulder-to-shoulder with me & the rest of the founding team.
Tyler Cowen did an 'ask me anything' at Jane Street when I interned in 2016. One of the interns asked him exactly this: "What do you think of the fact that we all work here instead of, I don't know, curing cancer?"
He replied with, roughly, "Those of you who work here probably couldn't do anything else other than perhaps math research. Arguably, working here is the economically efficient use of your time."
I think about whenever I see a comment like this. Quant firms select for a very specific set of skills. In particular, I've found that many traders/software engineers in quant are very smart but not very self-directed. Places like Jane Street work well for people who can excel, but only when given a lot of structure and direction. I think this is not unrelated to why so many people 'accidentally' end up as traders after going to an Ivy League school!
Tyler Cowen, master of the ‘cum hoc ergo propter hoc’ fallacy. He frequently mistakes the occurrence of phenomena for causative proof of that phenomena. He particularly exhibits this inclination when his confidence rises amid scant data (like the rest of us).
This error seems to be a particularly common (and often lauded!) trait among those who work in high-conjecture low-evidence fields (eg, economics). The prominent thinkers become skillful at deploying this fallacy: “see, it’s there, therefore <insert-personal-belief> is certainly the cause!”, using their credentials and esteem to mask the error. Listeners think, “well he’s a smart, respected guy,” and nod along despite the missing logical link.
I greatly appreciate Cowen’s podcast, and I definitely respect him as a thinker and inquisitor – so I don’t mean to discard his work or opinions (in fact, I appreciate his occasional brashness because it exposes the underlying thought/principle). However, many of his aggressive-yet-speculative statements (like the one you roughly quoted) are best received with an understanding of the error.
> He replied with, roughly, "Those of you who work here probably couldn't do anything else other than perhaps math research. Arguably, working here is the economically efficient use of your time."
Complete garbage. The same way that Jane Street hires smart people that don't know anything about trading and those people contribute, the same would be true if there was money in curing cancer.
General intelligence is overstated sometimes, but it is a thing. Someone who is smart enough to work for Jane Street probably could at least be an intelligence analyst or software developer at the NSA contributing to national security. (Jim Simmons literally was a code breaker during the Vietnam War)
I don't think there's a gene for playing esoteric minigames on the options market while you literally suck at everything else
While I’m sympathetic to the “people working hard to build out ad markets instead of cancer research” argument, I only believe in a weak version of this.
Why? I have met many “smart with computers” people. Many of them have terrible people skills, don’t show up to things on time, are unable to keep their workspace clean, don’t know how to explain anything, and cry about how they can absolutely never ever be interrupted because their workspace is so hard. There are also people who are “good at it all”, of course, but I have the impression that the math/computer people tend to be fairly unwilling to deal with even mild inconveniences.
People who can barely deal with the tyranny of daily standups probably would struggle a lot in a world where you need to write grant proposals continuously to justify your existence.
I’m being glib for effect, but there’s so much involved in getting work done beyond “being smart”!
Besides… it’s not like the reason we don’t do more cancer research is because smart people didn’t go into that. “Cancer research” is limited by funding for positions into that domain!
So “this quant should have been a cancer researcher” is saying “this person who decided to become a quant will be a better cancer researcher than a cancer researcher who went into that domain directly”. I don’t know the prestige vectors there but it’s a stretch in my book!
> People who can barely deal with the tyranny of daily standups probably would struggle a lot in a world where you need to write grant proposals continuously to justify your existence.
I'm continuously writing grant proposals to justify my existence, and have been quite successful (lucky) in it. But I do bitch about the pointless grant game and about the pointless meetings.
Perhaps the problem is that to survive in academia you have to be able and willing to waste your time on all the bullshit that is not research. And it selects for people who are good and willing at the grantwriting and politics game, which is not the same as being good at research.
Maybe there's some point in bitching about the tyranny. Having tech people to do sales and marketing on the side like researchers have to do probably isn't an ideal division of labor.
Ya, I’m very surprised by the argument “you’re some of the best at numerical analysis and high frequency trading, and you’d be bad at anything else”, lol. That said, I think there are better reasons to work at such a place. Providing liquidity to the market is a good thing, and has real world value, it’s just hard for us to connect it to concrete outcomes. But as a simplified “toy” example, when they orchestrate a trade for/with a retirement fund, they help the fund improve its holdings at very low cost. That benefits everyone impacted by the retirement fund
1. Incentivizing convergence of the price towards fundamental value, to support proper asset allocation decisions.
2. Supporting buying and selling (ie "liquidity") to shift consumption in time (and enable productive investments with the delayed consumption).
Suppose a retirement fund holds their investments over a 20 year period on average, growing at a modest 4%. A 1% wider spread would reduce the return from 119% to 118%. I'm not sure avoiding that is worth the financial sector constituting 30% of GDP.
What would happen if equity markets were only open a very short period a day? Say you have one auction a day, or maybe two, and no continuous trading?
Everyone whose advantage is speed would lose out (HFT, some prop traders). Their current gain would instead accrue to those on the other side of the trades.
This comment is weird to me. Are you saying that the "financial sector" (incredibly vague term) makes 30% of US GDP? Not even close. A trivial Google search proves that it is way off base.
> finance, insurance, real estate, rental, and leasing ... is 20.7% of US GDP.
Also, most of the GDP in the "financial sector" is in commercial banks and insurance companies. Yes, they take risk, but not the kind being discussed here.
Since the original article is about Jane Street's financial market making business, let's focus on investment banks. What percent of US GDP do you think that investment banks and trading hedge funds represent? It is tiny. I would be shocked if it is more than 5%.
> What would happen if equity markets were only open a very short period a day? Say you have one auction a day, or maybe two, and no continuous trading?
This seems like a question from Econ 101. Let's expand that to all free markets in the US. What if homes could only be bought or sold once per month, instead of daily? How about agricultural products? Quickly this argument falls apart. Wholesale and financial markets with continuous trading have existed for centuries. The purpose of continuous trading (or very frequent auctions, like the agro auctions in the Netherlands) is price discovery. If you do it less frequently, then you have weaker price discovery and worse (less accurate) prices.
Finally, professional financial market makers have an important role to play in reducing the size of bid-ask spread. I recently bought some 1Y US Treasury bills using Interactive Brokers. I was stunned by how tight are the spreads, and I am a "Retail Normie/Nobody". Absolutely, this was not available to people like me 30 years ago. Who do you think is providing this liquidity that keeps bid-ask spreads so tight?
The finance sector contributes only 7% of GDP, correct.
One of the sources I had in mind [0] cites 31%, but that was revenue as a proportion of GDP, which doesn't really make sense. However, the financial sector takes about 30% of US profits [1].
With respect to trading only once a day, I don't think your ad absurdum counterarguments hold water.
The HK stock exchange used to trade 4.5 hours a day, from 10 to 12, and then after a generous 2 hour lunch break from 2 to 4:30. How is trading 8 or 12 hours a day better for pension funds?
Price discovery with a limit order book that's cleared once a day might work just as fine as when it's spread out over hours, maybe even better.
Think about some major event affecting a company happening on the weekend. Then everyone can put in buy/sell orders with adjusted prices, and they'll be cleared during the morning auction. How is that worse than if the event happens intraday, and only the most switched on automatic HFT will pick off people still quoting at the old price, then the professional traders in hedge funds will pick off people?
As I said, the difference would be that the gains of the fast movers would instead be distributed among those on the "wrong side" of the news. Why should price discovery be worse?
Finally, what makes you think that liquidity and bid-ask spread concentrated in a minute a day would be worse than spread out over many hours a day?
I think the amount of money that is creamed off for this service is disproportionate, and the amount of benefit to wider society a case of diminishing returns.
Allocation of capital, market liquidity etc are useful, but the size of the financial sector and the rewards it gives out for this shuffling of money are insane.
I.e., they work to increase the return on capital. Since I believe one of the biggest problems in the world today is economic inequality stemming from an increasing gulf in the remuneration of labour and the remuneration of capital, I don't think this is a good thing. Let alone a good use of stupendous amounts of talent and money.
The only reason software engineers are able to be paid so much at all is because of “capitalism” and “free trade” I.e. vacuuming up money from the rest of the world, we sell them ads and “SaaS” and “intellectual property” while they sell us food and clothes. Would be a bad day for me personally and our profession in the US when that stops
We’ve seen what happens when the price of eggs goes up a little bit, never before seen levels of prosperity seems to be the only way to convince Americans to treat each other kindly, pick your poison I guess
I didn’t take that to be his point. I assume he says “economically efficient” because he means their strongest skillsets don’t have (m)any other uses and they wouldn’t be realizing their potential by leaving those skills unused.
He probably overstates that case, especially talking to early career interns that haven’t yet narrowed their specialization and could pivot to other highly quantitative roles that use other high level math.
He’s also probably flattering his audience, to whom “math research” is more likely to be status-bearing.
To build on / extend on this - quants / finance folks need to cultivate an image of only taking the very brightest, to justify the shit working conditions (even if pay is often decent) but honestly the brightest tend not to apply. Working in those environments is neither rewarding nor stimulating.
1. It looks like Syncthing is an application that lets you sync files? Moonglow runs one layer below - we call cloud apis for you, to set up and connect you to a remote Jupyter kernel.
2. I think the serverless here is actually pretty literal - you don't have to think about or spin up a Jupyter server. We normally describe it as 'run local jupyter notebooks on your own cloud compute,' which I think might be a little more clear.
Not exactly. Brev.dev helps you set up a Jupyter server, but you still need to set up your connection to it yourself. It's also mostly designed to run on the browser.
Moonglow abstracts over this, so you don't need to think about the server connection details at all. We're aiming for an experience where it feels like you've moved your notebook from local to cloud compute while staying in your editor.
Yeah, I agree! We looked into integrating Moonglow with academic clusters, because many of my ML PhD friends complained about using them. We unfortunately haven't found a good generalized solution, so I think VSCode's remote SSH + manual server management is probably the best option for now.
We make sure the remote containers have CUDA/Pytorch/Numpy/Matplotlib set up if you're using a GPU-based machine. It's actually far easier for me to run ML-based code through Moonglow now than on my Macbook - it's really nice to start with a clean environment every time, instead of having to deal with dependency hell.
We don't yet transfer the python environment on the self-serve options, though for customers on AWS we'll help them create and maintain images with the packages they need.
I do have some ideas for making it easy to transfer environments over - it would probably involve letting people specify a requirements.txt and some apt dependencies and then automatically creating/deploying containers around that. Your idea of actually just detecting what's installed locally is pretty neat too, though.
I have! I agree it's very good at applying abstractions, if you know exactly what you want. What I notice is that Claude has almost no ability to surface those abstractions on its own.
When I started having it write React, Claude produced incredibly buggy spaghetti code. I had to spend 3 weeks learning the fundamentals of React (how to use hooks, providers, stores, etc.) before I knew how to prompt it to write better code. Now that I've done that, it's great. But it's meaningful that someone who doesn't know how to write well-abstracted React code can't get Claude to produce it on their own.
reply