The Software Engineer

To understand what the software engineer is becoming, you have to understand what the software engineer was.

For most of the history of the profession, software engineering was an apprenticeship craft. You started as a junior. You were given small, contained problems by senior engineers who knew the codebase. You learned by reading their code, copying their patterns, getting your work torn apart in code review, and trying again. After a few years you were intermediate. You could be trusted with larger problems and less supervision. After more years you were senior. You could design systems, mentor juniors, and act as the source of authority on a domain. After more years still, you were staff or principal. You set technical direction for entire teams or organizations.

The progression took years because the knowledge was hard-won. There was no efficient way to compress fifteen years of pattern recognition into a textbook. The patterns lived in the heads of the senior engineers, and the only way to learn them was to work alongside the senior engineers long enough to absorb them. This is why the bootcamps that proliferated in the 2010s, despite their marketing, never really produced senior engineers. They produced juniors who could clear an interview screen. The actual making of an engineer took a decade and could not be rushed.

The day-to-day work, for most engineers, was a mix of activities that varied by seniority. Juniors spent most of their time writing code, reading code, running tests, and asking questions. Mid-level engineers spent more time on design discussions and code review and less time on raw coding. Seniors spent significant time in meetings, in architecture, in mentoring, and in unblocking other engineers. Across all levels, the work was a constant cycle of producing code, evaluating code, fixing code, and shipping code.

The compensation reflected the apprenticeship structure. Juniors earned less than they were eventually worth, because the company was paying for their training. Seniors earned more than the marginal value of their daily output, because the company was paying for the accumulated knowledge in their heads. The pyramid of the engineering org chart was justified by the pyramid of accumulated expertise. The company needed seniors to set direction, mids to do most of the building, and juniors to be trained into the mids and seniors of the future. Without juniors, the pipeline of future seniors collapsed. Without seniors, the work of the juniors lacked direction. The system was load-bearing in all three directions.

There is a historical analog worth knowing about. In the early days of the printing press, around the late fifteenth century, a profession existed called the scribe. Scribes were the people who copied books by hand. Producing a single book took months. The scribe was a respected craftsman with years of training. There were guilds of scribes, hierarchies among them, prestige associated with the role. When Gutenberg's press began producing books in the 1450s and 1460s, the immediate effect on scribes was not catastrophic. The press was slow to spread. Many scribes continued to work for decades. But within fifty years, the economic case for paying a scribe to copy a book had collapsed. The scribe profession did not disappear entirely; some scribes moved into adjacent work like illumination, manuscript production for wealthy collectors, or the early editorial roles in printing houses. But the broad, accessible profession of scribing as a path to a middle-class life was gone.

The software engineer of 2026 is in roughly the position of a scribe in 1490. The press has been invented. The early presses are slow. The good ones are getting faster. The economic case for paying a person to write code by hand, line by line, is in the early stages of collapse. The compression is not complete. There is still good money in being a senior engineer. But the trajectory is clear, and the engineers who are paying attention have already started moving.

Here is what AI is now doing inside software engineering, in 2026.

At the time of writing, the dominant AI coding tools include Claude Code, Cursor, GitHub Copilot, and Codex, with Lovable, v0, and Replit Agent having emerged as the leaders in AI-native prototyping. The tool landscape continues to shift, and any specific tool named here may have been displaced by the time this book reaches you. The pattern, however, is not going to shift. The work I describe in this chapter is being done, increasingly, by software that costs a small fraction of what an engineer costs, and the trajectory points in only one direction.

Code generation. The most visible part of the compression. Modern AI coding tools can take a description of what you want a piece of software to do and produce a working implementation. The implementations have improved every six months for four years and are now competent enough that most professional engineers use them every day. A junior engineer who used to take two days to write a feature now writes the same feature in three hours. A senior engineer who used to spend a day on a complex algorithm now sketches the algorithm with the AI in twenty minutes and spends the rest of the day refining it. The total time-to-ship for most software has dropped by a factor of three to five.

Code review. The second compression, less visible but arguably more important. AI tools now read code, identify bugs, suggest improvements, flag security issues, check for style consistency, and generate comprehensive review feedback faster than a human reviewer can. The senior engineer who used to spend an hour reviewing a junior's pull request now spends fifteen minutes confirming what the AI flagged. The activity that used to be the primary mechanism by which juniors learned from seniors has been disintermediated. Juniors are still getting code review, but they are getting it from the AI, not from the senior. The apprenticeship pathway has lost its main classroom.

Debugging. AI tools have become extraordinarily good at this. Show the AI an error message, give it the relevant code, and it will diagnose the problem with surprising accuracy and propose a fix. The work that used to be a senior engineer's distinguishing skill, the ability to look at a strange bug and reason quickly about its cause, is now table stakes for anyone with an AI subscription. The senior's diagnostic intuition still matters when the bug is genuinely novel, but those bugs are rarer than the profession likes to admit. Most bugs are variations on bugs that have been solved before, and the AI has seen them.

Test writing. Tests used to be the part of the job that nobody wanted to do. Tedious, low-status, easy to skip when deadlines pressed. AI tools now generate comprehensive test suites with minimal supervision. The engineer describes the function. The AI produces the tests. The coverage is often better than what a human would have written, because the AI does not get bored on the eighteenth edge case. Test writing has gone from a chore that engineers avoided to an activity that takes minutes.

Documentation. Same story. The eternal complaint about engineering teams was that the documentation was always out of date. AI tools now generate documentation directly from code, update it as the code changes, and produce reference material at a quality level that human-written docs rarely achieved. The role of the technical writer who used to support engineering teams has, for many companies, been absorbed into the engineering tooling itself.

Architecture and system design. This is the work that engineers said would be the last to compress, the work that requires the most judgment, the most cross-domain thinking, the most accumulated context about how systems behave at scale. It has compressed less than the other categories, but it has compressed. AI tools can now propose system architectures, evaluate tradeoffs between different designs, identify scaling bottlenecks, and suggest patterns based on what has worked at similar companies. The senior engineer's architectural judgment is still better than the AI's in most cases, but the gap is narrowing. The work that used to take a senior engineer weeks of design now takes days, and the AI is in the room for most of those days.

Now I want to tell you something specific, because the compression in software engineering has reached a point where the abstract description above does not fully capture what is happening.

I run an autonomous agent system out of a Mac Studio in my office. The system has a primary agent I call Mother, named after the ship's computer in the Alien movies. Mother has fifteen sub-agents, each with a defined role and a set of tools it knows how to use. I talk to Mother through Telegram on my phone. I can be at my kid's soccer practice and tell Mother to spin up a new project, scaffold a Next.js application, build out a basic feature set, push it to a repository, and deploy it to a staging environment. I get a notification when each step finishes. By the time soccer practice is over, the project has been built.

I am not an engineer. I am a designer who can read code and modify it when I need to. The system I just described is producing software at a level that, two years ago, would have required a small engineering team. It is shipping projects I would have hired someone to build for me. It is not perfect. The code it produces requires review. Some of what it ships needs to be revised. But the unit cost of producing software in my businesses has collapsed to the point where the question of whether to build a new tool or not is no longer a question of cost. It is a question of whether the tool is worth the time to specify.

I am one guy in Ohio. I am not the leading edge of this. I am the average case for what is now possible. There are people running operations more sophisticated than mine. The implication for the engineering profession, when a designer in his basement is producing the kind of output that used to require hired help, is something the profession has not fully reckoned with.

The compression in software engineering is not a small adjustment. It is a fundamental restructuring of what the work consists of, who can do it, and how much it costs to produce. The engineers who tell you AI is just a productivity tool are the engineers who have not yet understood what is happening to their profession.

What survives in software engineering, after all of this compression, is a shorter list than the profession would prefer.

The judgment about what to build. AI can produce software at a rate that no human team could match. That rate is now so high that the bottleneck has moved. The constraint on software production used to be how fast engineers could write code. The constraint now is how good the engineers are at deciding what code to write. The senior engineer who used to spend most of their time orchestrating juniors is now spending most of their time deciding which features the AI should build, which should be discarded, which should be refactored, which should be killed. This is a different skill from writing code. It is closer to product judgment than to engineering. The engineers who have it are pulling away from the engineers who do not.

The architecture that holds up under load. AI is good at proposing system designs. AI is less good at predicting how those systems will behave when they meet real production traffic, real user behavior, real failure modes. The senior engineer who has watched systems break in specific ways over a decade of operating production code has pattern recognition the AI does not yet have. This pattern recognition is most valuable in the moments when the AI proposes a cleanlooking design that will fail catastrophically the first time it sees real load. The engineer who can spot the failure mode before the system is built is irreplaceable, at least for now.

The debugging of the genuinely novel. Most bugs the AI has seen. Some bugs the AI has not. When something breaks in a way that does not match any pattern in the AI's training, the senior engineer with deep system knowledge is still the person who can figure it out. These cases are rare, but they are also the cases that bring down companies, lose money, and make the news. The engineer who can debug the unprecedented is the engineer the company keeps when it lays off everyone else.

The cross-domain integration. AI is excellent inside a single domain. AI is less good at integrating across domains, because the integration requires understanding which constraints from which domain apply where. The engineer who can hold the technical, the product, the business, and the legal context simultaneously, and design a system that respects all four, is doing work the AI cannot yet do well. This is the kind of work that historically lived at the staff and principal levels of the engineering hierarchy. It is now the kind of work that lives at almost every level, because the production work below it has compressed.

The trust to ship. There is still a category of code that has to be right. Code that handles payments. Code that controls medical devices. Code that runs in physical infrastructure. Code that touches national security. For this code, the question of who is accountable when it fails is not a hypothetical. The engineer who can sign their name to code, take responsibility for it in front of a regulator, and stake their professional reputation on it, is doing something AI cannot do, because AI cannot be held accountable. This residual is concentrated in specific industries, but it is real and it is durable.

What does not survive is the long apprenticeship that used to produce the engineers capable of doing the surviving work. This is the most under-discussed problem in the profession. The senior engineers of 2026 became senior by spending ten years writing code by hand, getting feedback from other seniors, and developing pattern recognition through repetition. The juniors of 2026 are not getting that experience. They are typing prompts to AI tools and reviewing the output. The pattern recognition that comes from typing the code yourself does not develop the same way when the AI types it for you. The pipeline that produces the next generation of senior engineers is breaking in real time, and nobody has figured out what to replace it with.

This is the strange situation the profession finds itself in. The work that survives requires deep judgment that takes years to develop. The path that used to develop the judgment no longer exists. The companies will need senior engineers in 2030. They will not have a way to make new ones. What this means for the profession over the next decade is one of the most important open questions in this book, and we will come back to it in chapter 27.

If you are a software engineer today, here is what to actually do.

First, accept that the compression is real and that hoping it reverses is not a strategy. The engineers who are doing well right now are the ones who internalized this in 2023 and started adjusting. The engineers who are doing badly are the ones who told themselves AI tools were a fad, would plateau, would not be able to handle their specific niche. The plateau has not arrived. The niche is not protected. Every six months the AI tools do more of what engineers used to do, and the engineers who keep insisting otherwise are losing ground every quarter.

Move up the stack from coding to architecture. The most defensible work in software engineering right now is the work of designing systems, not implementing them. If you are still primarily writing code by hand, you are competing with AI on its strongest dimension. If you are primarily designing what the AI implements, you are operating on a higher layer where AI is weaker and your judgment matters more. The migration from coding to architecture should be deliberate. Take on more design work. Volunteer to lead the technical planning for new projects. Write more design docs, fewer pull requests. The senior engineers who have made this migration are the ones thriving. The senior engineers who are still writing the most code on the team are the ones who will be redundant first.

Build your own AI workflow. The engineers who are pulling ahead of the field are not the ones who use AI tools the way the company tells them to. They are the ones who have built personal workflows that combine multiple AI tools, custom prompts, project-specific context, and integration with their existing development environment. This takes a few weekends to set up and pays off every day for years. If you do not have a personal AI workflow that goes beyond the default ChatGPT or Copilot integration, you are in the bottom half of the field on this dimension and falling further behind.

Learn the parts of engineering that AI cannot do well. Production debugging. Performance optimization at scale. Security review. Compliance work. Anything that requires holding the system in your head and reasoning about how it will behave under conditions the AI has not seen. These are the skills that will be valuable in 2030 because they cannot yet be compressed. Spend time on them now, while you have the runway to develop them.

Pick your specialization carefully. The engineering profession is bifurcating. Some specializations are being compressed almost to extinction. Frontend development for standard web applications. CRUD backend work. Most of the testing pyramid. Other specializations are holding up better. Distributed systems. Database internals. Embedded systems. Compilers. Anything that requires deep knowledge of how computers actually work at a level the AI has not yet absorbed.

If you are early in your career and choosing a specialization, choose one that has a moat. If you are mid-career in a specialization that is being compressed, consider a lateral move to one that is not.

Get comfortable with being a generalist. The pendulum is swinging back toward engineers who can do many things adequately rather than one thing extraordinarily. The reason is that the AI handles the production work in any given specialization, which means the engineer's value comes from being able to direct the AI across multiple specializations. A frontend specialist with no backend skills used to be valuable. A frontend specialist with no backend skills today is a frontend specialist whose AI tools can do most of their job. A generalist who can move between frontend, backend, infrastructure, and data, directing AI tools at each layer, is operating at a surface area that no specialist can match.

If you are early in your career, the situation is harder. The traditional path of joining a company as a junior, learning from seniors, progressing to mid-level over a few years, and eventually becoming senior, is breaking. Companies are hiring fewer juniors because the juniors' work can be done by senior engineers with AI tools. The juniors who are getting hired are being hired into smaller cohorts and given less mentorship, because the mentorship pipeline is overwhelmed. If you are a junior right now, the most important thing you can do is get senior-level skills as fast as possible, by any means necessary, because the runway you have to develop those skills is shorter than your predecessors had.

If I woke up tomorrow as a software engineer, here is what my first thirty days would look like.

Week one. I would build my personal AI development environment. Not the company-issued one. Mine. I would set up Claude Code or whatever the strongest tool is at the time of reading. I would integrate it with my IDE. I would build a personal context file that captures everything I know about the codebases I work in, the patterns I prefer, the patterns I avoid, the conventions of my team. I would spend the first weekend on this and have a working environment by Monday morning that operates on the specificity of my situation rather than at default settings. The personal context file is the leverage. Without it, your AI tools are doing what every other engineer's AI tools are doing. With it, your AI tools are doing what only you can do.

Week two. I would audit my work. For one week, I would track every hour. How much of the week was spent on production work the AI could now do? How much was spent on judgment, design, debugging, integration, mentorship? If the production percentage was over 50, I would treat it as an emergency. The role I had been hired into is not the role that is going to exist in eighteen months, and I have one year, give or take, to migrate.

Week three. I would start moving up the stack. I would volunteer for the design discussion my team has been putting off. I would write a design document for the next significant feature in my area, even if my title does not require me to write design docs. I would put it on the team's wiki. I would talk about it in the engineering meeting. I would make myself, deliberately and visibly, the engineer who thinks at the system level rather than the code level. This is the migration that matters most. The engineers who make it are insulated. The engineers who do not are exposed.

Week four. I would start building something on the side. Not because I want to leave my job. Because the experience of building something end-to-end with modern AI tools is the experience that teaches you what they can and cannot do. The engineers who only use AI tools at work, on the codebase they have always worked on, do not develop the intuition for what is now possible. The engineers who build a side project from scratch, by themselves, with AI tools handling most of the implementation, see what is happening to the profession from the inside in a way no amount of reading can provide. Two months of side-project work in late 2026 is more career-relevant education than a master's degree in computer science from five years ago.

Beyond the first month, the work is to keep migrating up the stack and to keep developing the skills the AI cannot yet do. I would deliberately seek out the hardest problems in my domain, the ones where AI tools have not yet been useful, and develop expertise in solving them. I would build a public surface for my thinking, on a blog or a substack or a personal site, where I write about what I am learning. I would be wary of any company that did not seem to have a clear strategy for navigating the AI compression, because that company is going to be in trouble in two years and I do not want to be in trouble with it.

The single move I would make if I could only make one: I would build a side project from scratch this month, by myself, using AI tools for everything I could not personally do, and ship it to real users. The experience teaches you more than anything else, and the things it teaches you are the things that determine whether your career survives.

A generation of engineers built their careers on the apprenticeship model.

They worked in basements and bedrooms in their teens. They went to computer science programs that taught them the foundations. They got internships, they got first jobs, they got code reviews from people who taught them how to think. They became seniors over years of work, by the slow accumulation of pattern recognition that came from typing code, watching it fail, and figuring out why. The engineering profession at its best was a real meritocracy, in which talent and persistence produced careers regardless of where you came from or what your parents did.

That model is breaking. The juniors of 2026 are not having the experiences that the seniors of 2026 had. They are not typing the code themselves. They are not getting torn-apart code reviews from senior engineers who care enough to teach them. They are not building the muscle memory that turns into pattern recognition that turns into senior judgment. The pipeline that produced the engineers we have now is breaking, and the engineers we have now are getting older, and the next generation of senior engineers is not going to look like the current one.

For the engineers in the middle of their careers, this transition is going to be the hardest part of their professional lives. They came up through the old system. They built their identities around being good engineers in the old sense: people who could write clean code, design good systems, debug hard problems, mentor juniors, ship products that worked. The old definitions of skill are still there, but the market for them is shrinking, and the new definitions of skill are not yet stable enough to anchor a career on.

What is being lost, more than the careers themselves, is a particular kind of professional dignity. The dignity of the craftsman. The dignity of having spent a decade getting good at something hard, and being known for it, and being paid for it. That dignity is becoming harder to come by in software engineering, not because the work is getting easier but because the work is being done by tools that are not paid in dignity.

The engineers who navigate this well will, in five or ten years, look back at this transition the way the human computers of the 1960s looked back at theirs. They will have moved up the stack, into roles that did not exist when they started, and they will have brought their accumulated judgment with them. The engineers who do not navigate it well will have a harder time, and many of them will be people the profession should not have lost. The technology arrived, and it did not consult them. It is not careful with the careers of the people inside it.

You cannot grieve and fight at the same time. You can grieve briefly, and then fight. The engineers who succeed in this transition will be the ones who do exactly that.

The compression of software engineering is opening up new ground that did not exist a few years ago.

The most interesting opportunity is the one I have been living. The solo or near-solo company. The business that, two years ago, would have required a team of ten engineers to build and maintain, and that one or two people with the right AI stack can now build and maintain themselves. This is not a hypothetical. There are companies generating real revenue, serving real customers, with employee counts that would have been impossible at any previous point in software history. The unit economics of these companies are different from the unit economics of the venture-backed startup. The ceiling is lower, but the floor is much higher, and the path from idea to profitable business is shorter than it has ever been. If you are an engineer with product sense, the opportunity to build your own thing has never been better, and it will not get worse anytime soon.

The second opportunity is the AI-native consultancy. Senior engineers with strong judgment and deep AI integration skills are increasingly being hired not as employees but as fractional partners. The model is the same as a senior medical specialist who consults across multiple hospitals. The engineer brings expertise and an AI stack. The client gets results that previously would have required a team. The hours are paid at a high rate because the output is leveraged. A handful of senior engineers I know have transitioned from full-time employment to this model in the past year, and most of them are earning more than they did as employees while working fewer hours.

The third opportunity is building tools for other engineers. The AI tooling landscape is still maturing. The platforms that win the next wave will be the ones built by people who actually understand engineering work from the inside. If you are an engineer who has been frustrated by the limitations of current AI tools, you are unusually well-positioned to build the next generation. The market is enormous, the customers know what they need, and the gap between what exists and what should exist is wide. Several of the most interesting engineering tool companies of 2026 were started by senior engineers who got tired of waiting for someone else to build the tool they wanted.

The compression of the engineering profession is also the largest period of opportunity for engineers since the early days of the personal computer. The engineers who see this clearly, and who position themselves to take advantage of it, will look back on 2025 through 2030 as the most productive years of their careers. The ones who spend those years insisting the compression is a hype cycle will look back on the same period and wonder what happened.

The next chapter examines a career that sits adjacent to engineering and has been under compression for almost as long, with results that are at least as severe and have been almost entirely overlooked in the public conversation. The data analyst.