Software Problems are Still Usually People Problems

LLMs and their integration with software engineering have really shaken up the industry and led some to comment that it all means software problems are no longer people problems. Based on my own experiences with LLMs and in the industry, I’d argue that now even more than before, software problems are largely people problems - in this post I’ll go over why.

People and Software

Most of the best managers and leaders I’ve known have always known the truth: technology problems are usually largely people problems. That isn’t to say that software doesn’t need extremely skilled technologists with a lot of capability, nor that it doesn’t require specialized skills, but just that ultimately at the end of the day it is a team and group endeavor, and so reduces to needing to get people working together to deliver an outcome that other people will use.

The reasoning behind this was something I grasped pretty quickly as a neophyte engineer, I saw it like this:

• People use software
• People describe software
• People make decisions about software
• People build software
• People are responsible for software

People are involved in every step of that process, so even if someone was not ready to go as far as to say that software problems were people problems, most people would at least admit you couldn’t escape involving people.

Some people have started to challenge this viewpoint.

People, LLMs, and Software

With the explosion of LLMs, particularly agentic systems and those that are being used for writing code, the perspective that people are inevitably part of every stage of software development has begun to be challenged. I’m not surprised, and I understand why: LLMs are absolutely changing the industry, regardless of how one feels about it. Here’s a short list of some of the things LLMs are now commonly doing in the industry:

• LLMs are now being used to write product requirements, doing some of the workload that PMs used to do.
• LLMs are now being used to write some of the code that engineers used to write on their own.
• LLMs are now being used via agentic workflows to perform some of the operations work that engineers of various sub-disciplines used to do on their own.

The conclusion a lot of people draw from this is that increasingly, AI is displacing humans out of the loop, and that the problems we’re facing are no longer people problems, but rather all AI problems. I disagree.

Even with all of this, I would argue that the people aspect of the work has never been more prominent. LLMs can only act on their context, and their context window is finite.

• LLMs can write product requirements, but they can’t evaluate if it solves the actual problem that originally needed solving, only people can do that. This means this problem space becomes more people driven, even if there may be less work.
• LLMs can write code, but they can’t consider the overall impact of their code on things outside of the context window. This leaves engineers to do all of the non-coding parts of their job even more than they do today because that portion of it isn’t being done when they write the code.
• LLMs can use software via agentic workflows, but ultimately they cannot know if their final output or use of this tooling is accomplishing a human goal, they lack the context for this. Only humans can confirm this and ensure that the overall way that LLMs are moving complies with the needs of the organization.

There’s one last and very critical point that makes me sure that even if the above changes, the people problems are not going anywhere.

Engineering and Accountability

Ultimately, writing the code has always been a small portion of what software engineers do. The same applies to product managers and writing requirements. The more LLMs take on the coding work, the more work that engineers do is going to be focused on the other, and arguably more important, functions we perform: evaluating risks, designing for scale, managing the lifetime of the codebase, thinking about the future, balancing tradeoffs, and ultimately being accountable for the final product.

That last one is important, because it is the fundamental reason that I don’t see the people aspect of all of this going away even with more advanced LLMs. To put it simply, LLMs are not capable of being held accountable.

I mean this in multiple senses. Accountable to peers? If you’re using an LLM you still have to make sure you’re solving the actual problem that people are having underneath. Accountable to leadership? That’s on software engineers, regardless of if we use an LLM or not. Accountable to regulators? Good luck blaming the LLM.

Only humans can be accountable, and so humans leveraging LLMs have an ethical and in many cases legal obligation to make sure the things they’re producing are solving the problems of people, not just the problems the AI made up.

The Future

People remain integral to software engineering, and software engineering problems can still largely be seen as people problems. The more we automate the code writing details, the more they’ll become people focused. Furthermore, accountability itself is something only humans can possess, and remains a deeply human and people focused part of the job.