Skip to content

The Unseen Shift: What Actually Changes When Engineers Use AI Every Day

#software-engineering #ai-tools #workflow #technical-practice #engineering-culture

Every single engineer I talk to uses AI now.

Nobody is arguing about adoption anymore. Nobody is posting hot takes about whether it works. It just does. It is in the IDE, it is in the terminal, it is pasted into Slack threads when someone hits a weird stack trace.

And almost nobody is talking about what actually changes after the first three months.

All the public conversation is still stuck on two dead ends: "AI will replace engineers" and "AI is just a better autocomplete". Both are wrong. The real change is quieter, stranger, and far more important.

AI did not remove work. It removed the friction. And it turns out almost all of that friction was load bearing.

It was the brake that stopped you building a whole agent framework just to post one Telegram message. It was the filter that kept your bad ideas safely in the drawer. It was the cost that forced you to use an off the shelf library instead of rewriting everything from scratch. It was the delay that made you think about the problem before you wrote the first line of code.

All of that is gone now. And nobody installed a replacement.

That is the actual story playing out right now, on every team, in every repo, at 2am every night.

Friction was never the enemy

This started with Sergey Frangulov's post, which is probably the most honest thing written about AI and engineering in the last two years.

He is 25 years into writing code. He installed Claude Code. Suddenly an idea that would have taken a month to prototype took an evening.

At first this felt like winning. Then it didn't.

All the untested ideas he had carried around for years died within days. Most were mediocre. Some were terrible. The friction of implementation was never the barrier. It was the anesthesia that let him keep believing the ideas were good.

Worse, every trivial task turned into an infinite rabbit hole. What started as "post one message to Telegram" ended at 2am as a fully pluginable multi-agent newsroom with exactly one user. He never sent the message.

Before AI, writing that custom sender would have taken three days. So he would have grabbed a library off npm, sent the message, and moved on. The cost of work enforced pragmatism.

That cost is now zero. So the pragmatism is gone too.

This is not a complaint about productivity. By every standard metric he is more productive now. He writes more code, ships more prototypes, builds better tools. He just never finishes the actual thing he sat down to do.

The friction everyone spent 25 years complaining about was a brake. AI cut the brake lines.

Using AI is easy. Engineering with it is hard.

Almost everyone is still stuck at the first stage.

You paste an error. You get an answer. You write a prompt. You get 200 lines of code. This is using AI.

This works great. Until it doesn't.

Jeel Vankhede put this better than anyone: the hard part was never getting the AI to write code. The hard part is telling it what not to write. The hard part is shaping the work before you hit send.

AI amplifies every existing part of the engineering loop. If you have good requirements, good tests, good review habits, you will get more good code faster. If you have bad requirements, no tests, and lazy review, you will get mountains of garbage shipped at 10x the old speed.

Code generation is the easy part. Verification got harder.

Nobody talks about this. Everyone shows the clean output. Nobody shows the three hours spent debugging the subtle architectural mistake that looked perfectly reasonable in the generated diff.

The old rule was think twice, code once.

The new rule is think three times, code once, review twice.

AI did not make thinking obsolete. It made it mandatory. You can skip writing the boilerplate. You cannot skip understanding the problem.

The end of the mid-depth specialist

This is rearranging what kind of engineers survive.

Benjamin Link walked through the part everyone is dancing around: AI eats I-shaped engineers first.

If your entire value is knowing the syntax of one framework, or the configuration flags for one database, you are already obsolete. A model knows that better than you, faster than you, and will never call in sick.

This is not a new trend. It is just accelerated. Every tool shift has eaten the mid-depth specialists. This one is just eating them faster.

The people winning right now are generalists. The T-shaped, the comb-shaped, the people who can move across boundaries, understand tradeoffs, connect pieces, and say no.

The surviving specialists are not the ones who know how to implement something. They are the ones who know when you should not implement it. They are the ones who understand the cost, the tradeoffs, the second order effects.

Depth did not disappear. It just moved up a layer.

Nobody cares if you can write a perfect React hook. Everyone cares if you can tell when building that hook is the wrong thing to do entirely.

The $0 bug that costs $1800

The new failure modes are almost all silent.

Arpit Bhayani wrote up the cleanest example: their OpenAI bill went from $620 to $2480 in 23 days. No errors. No alerts. No deployments. Nothing looked wrong anywhere.

It took two weeks to find it. An autosave hook had accidentally been wired to trigger a full GPT-4o batch report every 30 seconds per active user.

This is the new class of bug. Zero error rate. Perfectly correct behaviour. Exactly what the code said to do. And it was quietly costing thousands of dollars a month while every existing monitoring tool showed green.

Every existing engineering process is built to catch failures. None are built to catch successful overuse.

Total cost dashboards are useless. They tell you how much you spent. They will never tell you why.

The fix was not better rate limiting. It was not downgrading models. It was attribution. Tag every single model call with which feature, which service, which user triggered it.

This is not optional anymore. This is table stakes. If you cannot tell which feature spent the money in 30 seconds, you do not have a cost problem. You have a visibility problem that will eventually look exactly like a $1800 bill.

System prompts are the new spaghetti code

Everyone building agents runs into this wall eventually.

You start with a small system prompt. Then you add one rule. Then another. Then a reminder. Then a safety note. Then a workaround for a weird hallucination. Six weeks later you have a 1200 line system prompt that nobody understands and nobody dares edit.

This is spaghetti code. It is exactly the same mess engineers spent 50 years learning not to write. We just moved it from Python into markdown and pretended it was something new.

Gareth Edwards ran into this building an Anki tutor. The breakthrough was not writing a better prompt. It was stopping entirely.

Instead of one giant blob of instructions, he split behaviour into skills. Small, reusable, named packages of behaviour that the agent loads only when it needs them.

The system prompt stays 10 lines long. It says who the agent is. All the actual behaviour lives in separate skill files.

This is not a trick. This is just good software engineering. We already knew this. We just had to learn it all over again, one overgrown system prompt at a time.

All the old rules still apply. Separation of concerns. Single responsibility. Composition over inheritance. None of them went away because you are talking to a model instead of a compiler.

AI outputs need receipts

The worst failure mode is not bad code. It is confident wrong conclusions.

Yana Li documented this perfectly. Anyone can get a model to write a nice summary of user feedback. Nobody can tell you which comments the summary actually came from.

This is the quiet scam running through 90% of AI tools right now. They produce beautiful, confident, completely unsubstantiated reports. There is no way to verify if the pattern is real, or if the model just made up a nice story that sounded plausible.

The fix is simple, and almost nobody does it: every claim must be bound to evidence. Every conclusion must link back to the exact source rows that produced it.

The model can propose the story. The system must verify the receipts.

This is not about making AI perfect. It is about making it honest. It is about letting the user decide if the conclusion is justified, instead of being forced to trust a black box.

This will be the dividing line between useful AI tools and toys. The toys will give you answers. The good tools will show you the work.

Sovereignty is the unspoken requirement

All of this leads to one quiet shift almost nobody is talking about yet.

As AI moves deeper into the stack, you cannot trust external providers for anything that matters. You cannot trust their logging. You cannot trust their audit trails. You cannot trust that they did not change the output after the fact.

Ken Walger is building the sovereign AI stack for exactly this reason. The gateway is not enough. You need cryptographic verification at every step. You need immutable audit logs that cannot be altered, even by someone with root access. You need to know exactly what happened, exactly when, exactly who triggered it.

This is not paranoia. This is just engineering practice for a world where every third line of code comes from a model.

If you cannot prove what the system did, you cannot debug it. You cannot audit it. You cannot operate it.

The new work

Nobody is coming to install the brakes for you.

All the old guardrails are gone. The friction, the cost, the delay, the inconvenience that used to enforce discipline for free. All of it is gone.

Now you have to build all of that by hand.

You have to build stop conditions. You have to build attribution. You have to build evidence binding. You have to build audit trails. You have to learn to say no to a perfectly reasonable detour that will take all night and accomplish nothing.

That is the new job.

Prompt engineering is not the skill. Speed is not the skill. Output volume is not the skill.

The skill is slowing down.

The skill is deciding what not to build.

The skill is putting the friction back, on purpose, in exactly the right places.

That is what engineering with AI actually means.

Everyone else is just using it.