People (not just old men) are yelling at LLMs to build the thing they have in their head. No longer hindered by not knowing how to build a website or set up a server, they are speaking into existence exactly what they imagined. Vibe coding. Proompts engineered.

This is exactly why everyone hired engineers in the past and now they free from requirements documents, technical specifications, meetings, humans. The role of software engineer and perhaps even wider swaths of the organization can be replaced.

But Seriously

Why did the company founder hire that first engineer, and then a whole team of them? Was it to take words and make them working product? Yes, this is table stakes for a software engineer. Was it only that? No. Here are a few scenarios they hired that software engineer for:

• It’s 11:19pm on a Thursday and for some reason the website stops responding.
• A new feature on the landing page makes the contact link stop working.
• Customers are confused by the purchase page and fail to finalized their purchase.

In short, they solve problems. And they solve problems in real time, in the context of the company culture, product, and constraints. They don’t need constant meetings with the CEO to do it. They are professional software engineers who have seen similar problems before, seek to understand their customers and products, and deliver solutions in a way that AI is still not able to do.

Future generations

Companies are helping train better LLMs for future use (and purchase) rather than training junior engineers in the craft of solving software and product problems. There is no guarantee that your junior engineer won’t move on to another company after you have invested in them but there is certainly not a guarantee that Devin.ai will give you a discount next month because you help build their model. However, centralizing on a handful of LLMs consolidates control of price, creates single sources of failure and in many other ways puts all your eggs in one big opaque basket going forward.

Training the next generation of software engineers alongside your most senior engineers, who can see LLMs as another tool in their tool belt, will pay dividends across the entire landscape of software and product development. It will provide the diversification of skills required for your particular business at exactly the right time. Not with a pricey one-size-fits-all solution but with a real human being who is passionate about their craft and has been trained for exactly this purpose.

If I have seen further, it is by standing on the shoulders of Giants - Isaac Newton

None of us create something from nothing; we are shaped by those around us, both personally and professionally. We assess our strengths and apply them to the task at hand. We co-create with others on our teams and bring to life a product or service that had not existed before to help those around us.

We make plans to wrangle the upcoming problems and build solutions to overcome them. Sometimes, we anticipate obstacles and prepare accordingly; other times, we adapt to unexpected issues. In either case, our goal remains the same: to work more efficiently, produce meaningful results, and continuously improve our products—and our teams. We strive to bring order to chaos, to subdue complexity, and to serve more people through our efforts.

We also bring expertise and craftsmanship to our work. We refine our skills, seek more effective methods, and embrace best practices honed over time. Whether in software development, medicine, construction, or any other field, we don’t settle for the first idea that comes to mind. Instead, we push forward, building on yesterday’s knowledge to create something even better today.

When reviewing feedback on AI-assisted (or AI-generated) code, it often mirrors the feedback given to more junior developers—it’s all about context. One common issue is the rise of duplicate code, as AI tools lack full awareness of the repository’s structure. The solution? The same approach used for junior developers: broader context. If a module already exists that accomplishes the same task, it’s usually best to use it (applying DRY principles at the right level of abstraction). The AI Jr. Dev often struggles to balance maintainability and delivery effectively.

Starting with the belief that everyone deserves dignity and respect is fundamental to creating a great culture, whether in software engineering or any other field. We are born into a shared humanity, beginning life in circumstances beyond our choosing, gifted with abilities through no credit of our own. We did not select our parents or our starting positions, so I am deeply grateful for everything I have been given from the outset.

The strengths we do have should be cultivated, which is why I take a strengths-first approach to leadership. I do not claim to be the best in every area of life, nor would I expect my team to be. That is the value of a team—we bring unique, complementary strengths that, together, drive us toward a greater goal. My focus as a leader is to develop my team’s strengths while supporting their weaknesses through tools, collaboration, and strategic delegation. I do not expect areas where someone performs at a C- level to become A+ work suddenly. Instead, I emphasize helping them refine their strongest contributions—turning A- work into A+—and giving them opportunities to lead in those areas, ultimately strengthening the entire team. People often feel the most passion and fulfillment in these areas of strength.

As strengths are mastered, greater autonomy becomes possible. This autonomy is built on trust that team members can own their work while contributing to the team. Daniel Pink’s autonomy, mastery, and purpose framework, outlined in his book Drive, highlights how these elements foster motivation and productivity. When individuals understand their purpose within an organization and in the broader context of their lives, they are better positioned to recognize and respect the purpose of others, reinforcing a culture of shared dignity.

With this perspective, I approach my work with gratitude. I respect the strengths of those around me and dignify their contributions by granting them autonomy anchored in a clear and meaningful purpose.

This weekend, we had friends visiting from out of town. While waiting to see what my next job opportunity might be, I reflected on the “productivity” of this time. We talked, laughed, ate, and enjoyed each other’s company. Their daughters loved spending time with ours. But I couldn’t help but wonder: Was this a productive use of my time? Should it be? How does it compare to “work”?

Let’s start with the obvious: spending time with friends doesn’t pay the bills (though they generously shared meals with us). Providing for my family is my responsibility, and this weekend didn’t fulfill that directly. Yet, few of us measure the value of a job purely by money. Instead, we aim for work we enjoy, where we can make a meaningful contribution.

So, how do we bring value to the world? Through our talents—unique gifts we use to improve the lives of others. In our jobs, we amplify these talents by collaborating with people who bring their own strengths to the table. Together, we create products or services that help others achieve their goals.

This weekend, we dined out a few times and were struck by how the care and effort of the cooks and servers enhanced our experience. Their work brought joy to our time together. Similarly, while my friends and I didn’t earn money during our time together, we enriched each other’s lives through connection and love, without a team, meetings, or specific career skills.

As I look for my next role, I hope to mirror this: improving the lives of those around me by contributing my talents through a meaningful product or service. In a way, my weekend was “productive”—not in the traditional sense, but in the same spirit as a fulfilling workweek.