What AI changed, and what it didn't.
Everyone in the Salesforce ecosystem is currently posting some version of the same sentence about AI. I use it constantly, so I'd rather say something specific than add another one.
Here's the part that seems to get skipped. What changed isn't that I can produce more. Producing more was never my constraint. I could always build faster than a client could absorb, and the bottleneck was never how fast I typed. It was knowing what was worth typing.
AI is very good at producing. It's genuinely useful for thinking. What it can't do is the part that only happens in the room. It hasn't watched your estimator work, doesn't know which VP is going to kill this in review, and can't tell you whether the person entering data forty times a day will quietly go back to their spreadsheet.
That distinction decides how I actually use it.
Getting oriented faster. Before a discovery call I'll have it help me get up to speed on a firm's market, their competitors, the vocabulary they're going to use in the room. Ten years in and I still walk into calls where I don't know the domain, and arriving with a working model of their world instead of a blank page changes the quality of the first hour.
Pressure-testing a design. Explaining a data model to something that will ask obvious questions back is a decent substitute for a colleague who isn't free that afternoon. Half the time the objection is wrong. The other half I hadn't thought about it.
The scaffolding I'd otherwise write on autopilot. Test classes, boilerplate, the fourth variation of a component I've already built three times.
Catching the thing I missed at four in the afternoon. This one is underrated. Fatigue is a real failure mode and a second pass costs nothing now.
I don't ship anything I couldn't have built myself.
Not for purity reasons. It's that I'm the one standing in the room when somebody asks why it works that way, and the model suggested it is not an answer. If a formula I can't fully explain produces a number on a director's dashboard, I've handed a client something that looks like an asset and behaves like a liability. Same for anything going into a managed package, where a shortcut doesn't affect one org, it affects everyone who installs the next version.
There's a version of this that's about craft and a version that's about liability, and honestly both are doing work here.
It shows up in what I build, too. On a recent dashboard I added an AI summary that reads the aggregate figures and writes a short executive brief. It sends aggregates only and never record contents, it's labeled advisory, and it cannot modify a single record. Partly that's a safety decision. Mostly it's the same principle as everything else I build: a summary you can't trace back to what produced it is a number nobody can defend, wearing prose. And confident sentences are more persuasive than a figure on a chart, which makes them more dangerous when the derivation is invisible.
AI made volume cheap, and volume was never what made an implementation succeed.
It is very easy now to ship forty automations nobody asked for.
Every one of them technically functional, well-formed, correctly deployed, and collectively a system that feels like homework to the people who have to live in it. That's the same failure as before. It just arrives faster and with better documentation.
The clients I've seen fail didn't fail because their build was too small. They failed because nobody used what got built. Making it cheaper to build things nobody asked for is not obviously progress.
So the honest summary is narrower than most of what you're reading right now. AI gets me to understanding faster. It doesn't get me to understanding on its own. That part is still a conversation with somebody who would rather be doing their actual job, and it's still what determines whether any of the rest was worth building.