Software Engineering in 2026 - Outputs vs Outcomes

19 Sep 2026

Last year (2025) I took a few short contracts between jobs. I have a full-time software engineering job now, but I just realized it was probably the last time I will be paid to write code.

Output Driven Work

Historically, most contracts in the software world have been output driven. One of mine, for example, was to port some software to a new experimental platform and put together a demo. My job was just to deliver the working code and demos. This is the output part of our work. You don’t need to understand the business, come up with the idea, validate it, write requirements, deploy it, iterate on feedback, etc.

There has always been a glut of contract work like this floating around. Internal teams often don’t have the time, or specialized knowledge, to explore a new idea or get a side quest done quickly. These tasks are too disparate to justify bringing on a full-time person.

I’d also note, I’ve worked with many full-time engineers who saw their job through this lens too. They wanted to show up, be told what to build, deliver the code, and then go home.

Outcome Driven Work

One year later, advancements in coding agents has convinced me that the value of this part of the job is asymptotically approaching zero. We’ll now need to take responsibility for the whole process and be judged by our outcomes, not our output. That means this specific type of short term work will dry up. It also means full-time engineers who view their role this way will need to adapt.

Don’t get me wrong, for those of us that understand code and systems, we will have even more power in this future economy. But if you refuse to take responsibility for how your code actually creates value, you will find your power is greatly diminishing.

I have very complicated feelings about this, I think it diminishes the craft of what we do, and it will be quite disruptive to our field, but I feel that this is a good thing for the industry and for me personally. I’ve been viewing my role this way for a long time now and I’ve always sought out companies where software engineers already think this way.