Dev Skills for the LLM Era
There are certain skills software engineers can practice to further differentiate themselves from LLMs.
Books I am reading to uplevel my people skills
In my last post, AI: Accelerated Incompetence1, I claimed that LLMs can't replace human software developers, but I also wrote "there are certainly things you can do to further differentiate yourself from an LLM". In this post, I want to elaborate on the things I am doing to keep myself indispensable in the LLM age.
Chronologically, my focused journey to develop these skills began in 2023, before LLMs were quite as ubiquitous as today. In 2025, I have redoubled these efforts.
People Skills
As a younger dev, I wanted it to be true that people skills didn't matter in software engineering: I viewed emotion as a distraction, preferring to get right to the important stuff like defining requirements and writing code. However, as I've gotten into the mid to late years of my career, I've come to understand that awareness and management of my emotions and those of others is at the center of professional work.
If you don't believe me, go scroll through /r/ExperiencedDevs on Reddit. I see more posts about people problems than code or architecture.
If there's one thing a computer program can't do, it is offer genuine connection and empathy. When an LLM says nice things to me, it feels disingenuous. When a human uses kind words, it stands out. It makes me like them, and I feel like there's some good in this life, and I want to pass it forward.
At work, when you don't have any positional authority but need to collaborate, the best card in your hand is that people like and trust you. If you do have managerial authority over people, it's still in your best interest not to default to command-and-control schemes. As a leader, your example sets the tone for everyone else.
I've often half-joked that the best thing I've done for my career is get married. Why? My wife loves to talk. Not to make noise, but as a means to connect with me on an emotional level. Younger Doug thought that words were merely for communicating information: e.g. for filing taxes, reading documentation, or writing requirements specifications. I now understand that I can talk to people to, you know, make them feel cared about and to allow them to care about me.
To that end, a couple of weeks ago I went on a binge and bought these books, pictured above:
- How to Win Friends and Influence People by Dale Carnegie
- Emotional Intelligence by Daniel Goleman
- What Makes a Leader by Daniel Goleman
- Getting Along by Amy Gallo
- Dealing with Conflict by Amy Gallo
Whether its with these books or other resources, improving your people skills is not only likely to benefit your career, it might make you a happier person.
Managerial and Communication Skills
Each of us is now a supervisor of machines. I never wanted to be a manager, but thankfully, there is a large body of knowledge for managing people. We just have to contextualize it to machines.
What is different about managing LLMs vs people?
With people, there is relationship, mutual trust (or lack of it), and shared context. Machines have none of that: there's only your prompt, the system prompt, the context window, and the model's training. Moreover, the model doesn't have feelings and doesn't require feedback and growth.
One of the most important aspects of management is communication.
LLMs are poor communicators, so you have to make up the difference. Unlike a talented direct report, LLMs don't yet seem generally able to ask the question-behind-the-question or to infer a larger context behind a prompt, or even ask for clarification.
For LLMs, the medium of communication is writing. Therefore, it's important to think clearly and write unambiguously. Be explicit, specific, and clear; and ask the LLM to respond the same way.
Before prompt engineering was a term, we had technical writing. I recommend you review Google's free courses2.
Advanced Software Engineering Skills
Look for ways to advance your software engineering skills.
Now that each of us commands a team of fast, confident, often wrong virtual engineers, we can move up the value chain of engineering. LLMs buy us time to do more important things. We don't need to update the package dependencies by hand. We can ask an agent to, and with the time saved, we can talk with users or focus on refactoring the notification platform to an event-based architecture.
Where can we go to find advanced training in software engineering? Personally, I turn to books and courses. Paid courses are an excellent opportunity to differentiate from LLMs because being behind paywalls, their content is not scraped up with the rest of the publicly accessible internet. Books, legally or not, are more likely to be in the training dataset. Courses usually get you introduced to the instructor, whom you can reach e.g. by chat or email.
Books
It's easy to rattle off a list of books. Here's a curated list that I have actually read, studied, applied in my work, and recommend to you:
- A Philosophy of Software Design by John Ousterhout
- Grokking Simplicity by Eric Normand
- Working Effectively with Legacy Code by Michael C Feathers
Courses
In 2023, I bought access to Jimmy Koppel's Advanced Software Design course3. It's been well worth it. The course touts these benefits, among others, which I can attest to:
- Rise above subjective debates. Give concrete suggestions your team will understand and respect
- Escape software influencer dogma. Get your own compass.
For a sample of Jimmy's teaching, have a look at his blog, for example this post4.
This year Udi Dahan made Distributed System Design Fundamentals course5 available free of charge. The full course is pretty expensive, so it's a fantastic opportunity. Some experienced colleagues of mine took it years ago and rave about it. I've just started it this week.
Business Skills
My position in this post and the last has been that LLMs can't replace humans in skilled thought work. If your employer disagrees, there's one sure move you can make: you can employ yourself.
Yes, running your own business is allowed, and get this: customers don't care whether you use AI or not to make a product or service. They only care whether you solve a pain for them.
In 2023, I started a nascent software business. I quickly did what you're not supposed to do: I built a product based on a "cool idea". Instead of first finding customers and validating my idea, I jumped right in to coding. I spent hundreds of dollars and six months of nights and weekends. In the two years since, FitEdit6 has earned a few hundred dollars. In December 2024, I repeated the mistake with Linklever7. In six months, it's made about $40.
I'm doing it a better way now. I'm breaking out of the "fail cycle" of building before validating. Last year, I bought access to Rob Walling's course The SaaS Launchpad8. This year, I bought access to Amy Hoy and Alex Hillman's startup course 30x500 Academy9. These courses are teaching me to focus on customers and marketing before writing a line of code.
In February 2025, I was fired from my job. No LLMs were involved. I was grateful to be welcomed back to my previous job, but I resolved then that I wanted more financial security. A salaried engineer is a business with one large customer. I'd rather have 500 small customers. My goal is to build a product business that earns me financial independence.
Conclusion
Fellow dev, to stay economically valuable in the LLM age:
- practice soft skills and emotional intelligence. Most of engineering is human interaction.
- learn to write clearly. You're a manager of machines now.
- focus on deep expertise and system-level thinking. That's your bread-and-butter. Machines can handle the boring parts.
- consider starting a business. Then you can decide what mix of LLMs and humans to employ. Beware that coding is just one small part.