Software development has split in two: those who changed how they work with AI agents, and those who just changed their coding tools. AI agents can now autonomously write code, run tests, fix failures, and iterate, increasingly for hours without human input. The job of the developer has changed around them. The developers seeing step-function productivity gains aren’t using better coding tools than everyone else. They’re working differently: they are no longer building the software directly, they are building the agent setup that builds the software.
This is a guide for practitioners (see our guide for managers). If you already use an AI coding assistant but aren’t shipping materially faster, this will show you what to change. Fair warning: this is an engineering investment, not a switch you flip. You’ll spend weeks building intuition, writing steering files, refactoring your codebase, and learning to decompose tasks for agents. If you expect immediate gains without changing your workflow, you’ll be disappointed. The first weeks feel slower. The weeks after feel dramatically faster.
Frontier engineering is not vibe coding. It is not pasting prompts into a chat box and hoping for the best. It is a disciplined, methodical practice that augments engineering rigor with the leverage of AI agents. Over the long term, the skill you keep developing is managing your own attention. As agents take on more of the execution, that means carrying the cognitive load of context switching between several agents at once, deliberately holding a quality bar while everything moves faster, and mustering the self-restraint to stop checking on agents at dinner and late at night. The work is deciding, over and over, what needs your attention and what does not.
We’re still in the early-adopter phase of frontier engineering. Not many developers work this way yet, and the practice is still maturing: no one has worked out how to review agent output most effectively, or how to design tools and test infrastructure for agents rather than humans. Working this way still takes intuition: knowing what to delegate, how to scope it, and when to step in. That intuition comes from practice: the initial weeks spent writing steering files, refactoring your codebase, and learning to decompose work for agents. Once the intuition clicks, you ship dramatically faster. Now you can take on work that never fit before: features that were out of scope, the re-architecture you kept deferring, or the tests and tooling you never had room for. From there, the gains compound: every leap in what agents can do builds on top of what you’ve already learned. This way of working is still being defined, and the developers doing it now are the ones defining it. Start changing the way you work today.