As software engineers, we used to get a particular joy from releasing something we had spent months, sometimes years, building. Late nights at home, long evenings at the office, a codebase that finally felt stable enough to ship.
It could be a team finishing a difficult release or a solo developer publishing a slightly messy Objective-C or SwiftUI app. You knew the internal because you had written it. Getting it to work was part of the pleasure, not merely something standing between you and the release.
Our view is that this era is over as the default model for commercial development. Writing everything by hand is no longer economically sensible for most for-profit software companies, however much we might enjoy it.
Enjoying the work does not justify the expense
Coding agents can now implement features across multiple files, run tests and work through corrections. In an agent-led project, the developer can direct the implementation without personally writing it. This is already a working development model, not just a promise about future tools.
That changes the justification for doing the same work manually.
When an assisted implementation costs less after testing and corrections, the extra time spent hand-coding needs to produce something worth paying for. Better reliability or maintainability would qualify. Personal satisfaction would not.
For a solo developer, the calculation is no different. The hours might not appear on a payroll, but they still come out of the time available to support customers, sell the product and make a living.
You can prefer writing the implementation yourself and still recognize that it is the wrong commercial decision.
The working day is changing
For a developer working this way, the day can consist largely of prompting Claude or Codex, checking progress and correcting instructions. Breaking down tasks, supplying missing context and setting up reliable checks become substantial parts of the work. Some agent-led teams even delegate much of the code review to other agents.
Instead of implementing a feature, you explain what it must do. You check whether the agent understood. You tell it not to rewrite an unrelated module or introduce a dependency the project does not need. Then you verify the result.
That requires technical knowledge. It does not necessarily provide the same enjoyment as solving the implementation yourself. Engineers interviewed in Anthropic’s research described precisely this tension: greater output alongside missing parts of the coding work they used to do.
We should be able to admit that without pretending the productivity gains are irrelevant, or that everyone will find supervising agents equally rewarding.
The same approach extends beyond programming. Our Think-Act Desktop Agent is a general-purpose assistant that lets users describe a task, provide context, supervise supported actions and review the result. It brings that pattern to everyday computer work rather than just code.
This is the shift worth discussing
In our view, prompting and monitoring agents is becoming a central part of software development, rather than an occasional shortcut inside it.
That is a significant change for people who chose this profession because they enjoyed writing software. We can still do it for pleasure, for learning, or when a particular problem genuinely benefits from a manual implementation.
But commercial work has a different constraint. When the same result can be delivered reliably at a lower cost, a company needs a reason to choose the more expensive approach.
“I enjoyed building it myself” used to fit comfortably into the job. It is no longer enough to justify the time.
Users decide which connectors are installed and enabled.
