It's just not as fun anymore

If you were a software engineer in 2023, the year I entered the workforce, the field was more or less how it’d always been. As an individual contributor, you’d go deep—you’d shove print statements everywhere, scour stack overflow, research some docs, and pester your coworkers about why the system was built a certain way—and by the time you submitted your PR, you were proud. You became an expert on this small slice of the system. You could engage in thoughtful discourse around any comment because you knew what the hell was happening. The bugs you faced were enraging, but the “ah-ha” moments were even more rewarding. The flow state you reached during programming was a distinct pleasure you could not articulate to people in other fields.

Beyond this, programming was a personal craft that reflected an engineer’s personality. Even when following best practices, our subjective tastes would come out, so much so that you could even identify which coworker wrote code without the git blame. Joey considers util folders an anti-pattern. Tom’s variables are in British english. Soham really cares about alphabetizing his imports.

I am grateful to have begun professional programming in 2023 because I got to experience at least a bit of this world, but in 2026, the game has changed. I’d like to preface my vision of today by saying I am not a “doomer”. If anything, I believe there is more career opportunity than ever for software engineers, but the world I depicted above does not exist anymore. We used to be craftsmen, and now we’re machine technicians.

State of the world: July 2026

In the start of 2026, you could still handwrite code, but 6 months later most of us don’t anymore. I began working at Hex 2 months ago, and I have not handwritten a single line. Sure, we still go deep with the agent about structural and high level decisions, but we’ve exchanged the deep knowledge achieved from by-hand implementation for a short term efficiency buff. The codebase is now built for agents, not human eyes, and whenever I try to handwrite something nowadays, I inevitably anger a linter or cause some unintended side effect. Even the most skilled, staunch, anti-AI programmers can’t succeed anymore—the velocity and output expectations for ICs are simply too high to handwrite anything and still do well in performance reviews.

And while you have an agent running, you can do something else. Why not spin up another one to work on another task? And another one! And another one! One finishes, you check it’s work, kick it off and move to another. You are now switching context every 2 minutes instead of 2 hours (more on this later). This is the name of the game mid 2026. How much can you ship? Do you understand what it’s doing? Is it even important to anymore?

The software factory, and two emerging roles

Software development is approaching a point where it can be thought of as a “factory”. In some ways, this software factory has always existed—product decision or bug → project management (jira) → triage → design → eng implementation → QA → experiment → rollout → holdout—but people did everything. Every stage of this process involved humans doing complex, cognitive work.

Now, agents are becoming more autonomous, long running, and able to handle ambiguous questions, so much so that the software development process—by this, I don’t just mean engineering, but also QA, design, product, triage, etc—is becoming a self-functioning machine, one that does not require the human in the loop, at least not in most places. There are, however, a few important human roles to keep it running: the people that produce the signals that power what the factory makes, and the people that decide how it should function and tend to the operations.

The way I see it, the technical individual contributor has two options: become a product person (the signal producer), or become an infra person (the technician). Now that implementation is more or less trivial, you can spend your time working much nearer the product, or you can work in the technical weeds around infra, devops, telemetry, evals, etc.

Path 1: Product Person

The product person really has a split role. One half of this role is product management. With implementation being so trivial, they can focus more on “what should we ship”. Engineering-Product-Design (EPD) at most companies is, to some extent, morphing into one role. The engineers do design work, The PMs and designers submit PRs, etc.

The other half of the product person’s role is QA tester. When you’re shipping features at 10x the speed, you also have to verify 10x the code and results. In this way, a large portion of your role is QA testing and code review. You’re switching between different worktrees, spinning up dev and staging environments, and meticulously verifying and testing everything the agent did.

Path 2: Infra Person

The infra person is building the components of the factory and ensuring its every day operations flow smoothly. You might be architecting an overall system, spinning up cloud containers, building dashboards and alerts, or running evals to decide what model to use, but at the end of the day, you are creating and maintaining the software development apparatus, not developing the software itself.

Handloom weavers

In the 18th century, handloom weaving was a great trade to be in. The tedious and uncreative parts of textile production had been mechanized, so weavers had abundant resources, and a good handloom weaver could take pride in their craftsmanlike independence and high wages.

Sometime in the 19th century, the power loom arrived. It was cheaper and faster than hand weaving, and it rendered the craft obsolete. With it, there came many jobs to work the machines, but the creativity, product differentiability, and personal fulfillment of weaving was gone.

I see software engineers (or more generally, anyone who does cognitive work on a computer screen) as no different from 19th century handloom weavers. The agentic productivity tools and software factories of today are the power looms and textile factories of 200 years ago, and we must learn to be part of the factory, either producing signals or maintaining the systems, rather than compete against it.

Multitasking

I am not the guy with 20 cloud agents running at all times, but I’ll have a few local instances going at once on any given work day. The agents do their work, and I switch between them every 5 minutes to test it, verify the code structure produced (I hardly pay attention to syntax anymore), and review other people’s work.

The reason why this is so hard is that humans are not meant to multitask like this. Sure, having a dozen agents running overnight is cool, and it’s fun to push the boundaries of what’s possible, but there is no more “flow state”, no more of that amazing deep focus feeling you get from going all out on one task, where you forget your phone even exists, where an hour passes by in what feels like 10 minutes. By constantly context switching, we can generate a lot more output, but the fulfilling part of work, the flow state towards which humans are so naturally prone, is gone.

Me

Today, I feel optimistic about my job and opportunities, but pessimistic about the enjoyment of programming. Just like the handloom weaver turned machine operator, there is work for me, but it doesn’t scratch the same itch that it used to. So what will I be doing in 5 years? I don’t know if it will be programming (if I will learn to enjoy operating the software factory) or if it will be a drastic pivot to something else. In the meantime, I am going to put one foot in front of the other and see what happens from working at an AI startup in 2026, during this technological step function that makes me feel terrified and excited and existential all at the same time.