My New Reality of Software Engineering

Software engineering as a profession is going through an unprecedented phase shift, not just another tool cycle. In the past month I have written almost no code by hand and still shipped more than ever, because agents now handle large parts of the implementation loop under my direction. That sentence would have sounded like breathless hype even a year ago. It does not now. The models and the tools have crossed a threshold where they are good enough, fast enough, and cheap enough to materially change how teams work and what they can deliver.

You do not have to like every part of this, and you can still have serious concerns about cost, quality, jobs, or broader social and economic impact. I do too. But this shift is happening whether we are emotionally ready for it or not, and the economics will keep pushing it forward. The practical question is no longer “is this real?” but “how quickly can I learn to use it well?” The people and teams who invest now will have a major advantage in output, scope, and speed over the next few years. There is real value in these technologies for you now, in a way that wasn’t really true before.

A Career That Suddenly Changed

I have been a software engineer for more than twenty years. Looking back, it’s amazing how many things have changed in that time, and how many things have not. But what has happened in the last year, especially the last six months, has created a fundamental shift in how I work, how I think, how much I produce, and really what it even means to be a software engineer.

I was lucky (I think) to have always known that I wanted to write software as a career. I knew I wanted to work with computers from the moment I heard about them, before I ever actually touched one. When I was around six, my parents got me a VTech PreComputer 1000, a simple device that had math and geography quizzes, a very non-standard terrible keyboard, and a single 20-character dot matrix LCD display. But it had a mode where you could write BASIC, and a very small instruction manual. Writing line numbers when you could only see a single line at a time was quite the challenge, but I spent hours writing programs in that thing. Worse yet, it did not have any non-volatile storage, so if you turned the power off, your program was gone. That did not stop me from writing programs over and over, debugging, improving, and just playing with it non-stop. I made monitors, cases, and keyboards out of cardboard boxes and markers, just to pretend. When I saw my first “real” PC at my dad’s work I was hooked. This was the future, and I wanted to be a part of it.

The idea that I could not just use but control these things was so empowering and enchanting for me. Like actual magic spells that brought my whims to reality. And there was always this intertwined tension between wanting to learn the languages and patterns and efficient ways to write the code, and the actual production of the thing I was trying to build so I could show other people how cool it was. Both brought me so much joy.

And it has been that way for my entire career. I have always loved the actual writing of the code, the sound of my hands on the keyboard, the diffs in version control, but most importantly the problem-solving challenge and the problems I was solving for my users and customers. I was making lives easier, bringing joy to other people, or making them and myself money. But it always required me to do all of the work: understanding the problem, challenge, or pain point; coming up with a solution; making that solution a reality; debugging and maintaining existing code; building; testing; iterating; showing it to other people; and getting it into production.

I was at my current job when ChatGPT was first released. It was such a novelty at first, then we started getting scared that our jobs were over. Then we settled into the reality that while these things were cool, they had major limitations. They hallucinated. They could not keep much information in context. There was no way they were going to be able to handle our hundred-thousand-line codebases. We were thinking about their knowledge cutoffs, figuring out how and if they might be useful, and some of us were imagining a future where they could do so much more, but that was not the current reality and was not near term.

And slowly but surely things improved. We got new models, better tools. When I started at my company we had lots of challenges where we needed to do things at a scale that would mean hiring dozens if not hundreds of people if we wanted to do it fully and repeatedly. There was no way we could hire that many people, much less manage them. But we started building toward that future anyway, thinking that one day it might be possible.

Then Claude Code came out. The climate started to change. People started saying it could do so much more. I decided to start using it a lot more, letting it write the code maybe 75% of the time. I was still using things like Cursor’s tab completion and writing large blocks of code myself, but I slowly gave it more and more. I was working on large-scale systems, some from scratch, some existing. Large, architectural, ambitious projects, the kinds of things I love and am really known for. And it was handling it all.

And then, in the last month we got Opus 4.6 and Codex 5.3. These two models specifically have changed the game. They are more thorough, make fewer mistakes, go for longer - they are just all-around capable. My CTO put out a memo to everyone that we should not be writing most of the code anymore, we should be using the agents. They are smart enough, fast enough, thorough enough. Good enough. I was relieved; I had already decided to try and go all in.

And now I have not written more than a dozen lines of code by hand in the last month. Codex writes my code, helps me plan, manages git, creates my commits, pushes my PRs, gets second opinions, responds to review comments and addresses them, manages my stories, just about everything, just with my control and guidance. I am shipping more than ever, getting more done than ever, while writing virtually no code to do it. I am talking to an agent like I would talk to a colleague in Slack. I am writing in languages that I am not nearly as fluent in, but it does not matter. I am still shipping quality code that does the job as well as if written by an expert in those languages. I’ve shipped over 30 PRs in the 20 working days of February, across four major systems. Features, tests, documentation, bugfixes. It’s a whole new world.

The New Reality

In some ways, this world has changed so fast, and in other ways it felt inevitable. I told someone a year ago that before long it will be like we are all engineering managers with full teams of employees. That is really the way I feel now. Across my career we learned new frameworks, new languages, and new patterns, but the fundamental shape of the job stayed mostly the same. This time is different.

The reality is not evenly distributed yet. At my job, and in my social feed, we are in a bubble where people are pushing these tools hard and adjusting their workflows around them. At the same time, there are many engineers still working mostly the way they worked last year, and the twenty years before that. I am not saying everyone has to move at once, but I do think everyone will have to confront this shift. Within five years the landscape will look completely different. Expectations for output, speed, and scope are going to move. Teams that adopt these tools well will compound output, and that will gradually reset what “normal” looks like across the industry.

Part of this reminds me of when source control was becoming mainstream. I remember having to proselytize why it was good, a necessary way of working that was worth learning and adopting. I remember people resisting at first because it felt awkward and slow. We take it for granted now, but back then many teams still copied files by hand before making changes. But with version control, nothing fundamental about the job changed. This new way of working is much more revolutionary.

“Revolutionary” is an interesting and apt word here. In tech, we usually use that word in completely positive terms. Who does not want a revolutionary new product? But actual revolutions are messy and disruptive. There are winners and losers, and there are people very happy with the status quo who will resist as long as they can. This should not be a holy war, and I do not think in moral binaries about it. But I do believe this shift is inevitable. I might be wrong about the exact timeline, but I do not think I am wrong about the direction. We need to start mentally preparing ourselves for what comes next because the economics alone will force the shift.

There are also new problems we have to solve. When the execution cost drops, teams take on more, and the bottlenecks move. PRs get larger. Review burden increases. Product and design can become the new constraint. The mental split between writing code and supervising/reviewing code gets sharper, and that cognitive load is real. The context switching is easier than it was before, but it still takes its toll.

I do not want to give the wrong impression: this is not utopia. Agents make mistakes. Quality still depends on tests, review discipline, and engineering judgment. There may be less demand for software engineers in the future. I am concerned about what this means for junior pathways, for hiring, and for the broader economics of software. Businesses themselves will be disrupted by these changes because the economics are changing, and expectations about software are changing with them. I don’t personally believe this is the death of SaaS, but I expect the nature of it to change significantly.

You may be revolting against this movement because you don’t think AI in general or LLMs in software engineering are actually positive for society. You may be concerned about the energy and water use, the way the data centers and graphics cards and model training are consuming the economy. You may be worried that by participating in it you’ll be somehow culpable if this isn’t the future you want. I understand those viewpoints, and may even agree with you, but for what this means for our reality as software engineers today I just don’t think those things matter. This is the future, and it is the present. We are here.

A concrete signal: Block laid off 40% of their workforce while explicitly tying that decision to AI-driven changes in how work gets done. I do not think this stays inside tooling conversations much longer. It is going to become a hiring standard. In my next interviews, one of my first questions will be inference budget and agent tooling flexibility, and I expect my fluency with these systems to be one of their first questions for me.

I want to tell you that it’s okay if you haven’t tried these things yet, or are still using agents in an IDE or tab completion, that’s fine. If you’ve thought that this stuff is changing too fast and have wanted some dust to settle before investing in it, that’s fair. If you already have a full-time job and learning all of this feels like another full-time job, I get it. If you’ve tried these agents in the past and were disappointed, I understand. But it’s time to try again. Things have changed. They’re going to continue to change, but they’re truly good enough to really put to work and a worthwhile investment of your time at this point. If you haven’t gotten started with these technologies yet you aren’t late - you are right on time. But no matter where you are today, there can be a real emotional cost.

Mourning the Loss

You may be somewhere in the five stages of grief. Realize that one day you’re going to get to acceptance, but that may take time. It is completely normal if you’re still on an earlier stage.

If you are a software engineer because you like typing on the keyboard, writing the actual code, and thinking about the control flow of the program through each successive line in a file, this sucks. It does. I certainly think I am one of those people. I have softened my attachment to the actual code over the last decade of working in startups where the usefulness of the thing I write might not last long as we try to find the elusive product market fit, but I have always cared deeply about not just the outcome but also the formatting, organization, and elegance of the code I produced. I tried to leave code better than I found it with every PR. I cared deeply about names, had debates about comments, fought in tabs-vs-spaces wars. I had opinions on the aesthetics of files. I am not happy about leaving that behind - it certainly felt like it mattered at the time. I worry that my ability to read and write code will languish over time, and that somehow that will affect my ability to reason about software itself.

But if you care about solving problems and shipping, this might be the best thing that has ever happened. In so many jobs in my career I advocated for spending time on our tech-debt column in the project management system. There were so many things we wanted to do but could not find the time for. There was never enough time, never enough people to get everything done. We needed to ship the new feature, fix the priority bug, and do the next thing. Going back to maintain old code, or make that improvement that wasn’t in the critical path, was something you only got to do if you were lucky or you snuck it in. We can do those things now. Most of the time those things were not difficult. They did not need a genius to implement; they just required time we did not have.

Now you can give your intent and constraints and opinions to an agent that can do those things for you, including a lot of the bookkeeping around the change that used to make it not worth it. How many times have you looked at what would be a change of only a few lines and chosen not to do it because those few lines were actually hours of work when you considered making the story, creating the branch, writing the tests, creating the PR, asking for reviews, iterating on review comments, and deploying it? Those things are materially easier now.

At the end of the day, we are paid for the things we ship. Shipping has to be the goal. It has been great for the past twenty years that I have been paid to do this thing I love because I was shipping value to customers, but it was the value I was paid for, not the symbols I wrote. But I will mourn the loss of artisanal hand-written code.

When I am really honest with myself, though, I am happiest when I am productive. That is such a hard word to define, almost an emotion. But when I go to bed at night, I feel best when I feel successful at getting something new out into the world, a desire made into reality. The mechanics of doing that gave me pleasure, but that was never the thing that mattered most. What matters is shipping.

My Suggestions for How to Get Started

You may not know how to get started and the options may be overwhelming. If you are curious but still uncomfortable, the answer is staged adoption. Ask the agent to do one contained change, something that you already know exactly how you would do it. Review the diff. Run your tests. See what it got right, what it missed, and where your instructions were vague. Then try again. When you get more comfortable, push it further, give it a little more. Just start talking to it. I think you’ll be surprised.

The biggest unlock for me was moving from build mode to explicit planning. Before any change, have the agent produce a plan first. Then force it to ask clarifying questions until there is no ambiguity. I often tell it to be relentless about asking questions, questioning assumptions, and raising edge cases. Give it your plan and ask it to elaborate on it and challenge it.

Trust builds from repetition. At first, keep your hand on the wheel for anything that touches external systems: deploys, migrations, production settings, billing surfaces. Over time as results become predictable you can delegate more of the full loop: branch setup, implementation, tests, commits, PR creation, review response, and cleanup. The goal is not blind trust. The goal is reliable delegation with verification.

If you only take one practical step this week, make it this: install opencode, launch it in your current project, leave everything as the default, and just talk to it. Put it in plan mode and tell it what you are about to do and see what it thinks. Have it describe to you how a subsystem works. Ask it to find a bug. Just start talking to it and I think you will be surprised. Then, when you get a little more comfortable, get an OpenAI subscription and switch the model to gpt-5.3-codex and ask it to do the thing you were about to do.

But do not have brand loyalty in any way. Try and choose tools not produced by a single LLM provider (the main reason I like opencode right now). Don’t fall in love and get attached to any one model. Don’t dive too deep into integrations with any one software because a better one will come out tomorrow. This is hard in a lot of ways because it feels like you’re never going to “catch up” much less get ahead, but that’s okay. Part of this new reality is being prepared to learn new things all the time. We are so early. Everything is going to keep getting better. We are still figuring out what these things can do and how to work with them every day. If you can be part of that research that’s awesome, but you don’t have to blaze new trails, use these tools for the value you can get out of them and then replace them as soon as something better comes along.

You have to change your mindset and judge this workflow by shipping outcomes, not by how much code you personally typed. I still care about code quality and design choices, but I spend less energy on the bookkeeping around changes. That lowers the activation energy for all the little improvements we used to postpone forever. Tech debt gets burned down. Side quests that never seemed worth the overhead actually get done. Use it to be curious - those ideas you’ve had but it would take too long to write out and try. Create a branch, tell it what you’re thinking, and see what happens. Who cares if you have to throw it away - you will have learned something.

A normal day for me now is usually one core project I am driving end to end, plus smaller improvements running in parallel that would have sat in the backlog before. While I am iterating quickly on the main thread, an agent can be tightening tests in one area, fixing a flaky edge case in another, or preparing a cleanup PR for a naming inconsistency we have ignored for months. None of those tasks are individually hard. They were just never worth the setup cost before. I have the agents read my logs and find problems or opportunities for improvement. I have it check my understanding of subsystems or database tables and where they are used. I treat it like a coworker who already knows all the answers or knows where to find out faster than me.

I’ll give you an example. Recently my main goal at work has been creating a large system using agents to process and make sense of our data. I am spending the majority of my effort on this, more than enough for a full-time job. Along the way I am seeing bugs or opportunities to improve the UI in other systems, so I fire up another session and tell it what I want and let it cook in the background. Later when I get a break I go and check on its progress, look at the changes and try it out, and tell it to iterate or to cut a detailed PR. I’m shipping several of these side quests a week, things I never would have had time for.

The agents will make mistakes. You’ll have to be diligent to catch them. Tests and code reviews and actual QA on your part continue to be as important as ever. The agent might write a few thousand lines of code and you’ll realize that it’s gone off the rails and you’ll have to throw it all away and try again. Frequent commits will help. You’ll have situations where you weren’t specific enough or the agent misunderstands you and it goes and does the wrong thing. You’ll tell it to fix a failing unit test and it will delete the unit test (“fixed the glitch” office space style). These are all things you’ll have to navigate and get comfortable with and learn how to avoid. But - it’s worth it, and it’s time to learn these skills.

Do not expect that the agents will feel amazing when you first start. It takes time to learn how to prompt them the same way it took time to learn to code. You can write subpar code and get results and you can write better code and get better results. Prompting is the same way. It takes practice and experience, and the only way to truly learn is by doing.

You do not have to stop being an engineer to use this model. You still own the problem framing, architecture decisions, constraints, and quality bar. You are still accountable for what ships. You still need to read every line of code it produces. The difference is that execution becomes collaborative and parallel. In practice, that means you can do more at once, if your team can absorb the review load and process throughput that comes with it.

There Is So Much More to Say

Maybe you are worried about the costs, maybe you want more opinions on which LLMs to use, which tools to use, and just more examples of what you can do with it and how to fit it into your teams and your processes and your day-to-day. I hope to write more about these things soon (reach out on Twitter if you would be interested). Don’t believe everything you see on social media about the topic, but do believe some of it. The signal-to-noise ratio is terrible right now, there are lots of voices trying to make money and drive public opinion. Ignore most of them, but when you start to see themes emerge, pay attention. Remember that not everyone is working on the same kinds of things. Devs building frontends and webapps don’t have the same needs as those building operating systems, and so their experiences with the agents won’t be the same. Don’t assume that someone else’s experience applies to you.

If there is one takeaway from all of this, it is that the leverage is real right now, and the people who learn to direct it well will shape what software engineering looks like next.

I’m going to leave you with some tweets and articles from the past couple weeks that I think help make my points. I’d love to hear what you think - if you agree or disagree.