Am I a software engineer again?

I was hosting an AI roundtable with business school classmates recently when one of my classmates asked in a very direct but also very friendly way, "What is it that you do? Explain this to me." Fair question. Not because I don't know what I do, but because the labels themselves have become complicated in the age of AI augmentation.

As I've been providing AI expertise to people for hire, it has been a journey with two distinct threads. The first thread is my mission: I feel like I live in the future and I want others to have the capacity to execute the way I'm executing now. To leverage these tools, perform research faster, build prototypes, automate tasks, and experience this augmentation. This led me down the path of becoming an AI coach.

You might notice (or probably won't, since I'm not the center of your life APPARENTLY) that my LinkedIn now says "AI Transformation Consultant" rather than "AI Coach". Initially, I set out to show people how to use these tools. I found that the vast majority of people don't seem to want AI coaching.

The way I internalize this is that coaching is abstract. People don't want a personal trainer. They want to be fit. They don't want to show up to the gym every day and do the work. They want the six-pack. Similarly, people want the benefits of AI, but the packaging and selling of AI coaching is much more difficult.

The Vitamin vs. Aspirin Problem

Through this process, I discovered that while AI coaching was difficult to define and sell, the most effective help I can provide is solving today problems. It's identifying tasks that either they couldn't do before or that consume significant time and then automating those tasks to provide greater leverage and revenue.

There's a phrase in startups: "Is this an aspirin or a vitamin?" A vitamin is something people think is good for them. An aspirin alleviates serious, present pain. It's hard to get people to take their vitamins but when you need an aspirin that's hard to forget. AI coaching is a vitamin for many right now. Solving revenue-unlocking problem is an aspirin. Always has been.

The Identity Question

As I navigate this reality, I struggle with a question: am I a software engineer again? I actually spent some time turning down work because of it.

I have a CS undergrad. I worked as a software engineer at the beginning of my career. I went to business school, and I've been in product management ever since. My hesitation stems from a simple truth: I know software engineers. I work with software engineers. That's not what I've been doing.

Even as everyone proclaims that "everyone can now be a software engineer," I held back. Yes, I agree everyone can build. But not everything everyone builds should be deployed to production for widespread use.

What I've discovered, or been reminded of, is that there's immense value in software that doesn't need to scale. Software can be useful even if only one person uses it.

Software for One

Last week, I built a script that connects to the Gmail API, extracts specified emails, and converts them to markdown. I use it when preparing proposals for potential clients based on our email discussions. It formats everything perfectly for Claude Code or ChatGPT. Only I will ever use this tool. Yet it saves me hours and enables me to create more thoughtful, comprehensive proposals.

This is the kind of software anyone can now write: highly specific, personally valuable, and completely ungeneralizable. Before AI tools, the effort to build such a tool would have exceeded its value. Now, I can create it in hours. This fundamentally changes what's worth building.

The Blurred Lines

The identity question becomes more complex when I consider my recent work. A week ago, I went on a GPT-5-fueled binge to build a web application for my nonprofit client. A desire to kick the tires on this new model kind of got out of hand. I built the entire web app. We're shipping it to production. It's vastly better than their previous solution and directly drives revenue.

Did I build software? Absolutely.

This week, I collected all my meeting transcripts, proposals, statements of work, and emails in markdown. I opened them in Claude Code and generated "case studies" to summarize my work. From there, I generated updated messaging for my LinkedIn profile and content for landing pages. I then used meeting transcripts and emails from potential clients to create reengagement emails tailored to their specific needs.

Did I build software? Not exactly. But I leveraged software building tools (Claude Code) and created software to enable the effort (my Gmail to markdown tool).

The spectrum of my work becomes even clearer in another engagement. In addition to some GEO (Generative Engine Optimization, how you show up in LLM queries) and content analysis, I've been working with a leadership team on what the future of software products for software engineers looks like in a world where, increasingly, people don't engage with the tools directly, but they engage with AI that then manipulates the world through tools (APIs, MCP servers, CLI apps).

Am I building software? Nope. Not at all. But I couldn't have had that perspective without being immersed in the tools and the space.

Then there's my current engagement where I'm building voice agents for a client to augment their team's process, helping them reach out to apartment buildings about availabilities at scale.

Am I building software? Sure, but a lot of that is more on the side of crafting prompts and building AI tools. I feel like this could go either way.

These varied engagements, from building to strategizing, reveal something fundamental about where we're headed.

Beyond Labels

The fundamental shift I'm recognizing is that "AI" will eventually just become software. We now have the capacity to build faster and include elements that were previously impossible for regular developers to implement.

I created a workflow for a client to triage their email inbox, determining which emails should be forwarded to clients and which should be processed internally. Right now, this feels like a novel "AI solution," but it will eventually be as standard as mobile development became.

Perhaps the real answer is that software engineering remains a senior discipline to what I'm doing, but there's now a different variant emerging. Or perhaps I shouldn't be caught up with labels at all.

What matters isn't whether I'm a software engineer. What matters is that I'm helping people solve real problems with tools that didn't exist two years ago. I'm navigating not just the technical challenges but also the human ones: how to package these services, how to make the value tangible, how to meet people where they are rather than where I think they should be.

The label might be unclear, but the value isn't. And in a world where AI is rapidly redefining roles and what's possible, maybe that flexibility, that ability to be whatever the situation requires, is exactly what's needed.