I'm no business expert and Apple is of course in a unique position, but owning your own fabs has rarely worked out long term. They require eye watering amounts of CAPEX that needs to be amortized over a timeframe that's longer than apple's products. Today's bleeding edge fabs become tomorrow's "cheap" fabs that pump out chips that don't need to be bleeding edge for the components that go into everyday products like microwaves, cars, etc.
One of the reasons Intel fell behind is that they couldn't give access to their competitors for business reasons, and therefore could never scale as high as TSMC could.
There are many other reasons, but accounting is a huge one. Unless there is a huge ROI or something else we don't otherwise know, I don't see Apple adding such expensive deprecating assets onto their books as chip fabs.
A more realistic scenario that surely must have been considered is this:
They make a strategic investment in the DRAM maker. It's the same idea as buying an equity stake or entering a JV with a flat-panel maker. Or deploying cash to provide the latest EUV tooling to TSMC.
Large famous-brand computer maker has no expertise in running a fab.
I could punch holes in this idea right away. But it seems better than "tilting up your own fab".
The point of my GP post was that due to being one of the world's biggest and longest-term buyers, Apple is already paying very close to actual manufacturing costs + amortized capex because RAM is an undifferentiated commodity. Owning the factory themselves doesn't reduce the actual manufacturing cost + amortized capex that Apple would have to pay their own factory. Apple is already buying RAM at the lowest possible margins. It's similar math to deciding whether to spend your own cash or get a loan. If the loan's interest rate is low enough, it's better take the loan and put your cash to work where it can return a higher margin. And at the incredibly low margins Apple pays for RAM, keeping that cash in long-term investments will actually earn more money than putting it into building RAM factories.
If Apple could go back in time 3.5 years and decide to build their own factory, that would put them in a great position today. But deciding to do it now won't increase their supply 3.5 years from now more than just increasing their long-term orders with existing suppliers. Those suppliers will start building new factories based on Apple's increased orders and they'll do it faster and cheaper than Apple can because they don't have to build some factories in the U.S. for political reasons or worry as much about environmental regulation, permitting and ensuring Apple employees in Penang get benefits similar to employees in Cupertino.
Isn't one of the points of the article that memory manufacturers leave demand unmet for their own financial safety? In which case, nobody (including Apple) is paying close to manufacturing costs. There isn't enough memory to go around and prices are extremely inflated.
You're talking about the "best" things Apple could do with their money, in terms of investment returns, but I think that misses the point that Apple literally can't buy enough memory at any price.
> that misses the point that Apple literally can't buy enough memory at any price.
They can't buy enough today. I think I already explained this as well as I can in my second paragraph above. You seem to not be appreciating that every decision in this business has a 3.5+ year latency. And 3.5 years ago when Apple made the decisions they're living with now, Micron was selling their furniture (euphemistically speaking). Sinking billions into building RAM fabs would not only have gotten you laughed out of the boardroom, Apple shareholders would have rioted (for all the logical reasons I laid out in my prior two posts). The only scenario where the prudently balanced decision Apple made to not vertically integrate RAM manufacturing looks bad is the very unlikely scenario that actually happened this one time - but that 'bad look' is only temporary because the situation will probably look different 12 months from now (which is less than a third-of-a-fab-decision away)).
Back when I first became a strategist for a public F500 tech company whose products you probably use often, a very wise man took me to dinner and counseled me to never post mortem my decisions on the outcomes, but only on the decision process. In other words, knowing what I knew when I made the decision, did I choose the option most statistically likely to get the desired result - regardless if it worked or failed that time? In highly uncertain games, some bets don't pay off. In my work, if 60% of my decisions came out positively, I'd have been the greatest of all time (they weren't that quite that high). If strategists don't think this way we end up leading our companies to doom by "chasing black swans" (aka unlikely outlier outcomes).
> memory manufacturers leave demand unmet
That's not their plan or desire - it's just the inevitable result of trying to predict both future demand and future capacities of unbuilt fabs on new nodes (every new node is an adventure). Both are rough estimates with bell-curve probabilities and wide error bars. You might imagine the Chief RAM Strategist drags the center of the bell curve so the big bump in the middle is right over their best guess of what the fab yields and market demand will actually be three years from now - perfectly slicing the odds in the probabilistic middle. But they don't. Instead, being a smart, experienced strategist, they slide the bell curve a little bit to the low-side - because very profitably selling everything you can possibly make and regretting the 5 or 10% of demand you left unmet is a far, FAR better (and more survivable) problem to have than sitting on 5 or 10% unsold excess capacity from expensive fab space you paid to build but can't monetize. That extra capacity will often force you to take lower margins on ALL your capacity to ensure you sell through the extra 10%. This is how you speed run becoming an ex-strategist, sometimes of an ex-company.
In short, being wrong on the low side is the best kind of wrong you can be. But being wrong on the high side is the worst kind of wrong, and it's not linear. Every extra percent you go over costs significantly more than the last. If they do their job perfectly, it looks to consumers like "manufacturers leave demand unmet." If they do their job less than perfectly but pretty well, it looks like "RAM's too damn expensive and the idiots created a shortage - what were those morons thinking?" If they do their job catastrophically it looks to consumers like "Woohoo, RAMs dirt cheap. Look at me! I've got so many sticks I'm bathing in them like Scrooge McDuck!"
I'm not sure what you think I'm saying, but in case it needs clarifying, it is not that Apple should have built fabs 3.5 years ago, or today, or at any other point in time.
What I did say is that in a hypothetical world where Apple did invest in their own fabs, they'd have much better access to memory and could be selling machines with vastly more memory than their competitors today. Should they be doing this? I'm making no statement either way.
> a very wise man took me to dinner and counseled me to never post mortem my decisions on the outcomes, but only on the decision process
I appreciate this wisdom on one hand, but on the other it's comically misguided. You have no way to evaluate the decision process if the outcomes are not considered. Don't post mortem your decisions in a way that leads to self-blame or paralysis, but certainly post mortem them to see whether the process was suboptimal.
In this case, any board laughing at the idea of investment in memory 3.5 years ago should instead have been looking more closely at likely memory needs over the then-near-future, given the quite obvious upcoming demand for GPU memory. There's no magic bullet and they wouldn't have been able to make perfect decisions regardless, but clearly the process they followed at that time was suboptimal.
> What I did say is that in a hypothetical world where Apple did invest in their own fabs, they'd have much better access to memory and could be selling machines with vastly more memory than their competitors today.
Okay, I understand your point. I've always taken it as given that vertically integrating DRAM fabs was one of many options available to any very large manufacturer with sufficient cash flow. However, I think your point was inaccurate. If Apple invested in their own fabs, they would not have better access to memory today, unless they ALSO did something quite irrational and overbuilt their fab's capacity by a factor of 2X or more. In terms of greater capacity, at Apple's massive scale of consuming more than a "one fab" amount of output, owning their own fabs vs ordering from fabs owned by others still requires pre-ordering their expected RAM needs ~3.5 years in advance. Regardless who owns the fab, no fab can make significantly more chips without that long lead time. The difference in lead time, total capacity and margin between a self-owned fab you started building 3.5 years ago and "pre-buying most of a fab's output 3.5 years in advance" is minimal enough to be virtually immaterial. This entire area of strategic analysis is broadly called "Build vs Buy", but it has more to do with financial and tax metrics around cash on hand, capex, amortization and return on capital. The problem we're focused on here is lead-time or supply elasticity (eg how quickly can we get a lot more DRAM than we thought we'd need and at what cost delta). And, at this scale, those dynamics aren't fundamentally changed whether you Build or Buy.
> Should they be doing this? I'm making no statement either way.
Given the dynamics, I assumed you weren't just stating that acting irrationally is always an option, but that doing so was a rational option strategically. But it's not. Even in your scenario it wouldn't have changed anything UNLESS you imagine Apple of 3.5 yrs ago was psychic and built two fabs for every one they actually expected to need - but that would have been insane. And if they were that insane, they could have accomplished very nearly the same thing by pre-buying 2X their expected RAM needs from their 3rd party suppliers. At Apple's scale, 3rd party suppliers are what we call 'virtually captive'. You're such a large customer, you're practically funding the supplier's capex. This is a serious strategic problem for such suppliers (but great for Apple).
> I appreciate this wisdom on one hand, but on the other it's comically misguided. You have no way to evaluate the decision process if the outcomes are not considered.
Yes, of course you consider the outcome as one data point. But I said you don't assess by the outcome, meaning we don't judge the decision process's ultimate validity only (or even mostly) by the outcome. It's just one element. The reason is that for highly uncertain decision spaces with unknowable key externals, you can have NOT just: 1. Optimal decision-making / successful outcome, and 2. Sub-optimal decision-making / failed outcome but ALSO: 3. Optimal decision-making / failed outcome, and 4. Sub-optimal decision-making / successful outcome. Understanding the ramifications of this matrix is crucial - especially the last two.
A key example, is the hypothetical where a crazy strategist consults an astrologer, pre-commits to 2X the projected need for fab output (whether by building/owning fabs directly or just indirectly by pre-buying one or more fab's entire output in advance). If the astrologer says "build 2X what you think you'll need" and there's an unforeseeable confluence of events 3 years later that causes a worldwide shortage of RAM, then if you overweight the outcome in assessing if your strategic planning process is optimal, you'd always just do what the astrologer says. In short, in high-risk domains, sometimes a sub-optimal decision-making process can randomly result in a successful outcome - but that's a spurious signal.
If I'm the Apple VP responsible for DRAM supply chain strategy, the question I might ask my demand-side forecasting team is to run a post mortem study of whether any data sources might have existed at the time we locked in our DRAM capacity commit which could have predicted the DRAM bubble with sufficient certainty that we would have made a different decision back then. However, I'm virtually certain the answer is "No". At Apple's scale and longevity, their teams on this are already very good. If the answer was "Yes", they'd already have done it. I understand you think "this AI thing was knowable 3.5 years ago" but hindsight is always 20/20. If you haven't done such rigorous forecasting and post mortem analysis in complex, high-risk domains with thousands of variables, not just 'known unknowns' but many 'unknown unknowns', with billions of dollars at stake - it's difficult to appreciate the full scope of the challenge. The trick is the question is not just a true/false binary of "AI will cause a run on DRAM." The real question is multiple choice and the choices are numbered 1 through 5,000 (at least). And "AI will cause a run on DRAM" is just 'possible future scenario' #3,462.
If 256GB of RAM enables them to run on-device AI models that (for reasons) are a key feature differentiator?
Personally, I think there's no way memory heavy inference moves on-device (vs cloud) due to the economics, but it's not impossible technology + platforms go that way for currently unforeseeable reasons.
I think there’s a realistic chance consumer inference moves on-device. I think it really depends on marketing.
My non-tech friends and family would probably be served perfectly fine by local models today, if they had a working web search tool. Their queries are often “soft” and don’t have an exact answer. My mom and aunt used it to pick a hairstyle, my mom used it to get an image of what a room would look like with particular drapes in it, etc. Stuff I think mid-sized local models like Gemma or smaller Qwens could do without issue. They just don’t have a device that will run them.
Businesses won’t move. They need a huge context so they can stuff a bunch of Confluence pages in it and 300 tools and it needs to read an entire codebase and yada yada. The hardware depreciation and electricity will probably make it a net zero or even cost more than paying for API access.
My argument is predicated on the assumption that mainstream hardware manufacturers will copy the way Apple and Framework have made system memory usable for inference.
In that world, a) we are already at or close to having enough memory in local devices to do inference locally, and b) that memory isn't inference-specific and can be utilized for other things. Most devices come with enough memory to do some level of inference, and some come with plenty (eg a gaming desktop probably has 32GB+ of RAM in it).
You aren't going to run Kimi on it, but I think the reality for a lot of consumer inference is that it doesn't need to be. It's going to be a lot of things that are soft, and easily answered by a search API, so the LLM really just needs to be able to skim and summarize. Going a step further, we may even see some kind of hybrid approach where a local OpenRouter kind of thing decides whether the task is soft enough to do locally with models that fit in RAM or if it needs to be farmed out to a PaaS provider.
Right. I’m not arguing that Apple wouldn’t offer a 256GB model if they could make money doing it; I’m puzzled as to why they wouldn’t offer several lower-spec models as the entry-level into and then progressive upgrades within that line, since only some people need that 256GB feature differentiator of running frontier-level models on their MacBook Pro.
I think your comment about inventing new words is an interesting one. One of the things that I believe limits our ability to discover new ideas is our ability to describe related concepts. For example, the reason we still can't have clear discussions on consciousness is probably partly due to the fact that the necessary concepts haven't been cemented in language. We need new language before we can describe consciousness.
I would guess LLMs are limited in their ability to be genuinely novel because they are trained on a fixed language. It makes research into the internal languages developed by LLMs during training all the more interesting.
If AI turns out to be a bust, ignoring it could become a significant win. One possible outcome of AI adoption is that existing code bases are degraded, and existing programmer capability is allowed to atrophy. In that situation, companies that adopt AI lose out relative to companies that eschew it.
A better analogy would be that you do original research or work and produce a valuable book. Somebody else looks at your work, decides it has value, and reproduces it in a new book under their name. The new book is cheaper, or easier to find, or for whatever reason displaces your original book created through your own research and investment. Now somebody else is profiting off your creativity or work, without payment or even acknowledgement.
I'm not sure how this plays out legally, but it certainly seems unethical
So for example, when Disney sees value in public domain stories like Cinderella, Rapunzel/Tangled or Snow White, and they make movies out of them, profiting from the creativity and work of the Brothers Grimm without paying anything to their estate, or high school plays do Shakespeare, that seems unethical to you?
Would it be fair for Greece to do retroactive term extensions all the way back to Plato and then sue anyone who copies the idea of having a university or uses the Platonic solids or distributes religious texts that incorporate the dualistic theory of the soul?
Your examples, as you say, are all public domain. Are all the works we train LLMs on public domain too? Was the original book in my analogy in the public domain? What do you think about training on material that isn't yet in the public domain?
You're framing this as an ethical question, but copyright term lengths are essentially arbitrary. They're set by the government, as are the boundaries of fair use. At which point you're making a circular argument. That it's bad if it's illegal and that it should be illegal because it's bad. So what happens if someone argues the opposite? That it's not unethical if it's fair use and then it should be fair use because it's not unethical.
I'm not making a circular argument, nor one based on legality. You explicitly changed your example to use "public domain" content, and ignoring the legal specifics of that it's clear that's a separate category of content. Most people have no ethical issue with remixing or using content that has already done the rounds and delivered most of its immediate value to the creator. This is very different to your earlier examples with books, framed as two contemporary pieces of media competing with each other.
Letting companies train LLMs on the "classics" is very different to training on contemporary media where the creator still depends on it.
What kind of work are you applying Opus and other LLMs to? I'm quite curious to understand how other people are using these tools.
At the moment neither Opus nor any open weights models seem to be capable of doing complex work, and for less complex work the additional cost of Opus hasn't been worthwhile. This is for reasonably math-heavy computer vision applications.
What LLMs have been useful for is identifying forgotten code that will be affected when planning a change, reviewing changes, and looking up docs/recipes for simple tasks. But Opus doesn't seem necessary for a lot of that.
I have been using Opus (in zed) to find the “in between” bugs. Bugs that kinda live in the space between micro services or between backend and frontend.
It takes a bit of preparation to get good results, but it can usually find the source of bugs in 1-2 hours (200k-300k context) that would take me a week to track down.
I create a folder, and then open up git worktrees in sub folders for every repo I think might be involved. I also create an empty report.md file.
Then I give it a prompt that starts with “I need you to debug an issue”, followed by instructions for how to run tests in each repo, followed by @mentioning any specific files or folders I think is relevant (quick description of what they are), then the bug description.
After that I tell it to debug the issue, make no code changes and write its findings to the report.md file.
My current job has me overseeing a few teams of engineers working on ~10+ y/o legacy software systems that have not been especially well maintained. As an example, one team had a completely broken CI pipeline due to numerous flaky tests. They had configured the CI pipeline to rerun tests multiple times and still the master branch had like.. a 40% pass rate. Super ugly, but the suite took ~40 minutes to run and they were demoralized enough to not want to investigate it anymore.
I came in, set Claude up, gave it read access to CI artifacts, had it build out some tooling to monitor the rolling pass/fail rate over the last 30 days, and let it loose. It identifies the worst offending flaky tests, forms hypotheses on whether it's a testing issue or a production issue, then tries to divide-and-conquer until it gets minimal reproduction steps. If it's not able to create deterministic reproduction then it'll make a best guess at fixing the issue and grind away at test re-runs all night until it can try to figure out if it fixed the issue with statistical confidence instead.
It's not perfect. I have to throw away some of the bad solutions, but shaved 20 minutes off their pipeline and improved pass rate by 35% in a handful of weeks. Very minimal oversight on my part - just letting it run while I'm asleep and reviewing PR proposals during the day between meetings.
We have an initiative to make an entire web application significantly more accessible in response to some government mandates. Tight deadline, tons of grunt work, repetitive patterns, some small nuances on edge-cases. The team was able to create a set of skills for doing the conversion logic, slowly build up and address all the edge cases, and are now able to work several magnitudes more quickly in modernizing the app.
A team had punted repeatedly on updating Jest to the latest version because it inherently came with a breaking change to JSDOM which made some properties unable to be spied upon. Took like 20 minutes to have Claude one-shot the entire conversion when they'd ignored it for months because it just felt too finicky prior to agents. In general, everything to do with testing infrastructure is easy to push forward with confidence.
Uhm, we have an active interview pipeline where we give a take-home technical assessment. After we got a few submissions, and manually evaluated them, I fed our analyses in and our grading rubric and had it generate assessments for incoming candidates following the rubric. After checking a few pretty carefully it became clear that it was good enough to trust - the take home wasn't groundbreaking and the problem space was understood enough to be able to identify obvious issues if there were any.
I was given a small team of semi-technical people who were being used to fetch numbers from DBs for product/marketing/sales and perform light data analysis on them. A lot of their day to day was just paper pushing SQL queries into Excel spreadsheets and then transforming them into PowerPoints with key takeaways. They didn't have any experience writing code. I had Claude build a gameified playground for them where I gave them a VSCode dev container, a SQLite DB full of synthetic data emulating what they'd encounter IRL, and a Jupyter notebook filled with questions they'd need to answer by writing code to interrogate the database and form insights. In a couple of weeks I was able to get them to the point where they were comfortable writing basic Python scripts with the help of Claude and they're now off automating all their paper-pushing workflows with deterministic scripts. When they're done we're going to move them to higher value work by having them do sleuthing against our data and surfacing proactive insights to propose to Product rather than just reactively fetching data and building reports.
I was asked to quickly build a prototype for some basic AI functionality we thought we might want to add to one of the products. I was able to go from "I have no idea what I should build" to "here's a prototype we can put in front of clients and see if this idea has any merit" in about 14 hours. Just riffing with Claude from product idea to functional/technical specs, implementation plan, then full working prototype was one shot, and then a tight iteration loop for a couple of hours with me guiding it on personal aesthetic choices to give it enough final polish. Obviously I wouldn't ship this code into production, but it's really nice not having any sunken cost biases when demoing a prototype. If customers don't like it? Great, I lost one day and half the time I was multi-tasking while Claude implemented specs. Even better - I had Claude write a script to extract all the conversations I had with it and include those in the prototype repo. Then I filmed a quick demo video of my process, shared that with the engineers, and they're able to review my Claude conversations to get inspiration for how to modify their own agentic coding strategies.
> Uhm, we have an active interview pipeline where we give a take-home technical assessment. After we got a few submissions, and manually evaluated them, I fed our analyses in and our grading rubric and had it generate assessments for incoming candidates following the rubric. After checking a few pretty carefully it became clear that it was good enough to trust - the take home wasn't groundbreaking and the problem space was understood enough to be able to identify obvious issues if there were any.
If you're going to not invest any of your time, and just have an AI evaluate candidate homework, can you provide a single ethical reason for why candidates shouldn't just have AI do that homework for them?
We encourage candidates to use AI on the homework and to be comfortable sharing the prompts they used and the workflow they engaged the AI with to get to their end result. We've experienced a wide range of proficiencies in using AI to solve the technicals. Anything from lazy one shots with 1k loc changed and 0 awareness of trade-offs to very surgical, 200 loc changed where the candidates broke down the problem and guided the AI step by step.
Whether to lean into or push back against using AI in the technical was a major point of discussion for us when building the hiring pipeline. Ultimately we decided it would be fighting against the current to try to prevent candidates from using AI and so we decided to assume they would and build questions in to evaluate their efficacy.
I'm also not sure it's fair to say we invest no time just because we use AI. We hop on a call with each candidate after they submit the technical and ask questions about their process, how they decided scope, and try to figure out how much awareness they have of what they coded.
No one at my company cares about OpenClaw either. We do care that we can be billed unexpectedly (either usage quota immediately being consumed, or being charged additional costs), generally with zero recourse, because a particular set of characters that Anthropic doesn't like appears somewhere in a repo.
This week the characters are "OpenClaw". I won't even try to guess what might lead to erroneous billing next week.
There's still a meaningful difference between violence wielded by a single individual who feels angry or unheard, and violence wielded by a large representative group who has invested genuine effort in conversation before collectively deciding violence is required.
Yes, fully agree. Nonetheless, I suspect violence can be used more effectively and more minimally if it's considered and performed by a group rather than haphazardly by individuals. I recognise that's a very simplistic view.
I think it's as realistic as it is simplistic. The State gets a monopoly on violence so that you can sue someone who wrongs you instead of killing them. When conversation and cash fail, violence is all that's left, and we concentrate that power in groups of people tasked with deciding when the alternatives have failed. It doesn't always work but it's a better alternative than the individualized bloodlust disappointingly endorsed elsewhere in this thread.
Tools do author commits in my code bases, for example during a release pipeline. If I had commits being made by Claude I would expect that to be recorded too. It isn't for recording a bill of tools, just to help understand a projects evolution.
Vendramini's theory appears to be built upon some fairly extraordinary ideas that are not supported by actual evidence. In fact some of his claims (e.g. about face shape and skull placement) are directly contradicted by actual evidence. It's probably worth approaching this with some scepticism.
This is rather disingenuous. It can be hard to overcome momentum in research, but most researchers would be giddy with excitement if they could show our (extremely disturbing) forecasts regarding climate change are wrong and that things are much rosier than expected.
I also suspect you would find easy funding from existing climate change deniers. There is no shortage of well-heeled folk in that space.
Do you have a chip on your shoulder regarding research? You're begging the question by stating it is conducted in a "practically religious" way. Ask whether that's true before you question the effect it would have on somebody's behaviour.
