The Evaporation of Software Engineering (and the Rise of the Agentic Builder)

Your identity was built on a bottleneck.

If you’re like me, you likely thought software engineering was a safe and secure job …

In fact, I never thought I’d have to worry about a job again as long as I stayed on top of my craft…

I was dead wrong.

On a very particular day in mid-2025 I knew that my career had shifted, and by now, you’re also witnessing this shift firsthand.

From 2024 to early 2025 I was using AI-assisted coding tools like Copilot and Cursor as glorified autocomplete tools in my day-to-day coding. They were a nice productivity boost.

Then, in July of 2025, three things happened.

Number one: I kept hearing all the hype around how amazing all these coding tools were, but I wasn’t personally witnessing it. I wanted to really see what AI coding tools were capable of, so I set out to build a full SaaS (Software as a Service) application without writing a single line of code.

Well, I did it and it worked.

That was the origin story of this post.

I still remember the visceral feeling I got from seeing an AI agent do things that I’ve spent the last 20+ years honing my skills to do.

This is when I first felt the ground move beneath my feet.

Number two: AI was great at greenfield projects (new projects) but it struggled greatly with complex legacy applications.

This was the moat many engineers attached themselves to, and they’d say things like “AI can never solve these complex problems, we have nothing to worry about.”

I was highly skeptical, so I set out to test this hypothesis while working at Tinder.

In July of 2025 I wrote a reusable prompt (which we’d now call a “Skill”) that was about 2,000 words long and read like an instruction manual for how to handle a very challenging software library migration. We needed to do this migration hundreds of times across the code base. We were moving from one threading library to another, and every instance had its own edge cases. This would take an engineer 6-8 hours to complete successfully each time.

With this prompt, AI did it in 10 minutes … and it was correct.

I remember the exact moment the agent said it was done and the tests passed. I double-checked the work and it was right. It was done.

I was in shock …

I pushed my desk away from me, stood up in disbelief, and immediately went for a walk to clear my head. The world changed for me that day.

I still remember that instant like it was yesterday.

This was the moment that I knew things were over as I had known them for 20+ years.

Number three: I started seeing non-technical people with zero software development experience build real software that solved real problems.

I know a CFO of a mid-sized company who built a complete financial operations tool that now runs the company’s complex financial systems. He used AI to build the entire thing.

It was the tool that he wanted and had in his head for years, and now he has it.

When he showed it to our team it resembled a very highly customized solution with multiple integrations, systems that operated on a schedule (cron), aggregation of financial data, custom modeling, etc. It was a CFO’s fantasy realized.

The crazy thing?

He’s not technical, not in the slightest. When I asked him where the code was he said “I don’t know” (which is another problem in itself). He had built it with the Claude desktop app. That’s it. We eventually figured out that it was already stored privately in a git repo, but still … this goes to show that he prompted his way to a product that would have taken engineers a LONG time to build.

Another example: a friend who owns a gym recently built his entire coaching and nutrition platform from the ground up, integrating with clinical scanning systems and more. It was so impressive that his integration partners are trying to convince him to white label it (sell it under their own brand).

He then went on to build an iOS app, integrations with the national food database, and more. He has agents that process data from health systems nightly and build a RAG system (Retrieval Augmented Generation) so that his team can ask it questions when he’s not around.

He’s curated his own replacement as a way to scale his business.

It’s mind-boggling.

Again, this guy has no technical chops. I walked him through how to prompt Claude and he’s figured the rest out, just by asking Claude.

Engineers were not needed to build these things.

All three of these things illustrated the same core principle …

It was never about coding, it’s about the ability to execute.

The ability to execute has always been the separator between the dreamers and the doers.

Coding was just a gatekeeper.

As a software engineer, especially one who is over 40 and who’s spent 10-20+ years building and honing their craft (like I have), you have a bit of an immediate identity crisis that’s very anxiety-inducing.

If you write code, run product, handle marketing, or built your career on specialized knowledge, the next 6 months will define the future of your livelihood.

Specialization used to be the safe bet … now it’s a risk.

“Specialization is for insects.” - Robert Heinlein

The thing is, hyper-specialization in tech was always a risk.

Even though tech “moved fast,” it was still rather slow, as it allowed you to stay within a specialization lane for years at a time, shifting into new specializations over the years.

But if you stayed too long in one technology, you became pigeonholed and got stuck. You have to adapt.

I also fell victim to the hyper-specialization trap myself, eventually being labeled as a specialized Android expert for over 10 years.

I felt the pang of anxiety of being pigeonholed into an industry, and then I formulated a plan and escaped, not once, but twice.

In other words … I’ve seen this movie before and I know how this plays out.

So … who wins the next 6 months? Engineers? Product people? Someone else?

Everyone is asking it, but it’s the wrong question.

The real question is: what makes you valuable when execution is nearly free?

Your Job Is Evaporating, and It’s Taking Your Identity With It

“Identity is this incredible invisible force that controls your whole life. It’s invisible, like gravity is invisible, but it controls your whole life.” - Tony Robbins

If you’re like most software engineers, you’ve attached yourself to a technology, a programming language, or a framework, and now the foundation on which you’ve built your livelihood is shifting (AI is taking your job). You’re starting to worry about your future, and at a root level you start questioning yourself and your identity.

That anxiety is real, and it’s one I’ve felt before too.

When someone asks what you do, you might say you’re a “Software Engineer” or “Software Developer,” and if you’re hyper-specialized you’ll include the specialty in your description too.

Here’s something I used to say when asked this question:

I’m an Android Developer who has built some of the biggest apps in the world.

That was my reply to the “What do you do?” question for years.

You have a very similar version for your own story. You’re likely reciting it in your head now.

For me, it wasn’t “Software Developer” or even “Mobile Developer,” it was a hyper-specialized version of those - “Android Developer,” for nearly a decade.

My identity and my ego were attached to my work, and yours is attached to yours.

Your identity is layered and rooted in psychology and social science. Understanding this will allow you to reshape how you see yourself so you can learn how to progress and move on.

Occupational Categorization

What we do in the world is often an indicator to others of what we know, what we can do, how we spend our time, where we fit socially, and what others can expect from us.

This is known as occupational categorization, which is a form of social categorization. It is the cognitive act of sorting someone into a social category based upon what they do for work, such as “Android Developer” or “Senior Rust Engineer.”

Occupational categorization is important because it allows us to compress a very complicated description of a person into a usable mental model. We don’t have to think about the finite details of this person, their interests, their fears, their day-to-day life, etc.

We use occupational categorization to make things simple:

Henry is a Doctor, Richard is a Real Estate Investor, Bob is a Mechanic, Donn is a Software Engineer.

We all do this. You’re doing it right now. You’re thinking of your parents, your friends, and coworkers and identifying how you see them. You’ve already got them categorized. This is second nature to us and we don’t even think about it.

We do the same thing in software engineering. These are what we call “design patterns” in software, and they’re merely a meaningful categorization that allows us to short-circuit our communication without having to spend time explaining the minutiae every time.

Occupational categorization shares that attribute - it’s a short-circuit way to identify someone’s capabilities and where and what they do in the world.

When you categorize someone you make assumptions about them, what they do, how they act, etc. This is why you’re surprised when you learn that Suzi, your neighbor, who is a dentist, is also a world-renowned calligraphy artist. Your mental model of her was that of a dentist, and it gave you a compressed viewpoint of where and how she fit into society based upon you seeing her as a dentist. Calligraphy artist though? That one was surprising.

I’ve had this happen more times than I can count. I’m sure you have some situations you can recall as well.

The short of it is that using categorization helps us organize and simplify how we see the world and the people within it.

So how does this relate to you, your job, and AI taking over your job?

Social and occupational categorization is heavily correlated with how we see ourselves in the world.

So when you think of yourself as a “Software Engineer” or an “Android Developer” or the “Blockchain Engineer” or whatever it is, you’re already placing yourself into a socially recognizable grouping. You’re self-categorizing.

This is part of your identity because “Being a Software Engineer is part of who I am,” and that’s not a lie. I think that’s pretty hard to argue with. Writers see themselves as authors, physicians see themselves as doctors. This is common in the world.

Professional Identity Centrality

Professional identity centrality is when your profession becomes foundational to how you see your value, competence, and place in the world. Your work is no longer simply something you do. Your work becomes a major part of who you believe you are.

This is you saying something like this:

Being a Software Engineer is one of the main ways I understand my value, competence, status, and place in the world.

Of course, this doesn’t happen to everyone, but I’d argue that most people are in this boat. You most likely identify very closely with what you do for a living, especially in the software engineering space. It’s a career track that has taken many years to achieve mastery, and it’s one that constantly requires you to sharpen your skills. It’s prestigious in a way. Most people do not accidentally fall into being a software engineer. It’s a hard profession to master. That is all part of your identity.

When your occupation is in jeopardy and becomes destabilized, your core identity is now also at risk. This is a very uncomfortable feeling. This is why software engineers feel very anxious and nervous about AI. It’s seen as an identity threat.

But there’s an interesting paradox that software engineers face (and many knowledge workers for that matter) …

You know deep down that if you don’t use the tools (AI) then you’re going to get left behind, but there’s a strong, uncomfortable psychological undercurrent that pulls at you and tells you you’re training your replacement (AI). This is very unnerving because you’re “damned if you do” and “damned if you don’t” when it comes to AI. Don’t use it? Get left behind. Use it? Get replaced. Ugh.

Talk about a Catch-22. Oof.

You may not be thinking these exact same things verbatim, but your primal lizard brain knows that there’s an identity risk here. You may even start wondering, “The person I have been all of my life may not be the person I can continue being.”

That thought has crossed my mind more than a few times in the last couple of years, and it’s left an empty, vacuum-like feeling in my stomach each time.

The reason for this feeling is that the thing you used to find meaning and identity in is being destabilized.

Your day-to-day work (writing code) is now being delegated to an AI agent, and that attacks your identity and meaning, and ultimately your purpose.

Finding Value and Meaning During Destabilization

Moving on from your previous identity to a new one can feel like running across a ship’s deck during rough seas.

It’s rough, it’s more than a bit scary, and there’s always a chance that you might not make it (well, that’s at least what your brain is telling you).

The good news is that there’s actually a way to weather the storm and come out even stronger.

The Leverage Pendulum and the Great Overlap

Prior to the emergence of usable AI for software engineering there were often two camps of people. There were the idea people / visionaries (the product people) and the builders (the software engineers).

The overlap of the people who could do both has always been quite small. Yes, there were the people who could design, code, and sell, but they were the unicorns of the industry - they existed, but they were rare.

Many overconfident software engineers will say that they can “launch a successful startup,” but it’s a statement full of ego and pride most of the time, because most engineers will build something and have no idea how to position the product, market it, or sell it.

A lot of software engineers have thought, or even said this out loud:

“I know how to build software. I understand what the customer wants. Therefore, I know how to build a successful software business.”

This is the Dunning-Kruger effect, applied to a domain. The less you know about something, the easier it looks, because you don’t know enough to see what you’re missing. They might know enough about engineering, but they don’t know enough about positioning, distribution, sales, customer research, pricing, messaging, etc. to even recognize the sophistication involved in these disciplines.

I’m not talking down about software engineers here. I am one. I’m speaking from experience, and I’ve been the one who’s said the same thing above, but then had to go figure it out to make my products successful. It’s not exactly easy.

The thing that most engineers do not recognize is that the development of a software product has always been 30% of the problem. The remaining 70% of the problem was positioning, marketing, and sales.

That’s the core principle I’m illustrating here. There are only a handful of people who are good at “product” but also good at engineering - the unicorns. These cross-functional operators are usually the ones who became entrepreneurs and founders.

These are the people who could see a hole in the market, or a way to combine systems and products in novel ways, and knew what needed to be built, but also had the ability to build it, market it, and sell it.

Well-known and very big names that illustrate this include Elon Musk, Mark Zuckerberg, Larry Page, Jack Dorsey, etc.

The percentage of people who are like this is very small though. Most people you meet in this industry are either great engineers or great product visionaries, and they might have a little chops in one direction or another, but they’re still quite limited in either direction.

This meant that the pace of a software project was largely dictated by two things: the amount of engineering capacity available and the speed at which those engineers could execute.

When juxtaposing product and engineering in this scenario, much of the leverage sat with engineering. Engineering controlled the pace of execution. Product would define what should be built, but engineering ultimately determined how quickly those ideas would become working software.

In traditional software engineering, the early product decisions swung the pendulum with great energy towards the product / non-technical team. They needed to design and make the product decisions. When it came time to build, the pendulum swung with great force to the engineering side of the swing. As product changes were needed, the pendulum swung back and forth, like a predictable clock.

Tick.

Tock.

Tick.

Tock.

That was software engineering and the SDLC (software development lifecycle) at a very high level when evaluated from a 30,000-foot view.

AI fundamentally changed this constraint.

One of the most persistent frustrations for product leaders and non-technical visionaries was the gap between the speed at which they could imagine, refine, and evolve an idea and the speed at which engineering could actually build it. This was often at complete odds. The product folks could easily envision something changing daily while the engineering took much longer to develop.

AI changed the game.

The time required to turn an idea into something tangible has collapsed with the assistance of AI agents. In many cases, the barrier to experimentation is now little more than access to an AI agent with a chat interface and an afternoon or an evening spent iterating.

What this means is that the leverage pendulum has begun to shift from engineering toward product.

Product leaders can easily create the product that they have in their head with AI now.

I’ve personally seen it multiple times now.

Software that should have taken a year or more to make has been created in a couple of weeks with a non-technical person in the driver’s seat commanding Claude or Codex to do the work for them.

This works great for the product people because they’re able to quickly iterate on an idea and get something tangible in their hands.

The early phase of product development leverage has moved from engineering to product via self-service AI tools. This is great for business iteration.

But where and how does it fall apart?

Complexity and Scalability - Where the Pendulum Swings

While you’re worried that software engineering is dead, the fact is that there is some nuance to it.

It’s not dead, just dead as we know it. It’s transmuting into a new form. The rise of the agentic builder is upon us. Let me explain via two real-world scenarios I have faced in the last handful of months.

The Financial Tool Written by a CFO

In the beginning I mentioned the CFO who had created a full revenue operations dashboard that was quite impressive.

The reason I was chatting with the CFO was that he was having trouble with Claude Cowork, where he had built the tool. He was no longer able to make updates to his app. Claude Cowork was throwing an error over and over.

When I asked him how long he had been working in this chat, he said “Two months.”

What? Two months in the same chat? Yes.

The same context, for two months. Compacting, then re-compacting, running all within Claude Cowork.

After some research and some confirmation with the support team at Anthropic, I learned that he had reached a limitation with the size of the chat and that he needed to start a new chat, because the virtual environment that Cowork was running in was hitting its size limits.

He wasn’t aware he could start a new chat and continue there, and he was worried the agent would lose too much of the conversation to move forward effectively.

The tool he built had been deployed to a PaaS (Platform as a Service) provider that we use, via some internal skills my team had built to help facilitate the deployments of internal vibe-coded apps. That was proof our systems had been working.

Upon reviewing the tool with him I asked:

Where is the code for this?

His reply?

I don’t know. I think it’s in Claude Cowork. I don’t really know. I just ask Claude to make updates and it does, and then I tell it to make it live and then it’s on this URL (some URL where it’s deployed).

His reply confirmed my assumption - while the leverage pendulum has shifted for early product development, it swung back the other way towards engineering when we went beyond the basics.

This brought up my question of asking where the code was, because I wanted to be able to tell the next Claude Cowork session, after the handoff, where the code was located so it could continue working. But he didn’t know.

After some digging, we found it on a private GitHub, thankfully, and it was up to date.

In the end this showcased where the pendulum shifted back to the technical expertise - myself.

A Photography Management Solution That Would Not Scale

The second example is from a local photography studio owner who had vibe-coded his own customer relationship management tool and workflow tool in a popular vibe coding solution, Base44.

He had built things I didn’t know were possible in a tool like that, all via prompting: one portal that replaced a handful of giant Google Spreadsheets and a pile of other tools. For the first time, he could see his whole business at a glance.

Now for the problem - his business stored the raw photos and videos from every shoot in a shared Google Drive, so he had the agent wire Google Drive straight into his new app.

The agent had walked him through where to set up Google Cloud projects, obtain API keys, etc. and how to wire it together, but it kept failing with random errors. Upload progress wasn’t working and he was running into tons of problems, so he asked me to take a look.

This also confirmed my assumption that while the early low-hanging fruit of creating an MVP (Minimum Viable Product) that is usable to validate an idea is now solved, at a certain point some agentic solutions need proper guidance. The agents will follow your lead, and if you tell them that you want to put this stuff into Google Drive, they will. Even if that’s the wrong solution long term.

Why is it the wrong solution? For his business the data transfer fees were going to be too high long term, especially if he wanted to white label this solution (which he wanted to).

Again, the leverage pendulum swung toward the engineering expertise.

I was able to guide him to a performant, scalable, and affordable cloud provider that solved his upload/download problems, integration problems, and more - all because I understand the economics of how these systems work and where and why you’d choose one over the other.

This was then validated by a simple analysis done by Claude when I asked it to juxtapose the solutions against each other to verify that the decision was correct.

As complexity increases and demand for scalability increases, the leverage pendulum swings back to engineering.

In these cases, a software engineer is needed to course-correct the AI agent’s initial implementations, and add systems, guardrails, and architecture that aid future agentic sessions so that they stay on the rails.

Once that correction is completed by the engineering side, the leverage pendulum swings back to the non-technical side, because they can now operate with a hardened solution that the agent follows, which allows them to continue to iterate quickly.

This process keeps going back and forth in an act of refinement, with software engineers acting as course-correction mechanisms in all types of projects. I’ve seen and experienced this numerous times now. Even with large mobile apps like Tinder, cryptocurrency solutions like Polygon, web applications, desktop, and many more areas of the software engineering realm.

Think of it like getting in shape. If you’re out of shape, just moving every day will make a big difference. Walk, do some pushups, and you’ll improve. That’s the agent with a blank canvas. It makes something out of nothing and the early gains are immediate. Then what worked stops working. You plateau, or you hurt yourself. So you hire a trainer. They fix your form, set up a program, tell you to stop eating certain foods. That’s the engineer stepping in: architecture, guardrails, hooks in the harness so the agent stays on the rails. Then you go back to doing the work on your own. You keep what the trainer taught you, so you need them less. Until the next plateau. Back to the trainer, shorter visit this time. That’s the pendulum. Each swing back gets smaller because you keep what you learned.

The Pendulum Swings Get Smaller

With each corrective iteration that goes from engineer to product, the pendulum’s momentum decreases. Less engineering time is needed as more guardrails, systems, architecture, and deterministic checks are added, and less product time is needed from engineering. The pendulum swing slows, but it never remains fixed, and if it does, it only takes a new model change to re-ignite energy into that shift.

As a pendulum swings it’s subject to what’s known as “damped oscillation,” which is just a fancy way of saying: with each swing it loses some of its mechanical energy due to various factors.

Now, initial leverage starts with non-technical individuals, allowing them to move fast, but when it comes to systems, architecture, scaling, and complexity, the pendulum swings back towards engineering, as non-technical individuals simply do not know what they do not know and need that help and guidance.

But with each iteration the agentic system gets better and the pendulum swing is dampened.

Leave a pendulum alone long enough and it will come to a center fixed position.

But what does this mean for software engineering?

Less of the work will be pure engineering or pure product.

The pendulum settles toward the middle. It won’t stay fixated there, because every new model release kicks some energy back into the swing, but the swings keep getting smaller until they’re just barely a quiver.

The new role is a blend of engineering AND product. Both, together - not either or.

It’s the engineer who thinks like a product person and the product person who thinks like an engineer.

These are the people who spot a problem and solve it. They don’t wait on another department because “it’s not their job,” they just get it done.

The “not my job” crowd is going to be crowded out by agentic builders - the doers.

The engineer who sees a problem not only with some horizontal scaling infrastructure, but who can also see that conversions are falling on a dashboard because the call to action is now below the fold, is the one who is going to be employed.

It’s the engineer who loves to build new products but shows up interested to learn the business, the how and the why things are the way they are, and then uses their technical skills to build amazing products.

It’s the product owner who knows conversion rate optimization like no other, who sees “the code in the matrix” and develops a solution with an agent to solve a typically manual or complex process, who is going to remain employed.

People standing at either extreme of the pendulum, the pure specialists, are at risk of extinction if they fail to adapt.

Remaining a hyper-specialized technologist with no business acumen means you’ll be left by the wayside by those that adopt a “think like a business” mindset.

Remaining stuck as the “idea product guy” with no builder or engineering foresight means you’ll be left in the dust by your colleagues who simply think of an idea and go build it.

It’s the same story, just different sides of the same coin.

But those who stay pigeonholed in their feel-good safety zones of what they’ve done for years, those are the ones at risk.

Does this mean that specialists are going to go by the wayside? Not entirely. There will be the need for a specialist to understand deep technical topics, but even these specialists will also be well versed in disciplines outside of their technical expertise. Everything in the industry is shifting to more of an agentic builder approach.

It means that traditional software engineering, how we have known it, is dying. The separate identified roles are going with it.

The future is not software engineers or product people - it’s agentic builders. It’s people who combine both the business acumen and engineering talent to get things done, to solve problems, and create value.

It’s time to become an agentic builder, a hybrid of both an engineer and a product/business person.

New Realms of Responsibility

So how does a specialist become an agentic builder without throwing away everything they already know?

Both of these paths include the same map, a two-step process for moving from your specialist mindset into an agentic builder who can scale beyond yourself, as well as help your company scale, while also enabling you to move in other directions. I’ve done this from experience, so I can attest it works, and I’ve mentored other people down the same path as well.

Step 1 is codifying your existing skillset into reusable templates, skills, documents, and procedures that you, other people, or more aptly - agents can execute. This is where you scale yourself.

I already know what you’re thinking …

But by doing that, I’m putting myself out of a job.

No. You’re not, you’re making yourself scalable.

You will develop systems around these tools as time progresses, elevating you from an operator to an orchestrator.

Step 2 is an exercise in moving from specialist-based thinking to systems-based thinking. This is where you start to encompass thinking like a business (if you’re an engineer) and thinking like an engineer (if you’re non-technical).

Ultimately, this is an exercise in cognitive complexity. This is where you grow to become capable of holding multiple, sometimes competing considerations simultaneously instead of reducing all your decision making down to your default specialist skillset.

From Engineer to Agentic Builder

As an engineer you are inherently good at coding, systems, architecture, scaling, reducing complexity, building guardrails, tests, determinism, and more. These are all things that an agent-first system needs in order to scale beyond any simple application or system.

All of these things, from coding best practices, architecture, systems design, test structure, validations, evaluations, and more can and should be built into reusable skills, agent files, or best-practice files that you can hand off to other people or agents.

Remember that prompt that I said took a 6-hour process down to 10 minutes? That was me codifying myself. That’s what you want to do here.

By doing this you’ll realize that you can then start composing these skills into full agentic harness-like systems to fully automate much of your own mundane work.

This is only phase one though, and it’s the easy part … the next part is much harder for engineers.

In order to branch into a full agentic builder mindset, the number one thing you need to do is release your grip on your identity with what you’ve done for the last many years.

The challenge here for most engineers is to let go of their identity being tied to a programming language, framework, or platform. Many engineers have deep-rooted self-worth and identities of themselves as a Rust Engineer, or iOS Engineer, or a Blockchain Engineer, etc. You get the point.

While those are very useful skills and you can still be an expert in them, one of the key components to thinking like a business is identifying the right tools for the right job.

Grasping too tightly to a technology, programming language, or framework is like using a hammer for everything. It works well in some instances, but not for everything. You need a bigger toolbox.

What this means is that sometimes you’ll have an agent write software using TypeScript and Next.js, sometimes that means using Rust, and sometimes that means a simple Bash script.

It may also mean that you’ll never touch your most-used language again. You have to be OK with that.

I spent 10+ years perfecting the use of the Kotlin programming language in the Android ecosystem. I even have a 9+ hour course on it on YouTube which has been watched over 150K times. I ran one of the world’s most popular Android podcasts for 7 years with my co-host, and we helped hundreds of thousands of Android engineers hone and perfect their craft.

But you know what?

I haven’t touched Android or Kotlin in over 6 months.

Why?

They’re not the right tools for the job in my current projects.

I’m using the right tools for the right job when they’re needed, even if it’s not something I particularly love.

Fundamentally, everything you’ve learned up to this point is a Lego building block. These Legos can be programming languages, architecture, or even systems. Your job when thinking like a business is assembling the Legos that you have at your disposal to solve the problem at hand in the most efficient manner possible.

In other words, use the right tool for the right job.

What this also means is that you have to adapt your way of thinking from a pure builder to a business mindset.

For example, you might be able to build a product because you know what needs to be built, but is that the right choice? Perhaps buying an existing solution is a better move because of the time and resource constraints your team has. But perhaps it might be better to build it. This is a case-by-case basis, and one where you have to wear an engineering hat as well as a business one.

Software engineers have a terrible habit of reinventing the wheel when they should just use an existing solution. This is known as the Not Invented Here Syndrome.

In the case of engineering, your Lego building blocks consist of the awareness of economies of scale, cost and maintenance of software, etc. So yeah, you might be able to build a product for cheap, but what about the time to maintain, update, and keep the product running? Do you, your team, or the business have time to do that?

If not, then it’s likely better to buy vs. build. But maybe it’s a bloated product that is very expensive and you only use one feature. In a case like that, it might be better to build it instead of buying it.

This is what thinking like a business is about. Evaluating the second- and third-order effects of all decisions (technical and non-technical).

It also means thinking in terms of ROI, revenue, customer acquisition and retention, and company strategy (which should also be codified into a skill for easy reference).

When you start to apply these filters to your decision-making process, your decisions quickly change from doing what you’ve always done via the specialist mindset to doing what’s best for the company at that point in time.

The shift from a technical specialist mindset to including thinking like a business in your decision making will make you far more valuable than any other technical certification you can obtain.

If you want a title for what you become, call it an “Agentic Product Engineer.” Same builder, seen from the engineering side.

From Product/Non-Technical to Agentic Builder

As a product person or non-technical contributor, your strengths are what you work in every day. This could be designing products, user flows, legal, social media management, HR systems, and more.

For step 1 the same prescription applies here as it did for engineers. Codify what you know into skills, templates, and documentation that is accessible to humans and AI agents. If you’re not sure how to create a skill or template or anything of that nature, simply ask the AI to help you, and it will.

These are your Lego building blocks for building and doing what you know how to do. Codifying these will make you more efficient, useful, and beneficial to the company and the agentic systems that you build.

For a non-technical contributor, the number one skill you can learn to become more engineering-focused is to simply “ask the AI agent” when you run into a roadblock.

Not sure how to deploy your application? Ask the AI agent.

Not sure how to talk to a particular API? Ask the AI agent.

Not sure the best tool for the job? Ask the AI agent.

It’s exactly what I showed the gym owner from the beginning of this post. I taught him how to ask Claude, and Claude showed him the rest.

For moving into the more engineering mindset, there are a few things you need to think about, as you simply don’t know what you don’t know.

They can be boiled down to the following:

• Maintainable and Scalable Architecture (are the systems being built correctly and are they easy to maintain?)

• Guardrails & Safety Mechanisms (how can you make sure the system keeps working, doesn’t break, and quality improves?)

• Backups (what happens when something goes wrong, do you have backups?)

• Version Control (where is this code stored?)

• Governance (who does what and why - does your system need to know this up front?)

• Observability (how do you know what’s going on in the system?)

You’re never going to be an expert in engineering because that’s not your background, so asking the agent to make sure some of these things are implemented will get you a lot further.

One additional tip is to make sure you have something like DCG (Destructive Command Guard) installed to ensure that the agent does not make any glaring mistakes and doesn’t try to delete your production database, etc. Just point the agent to that link and have it help you set it up.

Thinking like an engineer is a completely different skillset, but just directing an agent in a few directions (as listed above) will get you 80% of the way to building software that is much more reliable than without it. This will allow you to iterate faster, with more confidence, and if/when you do need to get engineering involved you will have already done a lot of the heavy lifting.

Lastly, if you’re not sure, ask an engineer for their advice. They’re almost always helpful in providing you feedback on what they feel is the best tool/method for the job.

What to Do Next

Software engineering as we know it is dying, and in some companies it’s already dead. We’re now in the era of the Agentic Builder.

The builder is one who can cross the chasm of both engineering and business, keeping both ideas in their head. Agentic builders are more adaptive, responsive, and open to change, as they realize that change is the only true constant, and they can rely on agents to help bridge those gaps.

What this shift builds for you is a strong foundation of autonomy. You are the agentic builder. You are empowered to do what is right given the information you have.

You are the one who will see or find a problem and just act on it. You will get things done and can handle technical and non-technical challenges.

So now it’s time to get started. Here’s what to do next:

1. Create a list of things that you’re an expert in, things other people come to you for, and things you manually do.

2. Pick one. The thing you’ve done a few times recently that made you wince, wishing you didn’t have to do it again. The thing you procrastinate on, even though you could do it with your eyes closed. Open Claude or ChatGPT, tell it “help me turn this into a skill,” then word vomit everything you know about it onto the screen and ask it to interview you until it’s fleshed out. That’s your first skill. It takes 5 minutes. Now use that skill the next time you need to do the thing you procrastinate on, and watch how well it works. If you’re not sure the agent can do said thing, ASK IT. The rest will happen before you know it. Once you see what one skill does for you, you’ll start codifying everything.

3. Next, start learning how to think like a business. Each decision you make, even simple ones, think about how it affects the business. Pretend you owned the business, then think about how that decision would change your direction.

4. If you’re non-technical, learn one new engineering concept a week. That will compound. Ask the AI agent to teach you as if you’re a beginner so you understand the “why” of what it’s teaching.

5. Rinse. Wash. Repeat. Keep codifying. Keep growing in the other area.

You’ve got about 6 months to make the move from specialist to agentic builder. Make that move and doors stay open, and you’ll find new ones you didn’t know existed. Sit still in your specialty and you’ll spend the following 6 months, and longer, wondering how you got left behind.

So, what makes you valuable when execution is nearly free?

The ability to stand where the pendulum stops.

A builder who can read a balance sheet and a stack trace. Who has the technical depth to fix what the agent broke, and the business sense to know whether it was worth building at all.