Engineering

TL;DR Boris Cherny, who built Claude Code at Anthropic, posted a short framing: as engineering, product, design, and data science melt into one role, he sees five archetypes on his team The five are Prototyper, Builder, Sweeper, Grower, and Maintainer - and crucially, none of them map cleanly to a job title The interesting claim is not the list, it is the decoupling: the archetype is a description of what energy you bring to a system, not what your contract says you do I think the framing is genuinely useful as a self-diagnostic, and quietly radical for how teams get staffed and rewarded Where it leaves me unsure: it describes a steady-state team that already exists, and says less about how you grow people into these shapes, or what happens to the people who do not fit any of them A short post on X has been rattling around my head for a few days. Boris Cherny, who built Claude Code at Anthropic, was reflecting on what happens to roles when the old functional boundaries stop meaning much. His observation: when he looks at the Claude Code team, he does not really see engineers, designers, PMs, and data scientists. He sees five archetypes that cut across all of them. ...

When a spacecraft returns from the Moon, it strikes Earth’s atmosphere at around 25,000 miles per hour. The air in front of it compresses into a glowing plasma sheath hotter than molten lava, and the vehicle effectively becomes a fireball for several minutes. A reasonable question follows - why not just slow down first? Why not fire engines to drop down to something more manageable, like the ~17,500 mph of low Earth orbit, and skip the inferno entirely? ...

TL;DR The SID (Sound Interface Device), designed by Bob Yannes at MOS Technology in 1981, put a genuine synthesizer - oscillators, a filter, envelope generators - inside the 1982 Commodore 64 It was originally designed as a general-purpose synth-on-a-chip to rival professional instruments, not as a computer sound chip Three voices was a brutal constraint, and composers like Rob Hubbard and Martin Galway turned it into an aesthetic - fast arpeggios simulating chords became the signature C64 sound No other chip - not Atari’s TIA, not the Genesis’s Yamaha FM - achieved the SID’s cultural dominance The chip outlived its platform: SID-based music, hardware clones, and chiptune culture are still active today The Commodore 64, released in 1982, had one feature that set it apart from every other personal computer: it had a synthesizer on a chip. Not a speaker driver. Not a simple sound generator. An actual synthesizer - with oscillators, filters, envelope generators, the same components used in professional synthesizers costing thousands of dollars. ...

TL;DR Engineer burnout has a specific shape: infinite scope, context switching, invisible work, decision fatigue, and the expectation to be always-on Prevention rests on three pillars: timeboxing work items, learning to say no, and communicating honestly across levels Timeboxing works because it converts infinite scope into finite commitments - the box is the boundary, not the estimate Saying no is a skill with scripts, not a personality trait; most “no"s are actually “not now” or “not me” The paradox of boundaries: the engineers who protect their creative energy most fiercely are the ones who end up giving the most The Shape of Engineer Burnout Creative burnout in engineering looks different than burnout in other fields. It’s not just exhaustion from long hours (though that’s part of it). It’s the specific fatigue that comes from: ...

TL;DR Spec-driven development means making specifications iteratively precise enough that handing them to an AI produces the right result without further iteration AI makes hidden specification costs visible - ambiguous briefs now produce wrong code instantly rather than surfacing bugs slowly during implementation The spec becomes the product because it is where all the thinking lives; implementation is just the reflection of the spec in runnable form Good specs must be honest, not just precise - they should explain trade-offs accepted, constraints being solved for, and how you will know if the spec was wrong Developers in 2026 need to shift from implementing specs to writing specs that are clear enough to implement themselves There’s a moment in every developer’s career when you realize the code is not the product. The product is the decision. ...

TL;DR AI has collapsed the middle rungs of the engineering ladder by automating execution - the junior-to-architect progression no longer works the way it did The emerging split is two human roles: Architects who decide what to build and why, and Builders who turn architectural decisions into precise, testable specifications Neither role exists to write code - code-writing is incidental to both, and AI handles the bulk of implementation The two paths require genuinely different skills that do not build cleanly on each other; taste for architectural judgment and clarity for specification are separate capabilities If you are a junior engineer in 2026, you need to choose your path now - the traditional ladder is a trap, and “I write good code” is no longer a sufficient value proposition For forty years, the engineering career ladder has looked like this: ...