I remember what it was like when I first started making things on the computer. I can’t even say they were websites or even code at first. I recall using a program called ResEdit on my dad’s Mac Plus to mess with icons and game resources. Tweaking randomly until something worked. I couldn’t reproduce the patterns that led to success but tried very hard to make sense of them.

Recently, I started working with my daughter on a Raspberry Pi hooked up to a kit car. The directions weren’t great; the most helpful piece of documentation was a YouTube video that moved too fast and was out of date. But we eventually got it working. I shared with her the thrill of repeated failure leading to a flash of success. The 10,000 ways to not make a lightbulb, until we did.

I had a similar experience the other day. I was working on some code and asked an AI agent to build a starter project for me. It worked like magic. I looked it over and wanted to tweak the colors a bit. I poked at it myself but ran into another issue, so I gave it back to the agent. Of course, anything I updated was tossed out. Any slight improvements were one-shot over by the AI. And in some cases, it didn’t even retain its own previous work. I haven’t tried every AI agent or assistant available, but there’s a larger point here.

I was a solo developer in this case, trying to keep my own context while letting the AI write a large chunk of the initial project. If you asked me to explain how the code worked after multiple AI rewrites, I couldn’t without rereading the codebase and reacclimating myself to all the pieces. You often find engineers, and I am not immune, who optimize for code-writing over code-reading, and it was no different here. If I had been on a team, there would have been even more changes evolving the codebase in ways that could cause previous features to disappear. Something I understood yesterday could look completely different today.

This has been a bit of a gripe session about AI-integrated software development so far, but like I said at the beginning, there’s still some magic. For agencies and contracts built around one-shot projects, it’s a perfect fit. Need a website for a one-time event that no one ever needs to maintain? Perfect. Understand that, as has previously been the case, we may need to incur technical debt because of present market pressures? Okay. Need some inspiration or help with a particular error or library feature? Go for it (though I’ve often found that just reading the documentation is more helpful so far).

AI-integrated software development is what everyone is talking about right now. Autocomplete has been a staple of the software engineer’s toolkit for years, and an even smarter autocomplete will be that much more helpful. Tab-completing all the standard method and class documentation? Yes, please. This integration process will be an interesting adventure, one that will require iteration, just like everything else professional software engineers do.

Let’s start iterating, learning, and having our minds blown when things go right (and when they go wrong). I’ve always believed you should understand something before you tear it down.

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.” - G.K. Chesterton

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.