I don’t buy it - if you’re an engineering leader and this is happening it’s your responsibility to get out there and fix the problem through education, process improvements, improved automated quality checks, better planning. Sticking your fingers in your ears and shouting “no!” is not a sustainable strategy. Figure out what would allow your throughput to double, triple etc and go organise it. Focus on bottlenecks and the most difficult pieces. I’m speaking from active experience here.
One of the key things I've needed to educate people on is that code contributions are no longer valuable in and of themselves. Someone who produces a large volume of bad code does not have high throughput that needs to be allowed, they have low throughput that needs to be corrected. High throughput in software is now almost entirely about having the right ideas and analysis.
Thankfully it's not happening in my organization because we happen to have a sane, incremental strategy. But it's telling that you perceive any criticism of AI code reviewer burnout as "sticking your fingers in your ears". Perhaps you might benefit from a closer read of the article.
« it's telling that you perceive any criticism of AI code reviewer burnout as "sticking your fingers in your ears" »
Go back and re-read the quote from your comment - which I responded to: “ You will not convince the person drowning you in 2000 line PRs to stop. Start looking for a new job as if you have already been fired.”
I’m not overreacting to some nuanced take here. I’m not sure how to characterise quitting as a response to over-enthusiasm / slop as anything other than the career equivalent of sticking your fingers in your ears. I’ve been there, I’ve had the arguments, I have little sympathy for staff/principal engineers or above who react like this - their job is to fix the organisation, put a yoke around the beast of AI and find a way to tap the benefits and use the problems (like those 2000 line PRs) as a golden signal for where you need to educate and improve process and planning.
Again - I’m not selling anything here, I just have found it an interesting challenge over the last year and one where I’ve been happy to make progress organisationally despite the frustrating moments. If someone’s response to a problem like this is to throw their hands up in despair or to engage in whatever the logical opposite of AI-hype is (which the article resorts to repeatedly) then yes I’d worry about being laid off. If you’re in an organisation where you don’t have the agency to fix problems then absolutely - start looking for a new job.
I think the author means if it happens regularly, and asking people to stop doesn't work or marks you as a dangerous dissident. Obviously, it is wrong to quit in response to one person doing something stupid
This sounds to me like a demand that engineers fully submit to their future as reverse centaurs [0]. "Submit to the slop tsunami, become a glorified and burnt out button pusher!"
Even a large AAA game should be able to be cloned to a machine. You don't need to clone history, just use --depth to specify the number of commits you want.
Obviously a 20 year git repo with all commits is going to be massive, but you don't need that locally.
Also, it seems like it would be reasonable for a AAA game to version control assets separately from code.
Probably, but you want to version control assets too.
People usually mention git-lfs at this point, but that is always annoying to use in practice. There is also shallow-clones and sparse-checkouts, but these only mitigate the problem as there is no way around cloning at least one revision completely with git.
IME is is less capable of performing complex work, more frequently goes down blind alleys and needs correcting, that kind of thing. It's night and day vs CC.
And this has been comparing like for like with CC - say Opus 4.6 on the same reasoning effort? Hasn’t been my experience particularly but fair enough. I do tend to use them in different situations (CC outside of work).
Even if it is close, maybe GHC CLI has improved in the last month since I last used it, I know you didn't say it but calling people uninformed because they prefer one or the other is just wrong.
I’d agree, though maybe there’s a more charitable reading of the OP - “uninformed” is one of those accusations that it’s rarely very polite or fair to level against an individual but sometimes is reasonable against a group based on observation. My experience would be that it’s true that “devs says lots of uninformed things” - and I’d include myself in that. It’s been my experience that it’s particularly tough in this space at this time because:
1. Tooling is changing very fast but people tend to form sticky opinions (reasonably enough - there’s only so much time in the world).
2. It’s just hard to form robust objective opinions - you have to make a real effort to build test cases and evaluation processes and generally the barrier to entry there is pretty high.
So - I agree, calling people uninformed is not a great way to win them over, but maybe that’s the price of living in a world of anecdotes which become fixed in people’s minds.
Make it write a skill and rule hook for PreCompact to do a handoff that explains what was worked on, what to know, and what to do next. If it goes off the rails after compaction then it won’t be great in a new session either, and you want to make sure you maximize continuity or development will be unsustainable. A backlog.md and improvements.md workflow also helps with this (ticket numbers, descriptions, “focus on BACK-0075,” etc.)
I think the OP's comment is entirely fair. Karpathy and others come across to me as people putting a hose into itself: they work with LLMs to produce output that is related to LLMs.
I might reframe the comment as: are you actually using LLMs for sustained, difficult work in a domain that has nothing to do with LLMs?
It feels like a lot of LLM-oriented work is fake. It is compounding "stuff," both inputs and outputs, and so the increased amount of stuff makes it feel like we're living in a higher plane of information abundance, but in reality we're increasing entropy.
Tech has always had an information bias, and LLMs are the perfect vehicle to create a lot of superfluous information.
In my limited experience, using LLMs to code up things unrelated to LLMs (robotics for instance) is significantly less productive than using LLMs to code up things related to LLMs. It works, just not very well and requires a lot more leg work on the user end than in other areas.
To be fair Karpathy isn't known for using LLMs—not that I would assume or question whether he's used them 'for non-trivial tasks', but it's not like making the same comment in reply to Steve Yegge or someone. (However trivial we may think Gastown/Wasteland is in the other sense!)
That is not the case at all, considering that he himself started using and tweeting about llms for coding fairly recently. He's probably less experienced in that area than most people who started using claude cli last year.
He is a researcher who understands neural networks and their architectures exceptionally well. That is all.
That whole thread is just amazing, if you back up a couple of levels from ground zero. Great perspectives from a lot of thoughtful posters.
E.g., you can see a post from a user named dhouston, who mentioned that he was thinking about starting an online file sync/backup service of some sort.
Haha awesome. I guess they were going through YC right then, I still remember their launch video from around then and thinking it was one of the best ads I’d ever seen.
If you could share I’d be really interested in hearing a concrete example of the two behaving differently. I work in Microsoft (not on copilot - though I’m an heavy user, and use Claude code in a personal capacity) and would be quite happy to repro and report back to the copilot cli team who are responsive.
Back in 2012 after 8 months across Asia (through Turkey, Iran, India, Nepal, China, Vietnam, Cambodia, Thailand, Laos and Hong King) we took a flight to Buenos Aires (well, via SF for a weekend) then went entirely overland:
- Buenos Aires
- Puerto Madryn
- Ushuaia
- El Calafate
- El Chalten
- Bariloche
- El Bolson
- Mendoza
- Salta
- El Cafayate
- Into Bolivia…
- La Quiaca
- Tupiza
- Salar de Uniyi
- Sucre
- La Paz
- Copabanca
- Isla Del Sol
- Into Peru!
- Puno
- Cusco
- Aguas Calientes
- Arequipa
- Tacna
- Into Chile!
- San Pedro de Atacama
- Into Argentina
- Salta
- Puerto Iguazú
- Into Brazil
- Foz do Iguaçu
- Rio de Janeiro
- Ihla Grande
- Paraty
- San Paulo
- Home (via Amsterdam)!
I’m glad we did it when we were younger - golden years.
> In other words, that usage you like is costing them tons of money
Evidence? I’m sure someone will argue, but I think it’s generally accepted that inference can be done profitably at this point. The cost for equivalent capability is also plummeting.
I didn't think there would need to be more evidence than the fact they are saying they need to spend $600 billion in 4 years on $13bn revenue currently, but here we are.
Right, but if OpenAI wanted to stop doing research and just monetize its current models, all indications are that it would be profitable. If not, various adjustments to pricing/ads/ etc could get it there. However, it has no reason to do this, and like all the other labs is going insanely into debt to develop more models. I'm not saying that it's necessarily going to work out, but they're far from the first company to prioritize growth over profitability
This meme needs to go in the bin. Loss making companies love inventing strange new accounting metrics, which is one reason public companies are forced to report in standardized ways.
There's no such thing as "profitable inference". A company is either profitable or it isn't.
Let's for a second assume all the labs somehow manage to form a secret OPEC-style cartel that agrees to slow training to a halt, and nobody notices or investigates. This is already hard to imagine with the amount of scrutiny they're under and given that China views this as a military priority. But let's pretend they manage it. These firms also have lots of other costs:
• Staffing and comp! That's huge!
• User subsidies to allow flat rate plans
• Support (including abuse control and handling the escalations from their support bots)
• Marketing
• Legal fees and data licensing
• Corporate/enterprise sales, which is expensive as hell even though it's often worth it
• Debt servicing (!!)
• Generating returns for investors
Inferencing margins have to cover all of those, even if progress stops tomorrow and the RoI to investors has to be likewise very large, so margins can't be trivial. Yet what these firms have said about their margins is very ambiguous. As they're arriving at this statement by excluding major cost components like training, it's not clear what they think the cost of inferencing actually is. Are they excluding other things too like hw depreciation and upgrades? Are they excluding the cost of the corporate sales/support infrastructure around the inferencing?
To be clear, it's absolutely impossible for OpenAI and the others to stop. The valuation and honestly the global markets depend on them staying leveraged to the hilt. So they're not going to stop. However, the point is that the models are genuinely useful and people pay for them, and if we reset the timeline with a company that has just the current proprietary models, they could turn a profit. That might involve charging more than they do now, etc. But this is much different than OpenAI, specifically, trying to turn a profit today, which wouldn't work for many reasons.
But also, "profitable inference" IS a thing! "Gross margin" is important and meaningful, even if a company has other obligations that mean it's overall not profitable.
"profitable on inference" means "marginal costs of inference are lower than revenue". It is very common to distinguish between upfront costs vs. marginal costs when judging the economic viability of a business.
You mention "debt servicing", but OpenAI has no debt. All the money they have raised is equity not debt.
Nope. The only "all indications" are that they say so. They may be making a profit on API usage, but even that is very suspect - compare against how much it actually costs to rent a rack of B200s from Microsoft. But for the millions of people using Codex/Claude Code/Copilot, the costs of $20-$30-$200 clearly don't compare to the actual cost of inference.
If this is like the flow it uses for a codex / ChatGPT subscription it doesn’t even register a handler - the redirect opens as a 404 in your browser and there are instructions in copying the token from the query string!
