Coding Is Getting Cheaper. Software Engineering Isn't.

I saw a rate card going around recently, the kind of thing that gets shared because it's funny and a little too accurate. It compared developer options like a menu:

• Cat on a keyboard $5/hour
• Vibe coder $20/hour
• Software engineer $100/hour

It's a joke, obviously. But jokes like this usually work because there's a real observation buried in them, and this one is worth taking seriously for a minute.

AI has made writing code dramatically cheaper and faster. That part is true, and it's a good thing. What I don't think is true is the implication that follows: that software engineering itself has become less valuable, or that the $100/hour column is now overpriced nostalgia.

I'll say upfront where I stand, because it matters for how you read the rest of this. I use AI coding tools constantly. They've made me faster at almost everything I do. This isn't a "back in my day we wrote assembly" complaint. It's a more specific point: generating code and engineering a system are not the same skill, and AI doesn't remove the need for the judgment that separates the two.

What AI is actually good at

Ask an AI tool to write a product filter, a checkout validation script, or a Liquid section that shows a countdown timer, and it will probably do a decent job in under a minute. For a prototype, a simple feature, or a one-off internal tool, this is genuinely great. A few years ago, many of these tasks meant manually writing and debugging most of the implementation. Now you can often get to a solid first version in a coffee break. I'm not going to pretend that's anything other than a real improvement.

But writing syntax was never the hard part of this job. It felt like the hard part when you were learning, because getting anything to run at all used to take real effort. Once you've been doing this a while, you realize the actual difficulty was somewhere else the whole time: understanding what the system needs to do, how it interacts with everything around it, what happens when a customer does something you didn't anticipate, and what breaks six months later when someone else touches the code.

AI is very good at producing something that looks correct. It is much less reliable at knowing whether it's correct for your specific system, your specific data, and your specific edge cases. It will confidently write a discount calculation that's subtly wrong for one currency, or a webhook handler that assumes an order only ever has one fulfillment. The code runs. It even looks reasonable in a code review if nobody's paying close attention. That's the dangerous part.

Where this shows up in Shopify projects

This is where I spend most of my time, so let me make it concrete instead of abstract.

AI can write you a Liquid section, a JavaScript interaction on a product page, an API call to sync inventory, or a basic Shopify app feature, all quickly and all reasonably well. If that's the whole project, you genuinely don't need much more than that.

But most real Shopify work isn't one piece in isolation. It's Shopify Markets running alongside multiple currencies and languages. It's checkout customization inside the limits of what Shopify actually allows you to touch. It's inventory syncing correctly across a system that also depends on metafields, a couple of third-party apps, a custom API, and some legacy logic nobody fully documented. It's webhooks that need to behave correctly when they arrive out of order, or twice, or not at all. It's customer data that has to stay consistent across five systems that were never designed to talk to each other.

None of that is a code-generation problem. It's a "how do all these pieces actually interact, and what's the correct behavior when they conflict" problem. AI can help you write any individual piece of that puzzle, and with enough context, it can help you reason about the whole puzzle too. But someone still has to provide that context, challenge its assumptions, understand the platform and business constraints, make the trade-offs, and decide which solution is actually safe to put into production.

The part where you still need someone responsible

There's a version of the pricing argument that goes: why pay $100/hour when someone with AI can do it for $20/hour?

I don't think the honest answer is "because expensive developers are automatically better." Plenty of expensive developers aren't. The honest answer is that hourly rate is a bad proxy for cost. The real cost is closer to something like: rate × time × mistakes × future maintenance. A cheaper build can absolutely be the cheaper option overall, especially for a prototype, an internal tool, an experiment, or something genuinely low-risk. I'd never tell someone not to vibe-code a landing page test or a quick internal dashboard. That's often exactly the right call.

Where it gets expensive is when a fast, plausible-looking solution goes into production carrying business logic nobody fully checked, and the mistake surfaces three months later as a pricing bug, a broken checkout edge case, or a data sync issue that quietly corrupted orders for a week. At that point the $20/hour build didn't save money. It just moved the cost later and made it bigger, and now someone has to understand a system they didn't build well enough to fix it under pressure.

That's really the distinction I'd draw, and it's not "did AI write this." It's closer to: does anyone understand this system well enough to be responsible for it? A codebase that's ninety percent AI-generated can still be well engineered if someone experienced designed the approach, reviewed the output, tested the edge cases, understood the trade-offs, and is willing to stand behind it in production. The reverse is just as true. Code written entirely by hand, with no AI involved at all, can still be badly engineered if nobody did that work. The tool used to produce the code was never really the point.

A junior developer with AI can often produce a working first version impressively fast. Speed to a first working version isn't the same thing as speed to something you can safely run a business on. A senior engineer's value was rarely about typing code faster than everyone else. It's usually about not building the wrong thing in the first place, noticing a problem in the requirements before it becomes a problem in production, and choosing the simpler of two solutions instead of the more impressive one. Two hours of that kind of thinking has saved projects I've worked on from ten or twenty hours of building in the wrong direction. AI can help with that reasoning too. But it doesn't remove the need for someone to make the call and own the outcome.

Where this leaves things

I don't think the answer is to be suspicious of AI-assisted development, and I'd be a hypocrite if I argued that, since I use it every day. Developers who refuse to touch these tools are going to fall behind, plainly. But developers who lean on AI output without understanding what it produced are quietly building risk into their systems, and that risk doesn't show up on day one.

The strongest combination I've seen isn't "AI instead of engineering experience." It's engineering experience with AI as leverage: someone who already knows what a good solution looks like, using AI to get there faster, and knowing enough to catch it when the generated answer is wrong.

AI makes developers faster. It doesn't remove the need to know what you're doing, and for anything running a real business, that part hasn't gotten cheaper at all.