The modern trend is to think intelligence is generative “like compression” or “predicting next in sequence” rather than iteratively reducing uncertainty, like those fault tolerant humans.
Compression can be defined as reducing uncertainty. If you can predict the next sequence you can compress it to 0 bytes using arithmetic coding. Reliable prediction is what enables compression and it's the link between compression and AI that everyone is talking about.
No one ever in comp sci says artificial intelligence is "like compression", they correctly state that "artificial intelligence IS compression". It's absolutely known and accepted that artificial intelligence (defined as predicting outcomes with a measure of certainty and taking chosen actions towards goals using those predictions) has equivalence to compression in a very hard science way. The hardest part of artificial intelligence is compression and the remaining part, the choice of actions based on predictions is just a tree search to a goal.
Compression in image, video, sound, and text. These items to compressed are all created by humans and we will say represented by files. The difference between an instant of reality and the files is vast. Reality also doesn’t stand still and each instant needs to be captured and interpreted before AI happens.
AI can be just like compression but currently the compute power is no match for details.
Finally these reality details need consideration in any successful implementation. Which means the implementator needs to be aware of the details and successfully relate them to everything else in the model.
I think anyone surprised by these things is not fully engaged with what they are doing.
The factor that is missing in that analysis to me is a time based dynamic stability perspective. Humans have a pretty good ability to go off the rails in reasoning one day and wake up reasonable; a pretty good ability to pursue tasks, despite a multitude of distractions, for ten years or longer. The best models get appreciably worse over a half million tokens. Even using a bunch of limited context agents over time, they lack mental stability. They keep coming up with ideas contrary to the long term idea, and every so often generate ideas that make no sense but they have a hard time letting go of. So the pure functional LLM is compression, but AGI needs some centering process, some high level of dynamic stability to stay sane over time and in the face of 10,000 shiny pretty things to chase.
The harnesses get better, but I haven’t seen much experimentation on long term stability, at least since the “let the LLM run the candy machine” papers from a while ago.
Because the thing missing, even with the largest agentic swarms, is independent intelligence, where it’s given something to own, like say “end to end data quality as we add more clients” (for a SaaS) and it just figures out what that means at each time, mutating its role and solutions to fix the external world, without getting silly.
the things as developer i see no practical gain for us when we should and found model routing better than keep pouring investment into agentic model like, i rather use a smaller faster model with harnessing to do drama script generation instead of leaving it to Fable or Gpt5.5
I think what everyone underestimated was the absolute bonkers amount of compute it will take and how that compute must scale in order to keep up with larger and larger models.
I think Meta’s massive compute investment was never about its 100,000 engineers running coding models, but its 3,500,000,000 users wanting to use AI in every single product (and some new ones: Meta AI, glasses, etc.) So I would think that’s the part that’s not being utilized anywhere near the amount they hoped...
Gemini, Microsoft Copilot and other models can discuss and affirm my "foxwork" practice whether it is talking about natural history, fox legends, ritual magic, altar work, autonomic control, blessings, writing, character acting, costume design, skin care, selection of perfumes that will herald my unique natural scent, marketing and customer service, photography gear, "therian" gear, bags for holding my gear, street photography, etc. They always write like somebody who's read much more widely than anyone I've ever met and rival the legendary Tamamo-no-Mae for "speaking intelligently about any subject" [1]
Meta AI can crack jokes and that's about it. I guess there's a market for "stupid talk" but it's not that big.
[1] Like help me fix my washing machine that won't drain, come up with master narratives for the "polycrisis", talk about why Casey Handmer is wrong about space manufacturing, find papers about the social network of who sleeps with who at a high school, etc.
for us, maybe, but for someone who never really used the workflow, or looked at the “thinking” output where models spin their tokens on the stupidest shit, i can see how it wasn’t obvious.
Is that a problem for Meta though? They recently announced they're going to sell their excess compute, so I imagine the actual problem is they're resorting to doing that because AI isn't having nearly the effect/usage it was supposed to and now Zuck is being a sore winner about it
If Meta is selling their compute and Twitter is selling their compute and the stuff doesn't do anything you don't need an economics degree to figure out what's going to happen to the price of compute. In particular because 'compute' is a euphemism given that this is far from general purpose capacity, those are specialized chips that largely do one thing
All these companies are going to sit on their gazillion data centers once the mania dies down and will have a big problem about what to do with their mountain of hardware
I was involved in three efforts to commercialize foundation models before they were ready in the 2010s so I have a good picture of how progress works at this sort of thing and the pace a lot of the industry has been talking about is unrealistic: like people were disappointed with the rate of development of Apple Intelligence but it's actually progressed at about the rate I expected.
They also believed they would be able to build that compute without restrictions. Between hardware costs and massive public opposition, scaling as they had anticipated is in jeopardy.
Did we? Many of us have been saying that the amount of compute going into the models is unsustainable and that the models aren’t improving enough to justify that for over a year. The emperor has no clothes is true yet again.
No I don't think there was any systemic underestimation of compute. I see the opposite - every company understands compute is important and tries to get hold of it.
If you invest 100B dollars into compute while asking for 1T, but in reality would need 100T dollars to meaningfully move the needle, you're still significantly underestimating the amount of compute needed, despite not getting as much as you wanted.
More than that, I think people overestimate how much AI will progress as you throw more compute at it. It’s the “9 women can’t deliver a baby in a month” equivalent of AI. Additional compute won’t magically give you AGI.
Maybe not AGI, but if you look at the differences between, say, GPT-2 and GPT 5.5, it's remarkable how well it works to mostly just throw scale at the problem.
The difference is a lot more than just throwing scale at it, pretty much everything useful comes from an evolving landscape of post-training techniques.
Of course, param count and context length are also important because they increase the model's overall fidelity, but a base model without SFT, RHLF etc is effectively useless.
Correct. That is what I was trying to hint at. Yes, massive compute is needed to train ai, but it isn’t the only thing. A lot of research and experimentation goes into moving the marker just a little bit. Innovation can’t be forced into weekly sprints, it takes its own time.
Research and experimentation on neural nets has been going on since the 70s (arguably much earlier even), but the lions share of capability changes has all been in the last couple years.
Scale was really the unlock; the new pre and post training techniques and architectures are very cool and useful but they definitely aren't the differentiators when comparing to the previous era of NLP.
BERT is a transformer! The unlock happened within transformers, yes, but they were not exactly super new or innovative architectures at that time. The scale was the main innovation that brought us from BERT to today's frontier.
I think the “unlock” is that AI firms were given trillions of dollars to discover new techniques. In fact, there are very few industries where a sudden influx of that much money would not lead to rapid advancements. It’s not really unique to the AI field.
Your timeline is a bit backwards: they were given trillions of dollars only after they'd demonstrated a few pretty remarkable advancements.
The fact that their advancement suggested that pouring more compute would continue working was also especially attractive to investors: it made a massive R&D budget feel like less of a risk.
I think the unlock only happens once though. I think that's where people are misled at the moment, the technology was there but required huge compute and data ingest to show improvement, but we have done that now. What's next for a giant leap is not more compute, and what new data we can provide now pales in comparison to that first ingest.
Not really. I didn't use GPT-2, but I don't think there was much difference between we got what out of GPT-3.5 and 5.5. It's still an unreliable tool which will go off the rails the second you aren't watching it like a hawk. It still has zero intelligence or ability to reason as to why its output is flawed. Just throwing more compute hasn't gotten us anything worth using.
I was under the impression that the deltas between versions were shrinking- i.e. gpt 4 -> 5 was much less impactful than 3 -> 4 or 2 -> 3. If the growth is getting diminishing returns, I can't say I'm optimistic without finding a drastically different approach.
How do you know though? People thought ANNs and perceptrons were basically useless until pretty much around the time of AlexNet and while there were some architectural improvements (CNNs, transformers), the biggest thing that changed was that we simply threw more compute at it.
It's definitely too early to declare that more compute won't make a difference.
It was data. Alexnet worked because imagenet existed. It took less than a year between the dataset becoming public and the first version of Alexnet being trained.
Nah they'll hit a ceiling. Can only get so big before things collapse. And besides, they've already churned through the Internet's data. Not much new content left in the wild and patterns in other data forms (audio, image, etc should be pretty low by comparison.
I agree we're at diminishing returns, but when brain scanning gets good enough you have a better dataset than the internet, Facebook is deep into that research.
It will scale inefficiently until efficiency breakthroughs occur, but it's really hard to predict when those breakthroughs will happen. Plan on the worst, but be ready and capable of capitalizing when it happens!
Mark is really a bad leader with a mwah mwah vision. He is maybe correct in some things. But the execution is really really poor. Plus he does not have followers and believers. He only got money that can simulate followers to a certain extent
The gap between "useful chatbot" and "useful agent" is way bigger than people realize. A chatbot can be wrong 10% of the time and still help you. An agent that's wrong 10% of the time is sending bad emails and making wrong API calls with no one checking.
The gulf is bridgeable. The problem is that a lot of people are building agents without strong enough judgment layers around them. Work that can be verified with reasonable accuracy are the sweet spot right now.
Only with an LLM that's actually at agent-quality.
If "useful chatbot" and "useful agent" are two rungs on a ladder, the rung before them is "useful autocomplete". Autocomplete that only gets the next token right 90% of the time won't give you compiling code.
IMO present technology is tailored for an experienced developer to give agents manageable tasks that can be one-shot. The marketing right now reminds me of the 90s when AskJeeves promised natural language search when the technology was fundamentally still stuck in keyword search, and learning to craft a search query for Google is today’s prompt engineering
The problem is that with text/code, judgement is hard. Here is what it looks like for physical activity: https://www.youtube.com/shorts/lK7TjujKQLw It's hard to see how that it's not useful at best and could be a disaster for any unsupervised use.
I see this as the gap between an general-purpose agent and a coding agent. A coding agent can imagine something to be true, test it, discover that it's wrong, and recover.
But if you go beyond what can be tested easily, asking the agent to do real work rather than writing a patch, imagining things to be true is a problem.
My instinct (for better or worse) is usually contrarian. Most people seem very skeptical of what Meta is doing with AI. But, what if, in a way at least, it makes sense?
Maybe Wang has correctly identified that the programming and agentic ability that Anthropic and OpenAI models have has largely come from armies of software engineers creating massive datasets by writing out coding and agentic problems and solutions?
So he told Zuckerberg that. The reason it may be turning into so much friction is that at companies like Anthropic or OpenAI, training engineers were either hired specifically for that purpose or probably mostly handled through contracts with third parties (which again, hired them to train AI). And honestly many of them may be overseas or just happy to have a job in a difficult period. But anyway they wouldn't have very high salary expectations etc.
But Zuckerberg already had 25000 engineers. Why not take say 1/5 of them and get them working on the the dataset? The problem is that those engineers were hired for different prestigious highly paid positions at Meta/Facebook. They were not hired to do tedious grading of AI answers or quiz construction.
But Zuckerberg either has to do this, or spend additional billions on doing it all with external contractors. A third option would be to try to create a massive distillation operation. Or just hope that his engineers could invent some magical new training trick that manifested the agentic and programming skills without the large scale human input.
Or he could release a model trained largely by existing open weights models. Which without some huge breakthrough probably has no chance of surpassing them, so is pointless.
I think most of the substantive criticism of Zuckerberg has been about burning funds. If he gives up the "your job is to grade AI homework now" plan because his engineers refuse, he would need to go through third parties. The additional billions and billions this would cost would create more pressure on the bottom line and shareholder pressure.
It would also give up any potential advantage that Wang may have optimistically sold the operation as, on that using "real" engineers as opposed to lower paid data labelling engineers might result in a higher quality dataset.
At some point, model architectures that don't need such massive datasets or can be created automatically in a way that advances the frontier will probably come about. But right now it doesn't exist.
Further, the way AI works currently, business advantage from AI comes from encoding existing internal intelligence and knowledge. Meta's massive engineering corp effectively has that in their heads. Having them create these datasets is possibly the only way to leverage this knowledge asset in this paradigm.
I guess the problem is it means forcing thousands of people to do a different job from the one they were hired for.
While I mostly agree with your post, I do want to point out one thing:
> Or he could release a model trained largely by existing open weights models. Which without some huge breakthrough probably has no chance of surpassing them, so is pointless.
This seems to be categorically untrue. Composer 2.5 is a substantial improvement on its underlying Kimi base model.
If that is backed up by benchmarks then maybe they should imitate whatever Cursor did. What did they do?
They may eventually have to do that. Or they might be starting with an existing Llama model. Maybe I should have said "huge breakthrough or additional dataset".
What's the end goal? Meta-specific engineering, with baked-in knowledge of how FB, Threads, and WhatsApp work? General and/or coding products to compete with Anthropic and OpenAI? Some special Magic Thing which only Meta can invent which will bedazzle Meta's users?
You don't need giant datasets unless you know what you're going to do with them. OpAI and Anthropic are having enough issues making their products profitable. And those are, if not beloved, then at least respected, with a real, if patchy, reputation for usefulness.
What was Meta's pitch in this market? There were hints of interest when LeCun was still doing original R&D, and there was some distant possibility of a next-gen revolutionary product.
But now the goal seems to be to flail around doing something incoherently AI-branded with no obvious strategy.
The troops are being marched around, but no one knows where the battle is supposed to be.
They are making more money than ever before. Maybe Meta leadership doesn’t really care about having a coherent strategy at this point. They can afford to flail around to see if something sticks. Reminds me of Rich kids who have ability to travel the world and find themselves before settling into a career
One problem is that the AI agent market is fiercely competitive. Why build when you can buy? For the foreseeable future there will be a number of competitive models on the "efficient frontier" and I don't think one vendor will pull ahead.
In that market you can build a model and spend a lot of money on it and at best get something that's on the same frontier as everybody else but just as likely end up with uncompetitive models like the ones they have now.
You might save a bit running your own models, doing your own inference, etc. Why not take advantage of "last mover advantage" and buy whatever is best when you need it and figure the odds are good that everybody else is going to buy more GPUs than they need and as a large customer you'll be able to buy in bulk at fire sale prices?
That makes sense in a way, but remember that Meta had previously seen some brief developer glory in the initial Llama release. Going the off-the-shelf route would essentially be giving up on being on the technology frontier in this area, and not monetizing their knowledge assets.
>I think most of the substantive criticism of Zuckerberg has been about burning funds.
I'm not in the org myself I know some Meta SWEs tangentially. My understanding is that the biggest criticism is just the chaos of it all. Jumping constantly from one thing to another like headless chickens and accomplishing nothing.
It created an environment where it's kind of impossible to plan and progress your career.
I was worried this time last year that by this time this year, companies would have slashed their engineering teams down to a handful and everything would be driven by mostly autonomous agents with human guidance. But it just hasn't happened. Do I write all my code with an agent now? Yes. Can you just give an agent a desired outcome and let it work, unsupervised? Absolutely not. I can produce more code than I used to, but if I want it to be good, to be stable, to do what the product manager and designers want, it's only about 2 to 3 times more code than before. And that productivity is impacted by the fact that I'm reviewing 2 to 3 times more code than before (and you have to review, even more so now than before, because if you just let opus or gpt 5 do its thing, you'll get some terrible results, and I've found a lot of engineers on my team are just letting it do it's thing without a lot of iteration).
I have experienced and feel very much the same, and it is refreshing to see a realistic post about the success of agentic coding instead of the usual hype or doom.
As crazy as it may sound, my workflow today does not look too different from a year ago - where I was already heavy into claude code.
Im not certain things will look too different a year from now either. We still have serious bottlenecks in terms of focus/attention you have for both delegating agent work and being able to review it. Even if we solve the "trust what ai does" problem, these cognitive deficit issues still exist - for teams coordinating work, even users adopting new shit, etc.
As an industry we are leaning heavy into accepting "slop" being ok for status quo as we care more about efficiency of output right now. Slop will get better & we can become more adaptive to living with the paradox of amazing yet delicate systems generated by AI.
> Can you just give an agent a desired outcome and let it work, unsupervised? Absolutely not.
Ignoring instructions - whether in AGENTS.md or my prompt - is the worst of it, and it routinely happens. It just waives things that I explicitly told it to do as part of the design.
Vibe coders (in the true sense, zero oversight) claim that you just need to prompt it carefully. That's completely untrue when faced with your careful prompt being ignored.
I even have "don't overrule me without asking" in my global AGENTS.md, and it simply doesn't do that.
Your context isn’t to give it orders, they just don’t work like that. Your context (AGENTS.me, skills, per-request context we are sending in for each request to bots) is to give it the info it needs in the language category it’s trained for the answers you want; you have to give it a clear instruction each prompt. Basically, when you have a long session, you can see this by saying, ok, now moving onto another thing, blah blah blah (implicitly ignoring all previous instructions). It can even back fire - nagging too much about don’t skip tests in the context can make it slip into the linguistic space where there is some emergency and faking the results might be justified (I imagine there is a certain amount of training out there “just making the tests pass for now, will fix later, I promise.” If you rarely mention tests except “this one is failing, please investigate what is going on” (an informational outcome not a test outcome), it doesn’t really “cheat” (tho it can leap to conclusions as always). The tests need to be some deterministic step in the process anyways, tests don’t need fuzzy word directed search capabilities. But the models just don’t have the structure to allow feeding in a ten page set of rules and follow them. You can add a step to say, please check this git commit for compliance with the 23 rules in this standards file, and it will work better to catch the gaps.
Whenever I work on a challenging question I worry about this, because Opus will easily think for 200k tokens on the first prompt. I fear any follow up discussion is lobotomised!
Yeah totally feel you on this one! To avoid it or at least limit that I usually ask it to create external memories, clearing the context window and leaving just a trace to recall the memory created for that run. I hope it might help!
The agreed architecture is to use signing between two micros, so that a third can orchestrate between them in zero trust way (and to prevent a distributed monolith). It just decides that we can trust the third and skips the signing.
From what I can tell, the "established wisdom" is to get Fable to plan and Opus to implement (for cost purposes). The problem there is that Opus could ignore whatever it likes from Fable's plan.
Honestly this is where I would have fable generate a checklist and you just monitor opus to ensure it is going through the checklist. I think ignore is often the result of a context that is not focused enough.
i've yet to see a case where opus "ignores whatever it likes".
opus will definitely ignore instructions if you give it contradictory instructions, or a plan that has steps that obviously don't work with each other. but if you give it a coherent plan, it will follow it.
The Claude harness effectively summarizes the discovery into a plan document, clears, and starts with just that summary - so you'd be clearing context regardless.
Try writing it in first person instead of second person or neutral.
A while ago someone had a similar complaint on here and shared some example lines, and that popped out at me immediately. However much structure we've wrapped these in, they're still text generators trained on all sorts of things, and if you think about a narrative where first and second person speech would be used, try to imagine context: In first person, it's most likely a description of something as it happens someone planning what they will do. But in second person, especially command form, you open up to the possibility of commands being ignored, misunderstood, or actively rebelled against.
Whoever that was back then did some quick tests and found the pattern held, first person got it to follow far more reliably.
It can't follow orders because it isn't thinking - even in a best case scenario, all you're doing with AGENTS.md is altering the probability distribution of outcomes away from things you don't want towards things you do want.
However that still means there's always some probability it will do things you told it not to, it's just reduced. Always a small (hopefully very small) probability the next most likely sequence of tokens is for it to try and run `rm -rf /`
>I was worried this time last year that by this time this year, companies would have slashed their engineering teams down to a handful and everything would be driven by mostly autonomous agents with human guidance. But it just hasn't happened.
I find this somewhat puzzling. I thought things were moving quickly, but at this time last year I couldn't even get Claude (using Cursor) to spin me up a service skeleton that would compile, let alone do anything meaningful.
I know it feels like a long time somehow, but it was only between November and February that things started to actually somewhat work without significant hand holding. Even now, it seems like we're still figuring out how to fully leverage the current models and tooling, even in organizations that have largely gotten on board.
> at this time last year I couldn't even get Claude (using Cursor) to spin me up a service skeleton that would compile, let alone do anything meaningful
I've been using it to do this for 2 years now. And many people with me. The change you mention is one of is primarily one of Overton windows, of vibes.
Yeah, I strongly remember getting Sonnet 3.5 with Aider to boostrap an (albeit basic) project and getting it to work. Especially vivid because I told my roommate at the time about it and he also tried it out and was also shocked. I'd put maybe $20 in credits into the API haha. Feels so quaint, it's almost a foregone conclusion with the current models and harnesses.
>I've been using it to do this for 2 years now. And many people with me. The change you mention is one of is primarily one of Overton windows, of vibes.
I suspect this may have depended on the specific framework. I quite literally could not get Claude (in Cursor) to give me a basic Micronaut setup in a fresh workspace with essentially a "hello, world" API. I would guess that if you're using something like Python and FastAPI, it might have been an easier task or better represented in the data.
The difference that I observed in the Opus 4.5 era is that Claude could take a service framework it has never seen before (proprietary corp) and figure it out.
It's not all that surprising that people were worried and believed this. The AI companies and infrastructure companies partnering with them have spent a lot of money and time trying to convince people this is the case year after year. The critical clue people miss is that everyone claiming that has very clear financial incentives to convince people that's the case even when they know it isn't. Anyone who was actually building with LLMs and judging for themselves based on its performance knew fully well that wasn't the case year after year.
I've said this before: if anthropic (et al) thought they genuinely had a shot at replacing even 30% of white collar work, they would ABSOLUTELY NOT warn ANYONE. They would do what oil, leaded gas, and cigarette companies did. Swear under oath this is completely safe, commit GRIEVOUS societal harm that you explicitly promised wouldn't happen, and then end up in history books instead of jail for reasons beyond my ability to fathom.
No. The very fact they are trying to "warn" us means it's all marketing.
This has been corroborated for me on the engineering front that I can't find a single IC I respect who actually thought there was any evidence AI was going to live up to the hype. I saw a lot of people I always thought were idiots/sycophants/brown nosers go insane with AI. Never saw anyone id trust to help me cross a street blindfolded say more that "I may be wrong, but I'm not seeing any evidence yet".
Fwiw , you're conflating multiple things and consequently drawing premature conclusions.
It can be massively over hyped for it's current capacity and decimate the white collar work.
A lot of the difference of opinion is down to their point of view. At my dayjob, LLMs will not live up to anything because the enterprise is not structured to take advantage of it's strength. That's unlikely to change within the foreseeable future.
I strongly suspect you mostly talked with people coming from just such a background, because it's hard to go beyond our own bubbles
Yes, this... all the hype from the leading AI companies just pattern-matched so many past cases where things didn't pan out. really giving me the bad vibes..
>The critical clue people miss is that everyone claiming that has very clear financial incentives to convince people that's the case even when they know it isn't.
Social media is flooded with bots pushing this narrative - coding is dead, engineers are all cooked, the latest model is scarily good, "what am I for?", etc.
A good rule of thumb is that if it's a human being and not a bot, they'll use the word "slop" at some point.
coding harnesses improvements mattered more than llm improvements this past year. You could solve problems on claude sonnet on claude code that you couldn't solve a year prior.
I think it doesn't prove much that it hasn't happened yet. Companies might just be moving slower than you think, and are still planning on doing it. And, in many corners, "don't manually write code" is being joined by "don't manually read code" as an attractive principle.
you might have to think the way through though and these companies are already being caught up with the huge token costs at the same time.
There was an interesting comment during the cloudflare layoffs (partially driven by the fact that the company was bleeding money also because of its token costs from one estimate being 500 million$ per month, don't quote me on that though)
The part was that there is only an enough marketshare in the first place. Cloudflare was doing some crazy experiments like operating matrix on cf workers and wordpress alternative and fediverse and so much stuff.
So they basically spent 10x the amount of token (and the token costs) and I imagine as such the reading code of that part was getting sidelined as the attractive principle you are talking about.
Yet the market can't bring an actual demand 10x times though. These are things which nudge a user slightly but the actual impact on user growth isn't 10x or even justifiable within some cases given the costs.
Yet at the same time driving up the people who actually know their stuff and firing them because of the token costs. The people who have actually mitigated some of the largest DDOS attacks and are the backbone behind cf cash-cow (enterprise payments) is the fact that they have had the experience and entreprise knowledge about these things, yet they are literally removing that by firing workers and oh replacing them with interns. (They got 1111 interns and fired 1100 employees or something iirc)
It's weird and I have talked to some people about it but there is a disconnect between what management is hearing about AI and the ground reality of things. Reviewing code is becoming the bottleneck but if you don't review code and are shipping things to production, then you can get fired as I have talked about in some of my other comments sharing a story about how a guy shipped code to prod and the response was "but claude generated it" and got fired because the company basically said, look we basically don't care if it was generated by claude but the responsibility was on you to check it (review) and because the commit was done by you, you are gonna be treated responsible and he got fired from his job.
Yet this was the same company which was asking its employee to play around with claude at their free time, the manager of the employee I talked to being the most automatable person, the company employees working till 1 AM because they were saying to management that things were fine but they were being burried under the technical debt,that employee that I talked to got honest with the management and told reality and the management treated them as a person who didn't know AI or were the odd one out.
> (partially driven by the fact that the company was bleeding money also because of its token costs from one estimate being 500 million$ per month, don't quote me on that though)
Cloudflare had 5000 employees (pre-layoff), so you are suggesting that every single one of them (eng, HR, legal, finance, receptionists) was using $100k tokens per month (that's $1.2M annualized, per employee), for a total of 3x gross revenue going to AI spend.
Let's imagine that this isn't absurd on its face. If true, then you'd expect Cloudflare's Q1 earnings to show a massive, massive net loss. In fact Cloudflare was cash flow positive in Q1.
The rest of your post is more qualitative, so harder to disprove, but from what I can tell, it seems equally made up.
Although there is a difference in accrual earnings and cash flows. I was wrong with the number provided which although not as big as 1.5B of AI spend, is still a comparatively large number itself.
I have written an more in-depth comment if that interests ya (in a good faith discussion and please be kind to everybody)
also please don't call @kentonv an idiot and please read the HN guidelines[0]: Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
I had mistakenly written 500 million when it was around 5 million dollars so I messed up its 5 million per month, not 500 million. I wish to have a genuine discussion while you are here though because i can be wrong, I usually am and I would love to have a good faith discussion, thanks in advance!
I will try to back up a lot of it with hackernews comments from the thread when cloudflare layoffs were suggested so that I don't accidentally mis-represent anything and My suggestion wasn't a critique of cloudflare and please don't take it as such. The question was simply of the AI token costs associated.
and this was the comment that I was referencing to[0] which states the following:
> There was an recent article on X with an interesting take - it could be that companies are doing layoffs not because AI is making them more productive but because it hasn't. Their costs have gone up paying for expensive AI but haven't seen any revenue benefits to offset it.
An child comment of it talks about the coinbase layoffs which had happened around the same time[1]:
> (..) In 2023, their "Technology and Development" line item shows $1.32bn going out, and by 2025 it'd ballooned to $1.67bn. This is despite headcount actually contracting by almost a thousand people between those two statements.
Regarding this: > Let's imagine that this isn't absurd on its face. If true, then you'd expect Cloudflare's Q1 earnings to show a massive, massive net loss. In fact Cloudflare was cash flow positive in Q1.
We might be forgetting that (from my understanding, Cloudflare has never had profits) (positive annual net income) with an astronomically large P/E ratio.
> > The fact so many orgs opt for immediate greed over long-term growth really is its own canary that leadership and governance both has failed the marshmallow test.
> Why do you think it's greed? The company's stock is down and they just missed expectations on their last earnings report (unheard of in big tech in the last 2 years).
> It seems more like a traditional layoff scenario
Another comment [from the Layoff thread][2] which summarizes what I wish to say:
"Their AI costs have increased 600% but this hasn't translated into actual revenue. Also they are probably projecting AI costs to keep growing. They've done the math and at some point it is going to affect their bottom line. Reducing or limiting AI usage would be inconceivable given Cloudflare itself has invested on AI and is selling AI services. Instead they've opted for reducing about 20% of their head count."
I genuinely wish if we can have a good faith discussion about it. I appreciate cloudflare as a product myself and actively use cf tunnels, which is why I care about it as well and I wish to have a good faith discussion about it hopefully as well :-D
> The rest of your post is more qualitative, so harder to disprove, but from what I can tell, it seems equally made up.
I can be wrong, I usually am and if I am wrong, I wish to learn from it and I wish to improve as a person too!
I have learnt from this discussion (up until now) that I should mostly try to provide sources whenever talking on a public place/ on the internet so that I can be more accurate and I sincerely wish to have a good faith discussion once again, thanks and have a good day @kentonv :-D
Sure but there's also little reason to think we'll be able to replace xyz role entirely with software next month, or year, or decade. It's easy to disprove claims about the future; it's quite difficult to make believable ones.
> in many corners, "don't manually write code" is being joined by "don't manually read code" as an attractive principle.
I'm pretty sure I know where the failure case on that one is. The reason we're still manually reading code is to catch the failures and edge cases that the LLM fails to; not reading the code doesn't magically make the code good.
"companies would have slashed their engineering teams down to a handful and everything would be driven by mostly autonomous agents with human guidance. But it just hasn't happened. "
Companies are putting a ton of effort into getting to that point of having agents do the work unsupervised. Whoever gets there first is going to be the winner.
I personally don't think it's possible and I haven't written a line of code since Sept 2025.
There's an AI psychosis going on right now, especially among the execs or management class, and we all gotta nod our heads in agreement and burn through tokens.
I don't think it's possible either. DHH pointed out in the most recent episode of Rework that AI removes a lot of the barriers to shipping code, therefore making it possible to build in lots of different directions in ways that was prohibitive to many organizations in the past. But this isn't necessarily a good thing, companies still need to understand what to build in order to ship a cohesive product. AI is great for prototyping and refining use cases in ways that are far superior to static figma designs, etc., but it is not a replacement for taste and execution.
But a slop machine that haphazardly shoots features against the wall to see what sticks still isn't a winning product strategy in 2026. And the problem I see increasingly is that so much energy is being focused on how to deliver with AI internally and externally that is not being expended to advance a company's product. I believe more and more in the idea that for many startups and companies, the actual "customers" are the investors and the product-market fit that companies seek is the product of the company itself, because this is all being driven from the top down, not by customers and users in the market asking for AI features.
> I believe more and more in the idea that for many startups and companies, the actual "customers" are the investors and the product-market fit that companies seek is the product of the company itself
In many respects this reflects the growing K-shaped nature of our economy. Average consumers don't matter because you really just need a small cohort of wealthy individuals to be hyper-invested in your product, 'regular' consumption is therefore just a way to keep things relatively on rails rather than the actual economic driver.
All of these AI-first companies don't actually have any market fit, so what they're doing is selling an imaginary product so that they can get investments and loans. As you said the company is the product.
But that's the nature of the beast isnt it? A probabilistic token predictor will all always have some errors from a human perspective, more and more energy, money and resources will always be needed to control and direct towards desired outcomes.
The bottleneck wasn't the coding, but previously it had the second order effect of slowing product development decisions enough to improve product cohesion.
"What can we get rid of for MVP" as a design strategy vs a way to iterate fast, for instance. Cutting things isn't a way to product cohesion, especially if you never go back to do the full-featured version.
Sometimes I wonder how many features or products flopped because the MVP dropped the things that would've actually taken off, and the business "smartly" pivoted away.
There's still a limit to how many new features you could shove in front of your users per month. But what if they were all much more baked out of the gate?
(See also: "data driven" product management as an excuse to not have your own vision for the product. If three competitors build a lot more in the span of six months, but have to depend more on their own skills and instincts vs A/Bing every little detail, maybe more of them will ship more bold and interesting new things.)
I feel like the increased reviewing time is consistently understated. I’m just an IC, but it seems obvious to me that you cannot cut staff and achieve increased output. There literally aren’t enough eyeballs to go around reviewing code when everyone is 2-3xing their output. I spend so much more time reviewing code; reviews that are sorely needed because I regularly catch batshit insane “fixes” that work but would quickly turn the codebase into a mess (the most recent one being a multi-hundred line diff that I went and fixed in 2 lines in 15 min). Maybe I’m underthinking it but it seems obvious that you either maintain the same output with fewer staff or you gain increased output with the same staff. All the companies that are attempting to cut staff and gain increased output are chasing an impossibility and throwing away their opportunity to accelerate.
Frankly: if you want it to be good and stable, you can't really go any faster than before. The time it takes you to review all the code is no less than it would've to just write it in the first place, because the actual typing things out was never the part which took up time.
I can similarly output 2-3x more code but everything stalls down to me having to review and integrate in a meaningful way the moment I am the one that has to maintain that code.
It's eerie to observe collaborators output code they don't understand, spend days chatting with Claude instead of reading (like really reading) compiler's output or 3 pages of manual, and how lost and oblivious they look when the AI fixates on solving a different problem than the one they have been tasked.
> I was worried this time last year that by this time this year, companies would have slashed their engineering teams down to a handful and everything would be driven by mostly autonomous agents with human guidance. But it just hasn't happened.
Amara’s law: We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
This continues to be applied to AI where people think is going to be next 12 to 18 months. Changes are coming but certainly not at the rate Zuckerberg and most people are thinking.
I believe this in general but the issue with AI specifically is historically in every cycle we've overestimated the potential of AI in both the short and the long run - people in the 60s were genuinely quite convinced we were close to AGI for a few years, as ridiculous as that now sounds.
This is why you get "AI winters" but we've never had a "steam engine winter" or a "railway winter" or a "petrochemicals winter"
It's interesting to score our predictions of various technologies. I've been waiting for hoverboards for 40 years. Our predictions of nuclear power being in every consumer appliance were way off. We just couldn't make it safe and cheap enough. This is a common theme for "physical" technologies. On the other hand, we greatly underestimated the advent and potential of the internet. Most science fiction of the 20th century envisioned very large computers with limited interconnected capabilities. We made computers far smarter and more ubiquitous than most could ever have conceived. I see AI as a function of the kinds of technologies we consistently underestimate.
Yes, that's a fair counterpoint. I guess my counter-counterpoint would be that LLMs actually seem to have characteristics closer to the first group than the second, in that they (currently at least) need enormous quantities of physical things and energy in order to work.
So the nuclear power problem of "it works fine and it's actually very good in a lot of ways, it's just too expensive" could be quite relevant
Thats not the problem (its been done, see Messmer Plan or Japan's ABWR fleet[1]), getting the support of the public (and keeping that support, unlike France did beginning in the 90s)
Could be lack of imagination on my part but I truly can't imaging shipping 1000's of lines of code that I can't understand (beyond low-stakes prototypes). That means there's a ceiling on productivity gains.
If you end up with 2 to 3 times more code. That is HORRIBLE, because it means about 50-66% of the code is otherwise unnecessary.
However, if you get 2 to 3 times the code in the interim, that's probably less than what's needed. I find myself cycle through almost 10x-20x amount of code implementations to get what I want which is actually less code, simple solution and desired behavior.
I kinda love that you made this post feel negative enough that a bunch of AI skeptics are enthusiastically agreeing with a post suggesting that the realistic, pragmatic bear case for AI is, uh, 2-3x productivity improvements.
Do I write all my code with an agent now? Yes. Can you just give an agent a desired outcome and let it work, unsupervised? Absolutely not.
I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them.
Some devs just 'get it' and thrive, leading a team really well and building a great culture. But a lot of them don't, especially if they don't get the support necessary to understand what changes when you move from IC to manager. If the team (or agent swarm) isn't performing well it often isn't a problem with them. It's a problem with the new manager still trying to stay on top of everything and micromanaging all the things. Alternatively, the new manager is completely hands off and only appears at a check-in point (one-to-one, agent completes a task, etc) where they crap on the work and get cross.
I have no evidence for this, but I'd guess that putting developers through some sort of management training would make them much better at using agentic swarms.
We are beset on all sides with companies declaring agentic coding a failure and here you are stating as a matter of fact some teams “thrive” with this probabilistic expensive approach to approximating working code?
All the while concluding with “I have no evidence for any of this”.
Agentic coding is absolutely not a failure. It's just not the 10x that CEOs really wanted it to be.
We learned that some tasks don't really benefit from AI while others do. My team went from 7 people to 2 (went to new teams, no layoffs), and we're doing the same amount if not more work than we used to.
Is it more draining and lacking of focused work? Yes.
Is it more money for the business? Yes.
Now we just need to find those tasks. I want to believe.
> and we're doing the same amount if not more work than we used to
Zero evidence for this. It's programmers self-reporting their own productivity. (Have we not learned this lesson after 50 years of programming practice?)
Friend, you are commenting on a thread where one of the most prominent figures in tech (rightly or wrongly) is saying something did not meet expectations. As far as we can tell this is a man with every incentive to exaggerate and boost these products.
In my world, when something is expensive and doesn’t meet expectations it called a failure. Especially when something has been as hyped, scrutinized, defended and attacked as vibe coding.
Honestly, if you are the director of robotics at a firm I think it’s time you took a cold shower.
Why would Zuckerberg want to boost their AI, they have none to speak of after Llama really? Zuckerberg actually has every expectation to downplay AI so as to save face that Llama failed compared to frontier models.
On the other side of this you have two companies growing revenue literally the fastest ever in any market segment, just for said tech. Somebody is spending this money and thinks it's worth it. Let's check back in six months.
Directionally, that's why companies are getting rid of token leaderboards and imposing limits on LLM costs. There's a diminishing marginal return to tokens
> Is it more draining and lacking of focused work?
To be completely honest, I’m living life right now. I love programming with my bare hands, but man I’m living just building a gajillion things a mile a minute with LLMs. I then come home and spend hours building stuff for myself using local models. I’ve never been so excited about just building shit, that I sometimes want to pull all nighters because I’ve been in the zone (a for work and at home).
Draining? Sorry… inject that LLM serum right into my veins
I am also leading a small team of myself and 2 others and we're getting a lot done. The short lines of communication of being a small group + the power of agents has been great for us.
Because this companies defined the goal to replace humans with AI what didn't happen. What happened is that the humans can work faster and have more coffee breaks while the AI iterates for the next review and iteration round by that human.
why would companies who build tools for developers say they'd want to replace humans with AI? it was never the goal, it was never stated like that. they said that by the end of 2026 most of the code being output would be generated by LLMs, and is pretty much true.
The bit I don't have evidence for is whether or not teaching ICs to be managers would improve how they use agentic AI. I have plenty of evidence for the efficacy and effectiveness of AI itself (although not qualitative or obviously causal unfortunately.)
> plenty of evidence … although not qualitative or obviously causal
Those two things are the opposite of each other (evidence, but only anecdotally; you cant be both).
Anyway.
More tangible to your argument; what is your argument that this will be more effective than just prompt engineering?
Ive long believed that prompt engineering is a losers game; if there is a trivial set of tricks that improve the output, they will simply be automatically applied.
We see this playing out with the system prompts in coding agents and image gen.
The value of learning “photo realistic studio lighting…” was non existent. The nano banana api is capable of taking a naive prompt and expanding it with these tricks.
People who devoted themselves to learning these “magical incantations” wasted their time and effort; and it was obvious, from the beginning this would be true.
Now.
With managing agents; if a trivial set of management tricks can drastically improve the results, why are you better off learning them now, rather than waiting for them to be baked into cursor/codex/claude in easy mode?
What makes you believe this is a valuable investment in time and effort?
Even if we accept that right now assigning personas to agents and managing them as a manager yields good results, the horizon for change right now is so short, it seems extraordinary to suggest mass management and leadership training for engineers.
We should just wait and see.
All in investments like this would just be tokenmaxing in a funny hat.
are we tho? i don't really see anyone going back to planning and coding by hand, that ship has sailed and it's not coming back. people ditching agentic workflows altogether would be failure, people figuring out it's not a miracle tool and has uses for which it's not as productive is correction.
I think you are confusing manager with ICs. Managers don't really read or review the codes. What you are describing is where agents are doing all the coding and reviewing without people in the loop. I don't think the op is working with the code as black box. He is more about describing the higher IC workflow.
Whether we still need people in the coding loop is not a trivial difference
Good ones do. Reading the code someone is contributing is a powerful signal about how well they're doing.
ICs who manage swarms of agents should operate the same way. They set them off to do something, and then look at the output to see if it's going well.
That's the point I'm making here: managing a team of ICs and managing a swarm of agents has a lot of overlap in the systems and processes you can use to see if it's working well. By teaching ICs to be better managers I think they'd get better at using agentic AI.
There's such and such. In some companies, the leaf engineers report to a team lead, which might or might not be granted this 'manager' title. Those poor fellows essentially doing double-duty and are the most likely candidates for burn-out.
"I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them."
I doubt that. Management is mostly dealing with people, the actual "management"* part is not where developers moving into management roles typically fail, it's the people part. With agents you have the management part without the people part.
I disagree with your 2nd assertion. Even engineers who are less tech lead style engineers, can gain a significant boost in productivity by being able to quickly run through POCs and build an understanding of surrounding areas of their work, so they are able to contribute more.
For eg I am able to make React changes much faster and the changes are higher quality, given frontend dev has never been my job role. I’m able to spin up test harnesses, write throw away glue code, test against large datasets, etc
> I am able to make React changes much faster and the changes are higher quality, given frontend dev has never been my job role
Man, if I had a dollar for every time someone said "I'm not good at X, but LLMs are so impressive at it". Like do you think there might be some connection between those two points?!
> I’m able to spin up test harnesses, write throw away glue code, test against large datasets, eTc
It seems that I don’t like coding when I read these kinds of statements. If I’m doing an experimentation, it would be a few lines at most. Because that’s all I needed before I can write a solution.
Writing code is the last tool to design with. Thinking and a bit of sketching is what I do mostly. Then I verify small bits with code (mostly for checking a library when the documentation is lacking or a stub when I’m focusing on another part). Otherwise, it’s just enough code to get it working well and refactoring when the requirements changes.
I get why you think this but you are incorrect. Why? Because managing a team of people is very very different from managing outsourced contractors, and LLMs are much more like the latter than the former.
Yes, an agent does feel like a very eager and very knowledgeable but also very clueless junior developer sometimes. But no, working with agents is not like leading a team of developers. You don't have to make sure an agent stays motivated, give it the feeling that its work is valued (I can let an agent spend some time building a prototype and then decide not to use it, if I did the same thing with something a junior developer took a week to build, that probably wouldn't be a good idea) etc.
> I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them.
I disagree.
From ICs that I lead, I expect that they learn fast. On the other hand, LLMs are basically incapable of improving.
Another issue that I can see is that I don't particularly like eager new colleagues who come up with (hallucinate) wrong answers. At the beginning, if you are uncertain, learn, and if you have questions that learning does not answer by itself, ask questions. But strongly avoid hallucinating answers. New colleagues can be taught that, LLMs not so.
LLMs can be 'taught' though. You can give them additional context or instructions. The difference is that they can't really teach themselves.
This is roughly what I'm saying - someone who's managing an IC can steer them on the right course, and someone who's managing an agent can also steer it on the right course, so teaching someone how to handle ICs well gives them skills that are also applicable to handling agents well.
It's not perfectly analogous obviously because ICs are people and need to be managed as people, but I really think the skills are quite transferable in one direction. I'll add that I don't think someone learning to manage agents would necessarily become a good people manager.
> I don't particularly like eager new colleagues who come up with (hallucinate) wrong answers.
People are most likely to come up with suggestions and ideas earlier rather than later.
Often they’re not learning what is “correct” but just how to “fit in”. A fresh perspective can be good even if flawed. It can help others spark new ideas and think outside the box.
The problem often is that the new manager can teach their hires to write better code and train them to be new managers. Given that a team leader in such a scenario is often checking for correctness, I am not sure if current LLM based AI will ever be able to do it. We need new AI for it.
I agree there is a skill change but agents aren't people so managing them is very different. E.g. you can spin up 1000 agents. Get them inti tight loops and get them more context and so on. A manager doesn't do that with people.
Do you mostly use agentic swarms? If so, I’d be curious of your use cases. People talk about “managing agentic swarms” a decent bit, especially on LinkedIn. I just don’t see how they are the best solution for majority of development use cases. At best they seem like using only a hammer to make sculpture.. or a sandwich.
> Some devs just 'get it' and thrive, leading a team really well and building a great culture.
I don't think it's this because the outcome you get from AI isn't controllable. You can give it the best prompts and design suggestions and it'll still give you completely wrong or horribly written code.
If you were a manager and one of your reports kept producing completely wrong and horribly written code that other folks on the team keep bringing up as problematic in PR reviews or privately, that developer would eventually be fired for someone better.
But in the AI case, there is no replacement because all of the LLMs have severe problems.
> because the outcome you get from AI isn't controllable. You can give it the best prompts and design suggestions and it'll still give you completely wrong or horribly written code.
I don’t have a dog in this fight but it seems you’re not accounting for iteration. A horse will veer off of a road if not occasionally nudged to stay on it.
> I don’t have a dog in this fight but it seems you’re not accounting for iteration and feedback
You can provide AI official sources to look at and dozens of prompts. I've lost track of the number of times where it didn't arrive at the right answer with tons of opportunities to correct itself based on feedback.
Just an endless of sea of "you're absolutely right to have brought that up, I didn't think about that" and other phrases it constantly uses when it fails to provide a solution. Fast forward 20 minutes later and it starts providing the same nonsense it did at the beginning because it forgot what it already said.
The code solutions it provides are so consistently bad but it's not limited to code. I recently tried a YouTube feature where it can generate AI thumbnails from your video. The results were really lackluster. It completely ignored my feedback like "use a real webcam photo of me that you see in the video", to which the AI recreated a completely different looking human that wasn't me. It even swapped out my real glasses with a rendering of glasses I don't have and kept on making incorrect assumptions about everything. After about 10 prompts and 20 minutes of waiting for thumbnails I gave up, it was really poor.
None of that supports the claim that it "isn't controllable," though. A curious mind should probably find it interesting that it can be fallible in those ways yet still useful for producing work, and ask how both can be true at the same time.
> Some devs just 'get it' and thrive, leading a team really well and building a great culture.
I think what makes a dev well suited for AI isn't the same as managing a team. What really helped me get productive is having to write a lot of user stories and acceptance criteria with the wisdom of being a dev tasked with implementing them. Also, being on the refinement calls, answering questions, and updating requirements/AC is good feedback for authoring better requirements. If you're good at authoring requirements, checking output, and communicating corrections concisely then you can get the LLMs to sing.
I find it interesting that when drawing this parallel you mention that some devs 'get it' and 'build a great culture'; I think this is exactly where the analogy breaks down. Good managers get great results from people (and for people! they are linked).
Good AI managers are just running optimization loops at more declarative levels. Yeah, you need to get comfortable with less personal review of code for both, but I think the differences outweigh the commonalities - it's much easier for someone with a more 'traditional' IC model to be successful with agents then they would be with management, and I think most (good) management training would be entirely irrelevant. Parallels are maybe tighter to higher IC progressions.
In my experience, it's the opposite. People who become dependent on AI agents are avoiding human contact, and people who become managers are seeking it out (for better or worse).
My experience is that AI agents write 20-33% more code than I would for a given feature set, mostly because they are worse at remembering what utility functions already exist and less likely to merge similar functions into more generic ones. They generate that code 2-10 times faster than I could. Defect density is harder to compare: I probably generate more "dumb" defects due to oversight or missing unit tests, but fewer defects that violate domain rules or architectural objectives.
Measuring aircraft production per weight doesnt sound like that bad of a proxy. If I hear that Boeing produced 300 kilotons worth of aircrafts this year, I'd be right to suspect they've ramped up production.
The thing is: I could produce 2-3 times as much code as before _without_ an LLM, if I didn't care about my colleagues' ability to review my output properly.
Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.
A huge part of the job of Software Engineering is producing the right amount of code at the right time.
> Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.
> A huge part of the job of Software Engineering is producing the right amount of code at the right time.
Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small.
120 kloc mostly from one single developer copy-pasting and keeping non-compilable code for an obsolete target "for reference" for a decade, becoming both a ball of mud and a whole pantheon of god classes? Won awards.
Properly engineered, mandatory code review, mandatory unit tests, dev meetings to knowledge-share? People with the money said too slow, closed it down.
(Sometimes people bring up how bad Musk's code was at PayPal. I never bothered investigating. Successful product though, wasn't it?)
Survivorship bias, you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise, or a product that is possible within constraints that otherwise could have been a success, but not realised by sloppy work and incompetence.
Further more the dependencies you choose to build your product are presumably filtered for engineering practices or world class engineers. So give the choice you yourself prefer top quality engineering, so do your customers.
> you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise
Trying to ignore the nuance is hard in your position or the following one I’ll give is difficult.. but is the opposite potentially true as well? We don’t know how many projects failed because of over optimizing, too much time spent on design and engineering decisions. It’s of getting out and MVP to market. I only say this because I have been apart of a few of these.
The statistical problem is small sample size, not survivorship bias, as I got to see things before failure. These two examples are merely illustrative of things I've seen.
I think both are at play here and I don’t know about Musk’s programming skills. But it seems that they had other very good programmers (including levchin). So maybe business success can buy good engineers to clean the messed up code. I’m not sure how it goes with AI now though.
If you can call being an “also ran” in a field they had a ten year march on their competitors in success, yeah.
Truth be told it was the shoddy code they were forced to use for the vanity of their paymaster might well have held them back, though manifestly that is not a bad thing. Probably the best outcome, really.
The first thing they buy of the success money though, is a struggling technical competitors, so that this team can clean up there mess. This would mean that AI is only a good contributor at startups and with prototypes.
There's a trade-off to be made, and it's not necessarily clear where the trade-off sits for any particular company, or even team within the company.
One product person described it as eating vs breathing. Availability is like breathing: if you stop being available (including, but not limited to, because your software is a big ball of mud) then you're going to die pretty quickly. Product is like eating: you might not die so quickly but if no-one's buying what you're selling then you're still not going to survive.
The team I'm part of is a platform team, so we're closer to being lungs than being stomach. We can (and I appreciate being able to) focus more on stability than feature development.
> Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small.
One of the most uncomfortable truths about our profession is that there is no floor to how bad software can be while still making people billions of dollars.
The software only had to be good enough to support the business. It doesn't have to win a Turing Award, and probably wouldn't help the business if it did.
I have been saying this for years, I once had a heated argument about a small system of maybe 1000 lines of code that was technically superior and more scalable but was freaking 1000 lines of code to maintain compared to the quick and dirty 10 lines of code it was suppose to abstract and make generic (for future use of course).
That with also countless debates over insignificant features in frontend apps at the cost of extra code. Frontend code is very susceptible to this maintenance cost dilema.
Many developers are too focused on delivery value compared to maintenance cost. It is unfortunate that non-technical management can see value delivered, but not maintenance cost incurred. With LLM-assisted code this has become many times worse.
I wonder though if, as long as you have LLMs to maintain the extra code, it's worth it to gain the new feature. Less tech debt than your intuition expects.
>Many developers are too focused on delivery value compared to maintenance cost.
The way this is worded feels like it leaves the blame on developers. Aren't these developers focused on exactly what they are being judged by? Shouldn't we say it is the management who is too focused on delivery value compared to maintenance cost? Is it the developer's job to guide management or the manager's job to request guidance, assuming such guidance is needed?
We need to make sure the responsibility to resolve this problem falls on those with the power to act on it, and in this, developers tend to be receiving far more responsibility to fix than power to fix.
I don't think so, my experience is that most often falls into two scenarios:
1) The devs pushing for more complex solutions, covering obscure edge case scenarios, feature-creep, "future-architecturing" because they are more interesting to implement. Classic over-engineering problems.
2) The features the managers actually want are usually boring or annoying to implement and the devs just work around any big architectural problems caused by the feature delivery.
1 is 100% on the devs, 2 it varies wildly, the willingness to address architectural problems are often under pressure by time-delivery estimates from managers. But many devs (especially in companies with low morale) will often just work around issues because addressing the underlying problems can be very difficult and/or time consuming.
Meaning either the dev wants to do the right thing but doesn't have the time, or the dev doesn't care enough and just pushes the tech debt down to the future (when hopefully they will be at another job).
LLMs makes both problems significantly worse, although they are also often very helpful with the big restructurings mentioned in 2. The dev can still be lazy and the deadline can still be too tight even with that extra LLM help.
It's apples and oranges. Lines of code is just a measurement. You can't look at a whole codebase and say "these X lines are essential, those Y lines are excess, delete those" -- the lines interact with each other to create the whole thing.
It would be like saying "Weight in kilograms of course is an asset for an airplane. That's what keeps it in the air. What other real asset is the airplane made of?"
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.
I think that coding reviews are no longer feasible as they used to.
The pace and expectations have increased and a human can barely cope with reviewing its own code, let alone colleagues'.
They are not going to disappear in critical aspects of a codebase, nor shouldn't, but the industry will eventually reward self sufficient individuals able to keep the pace, harness and run adversarial reviews against the design and implementation autonomously.
I'll also say the harsh truth. A well implemented adversarial flow will do either better than your peers or will deliver 95% of the value at a fraction of the cost.
The industry has never valued product, let alone code quality except in places they are core to the business.
Otherwise you would not have MIT-bred leetcode ninjas writing react/tailwind bugged monstrosities at half a million/year for billion dollar products.
This is one of the things I ran into early on. LLM needs to compute the determinant of a matrix? Sure, just spit out some huge hyper optimized implementation of it. Good luck maintaining that. Slapping "use industry standard open source libraries for common functions" has improved the quality of LLM output for me by such a large margin.
"A huge part of the job of Software Engineering is producing the right amount of code at the right time."
But the whole job of the owners is to lower the costs as much as possible to produce the product, especially in an environment with higher costs to borrow (higher interest rates at the fed)
Back in the day there was a mantra: best amount od code is 0.
Now we have agents spitting lines after lines.
I am not afraid of my future. Even if one person can do work of 5, the amount of generated code will grow exponentially. And not everything can he vibecoded with 0 knowledge.
There is a complexity that need understanding to change and optimize. For now :)
I'm really struggling to get an agent to write code I'm happy with. It's mostly pretty awful.
I've a fairly simple c# coding style. But simple is proving a bit more difficult to convey than I thought.
I get it to produce code. I then have to spend along time convincing myself it's correct. If I don't I end up embarrassing myself when a coworker reviews it, questions it and it's obvious I don't properly understand it.
This is really starting to screw with me mentally. It's like everyone in the world is saying they can fly by flapping their arms (dark factories). When I try I just stay in the same spot burning a lot of energy.
I don't think everyone in the world is saying they can fly by flapping their arms. It's a small number of very vocal, very online, AI enthusiasts, many who have a financial stake in AI winning.
work from tests to implementation. Validate the tests, and work with the agent to ensure there are not more cases that need testing. Then you can let the agent implement the code and you can refine it until it's simple enough but covers the test cases. TDD is the only way to use agents effectively, imo
Thanks. I have been doing this tdd abd it's a big improvement but the code is still pretty awful. Two skills I rely on are Matt pococks grill-me and his tdd. These massively helped, and technically the code generated is correct but it's still hard to follow and bloated.
As a hobbyist coder, I wonder how much more new code, fundamentally, there needs to be? New devices need new firmware, new cars etc, but how much of that is bespoke? Sure, a new movie or a book is new entertainment, but I've already seen that movie and read that book, they just had different jackets. What do these "engineers" actually do that is novel and how much of the pizza is the novel slice is?
I would add that a lot of that extra code is often in test/demo paths... I tend to think of working with an Agent as a "team" of 1 + agent... where the developer is now wearing a QA and PM hat in addition to lead/sr dev. That the work getting done is now roughly the offset of what a team would have produced and that coordination needs to step back and treat each individual with an agent as roughly a dev team. Coordination overhead and mythical man month still apply, just at a layer up.
That's a great question. Some form of union has already started in some companies, as far as I know. But not many employees have joined those unions. Probably because most employees have high income and don't really feel like they need collective bargaining power, compared to other low-income laborers.
I think there are seriously misplaced expectations here. The primary role of AI is transference of effort, while "increased productivity" is just a side-effect (since computers are so much faster than humans at highly repetitive tasks). It's about not having to directly do X anymore (or as often), even though it may take a few rounds to get X to a satisfactory point. But even if following up is needed, most of the effort budget can then be used for Y.
Also those with very heavy investment in AI are looking for bonkers results, which is the cause of their disappointment. They need to reduce their expectations. I for one am loving the results so far.
Having agents is like going from walking to having a bicycle.
Business executives look at this and think "at this rate of progress we'll have self-driving cars in a few years!" and start making serious plans for that world.
In reality I think we're going to be riding bikes for a long time. That situation of increased individual contributor productivity makes engineers more valuable, and increases the utility of engineers rather than making them a burden on your budget.
Thus, cutting headcount right as they had huge potential to become vastly more productive was a stupid move. It's an admission that you don't know how to manage people effectively, which is embarrassing when you're paid mountains of money for your management skills.
Nobody knows if we are going to "just" be riding bikes for a long time.
To give time for society to adapt I hope it's the case, but we really have no idea.
Right, but if your real assertion is “we have no idea”, it seems you should point your skepticism significantly more towards the people betting $100 billion dollars that self-driving cars are coming next year than the ones who aren’t.
Evidence towards aside, the risk calculation depends on how much upside is from the 100B if progress starts the same rate. I think it's hard to bound that accurately
It looks pretty clear LLMs don't get us there by themselves, no amount of duct tape, WD-40, etc. gets us past, say, the mathematical certainty of hallucinations.
I mean, we don't know it any more than we don't know someone won't come out with cold fusion tomorrow, but it's a fundamental breakthrough away from where we're at. This isn't some routine engineering project with a guarantee of completion if you're just willing to keep pouring the billions. That's playing the lotto, you can pour away and get flat nothing.
The only difference is they're pouring billions and praying a rabbit comes out of the hat, but it's actually not much reason to expect they're going to pull the cold-fusion level rabbit out of their hat they'd need to get us past bikes.
Have you seen the original bicycles. Boneshakers and so on. No pneumatic tires. They were just enough more efficient than walking to sell but other than that pretty dreadful. Penny farthings where your feet directly drove the wheel. So many injuries!
There's a disconnect between measured productivity and "anecdotal" productivity. I love this chart because it also demonstrates one of the most effective ways to increase productivity: simply reducing the workforce.
with coding, you have sort of a framework for doing it right, if you have good specs, good testing practices, strict grounding in expected results deterministically, good linting, etc... this is much easier to automate with AI for the coding part within that assuming you did your homework around it... i don't have experience with all the business layers but it seems a bit more nuanced and fuzzy as you get away from that "harness" of sorts as it doesn't have to work in the same way as code for execution and evaluation... and even if code works, it still needs tastemakers in the final ok. maybe the taste maker ability still needs a lot of work/scale to be feasible, idk, like its still earlier than later on that. maybe Elon already cracked this to an extent given his automation in various companies.
I'm sorry if it's a non sequitur but I feel even beyond superintelligence/AI/LLM whatever of the last few years... they've always done this, it's always been somewhat hamfisted
Examples abound of "I reported Nazi hate page. Didn't violate community guidelines. I called my friend a jerk, jokingly, got a month ban
For years. Not restricted to when ChatGPT et al arrived on the scene
(Because, AI in theory makes sense. If you want to monitor things at scale you might use AI - however that's defined - to make your workload easier. When is an account being hijacked? When are bad actors infiltrating the system? Or whatever)
If a Meta employee screws up a major project, what happens? What will happen to the executives behind these mass firings and realignment - executives of one of the very top SV companies whose job is dealing with the landscape of disruptive technology development and overreacted to the latest thing? What is the standard for them?
279 comments
[ 4.1 ms ] story [ 133 ms ] threadThe modern trend is to think intelligence is generative “like compression” or “predicting next in sequence” rather than iteratively reducing uncertainty, like those fault tolerant humans.
No one ever in comp sci says artificial intelligence is "like compression", they correctly state that "artificial intelligence IS compression". It's absolutely known and accepted that artificial intelligence (defined as predicting outcomes with a measure of certainty and taking chosen actions towards goals using those predictions) has equivalence to compression in a very hard science way. The hardest part of artificial intelligence is compression and the remaining part, the choice of actions based on predictions is just a tree search to a goal.
AI can be just like compression but currently the compute power is no match for details.
Finally these reality details need consideration in any successful implementation. Which means the implementator needs to be aware of the details and successfully relate them to everything else in the model.
I think anyone surprised by these things is not fully engaged with what they are doing.
The harnesses get better, but I haven’t seen much experimentation on long term stability, at least since the “let the LLM run the candy machine” papers from a while ago.
Because the thing missing, even with the largest agentic swarms, is independent intelligence, where it’s given something to own, like say “end to end data quality as we add more clients” (for a SaaS) and it just figures out what that means at each time, mutating its role and solutions to fix the external world, without getting silly.
https://uk.pcmag.com/ai/165970/meta-exploring-option-to-sell...
Meta bought too many GPUs, has spare GPU capacity and they are exploring renting that capacity out.
The problem is not that the models need too much to do the job. If that were the case, Meta would not have spare capacity.
The problem is that the models currently can't be made to do the job.
Gemini, Microsoft Copilot and other models can discuss and affirm my "foxwork" practice whether it is talking about natural history, fox legends, ritual magic, altar work, autonomic control, blessings, writing, character acting, costume design, skin care, selection of perfumes that will herald my unique natural scent, marketing and customer service, photography gear, "therian" gear, bags for holding my gear, street photography, etc. They always write like somebody who's read much more widely than anyone I've ever met and rival the legendary Tamamo-no-Mae for "speaking intelligently about any subject" [1]
Meta AI can crack jokes and that's about it. I guess there's a market for "stupid talk" but it's not that big.
[1] Like help me fix my washing machine that won't drain, come up with master narratives for the "polycrisis", talk about why Casey Handmer is wrong about space manufacturing, find papers about the social network of who sleeps with who at a high school, etc.
All these companies are going to sit on their gazillion data centers once the mania dies down and will have a big problem about what to do with their mountain of hardware
They were allegedly massive but the cost and returns were not worth it.
Of course, param count and context length are also important because they increase the model's overall fidelity, but a base model without SFT, RHLF etc is effectively useless.
Scale was really the unlock; the new pre and post training techniques and architectures are very cool and useful but they definitely aren't the differentiators when comparing to the previous era of NLP.
The fact that their advancement suggested that pouring more compute would continue working was also especially attractive to investors: it made a massive R&D budget feel like less of a risk.
It's definitely too early to declare that more compute won't make a difference.
Only with an LLM that's actually at agent-quality.
If "useful chatbot" and "useful agent" are two rungs on a ladder, the rung before them is "useful autocomplete". Autocomplete that only gets the next token right 90% of the time won't give you compiling code.
The elaborate workarounds you have to build to help an agent which fundamentally doesn’t know what it’s doing reminds me of this old blog post about TDD: https://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-...
IMO present technology is tailored for an experienced developer to give agents manageable tasks that can be one-shot. The marketing right now reminds me of the 90s when AskJeeves promised natural language search when the technology was fundamentally still stuck in keyword search, and learning to craft a search query for Google is today’s prompt engineering
But if you go beyond what can be tested easily, asking the agent to do real work rather than writing a patch, imagining things to be true is a problem.
Maybe Wang has correctly identified that the programming and agentic ability that Anthropic and OpenAI models have has largely come from armies of software engineers creating massive datasets by writing out coding and agentic problems and solutions?
So he told Zuckerberg that. The reason it may be turning into so much friction is that at companies like Anthropic or OpenAI, training engineers were either hired specifically for that purpose or probably mostly handled through contracts with third parties (which again, hired them to train AI). And honestly many of them may be overseas or just happy to have a job in a difficult period. But anyway they wouldn't have very high salary expectations etc.
But Zuckerberg already had 25000 engineers. Why not take say 1/5 of them and get them working on the the dataset? The problem is that those engineers were hired for different prestigious highly paid positions at Meta/Facebook. They were not hired to do tedious grading of AI answers or quiz construction.
But Zuckerberg either has to do this, or spend additional billions on doing it all with external contractors. A third option would be to try to create a massive distillation operation. Or just hope that his engineers could invent some magical new training trick that manifested the agentic and programming skills without the large scale human input.
Or he could release a model trained largely by existing open weights models. Which without some huge breakthrough probably has no chance of surpassing them, so is pointless.
I think most of the substantive criticism of Zuckerberg has been about burning funds. If he gives up the "your job is to grade AI homework now" plan because his engineers refuse, he would need to go through third parties. The additional billions and billions this would cost would create more pressure on the bottom line and shareholder pressure.
It would also give up any potential advantage that Wang may have optimistically sold the operation as, on that using "real" engineers as opposed to lower paid data labelling engineers might result in a higher quality dataset.
At some point, model architectures that don't need such massive datasets or can be created automatically in a way that advances the frontier will probably come about. But right now it doesn't exist.
Further, the way AI works currently, business advantage from AI comes from encoding existing internal intelligence and knowledge. Meta's massive engineering corp effectively has that in their heads. Having them create these datasets is possibly the only way to leverage this knowledge asset in this paradigm.
I guess the problem is it means forcing thousands of people to do a different job from the one they were hired for.
> Or he could release a model trained largely by existing open weights models. Which without some huge breakthrough probably has no chance of surpassing them, so is pointless.
This seems to be categorically untrue. Composer 2.5 is a substantial improvement on its underlying Kimi base model.
They may eventually have to do that. Or they might be starting with an existing Llama model. Maybe I should have said "huge breakthrough or additional dataset".
What's the end goal? Meta-specific engineering, with baked-in knowledge of how FB, Threads, and WhatsApp work? General and/or coding products to compete with Anthropic and OpenAI? Some special Magic Thing which only Meta can invent which will bedazzle Meta's users?
You don't need giant datasets unless you know what you're going to do with them. OpAI and Anthropic are having enough issues making their products profitable. And those are, if not beloved, then at least respected, with a real, if patchy, reputation for usefulness.
What was Meta's pitch in this market? There were hints of interest when LeCun was still doing original R&D, and there was some distant possibility of a next-gen revolutionary product.
But now the goal seems to be to flail around doing something incoherently AI-branded with no obvious strategy.
The troops are being marched around, but no one knows where the battle is supposed to be.
Code autocomplete is a success, password reset via ai is a failure - everything else ... still busy tokenmaxxxing in search of a problem it fits into.
In that market you can build a model and spend a lot of money on it and at best get something that's on the same frontier as everybody else but just as likely end up with uncompetitive models like the ones they have now.
You might save a bit running your own models, doing your own inference, etc. Why not take advantage of "last mover advantage" and buy whatever is best when you need it and figure the odds are good that everybody else is going to buy more GPUs than they need and as a large customer you'll be able to buy in bulk at fire sale prices?
I'm not in the org myself I know some Meta SWEs tangentially. My understanding is that the biggest criticism is just the chaos of it all. Jumping constantly from one thing to another like headless chickens and accomplishing nothing.
It created an environment where it's kind of impossible to plan and progress your career.
The 2017 Rohingya massacre in Myanmar? They handed him the death toll. He filed it under growth.
Im not certain things will look too different a year from now either. We still have serious bottlenecks in terms of focus/attention you have for both delegating agent work and being able to review it. Even if we solve the "trust what ai does" problem, these cognitive deficit issues still exist - for teams coordinating work, even users adopting new shit, etc.
As an industry we are leaning heavy into accepting "slop" being ok for status quo as we care more about efficiency of output right now. Slop will get better & we can become more adaptive to living with the paradox of amazing yet delicate systems generated by AI.
But I do think we are going to learn to slow down
https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing...
Ignoring instructions - whether in AGENTS.md or my prompt - is the worst of it, and it routinely happens. It just waives things that I explicitly told it to do as part of the design.
Vibe coders (in the true sense, zero oversight) claim that you just need to prompt it carefully. That's completely untrue when faced with your careful prompt being ignored.
I even have "don't overrule me without asking" in my global AGENTS.md, and it simply doesn't do that.
I try to avoid > 200k contexts, as the 1M context is where I first saw the massive decrease in reliability.
And my AGENTS is really short, and I said it was ignoring decisions in the prompt.
You really need to look into hooks based on your coding agent. This is very much a solved problem as I demonstrate with
https://github.com/gitsense/pi-brains
I have a test repo
https://github.com/gitsense/gsc-rules-demos
that shows how you can block and warn and do other things.
You obviously can't have a "Don't make a mistake" rule though.
The agreed architecture is to use signing between two micros, so that a third can orchestrate between them in zero trust way (and to prevent a distributed monolith). It just decides that we can trust the third and skips the signing.
opus will definitely ignore instructions if you give it contradictory instructions, or a plan that has steps that obviously don't work with each other. but if you give it a coherent plan, it will follow it.
Try writing it in first person instead of second person or neutral.
A while ago someone had a similar complaint on here and shared some example lines, and that popped out at me immediately. However much structure we've wrapped these in, they're still text generators trained on all sorts of things, and if you think about a narrative where first and second person speech would be used, try to imagine context: In first person, it's most likely a description of something as it happens someone planning what they will do. But in second person, especially command form, you open up to the possibility of commands being ignored, misunderstood, or actively rebelled against.
Whoever that was back then did some quick tests and found the pattern held, first person got it to follow far more reliably.
However that still means there's always some probability it will do things you told it not to, it's just reduced. Always a small (hopefully very small) probability the next most likely sequence of tokens is for it to try and run `rm -rf /`
People thought they'd get their own persona through AI, they get a sum of the best and worse of everyone.
I find this somewhat puzzling. I thought things were moving quickly, but at this time last year I couldn't even get Claude (using Cursor) to spin me up a service skeleton that would compile, let alone do anything meaningful.
I know it feels like a long time somehow, but it was only between November and February that things started to actually somewhat work without significant hand holding. Even now, it seems like we're still figuring out how to fully leverage the current models and tooling, even in organizations that have largely gotten on board.
I've been using it to do this for 2 years now. And many people with me. The change you mention is one of is primarily one of Overton windows, of vibes.
I suspect this may have depended on the specific framework. I quite literally could not get Claude (in Cursor) to give me a basic Micronaut setup in a fresh workspace with essentially a "hello, world" API. I would guess that if you're using something like Python and FastAPI, it might have been an easier task or better represented in the data.
The difference that I observed in the Opus 4.5 era is that Claude could take a service framework it has never seen before (proprietary corp) and figure it out.
No. The very fact they are trying to "warn" us means it's all marketing.
This has been corroborated for me on the engineering front that I can't find a single IC I respect who actually thought there was any evidence AI was going to live up to the hype. I saw a lot of people I always thought were idiots/sycophants/brown nosers go insane with AI. Never saw anyone id trust to help me cross a street blindfolded say more that "I may be wrong, but I'm not seeing any evidence yet".
It can be massively over hyped for it's current capacity and decimate the white collar work.
A lot of the difference of opinion is down to their point of view. At my dayjob, LLMs will not live up to anything because the enterprise is not structured to take advantage of it's strength. That's unlikely to change within the foreseeable future.
I strongly suspect you mostly talked with people coming from just such a background, because it's hard to go beyond our own bubbles
The irony here is that you are correct in the original sense of the word "decimate".
However, in my lifetime I've never seen someone both understand the original meaning of the word "decimate" and use it as the ancient Romans intended.
Social media is flooded with bots pushing this narrative - coding is dead, engineers are all cooked, the latest model is scarily good, "what am I for?", etc.
A good rule of thumb is that if it's a human being and not a bot, they'll use the word "slop" at some point.
https://fortune.com/2026/04/04/ai-jobs-future-not-important-...
There was an interesting comment during the cloudflare layoffs (partially driven by the fact that the company was bleeding money also because of its token costs from one estimate being 500 million$ per month, don't quote me on that though)
The part was that there is only an enough marketshare in the first place. Cloudflare was doing some crazy experiments like operating matrix on cf workers and wordpress alternative and fediverse and so much stuff.
So they basically spent 10x the amount of token (and the token costs) and I imagine as such the reading code of that part was getting sidelined as the attractive principle you are talking about.
Yet the market can't bring an actual demand 10x times though. These are things which nudge a user slightly but the actual impact on user growth isn't 10x or even justifiable within some cases given the costs.
Yet at the same time driving up the people who actually know their stuff and firing them because of the token costs. The people who have actually mitigated some of the largest DDOS attacks and are the backbone behind cf cash-cow (enterprise payments) is the fact that they have had the experience and entreprise knowledge about these things, yet they are literally removing that by firing workers and oh replacing them with interns. (They got 1111 interns and fired 1100 employees or something iirc)
It's weird and I have talked to some people about it but there is a disconnect between what management is hearing about AI and the ground reality of things. Reviewing code is becoming the bottleneck but if you don't review code and are shipping things to production, then you can get fired as I have talked about in some of my other comments sharing a story about how a guy shipped code to prod and the response was "but claude generated it" and got fired because the company basically said, look we basically don't care if it was generated by claude but the responsibility was on you to check it (review) and because the commit was done by you, you are gonna be treated responsible and he got fired from his job.
Yet this was the same company which was asking its employee to play around with claude at their free time, the manager of the employee I talked to being the most automatable person, the company employees working till 1 AM because they were saying to management that things were fine but they were being burried under the technical debt,that employee that I talked to got honest with the management and told reality and the management treated them as a person who didn't know AI or were the odd one out.
Sooo I don't know actually to be honest.
Cloudflare had 5000 employees (pre-layoff), so you are suggesting that every single one of them (eng, HR, legal, finance, receptionists) was using $100k tokens per month (that's $1.2M annualized, per employee), for a total of 3x gross revenue going to AI spend.
Let's imagine that this isn't absurd on its face. If true, then you'd expect Cloudflare's Q1 earnings to show a massive, massive net loss. In fact Cloudflare was cash flow positive in Q1.
The rest of your post is more qualitative, so harder to disprove, but from what I can tell, it seems equally made up.
(I work at Cloudflare.)
Comparing accrual earnings to cash flows.
I have written an more in-depth comment if that interests ya (in a good faith discussion and please be kind to everybody)
also please don't call @kentonv an idiot and please read the HN guidelines[0]: Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
[0]: https://news.ycombinator.com/newsguidelines.html
I had mistakenly written 500 million when it was around 5 million dollars so I messed up its 5 million per month, not 500 million. I wish to have a genuine discussion while you are here though because i can be wrong, I usually am and I would love to have a good faith discussion, thanks in advance!
I will try to back up a lot of it with hackernews comments from the thread when cloudflare layoffs were suggested so that I don't accidentally mis-represent anything and My suggestion wasn't a critique of cloudflare and please don't take it as such. The question was simply of the AI token costs associated.
and this was the comment that I was referencing to[0] which states the following:
> There was an recent article on X with an interesting take - it could be that companies are doing layoffs not because AI is making them more productive but because it hasn't. Their costs have gone up paying for expensive AI but haven't seen any revenue benefits to offset it.
An child comment of it talks about the coinbase layoffs which had happened around the same time[1]:
> (..) In 2023, their "Technology and Development" line item shows $1.32bn going out, and by 2025 it'd ballooned to $1.67bn. This is despite headcount actually contracting by almost a thousand people between those two statements.
Regarding this: > Let's imagine that this isn't absurd on its face. If true, then you'd expect Cloudflare's Q1 earnings to show a massive, massive net loss. In fact Cloudflare was cash flow positive in Q1.
We might be forgetting that (from my understanding, Cloudflare has never had profits) (positive annual net income) with an astronomically large P/E ratio.
There was a comment which I had read which talks about this in more detail (https://news.ycombinator.com/item?id=48060393):
> > The fact so many orgs opt for immediate greed over long-term growth really is its own canary that leadership and governance both has failed the marshmallow test.
> Why do you think it's greed? The company's stock is down and they just missed expectations on their last earnings report (unheard of in big tech in the last 2 years).
> It seems more like a traditional layoff scenario
Another comment [from the Layoff thread][2] which summarizes what I wish to say:
"Their AI costs have increased 600% but this hasn't translated into actual revenue. Also they are probably projecting AI costs to keep growing. They've done the math and at some point it is going to affect their bottom line. Reducing or limiting AI usage would be inconceivable given Cloudflare itself has invested on AI and is selling AI services. Instead they've opted for reducing about 20% of their head count."
I genuinely wish if we can have a good faith discussion about it. I appreciate cloudflare as a product myself and actively use cf tunnels, which is why I care about it as well and I wish to have a good faith discussion about it hopefully as well :-D
> The rest of your post is more qualitative, so harder to disprove, but from what I can tell, it seems equally made up.
I can be wrong, I usually am and if I am wrong, I wish to learn from it and I wish to improve as a person too!
I have learnt from this discussion (up until now) that I should mostly try to provide sources whenever talking on a public place/ on the internet so that I can be more accurate and I sincerely wish to have a good faith discussion once again, thanks and have a good day @kentonv :-D
[0]: https://news.ycombinator.com/item?id=48055149
[1]: https://news.ycombinator.com/item?id=48055413
[2]:https:/&#x...
I'm pretty sure I know where the failure case on that one is. The reason we're still manually reading code is to catch the failures and edge cases that the LLM fails to; not reading the code doesn't magically make the code good.
It never was going to happen.
Always the same story: https://en.wikipedia.org/wiki/Gartner_hype_cycle#/media/File...
I personally don't think it's possible and I haven't written a line of code since Sept 2025.
There's an AI psychosis going on right now, especially among the execs or management class, and we all gotta nod our heads in agreement and burn through tokens.
But a slop machine that haphazardly shoots features against the wall to see what sticks still isn't a winning product strategy in 2026. And the problem I see increasingly is that so much energy is being focused on how to deliver with AI internally and externally that is not being expended to advance a company's product. I believe more and more in the idea that for many startups and companies, the actual "customers" are the investors and the product-market fit that companies seek is the product of the company itself, because this is all being driven from the top down, not by customers and users in the market asking for AI features.
In many respects this reflects the growing K-shaped nature of our economy. Average consumers don't matter because you really just need a small cohort of wealthy individuals to be hyper-invested in your product, 'regular' consumption is therefore just a way to keep things relatively on rails rather than the actual economic driver.
All of these AI-first companies don't actually have any market fit, so what they're doing is selling an imaginary product so that they can get investments and loans. As you said the company is the product.
"What can we get rid of for MVP" as a design strategy vs a way to iterate fast, for instance. Cutting things isn't a way to product cohesion, especially if you never go back to do the full-featured version.
Sometimes I wonder how many features or products flopped because the MVP dropped the things that would've actually taken off, and the business "smartly" pivoted away.
There's still a limit to how many new features you could shove in front of your users per month. But what if they were all much more baked out of the gate?
(See also: "data driven" product management as an excuse to not have your own vision for the product. If three competitors build a lot more in the span of six months, but have to depend more on their own skills and instincts vs A/Bing every little detail, maybe more of them will ship more bold and interesting new things.)
It's eerie to observe collaborators output code they don't understand, spend days chatting with Claude instead of reading (like really reading) compiler's output or 3 pages of manual, and how lost and oblivious they look when the AI fixates on solving a different problem than the one they have been tasked.
Amara’s law: We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
This continues to be applied to AI where people think is going to be next 12 to 18 months. Changes are coming but certainly not at the rate Zuckerberg and most people are thinking.
This is why you get "AI winters" but we've never had a "steam engine winter" or a "railway winter" or a "petrochemicals winter"
So the nuclear power problem of "it works fine and it's actually very good in a lot of ways, it's just too expensive" could be quite relevant
Thats not the problem (its been done, see Messmer Plan or Japan's ABWR fleet[1]), getting the support of the public (and keeping that support, unlike France did beginning in the 90s)
[1]: https://www.youtube.com/watch?v=w2YHrJafMlE
However, if you get 2 to 3 times the code in the interim, that's probably less than what's needed. I find myself cycle through almost 10x-20x amount of code implementations to get what I want which is actually less code, simple solution and desired behavior.
"..........."
I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them.
Some devs just 'get it' and thrive, leading a team really well and building a great culture. But a lot of them don't, especially if they don't get the support necessary to understand what changes when you move from IC to manager. If the team (or agent swarm) isn't performing well it often isn't a problem with them. It's a problem with the new manager still trying to stay on top of everything and micromanaging all the things. Alternatively, the new manager is completely hands off and only appears at a check-in point (one-to-one, agent completes a task, etc) where they crap on the work and get cross.
I have no evidence for this, but I'd guess that putting developers through some sort of management training would make them much better at using agentic swarms.
We are beset on all sides with companies declaring agentic coding a failure and here you are stating as a matter of fact some teams “thrive” with this probabilistic expensive approach to approximating working code?
All the while concluding with “I have no evidence for any of this”.
We learned that some tasks don't really benefit from AI while others do. My team went from 7 people to 2 (went to new teams, no layoffs), and we're doing the same amount if not more work than we used to.
Is it more draining and lacking of focused work? Yes. Is it more money for the business? Yes.
Now we just need to find those tasks. I want to believe.
> and we're doing the same amount if not more work than we used to
Zero evidence for this. It's programmers self-reporting their own productivity. (Have we not learned this lesson after 50 years of programming practice?)
In my world, when something is expensive and doesn’t meet expectations it called a failure. Especially when something has been as hyped, scrutinized, defended and attacked as vibe coding.
Honestly, if you are the director of robotics at a firm I think it’s time you took a cold shower.
If you claim 10x and deliver 3x, that is a failure. The 3x may still be impressive or a gamechanger or ..., but it still falls short of its promises.
Pay me 8x to get 10x, great. Pay me 8x to get 3x, nope.
To be completely honest, I’m living life right now. I love programming with my bare hands, but man I’m living just building a gajillion things a mile a minute with LLMs. I then come home and spend hours building stuff for myself using local models. I’ve never been so excited about just building shit, that I sometimes want to pull all nighters because I’ve been in the zone (a for work and at home).
Draining? Sorry… inject that LLM serum right into my veins
It’s absolutely 10x faster for coding. But coding is only 10% of my job. The other 90% is figuring out what to code.
Those two things are the opposite of each other (evidence, but only anecdotally; you cant be both).
Anyway.
More tangible to your argument; what is your argument that this will be more effective than just prompt engineering?
Ive long believed that prompt engineering is a losers game; if there is a trivial set of tricks that improve the output, they will simply be automatically applied.
We see this playing out with the system prompts in coding agents and image gen.
The value of learning “photo realistic studio lighting…” was non existent. The nano banana api is capable of taking a naive prompt and expanding it with these tricks.
People who devoted themselves to learning these “magical incantations” wasted their time and effort; and it was obvious, from the beginning this would be true.
Now.
With managing agents; if a trivial set of management tricks can drastically improve the results, why are you better off learning them now, rather than waiting for them to be baked into cursor/codex/claude in easy mode?
What makes you believe this is a valuable investment in time and effort?
Even if we accept that right now assigning personas to agents and managing them as a manager yields good results, the horizon for change right now is so short, it seems extraordinary to suggest mass management and leadership training for engineers.
We should just wait and see.
All in investments like this would just be tokenmaxing in a funny hat.
Whether we still need people in the coding loop is not a trivial difference
Good ones do. Reading the code someone is contributing is a powerful signal about how well they're doing.
ICs who manage swarms of agents should operate the same way. They set them off to do something, and then look at the output to see if it's going well.
That's the point I'm making here: managing a team of ICs and managing a swarm of agents has a lot of overlap in the systems and processes you can use to see if it's working well. By teaching ICs to be better managers I think they'd get better at using agentic AI.
There's such and such. In some companies, the leaf engineers report to a team lead, which might or might not be granted this 'manager' title. Those poor fellows essentially doing double-duty and are the most likely candidates for burn-out.
LLMs are driven by the text you enter into them and they are never fully autonomous unlike an actual employee.
You cannot train an AI and then at some point just let it loose.
I doubt that. Management is mostly dealing with people, the actual "management"* part is not where developers moving into management roles typically fail, it's the people part. With agents you have the management part without the people part.
For eg I am able to make React changes much faster and the changes are higher quality, given frontend dev has never been my job role. I’m able to spin up test harnesses, write throw away glue code, test against large datasets, etc
Man, if I had a dollar for every time someone said "I'm not good at X, but LLMs are so impressive at it". Like do you think there might be some connection between those two points?!
It seems that I don’t like coding when I read these kinds of statements. If I’m doing an experimentation, it would be a few lines at most. Because that’s all I needed before I can write a solution.
Writing code is the last tool to design with. Thinking and a bit of sketching is what I do mostly. Then I verify small bits with code (mostly for checking a library when the documentation is lacking or a stub when I’m focusing on another part). Otherwise, it’s just enough code to get it working well and refactoring when the requirements changes.
I disagree.
From ICs that I lead, I expect that they learn fast. On the other hand, LLMs are basically incapable of improving.
Another issue that I can see is that I don't particularly like eager new colleagues who come up with (hallucinate) wrong answers. At the beginning, if you are uncertain, learn, and if you have questions that learning does not answer by itself, ask questions. But strongly avoid hallucinating answers. New colleagues can be taught that, LLMs not so.
LLMs can be 'taught' though. You can give them additional context or instructions. The difference is that they can't really teach themselves.
This is roughly what I'm saying - someone who's managing an IC can steer them on the right course, and someone who's managing an agent can also steer it on the right course, so teaching someone how to handle ICs well gives them skills that are also applicable to handling agents well.
It's not perfectly analogous obviously because ICs are people and need to be managed as people, but I really think the skills are quite transferable in one direction. I'll add that I don't think someone learning to manage agents would necessarily become a good people manager.
That's not teaching. Giving someone new information in the moment does not amount to giving them new long-term capabilities.
People are most likely to come up with suggestions and ideas earlier rather than later.
Often they’re not learning what is “correct” but just how to “fit in”. A fresh perspective can be good even if flawed. It can help others spark new ideas and think outside the box.
Do you mostly use agentic swarms? If so, I’d be curious of your use cases. People talk about “managing agentic swarms” a decent bit, especially on LinkedIn. I just don’t see how they are the best solution for majority of development use cases. At best they seem like using only a hammer to make sculpture.. or a sandwich.
I don't think it's this because the outcome you get from AI isn't controllable. You can give it the best prompts and design suggestions and it'll still give you completely wrong or horribly written code.
If you were a manager and one of your reports kept producing completely wrong and horribly written code that other folks on the team keep bringing up as problematic in PR reviews or privately, that developer would eventually be fired for someone better.
But in the AI case, there is no replacement because all of the LLMs have severe problems.
I don’t have a dog in this fight but it seems you’re not accounting for iteration. A horse will veer off of a road if not occasionally nudged to stay on it.
You can provide AI official sources to look at and dozens of prompts. I've lost track of the number of times where it didn't arrive at the right answer with tons of opportunities to correct itself based on feedback.
Just an endless of sea of "you're absolutely right to have brought that up, I didn't think about that" and other phrases it constantly uses when it fails to provide a solution. Fast forward 20 minutes later and it starts providing the same nonsense it did at the beginning because it forgot what it already said.
The code solutions it provides are so consistently bad but it's not limited to code. I recently tried a YouTube feature where it can generate AI thumbnails from your video. The results were really lackluster. It completely ignored my feedback like "use a real webcam photo of me that you see in the video", to which the AI recreated a completely different looking human that wasn't me. It even swapped out my real glasses with a rendering of glasses I don't have and kept on making incorrect assumptions about everything. After about 10 prompts and 20 minutes of waiting for thumbnails I gave up, it was really poor.
This bottleneck will always have to exist unless companies just accept AI defaults, with predictable outcomes.
I think what makes a dev well suited for AI isn't the same as managing a team. What really helped me get productive is having to write a lot of user stories and acceptance criteria with the wisdom of being a dev tasked with implementing them. Also, being on the refinement calls, answering questions, and updating requirements/AC is good feedback for authoring better requirements. If you're good at authoring requirements, checking output, and communicating corrections concisely then you can get the LLMs to sing.
Good AI managers are just running optimization loops at more declarative levels. Yeah, you need to get comfortable with less personal review of code for both, but I think the differences outweigh the commonalities - it's much easier for someone with a more 'traditional' IC model to be successful with agents then they would be with management, and I think most (good) management training would be entirely irrelevant. Parallels are maybe tighter to higher IC progressions.
The job isn't to write code. The job isn't to architect. Those are means to an end.
Anecdotally: it seems like the most principled developers are having the most trouble adapting to agentic workflows.
I have no idea why everyone seems to have forgotten this simple fact over the last four years.
Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.
A huge part of the job of Software Engineering is producing the right amount of code at the right time.
> A huge part of the job of Software Engineering is producing the right amount of code at the right time.
Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small.
120 kloc mostly from one single developer copy-pasting and keeping non-compilable code for an obsolete target "for reference" for a decade, becoming both a ball of mud and a whole pantheon of god classes? Won awards.
Properly engineered, mandatory code review, mandatory unit tests, dev meetings to knowledge-share? People with the money said too slow, closed it down.
(Sometimes people bring up how bad Musk's code was at PayPal. I never bothered investigating. Successful product though, wasn't it?)
Further more the dependencies you choose to build your product are presumably filtered for engineering practices or world class engineers. So give the choice you yourself prefer top quality engineering, so do your customers.
Trying to ignore the nuance is hard in your position or the following one I’ll give is difficult.. but is the opposite potentially true as well? We don’t know how many projects failed because of over optimizing, too much time spent on design and engineering decisions. It’s of getting out and MVP to market. I only say this because I have been apart of a few of these.
The statistical problem is small sample size, not survivorship bias, as I got to see things before failure. These two examples are merely illustrative of things I've seen.
If you can call being an “also ran” in a field they had a ten year march on their competitors in success, yeah.
Truth be told it was the shoddy code they were forced to use for the vanity of their paymaster might well have held them back, though manifestly that is not a bad thing. Probably the best outcome, really.
One product person described it as eating vs breathing. Availability is like breathing: if you stop being available (including, but not limited to, because your software is a big ball of mud) then you're going to die pretty quickly. Product is like eating: you might not die so quickly but if no-one's buying what you're selling then you're still not going to survive.
The team I'm part of is a platform team, so we're closer to being lungs than being stomach. We can (and I appreciate being able to) focus more on stability than feature development.
One of the most uncomfortable truths about our profession is that there is no floor to how bad software can be while still making people billions of dollars.
The software only had to be good enough to support the business. It doesn't have to win a Turing Award, and probably wouldn't help the business if it did.
I have been saying this for years, I once had a heated argument about a small system of maybe 1000 lines of code that was technically superior and more scalable but was freaking 1000 lines of code to maintain compared to the quick and dirty 10 lines of code it was suppose to abstract and make generic (for future use of course).
That with also countless debates over insignificant features in frontend apps at the cost of extra code. Frontend code is very susceptible to this maintenance cost dilema.
Many developers are too focused on delivery value compared to maintenance cost. It is unfortunate that non-technical management can see value delivered, but not maintenance cost incurred. With LLM-assisted code this has become many times worse.
You can pretend that's not true, but it is. And it's only going to get better.
The way this is worded feels like it leaves the blame on developers. Aren't these developers focused on exactly what they are being judged by? Shouldn't we say it is the management who is too focused on delivery value compared to maintenance cost? Is it the developer's job to guide management or the manager's job to request guidance, assuming such guidance is needed?
We need to make sure the responsibility to resolve this problem falls on those with the power to act on it, and in this, developers tend to be receiving far more responsibility to fix than power to fix.
1) The devs pushing for more complex solutions, covering obscure edge case scenarios, feature-creep, "future-architecturing" because they are more interesting to implement. Classic over-engineering problems.
2) The features the managers actually want are usually boring or annoying to implement and the devs just work around any big architectural problems caused by the feature delivery.
1 is 100% on the devs, 2 it varies wildly, the willingness to address architectural problems are often under pressure by time-delivery estimates from managers. But many devs (especially in companies with low morale) will often just work around issues because addressing the underlying problems can be very difficult and/or time consuming.
Meaning either the dev wants to do the right thing but doesn't have the time, or the dev doesn't care enough and just pushes the tech debt down to the future (when hopefully they will be at another job).
LLMs makes both problems significantly worse, although they are also often very helpful with the big restructurings mentioned in 2. The dev can still be lazy and the deadline can still be too tight even with that extra LLM help.
wrong framing imo
EXCESS lines of code are a liability.
Code of course is an asset.. what other real asset is producing cash-flows? lol come on.
It would be like saying "Weight in kilograms of course is an asset for an airplane. That's what keeps it in the air. What other real asset is the airplane made of?"
companies are doing that as well lol (re: tokenmaxxing)
The pace and expectations have increased and a human can barely cope with reviewing its own code, let alone colleagues'.
They are not going to disappear in critical aspects of a codebase, nor shouldn't, but the industry will eventually reward self sufficient individuals able to keep the pace, harness and run adversarial reviews against the design and implementation autonomously.
I'll also say the harsh truth. A well implemented adversarial flow will do either better than your peers or will deliver 95% of the value at a fraction of the cost.
The industry has never valued product, let alone code quality except in places they are core to the business.
Otherwise you would not have MIT-bred leetcode ninjas writing react/tailwind bugged monstrosities at half a million/year for billion dollar products.
I'd go further and say that usually the goal is to use as little code as possible without sacrificing readability.
Brevity is compression, and compression surfaces the salient points of a problem.
Elegance often comes down to brevity.
But the whole job of the owners is to lower the costs as much as possible to produce the product, especially in an environment with higher costs to borrow (higher interest rates at the fed)
I am not afraid of my future. Even if one person can do work of 5, the amount of generated code will grow exponentially. And not everything can he vibecoded with 0 knowledge. There is a complexity that need understanding to change and optimize. For now :)
It was true for that time, because producing and maintaining the code was done by humans with limited speed of comprehension.
Today, we might challenge this assumption (not saying its wrong or right), because migrations can be done in 1-2 weeks with hundreds of agents.
When you come back to the codebase in two weeks or a few months, the agent just redoes stuff
I feel like even those benefits gonna melt pretty quickly. It's great as code review buddy tho
I've a fairly simple c# coding style. But simple is proving a bit more difficult to convey than I thought.
I get it to produce code. I then have to spend along time convincing myself it's correct. If I don't I end up embarrassing myself when a coworker reviews it, questions it and it's obvious I don't properly understand it.
This is really starting to screw with me mentally. It's like everyone in the world is saying they can fly by flapping their arms (dark factories). When I try I just stay in the same spot burning a lot of energy.
https://github.com/mattpocock/skills/blob/main/skills/produc...
Also those with very heavy investment in AI are looking for bonkers results, which is the cause of their disappointment. They need to reduce their expectations. I for one am loving the results so far.
Business executives look at this and think "at this rate of progress we'll have self-driving cars in a few years!" and start making serious plans for that world.
In reality I think we're going to be riding bikes for a long time. That situation of increased individual contributor productivity makes engineers more valuable, and increases the utility of engineers rather than making them a burden on your budget.
Thus, cutting headcount right as they had huge potential to become vastly more productive was a stupid move. It's an admission that you don't know how to manage people effectively, which is embarrassing when you're paid mountains of money for your management skills.
I mean, we don't know it any more than we don't know someone won't come out with cold fusion tomorrow, but it's a fundamental breakthrough away from where we're at. This isn't some routine engineering project with a guarantee of completion if you're just willing to keep pouring the billions. That's playing the lotto, you can pour away and get flat nothing.
The only difference is they're pouring billions and praying a rabbit comes out of the hat, but it's actually not much reason to expect they're going to pull the cold-fusion level rabbit out of their hat they'd need to get us past bikes.
Pretty good analogy I reckon.
https://fred.stlouisfed.org/series/OPHNFB
Examples abound of "I reported Nazi hate page. Didn't violate community guidelines. I called my friend a jerk, jokingly, got a month ban
For years. Not restricted to when ChatGPT et al arrived on the scene
(Because, AI in theory makes sense. If you want to monitor things at scale you might use AI - however that's defined - to make your workload easier. When is an account being hijacked? When are bad actors infiltrating the system? Or whatever)