# Is AI the End of Engineering, or Just the Beginning?

AI is eating some old software work, but it is also creating a new category of engineering: turning half-working AI systems into durable business tools.

Published: June 27, 2026
Tags: AI, Engineering, Product Engineering

Canonical URL: https://michaelrispoli.com/blog/is-ai-the-end-of-engineering-or-just-the-beginning/

There's a pattern that keeps showing up in the businesses I talk to that want to implement AI.

Someone inside the organization, usually not an engineer, builds something they probably would have paid me to build in the past. Maybe they spin up a little data dashboard. Maybe they put together a landing page. Maybe they fix some part of an existing project, or revive some abandoned thing that never quite got finished.

Either way, it is usually a product manager, designer, marketer, operations person, or founder doing something they did not have the power to do before.

And then the thing starts to work.

Not fully. Not perfectly. But enough.

It gets just useful enough that the team starts depending on it. The team starts to ask for new features. Managers and IT staff start to ask about how it works. It needs to meet security requirements. It needs to connect to the right systems. It needs to stop randomly breaking. It needs polish.

That is usually where I enter the conversation.

A lot of engineers look at this and understandably say, "Well, this could be the end." If these models keep getting better, maybe they will eventually handle the engineering part that these people are currently getting stuck on.

I understand that fear. A lot of the easy work is disappearing. People are not paying as much to have someone spin up a simple landing page. They are not always paying someone to configure a CMS. They are not always paying for the little dashboards, the internal tools, the basic websites, or the quick fixes that used to be great bread-and-butter work. That work was not always difficult, but it was income-generating work.

But I think there is another possibility here.

AI may not be the end of engineering. It may be the beginning of an entirely new category of engineering work.

Because what I keep seeing is that people can now get much further than they used to. A non-technical person can build something that looks and feels real. They can get a dashboard working. They can prototype a workflow. They can duct tape together a tool that actually helps the business. The tool's usefulness can be verified before the business ever spends real money building it.

But then they hit the wall.

And the wall is not always "the model is not good enough." The wall is usually that they do not know what to ask for. They know how to describe features, but they don't know how to describe good software.

I see this all the time. Inexperienced people are using the best model money can buy. They are saying, "I'm just going to use GPT-5.5 for everything," or Claude Opus, or whatever the current monster model is. Maybe they have an AI budget. Maybe they do not. But either way, they start burning through tokens.

I have one client that burned through an entire paycheck's worth of tokens trying to build a thing.

And the crazy part is the project probably did not require that much token burn.

The issue was not that the work was impossible. The issue was that they did not know how to communicate what they were asking for in a specialized way.

Every field has terminology. Design has terminology. Medicine has terminology. Engineering has terminology. Law has terminology. Sometimes one correct word can express what would otherwise take paragraphs to explain. A single term, a handful of tokens, can point the model toward the exact shape of the thing you want.

But if you do not know that term exists, you end up writing paragraph after paragraph of prose trying to describe something that already has a name.

That is where a lot of waste happens. The user is trying to explain a concept the field already solved. The model is trying to infer what they mean. They go back and forth. The conversation gets longer. The context gets messier. The cost goes up. The quality goes down.

This is one reason I feel fortunate that I came into software before these tools existed. I had to learn the terminology. I had to learn the algorithms. I had to learn the pesky Gang of Four design patterns. I had to learn the annoying little Linux commands. I had to learn what things were called.

That does not mean I can implement every possible algorithm in every possible programming language from memory. Nobody can do that. But I do know broadly what I am looking for. I know the language of the space. I know how to say the thing correctly in a small number of words. This translates to token savings. 

And weirdly enough, this brings me to one of my favorite sports: rock climbing.

I was raised rock climbing. I learned to traditional lead climb from my uncle, who came up in an era where climbers used very basic, simple machines to protect climbs.

They had nuts, chocks, hexes, and other pieces of what we called passive protection. These were basically pieces of metal attached to wire cable that you would wedge into the rock. Ideally you wanted a V-shaped notch in a crack, something that would allow the piece to seat itself securely. If it was a horizontal crack, you might place a hex, which like its namesake was hexagonal in shape and you could kind of cam it into position. There were also tri-cams, which did something similar in their own strange little way.

But the basic idea was the same.

You were wedging small pieces of metal into the rock and trusting them to hold you if you fell.

Then along came a little technology called the spring-loaded camming device. Wild Country made one of the iconic early versions, called Friends, and they changed everything.

A spring-loaded camming device has lobes that contract when you pull the trigger and expand when you release it. You place it into a crack, let it expand, and when it is weighted during a fall, the outward force is magnified by the geometry of the device.

That meant you could protect cracks that were very hard, or sometimes nearly impossible, to protect with passive gear.

They worked in flaring cracks, where the crack rounds outward toward the edges. They worked in horizontal cracks. They could handle multidirectional forces better than many passive placements. If you placed a hex in a horizontal crack and the rope jerked it upward, it could come loose. So you had to think carefully about extending the connection point between the rope and the gear to prevent that from happening.

Cams changed the calculation.

They were faster to place. They fit in more places. They made climbers feel more secure. They opened up new routes.

But they came with a cost. They were bigger and took up more space on your harness. They were also heavier.

Today, modern gear is much lighter, but back then a lot of these spring-loaded devices had metal stems and real heft to them. You had to make a trade-off. Do you carry more active protection because it is easier and fits in more places, or do you carry lighter passive protection because you know how to place it well?

We have to make the same trade-off with AI in software. Do you throw masses of tokens at it until you get what you want, or do you have the precision to use a simple incantation for the same output?

If you are good at placing passive protection, you do not need to haul an entire rack of heavy cams up the wall. You can move more efficiently. You can preserve energy. You can make better decisions because you have more tools available to you.

The same thing is true with AI.

If you know how to get great work out of lighter-weight models, you become more token efficient. You are preserving the amount of weight you are hauling up the wall. Your strength, your budget, your context window, your patience, all of it lasts longer.

Not everything needs the biggest model. Not every task needs the heaviest tool. Sometimes you need the expensive spring-loaded camming device. Sometimes you just need a nut that fits perfectly.

The engineer who knows the old ways has an advantage here.

That does not mean we reject the new tools. Quite the opposite.

The birth of the spring-loaded camming device opened up climbs that were previously considered unsafe to lead.

There is a famous climb my uncle showed me called *Mr. Machine*. It was named so because it was one of the first climbs done with these spring-loaded camming devices. The climb had a series of horizontal, flaring cracks with rounded-out shapes that were basically impossible to lead safely with the passive protection climbers had before.

Sure you could solo it and risk death and serious injury. But to lead it the way us mere mortals do, from the ground up with a rope, you needed cams.

The new technology did not remove the need for climbing skill. It opened up a new world where skill could be applied.

Nobody before that had fully conceived of a world where removable protection could be placed that quickly, hold that securely, and work in that many strange features of the rock. Once the gear existed, climbers started looking at walls differently.

As climbing gear got better, we got lighter cams, smaller cams, offset cams, flexible-stem cams, micro protection, and all kinds of newer, lighter, stronger, more specialized tools. Each improvement opened up new possibilities. New generations of climbers looked up at walls and saw lines the previous generation did not see, not because the previous generation lacked courage or imagination, but because the gear changed what was possible.

AI is doing something similar to computing.

We are entering the world of non-deterministic computing, and everyone is trying to learn the latest thing. Every time a new model comes out, we all go, "Oh my God, everything has changed forever. Nothing will be the same. Learn this or be left behind."

But that is a silly way to look at it.

You are not "left behind" because spring-loaded camming devices exist. You are left behind if you refuse to understand what they now make possible. You have to look at technology through a new lens, the same way climbers had to with their newfound power.

The new generation of engineers will still have to learn the old ways. They will have to understand the old tools, the old commands, the old systems, the old engineering process. Because guess what? That stuff still comes in handy.

When I go up a wall, I still make the trade-off. If a piece of passive protection fits perfectly, I place it. I do not waste a cam just because cams are newer.

The same is true at a computer.

If I can type a bash command faster than I can ask Codex to do it, I should type the bash command. Moving a file from one directory to another is not some grand prompt engineering challenge. It is `mv`. Copying a file is `cp`.

We should not be sitting here saying, "Well, I do not need to learn any Linux commands anymore because I have Codex."

You can look at it that way, but it is definitely more characters to say, "Move this file from this path to this other path," than it is to type the command.

Learning this stuff is still useful if you want to use a computer efficiently.

At the same time, there are now parts of applications that are possible that were not possible before. There are interfaces that can exist now because we have this strange new ability to loosely ask a machine what we want and get a reasonable response back.

The interfaces of the future are probably not all going to look like ChatGPT or Claude. They are going to be specialized machines. They are going to be workflows, tools, agents, dashboards, terminals, canvases, editors, and strange new compositions we have not fully imagined yet.

A little while ago, everyone thought AI coding was going to live mostly inside IDEs. Then tools like Codex and Claude Code pulled people back into the terminal, this old thing we supposedly moved beyond. Cursor has a CLI and cloud-agent workflows with shared terminal sessions. Now people are asking whether the future is agents, loops, Kanban boards, plan mode, terminal sessions, or some combination we do not have a name for yet.

We are in a state of extreme innovation. And all of that has to be built by engineers.

Not because engineers have a monopoly on ideas. They do not. In fact, many of the best ideas will probably come from people outside engineering, because they are closer to the business pain. They are the ones inside the organization duct taping together these first strange little tools with AI.

But engineers are going to be the ones who know how to turn those ideas into durable systems.

They are going to know how to configure these models, connect them to real data, control their behavior, manage cost, build guardrails, design workflows, handle permissions, satisfy security requirements, and combine older engineering processes with this new AI-native layer.

That is the work that has not fully arrived yet.

Or maybe it has arrived, but we do not have clean names for it yet.

This brings me back to why businesses are reaching out to me now.

They usually wet their whistle by building something themselves. They get a little app working. They use AI to solve some annoying internal problem. They build a tool that is kind of working but kind of not. Then they start wondering if more is possible.

Could it read documents? Could it follow a workflow? Could it make recommendations? Could it connect to their CRM? Could it follow their security rules? Could it be governed? Could it handle weird edge cases? Could it be cheaper to run? Could it become something the business actually depends on?

That is where the old and new worlds meet.

And that is where engineering is not ending. It is changing shape.

Yes, some parts of the industry are in a state of atrophy. I think we have to be honest about that. A lot of the work people used to pay for is being eaten by tools. The landing pages, the basic websites, the simple dashboards, the CMS configuration, the little pieces of glue code. Some of that work is gone, and some of it is not coming back in the same form.

But the new thing is coming.

When we look up at the wall now, we have to ask: what is the new Mr. Machine?

What is the climb that was not possible before this gear existed?

Those ideas will lag behind the technology at first. It takes ingenuity and imagination to find these novel use cases. It takes weird people staring at the wall and seeing something others do not see yet. It takes business owners realizing they no longer need you to build the simple website, but they do need you to help make this half-working AI system real.

And as more of these systems show up, more people will start to understand what is possible.

They will not call and say, "Can you build me a landing page?"

They will say, "I put this thing together. It works, kind of. It is costing me a lot of money. It breaks in weird ways. There is a bunch of stuff I want it to do. I need someone to make this reliable because we've created something valuable."

That is not the end of engineering.

That is a new wall.

And we are only just starting to see the new lines that are possible.