Everyone can build now. The fundamentals shouldn't change.

In my career group last week we got into how AI is fundamentally changing organizations. AI is a new tool and while it can be used to accelerate outcomes, it shouldn't overwrite good process. Most of what I'm watching isn't organizations getting reinvented. It's organizations mistaking a tooling change for a process change, and loudly skipping the parts that were always the actual product work.

Here's the distinction I think matters. What AI changed is real: who does the work, how fast a first version appears, and what that version looks like to someone watching.

What it didn't change is the part that was always hard: rooting what you build in a real customer problem, ruthlessly prioritizing, making something usable, not just visible, coordinating across stakeholders and bringing the org along, making systems actually connect. Those didn't get easier. They got hidden behind a seemingly working prototype, which is a different thing entirely.

I'm seeing the same move play out in four places.

Everyone can build now, so everyone skips to the solution

When anyone can stand something up in an afternoon, the temptation is to jump straight to the solution and work backwards to find a problem it solves. I get the appeal. Building feels like progress in a way that discovery never does.

But the fundamentals of product didn't change because the tooling did. You still have to start from a customer need, not from the thing you already built. You still have to prioritize against everything else competing for attention. You still have to coordinate with the people who'll have to support, sell, and live with the thing. Rebrand the role as "builder" if you want, that's fine, the title was never the point, the discipline behind it is.

My own guardrail against this is a ladder. When a problem lands on my desk, I work up from the cheapest fix before I reach for the expensive one. Can a process change solve it? A clearer workflow? Plain rules-based automation? AI only earns the top rung when the problem actually needs judgment, language, or pattern-finding the simpler tools can't provide. If a rules engine does the job, ship the rules engine. The tooling got faster, but starting from the problem instead of the thing you already built is still the work.

Design becomes "the people who make it pretty"

This is the trend I think is coming next, and it's going to have real consequences for organizations and users.

Good design can look deceptively easy, but it's not. Great UX makes experiences engaging and usable. That distinction is easy to lose right now, because there's a real movement toward "design builders," designers who also ship front-end code. On its own, that's not necessarily a bad thing. It pushes on the boundary between design and engineering, and some of that pressure is healthy.

But, I do worry that in blending the design and engineering, you may lose sharpness on both sides. And the other part I'd watch is what happens to full-time design once a B2B product locks in its core patterns. Once enough of the design system is built and live, a lot of the remaining work is seen as variations on a theme. It's not hard to imagine leadership looking at that and deciding ongoing design is a luxury, something you rent from an agency for the occasional big swing rather than staff full-time. If that happens, it's a boon for design agencies and a direct hit to in-house design. And the thing being cut won't be "making it pretty." It'll be the usability work that was always the real job, just less visible than the engineering bill next to it.

Tokenmaxxing was never the point

For a while the flex has been token usage. Leaderboards of who burned the most tokens. Someone in my career group mentioned spending a thousand dollars last month, and that figure was being treated as the measure of success. Not outcomes, not even outputs. Just tokens and dollars.

So of course the correction is already swinging the other way, toward restricting access to the frontier models and capping spend. Which tells you the original metric was wrong in both directions. The question was never how much you spent or how little. It's whether any of it produced an outcome worth having. Are we tokenmaxxing, or are we outcomemaxxing? Most orgs can't answer that yet, which is the actual problem.

The C-suite can build now, and that won't turn out well

Leadership has always been frustrated with how long development takes. A lot of that frustration came from the hard parts being invisible to them. Integration, edge cases, the slow work of making everything connect and keep working. That difficulty got obfuscated, so from the top it looked like product development was just "slow."

Now a C-suite leader can (re-)build the thing themselves. Stand up a proof of concept, watch it "work," and reasonably ask why the "real" version took so long to build. The trap is that the prototype was never the hard part. The prototype skips integration, security, scale, the existing systems it has to support, and every workflow it touches. Proving an idea works in isolation and shipping it into a running business is a completely different beast. Congrats, you rebuilt part of the app, but what's your plan for the rest of our customers still using 90% of the now "legacy" app?

Where this goes next

After tokens and dollars, I think the next stop is justification-based usage: employees asked to defend their AI spend against company goals, maybe capped to specific models by level, maybe with the actual prompts and conversations surfaced in vendor reports for managers to audit. I can already picture the support-ticket template with a justification field.

I am worried that organizations are about to unnecessarily rewrite the fundamentals without an eye on outcomes. We're already seeing reversals on AI firings, reductions in AI spend, and I think that the next conversation will be a pendulum swing back to first principles.

I don't think organizations need to be fundamentally reinvented. The tools are new and the fundamentals didn't move. Customer problems, usability, outcomes, and the glue that holds it together were the work before, and they're still the work. The orgs that remember that will be fine. The ones redrawing the org chart around the tool are going to relearn it the expensive way.