The Builder Role
It is exhausting. It is exciting. And it is redefining what great engineers actually do.
The ground shifted. Not gradually. Fast.
Simon Willison, who co-created Django and has been one of the most clear-eyed voices on AI-native development, said it plainly: he writes 95% of his code from his phone now, and he is mentally exhausted by 11am. That is not a productivity failure. That is the cost of being the architect, the product manager, the QA engineer, and the developer all at once, simultaneously, every day.
This is both the most exhausting and the most exciting moment to be an engineer. Those two things are true at the same time.
But here is what needs to be said directly, especially to staff engineers who spent years going deep on a specialized layer of the stack and got comfortable there: the moat you built around deep specialization is not the moat it used to be. If your value has mostly been in knowing one domain exceptionally well while staying out of the messier work of collaborating across functions, writing clear context for others, thinking about outcomes beyond your lane, that comfort zone is now fading and you need to evolve your skills.
I know this seems scary. Your deep technical expertise is still your leverage and foundation. It is what makes you unstoppable as an engineer, but you need to step up quickly because the models are catching up.
The task is not the job
Jensen Huang put the sharpest frame on this in his appearance on the No Priors podcast:
“The purpose of a software engineer is to solve known problems and to find new problems to solve. Coding is one of the tasks. If your purpose literally is coding, somebody tells you what to do, you code it. All right, maybe you are going to get replaced by the AI.”
Tasks are discrete and repeatable. Writing boilerplate, converting designs, hooking up endpoints. Your actual purpose is judgment: what to build, why it matters, where the real problem is, and how to translate a messy human need into something that works. That judgment has not been automated. The tools freed up more of your time to use it.
The engineers who feel most anxious right now are often the ones who built their professional identity around the task. The engineers who feel most energized are the ones who always cared more about the problem.
The multiplier has a new definition
A staff engineer on a team used to mean that team could deliver multiples of what it could without them. Not because they did more work, but because they raised everyone around them. They mentored, they unblocked, they dove in when the team was stuck. Their presence multiplied the output of the people next to them.
That is still true. But the definition of multiplier has expanded.
The real multiplier today is the engineer who knows how to wield agents effectively and coordinate their output toward a result the company actually cares about. That means decomposing complex problems into tasks agents can execute reliably, reviewing and directing that output with enough judgment to catch what went wrong, and owning the integration into a real system that holds up in production.
It also means communicating what was built, to whom, and why it matters. Working well with others, not just technically but in the full human sense: understanding what stakeholders need, translating across the technical and non-technical divide, making your work legible to the people who depend on it. These were always important skills. They are now non-negotiable ones.
There is a new operating mode. It is being called The Builder.
There is a new pattern emerging. Not a new title, but a new operating mode. You will see it referenced as The Builder. The SF Standard captured it in March 2026: teams that used to be organized like assembly lines, product managers wrote specs, designers mocked things up, engineers implemented, are dissolving. The lines between roles are compressing. Others have identified the Builder mindset as the common thread: what they share is not a job title, it is an orientation toward outcomes over lanes.
A Builder owns their product end to end, including the parts that used to belong to someone else. Architecture, yes. But also user insight, documentation, metrics, and distribution.
That last one matters more than most engineers want to admit. You can now build and ship a working product in a couple of days. The bottleneck is no longer technical capacity. It is whether anyone cares. Understanding distribution and the gap between what users say and what they actually do are not soft skills. They are the skills that determine whether what you build creates real value.
Go back to first principles
Practices that engineers spent years avoiding because they were slow and uncomfortable are worth revisiting now.
TDD is the clearest example. Most engineers know test-driven development is the right approach. Most do not practice it consistently because writing tests before implementation is friction. Simon Willison makes the case that this is now one of the most powerful patterns in agentic engineering. Tell your agent to use red/green TDD. Write the tests first, confirm they fail, then let the agent implement until they pass. The agent does not complain about friction. It does not cut corners because the deadline is close. The result is real test coverage and a codebase protected against regressions as the project scales.
The same logic applies to documentation, changelogs, and edge case analysis. All the practices engineers skipped because they were tedious. Agents handle tedious without complaint. The question is whether you are directing that capability intentionally, or still skipping the fundamentals with a faster tool.
Find the balance
The pace of this moment is real. The cognitive load has relocated. You are making more decisions per hour, directing more output, holding more context. That is a different kind of tired than grinding through a hard implementation, and it sneaks up on you.
But here is the thing worth remembering: it was never about the hours. It was never about the number of PRs. The job has always been about delivering results and creating value. The old world just required hours of manual craft to get there. Writing code was the long road between the idea and the outcome. That road is getting shorter. The destination has not changed.
One side note: Deep knowledge of a domain is what separates an engineer who can effectively direct agents from one who just generates output and hopes for the best. The goal is not to abandon what you know. It is to use it as the foundation for operating at a much wider surface area than you ever could before.
Burnout in this new model comes from not adjusting your mental model of what good work looks like. If you are still measuring yourself by output volume, by lines written or tickets closed, you will exhaust yourself optimizing for the wrong thing. Measure by the result. Did it ship quickly? Does it work? Does anyone care? That is the bar.
Protect your thinking time. The judgment layer is now the most valuable thing you bring. Find the balance and learn to rethink how you work, audit where you are spending your time and make an intentional shift.
Most engineers are not there yet
The Builder model is the direction of travel. It is not the baseline expectation for everyone today. A significant percentage of engineers are not yet strong end-to-end players, and the tooling changed faster than the skills did.
In a previous post on player assessment, I wrote about the coaching responsibility engineering managers have right now: knowing your players clearly enough to understand who is genuinely AI-augmented and who is just adjacent to it. That distinction is everything, and it requires a different kind of support for each person. Every engineer should be actively moving toward the Builder model, even one capability at a time.
Call For Action
I know it may feel scary but staying in your comfort zone would be detrimental to your future and growth. You need to make the shift now and as quickly as possible.
Lean into the opportunity this new future is enabling. Raise your bar for what you can deliver and accomplish. Rethink your timelines, constraints and priority. You have a team of agents at your disposable. Pick one thing you have never owned end to end. Ship it yourself using agents. Do not hand off the parts that feel outside your lane. Use the tools to cover the gaps and direct the output..
That is what operating as a Builder feels like. Keep at it, increasing your scope and the results you are aiming to deliver. Find the balance but don’t lose sight of what matters.
Till next time!