The future of "Software Engineering"

Intro

Right now everyone is guessing what the future of software engineering holds, given the renaissance of AI and LLM-based coding tools.

I've recently had time to experiment with Claude Code, and to use it at work. I stand by what I've said and thought, regarding where the onus of critical thinking and planning lies, and what you can/can't expect from LLMs. And further, one defining feature of the software industry is that there is a paradigm-changing technological breakthrough roughly every decade or so – this is no different.

What I mean specifically by that is that the source of the code (who wrote it) now carries no inherent value; the old comparisons like "100 lines of junior code" versus "10 lines of senior code" are basically invalid, because code can (and probably should) be mostly generated from the same set of tools.

Even if LLM based tools don't have adequate training data for your language or domain, it is purely a matter of time, so buckle up.

Written in response to this video. Most of the links I've shared below were lifted directly or indirectly from that video, and it's definitely worth a watch.

What does the future hold?

So what is the future? My cop-out answer is that nobody can say for sure, especially with how wildly things are changing right now. So of course, my guess below may well be wrong. But I think there's value in going through the exercise of guessing, so here goes:

1) Your value as a SWE

(Keeping Goodhart's law, below, in mind) A new metric of success for software development will be how many agents you can keep busy and contributing code at once. In other words, how quickly can you create tasks/stories/feature specifications, refine them for dispatch to a development agent, review the changes the agent creates, and get the completed task delivered.

2) New job titles and skills

It will be critical for business success to continue to have humans accountable for development, bug fixes, and so forth, so we will see a rise in job titles along the lines of "Software Dev Agent Shepherd" or similar; the skillset for this role will be a hybrid between close-to-software debugging and analysis skills, to resolve tricky issues, and high-level architectural/design skills. This means you should brush up on your UML.

GitHub - plantuml/plantuml: Generate diagrams from textual description

Generate diagrams from textual description. Contribute to plantuml/plantuml development by creating an account on GitHub.

GitHubplantuml

Some anedcotal evidence: I've found that a few PlantUML diagrams and a thorough readme describing how software ought to work, is basically enough to sic Claude on a whole small-to-medium sized project, including its own granular planning (milestones and feature sets supporting the overall design), tests, iterative development, and so forth. All I had to do was provide feedback along the way, but given a good starting design and architecture, agents seem ready to rapidly actualize them.

3) Feedback-to-feature loops

It will be critical for businesses to automate the customer-feedback-to-release loop as much as possible, with humans in the loop in a few critical spots. I've already heard stories of companies deploying releases to customer feedback within ten minutes, and this will likely get more and more common

4) Engineering allocations

Wise businesses will not lay off the highly skilled engineers they've invested in hiring, training, and mentoring, but will instead re-allocate more of those resources to internal infrastructure development, for things like bespoke MCP services, what I mentioned in #3 above, and so forth.

I'm not going to cite a dictionary and show it, but by the very definition of "engineering" no engineers are going to be out of a job. The definition of our job has changed, and we need to understand how to use the new tools to do our job, but unless you think we will no longer have problems, or desire results, then you ought to agree that engineering as a role isn't vaporizing.

Now, many of the new problems business need to solve will be answering the internal question: "How do we get the most out of agentic tools?" – which naturally leads to the conclusion that we'll see more investment in internal infrastructure to do so.

5) Team sizes

For development purposes, we will start to see more, smaller teams, whose accountability grows in breadth. And they'll keep the internal teams from #4 busy with requests for new tools. I'm unsure if this will carry over to management organization. And frankly, I don't think any guess I make for that domain will have any value.

I found the concepts described by Team Topologies to be helpful (linked below), as well as this blog post responding to the book (which I didn't read; I reviewed the site below).

Key concepts and practices for applying a Team Topologies approach to team-of-teams org design — Team Topologies - Organizing for fast flow of value

Explore key concepts of Team Topologies: four team types, interaction modes, platform-as-a-product, and more. Tools and practices included!

Team Topologies - Organizing for fast flow of value0

6) Best practices

We'll see a renewed interest in best-practices, which will present as a refreshed interest in existing literature, as well as a lot of new literature. The new stuff will, as usual, basically echo the earlier stuff, but in the new context.

Half joking here, but my guess is we're going to see Agile Development turn into AI-Developed, Human Driven (ADHD) product development. More on that in a future post, but I think we'll see best practices built on the following principles:

Aside: ADHD Development Principles

1. AI drives content, humans drive outcomes. LLM systems have notoriously poor critical thinking skills. Despite many application-level guard rails being put in place to prevent weird accidents, we still see stories critical problems accidentally making it to prod, when AI is given the keys. So at least for the time being (and my theory is forever, at least in some form) we will see humans in the loop to be accountable for outcomes.
2. AI amplifies force; humans grow in force. Because there is already a lot of content showing AI as a force multiplier, and junior engineers don't get as much out of AI systems, we will see a lot of ill-advised business laying off junior engineers, whereas the forward thinking businesses will specifically invest in junior engineers. More internal mentoring, some techniques for using agentic tools as teaching instruments for juniors, and so on. Below is a thought from someone working at Cursor, showing that senior engineers tend to get more out of agents at this time. His conclusion? "Coding agents amplify existing engineering skill, not replace it." The natural conclusion is that human engineering skill is still critical, so companies that want longevity must invest in growing juniors into seniors.

1. No tribal knowledge. In order to handle the rapid context switching that comes from ADHD Development, both people and agentic tools must have quick access to all relevant information about tasks, software architecture and design, and so forth. That way, engineers and agents both can operate without specific long-term context (i.e.tribal knowledge), liberating both parties to have broader reach. As such, we'll see better in-code documentation, more use of tools like UML to articulate software, and
2. Best practices are the new standard practices. Most best practices were designed to reduce risk and cost wherever mistakes and errors are possible. LLM based tools are a double-edged sword in that they can generate content much more quickly than humans, but also introduce a new point at which mistakes and errors can enter the workflow. Most best practices are often punted on because they take too much time, and humans can operate with long-term context (tribal knowledge). Agentic tools still can't, at least for now. Following best practices create a positive feedback loop with LLM based code generation, where the code generated is better and less error prone, which unlocks more time to follow best practices. It's a positive feedback loop.
3. Build up, select, carve down. LLMs generate content rapidly, but not necessarily the right content, and not necessarily with the focus of an experienced engineer. So we will likely see engineers use agentic tools to audition multiple approaches to the same problem, perhaps even simultaneously, select the best approach, then simplify and normalize the solution. This is already the norm in many other fields, and now that code is "free" we'll come to view this technique not as an unnecessary engineering cost, but a normal part of existing paradigms such as emergent design.

Conclusion

We're in a time of significant upheaval in many industries, due to the AI renaissance. And while there's almost certainly an AI bubble (after all, making it easier for people to actualize ideas doesn't necessarily mean there are more good ideas), the tools are also triggering paradigm shifts in how people do valuable work, and what work is valuable.

If you're lucky enough not to have been laid off since this paradigm shift started, and you think you don't need to bother using agentic AI tools, you are simply wrong. Here's a brief list of big-name software people who have used "vibe coding" to work on projects, with positive opinions.

If you have been laid off and can cough up the coin to start using agentic tools like Claude, now's not the time to despair – instead, use the new tools and show what you can do with them, refresh your portfolio and resume with all those annoying AI bubble keywords you've been dreading throwing in there, and you may find yourself with a job again soon. Or maybe better: one of your software projects might take off.

The Creator of Ruby on Rails: DHH

Promoting AI agents

At the end of last year, AI agents really came alive for me. Partly because the models got better, but more so because we gave them the tools to take their capacity beyond pure reasoning. Now coding agents are controlling the terminal, running tests to validate their work, searching the web for documentation, and using web services wit…

The Creator of node.js: Ryan Dahl

The Creator of Redis: antirez

Replace fast_float C++ library with pure C implementation by antirez · Pull Request #14661 · redis/redis

The fast_float dependency required C++ (libstdc++) to build Redis. This commit replaces the 3800-line C++ template library with a minimal pure C implementation (~260 lines) that provides the same f…

GitHubredis

The Creator of Linux: Linus Torvalds

GitHub - torvalds/AudioNoise: Random digital audio effects

Random digital audio effects. Contribute to torvalds/AudioNoise development by creating an account on GitHub.

GitHubtorvalds