There is a small lie buried in the way many of us learned software engineering.
The lie is that the job is writing code.
For a long time, that was close enough to true. A great engineer was often the person who could take an idea, descend into a codebase, and come back with something working. Entire careers were built on being unusually good at turning intent into software.
What changed becomes easier to see when you separate software work into three loops.
The first is the code iteration loop. This one has clearly accelerated. A feature stub, a migration, a small service, a test harness, a UI flow, a batch job — the sort of thing that used to take hours of typing and rummaging through documentation — can often be produced in minutes.
The second is the system integration loop. This one moves faster too, though less dramatically. Components appear quickly. Making them agree on contracts, data models, retries, ownership, latency budgets, and failure behavior still takes real care. Software can now be generated faster than coherence.
The third is the product and organization loop. Users react on their own schedule. Revenue, retention, support volume, team understanding, and operational stability still reveal themselves over weeks and months. This loop remains mostly human.
I felt that difference most clearly after moving into management. Engineers live close to the compile button. Managers work with delayed signals. A hiring decision in March may explain itself in August. A change in team boundaries can take a quarter before its effects become clear.
Agents shortened that distance for me. I could define a problem in the morning, set the constraints, review a working result, and run the cycle again that same day. The rhythm felt familiar again: make a decision, see what happens, adjust, repeat.
That change matters because it shows what is actually getting cheaper. Routine implementation is getting cheaper.
If a person can describe a service clearly, specify a user flow, outline a migration, define the happy path and the ugly cases, and explain what “good” looks like, an agent can often produce a workable first pass. The old moat of personally turning a spec into code is narrower than it used to be.
That does not remove the need for judgment or ownership. It raises the value of both.
A model can offer six plausible authentication systems. Experience decides which one fits a startup chasing speed, which one fits a company heading toward an enterprise security review, and which one will age well inside the systems you already have. Someone still owns the rollout, reads the metrics, decides whether the strange dip is noise or the start of a real incident, gets on the call with the unhappy customer, and carries the pager.
As implementation gets cheaper, more of the work gathers around requirements, boundaries, contracts, and success criteria — the small details that keep one subsystem from quietly disagreeing with another.
Imagine a system with three subsystems: auth, payments, and notifications. Each one gets built quickly. Each one has tests. Each one demos well. Then integration begins. Auth passes user context through headers. Payments carries its own session model. Notifications polls a table that nobody else writes to. Each subsystem makes sense on its own. The whole system behaves like three neighboring countries that each decided to drive on a different side of the road.
This is a familiar engineering pattern. We build an abstraction, it saves time, and later it leaks. Agents are a powerful abstraction over implementation. They let a person work one layer above the code, which is useful for the same reason any good abstraction is useful.
The leaks show up at the service boundary, in the vague performance target, in the retry policy that lived only in somebody’s head, in the data model nobody pinned down, and in the demo path that glides past the hard cases. Faster code generation makes those leaks easier to create because the surrounding structure has less time to form on its own.
When implementation was slower, some of those problems surfaced in the ordinary friction of design reviews, long pull requests, and coordination overhead. Cheap implementation weakens those checkpoints. Teams have to define the seams earlier: what the inputs and outputs are, what the API guarantees, what gets persisted, how errors travel, what can be retried, and how success will be measured.
The coding gets cheaper. The boundaries demand more attention.
That is why staff engineers and engineering managers matter more in an agent-heavy world. A larger share of the value now sits in decomposition, sequencing, quality bars, and contract design. The person who can carve a messy business problem into stable, testable pieces becomes more valuable when implementation is abundant.
The same shift is changing roles around the edges. Engineering managers can get hands-on leverage again because architecture and product context can turn into prototypes very quickly. Senior ICs gain even more value from product judgment, prioritization, and the ability to spot where a clean local solution will create a messy global one. Designers can build interactive front-end prototypes that answer real questions. Product managers can assemble working demos that test an idea against reality instead of stopping at a persuasive deck.
The walls between roles are lower when implementation is abundant.
The best people already worked across some of those boundaries. Great managers understood systems. Great ICs understood the product. Great designers understood flows and constraints rather than only surfaces. What changed is that crossing those lines is cheaper and more useful than it used to be.
Junior engineers enter this world with a real advantage. They can get more reps, ship features earlier, and watch systems respond. That can accelerate the path to judgment in a meaningful way.
It does not remove the need for apprenticeship or fundamentals. Agents are an abstraction, and abstractions leak. A junior still needs to learn how to debug, how to trace state through a system, how to read code written by other people or by a model, how latency and concurrency change behavior, why tests can pass while the system remains wrong, and how production differs from a good demo.
The broader business effect follows naturally. Sheer implementation capacity becomes a less reliable moat. A small team organized around fast specification loops, strong quality gates, and thoughtful use of agents can compete in places where raw implementation capacity used to matter a great deal.
Large companies still hold real advantages in distribution, trust, compliance, and operational depth. Even so, some of the coordination overhead inside big engineering organizations made sense in a world where implementation was expensive. As that cost falls, more of that process starts to look optional — or at least in need of rethinking.
The job is still engineering, and deep technical skill still matters. As implementation gets cheaper, more of the work moves up a layer: deciding what should exist, defining the boundaries that keep it coherent, and owning the result when reality pushes back.
That is where more of the job lives now.