For years, the developer laptop conversation was simple: get a fast CPU, enough RAM to run a few Docker containers and a browser with forty tabs open, and a keyboard that doesn’t feel like a toy. That conversation has changed. AI coding assistants and local large language models now sit in the loop for a growing share of the day, and they change what “enough” actually means.
A developer running GitHub Copilot or Cursor against a cloud model doesn’t need much extra horsepower. The heavy lifting happens on someone else’s servers. But a growing number of developers are pulling models down and running them locally, either for privacy, for cost control, or because a spotty connection makes cloud tools unreliable. That shift is what’s rewriting the developer hardware shopping list.
Why memory, not clock speed, is the new bottleneck
Large language models are memory-hungry before they’re anything else. A 7-billion-parameter model needs several gigabytes just to load, and the number climbs fast with anything larger. On a traditional PC, that memory has to live in the GPU’s VRAM, and consumer GPUs top out well below what a serious local model wants.
This is the spec that quietly reordered developer buying habits. Shoppers used to ask how many cores a chip had. Now the question is how much memory the model actually needs.
Why the MacBook became the default answer
Apple’s unified memory architecture is the reason MacBooks turned into the go-to developer machine for local AI work almost overnight. Instead of splitting memory between a CPU pool and a separate, smaller GPU pool, Apple Silicon chips share one large memory pool across the whole system. A MacBook configured with 64GB or 128GB of unified memory can load a language model that would require a multi-thousand-dollar discrete GPU setup on a Windows machine, and it does it inside a laptop that also handles the rest of a normal engineering workload (IDEs, containers, browser tabs, video calls) without choking.
That combination is why MacBooks have taken over so much developer mindshare recently. It’s not a brand preference; it’s that Apple happened to build the memory architecture local LLM work actually wants, in a laptop that was already popular with developers for other reasons (a real Unix-based terminal, strong build quality, long battery life). The AI use case landed on top of an already-strong existing habit.
Where a MacBook still isn’t the right answer
Unified memory has real limits. A MacBook can load and run models, but it isn’t the machine for training them or for fine-tuning at scale. Model training leans heavily on CUDA, Nvidia’s software layer, which is far more mature and far better supported by the machine learning ecosystem than anything on Apple hardware. For that work, a workstation with an Nvidia GPU carrying dozens of gigabytes of dedicated VRAM, or a tower built around two or three of them, is still the tool for the job.
The same is true for anyone running the largest open-weight models, the ones that only fit comfortably with serious dedicated VRAM rather than a laptop’s shared memory pool. Developers doing that kind of heavy local inference or model experimentation are still building or buying Linux and Windows workstations, not MacBooks. It’s less a rivalry and more a split: MacBooks for running models day to day inside a normal dev workflow, discrete-GPU towers for pushing the ceiling on model size or doing actual training work.
The rise of the cloud dev box as a third option
Not every team wants to buy either machine. A growing number are sidestepping the hardware question entirely by giving developers a cloud-hosted development environment: a remote box with the GPU and memory to run heavy AI workloads, accessed from whatever laptop the developer already has. This turns “what computer does the team need” into “what access does the team need,” which is a much cheaper problem to solve for a distributed team, and one that scales up or down instantly instead of sitting on a shelf as underused hardware.
That model also sidesteps a real question a lot of engineering leaders are quietly asking right now: will AI replace software developers, or just change what tools sit on their desk? The honest answer, backed by Full Scale’s own look at AI’s real impact on software development, is the second one. AI is taking over repetitive, mechanical parts of the job, not the judgment calls, the architecture decisions, or the debugging instincts that come from experience. The hardware conversation is really a proxy for that bigger shift. Teams aren’t buying more powerful machines because coding is disappearing. They’re buying them because the job now includes running and evaluating AI tools alongside writing code.
What this means for how AI coding tools actually get used
Having the memory to run a local model is only half the story. The other half is what that model is actually good for once it’s running. AI pair programming with a coding assistant, whether local or cloud-hosted, tests a developer’s skills rather than simply speeding them up. Knowing when to trust a suggestion, when to rewrite it, and when the assistant has confidently produced something wrong all still depends on the developer sitting in front of the machine. A fast local model on a well-specced laptop removes latency and privacy concerns. It doesn’t remove the need for a developer who knows what good code looks like.
That distinction matters for teams building out engineering capacity around this shift. Buying the right hardware solves the “can this machine run the tools” problem. It doesn’t solve the separate problem of finding engineers who already know how to work effectively alongside AI tooling day to day, which is increasingly its own hiring category, distinct from general software development experience. Companies scaling this kind of work are building out hiring pipelines specifically for AI-focused engineering talent rather than assuming any developer can pick it up on the job.
The bottom line for developer hardware going forward
The next few years of developer hardware will keep being shaped by this same tension: unified-memory laptops for portability and day-to-day AI-assisted work, discrete-GPU workstations for anyone pushing model size or doing real training, and cloud dev boxes for teams that would rather rent the capability than own it. None of the three is disappearing. They’re splitting into different jobs, the same way desktop towers and laptops split into different jobs decades ago instead of one replacing the other.
For developers deciding what to buy next, the practical question isn’t “Mac or PC” anymore. It’s how much of the AI workload needs to run locally, how large the models are, and whether the answer to “what computer does this need” is really a hardware purchase at all, or just a login to somebody else’s GPU.