Supervising Systems That Write Code [2025 Reality Check]

What’s changing for enterprise architects? AI-assisted development has crossed a threshold where you’re no longer writing most of the code yourself. You describe intent, the tools generate implementation, and your job shifts to supervision, constraint definition, and architectural judgment. The productivity gains are real, but so is the risk of generating technical debt at unprecedented speed if you lack discipline.

I went back to the IDE.

Not to prove I can still code. As a CTA who’s led 30-person delivery teams, I know what I can build. I wanted a reality check on development with AI assistants.

So I didn’t run Hello World. I didn’t build toy examples. I threw ugly stuff at them:

• Permission management across complex sharing hierarchies
• Security audits of existing codebases
• Refactoring legacy services nobody wanted to touch
• Starting a micro-SaaS from architectural concept to working prototype

The verdict is simple: the threshold has been crossed.

What Changed

Twelve months ago, my mental model was: “This is a nice productivity boost.” I’d use AI to generate boilerplate, speed up documentation, maybe scaffold some tests.

That mental model is obsolete.

The friction between intent and execution has collapsed. These tools now hold a frightening amount of context. You describe an architectural concept, and within hours you have working code that implements it. Not pseudo-code. Not a starting point. Working, testable, deployable code.

Think about what this means in practice. Development velocity that used to require a team can now be achieved by a single architect with clear intent. Features that would sit in a backlog for quarters can be prototyped in a weekend. The gap between “good idea” and “let’s test it” has shrunk to almost nothing.

The Enterprise Opportunity

Most Salesforce work is not greenfield. Organizations are sitting on years of temporary fixes, odd design decisions, and business rules nobody remembers documenting.

I’ve spent years reviewing codebases where developers were afraid to change anything because the implications were unclear. AI changes that equation. You can ask “what happens if I modify this trigger?” and get an analysis that would have taken days of manual tracing.

The progression I’ve experienced is telling. A year ago, I’d use AI to write utility methods. Date formatting, string manipulation, validation helpers. The stuff that’s tedious to think through but necessary. Boilerplate that I knew how to write but didn’t want to spend mental energy on.

Now? I’m building entire features without even touching the terminal. Need a new field? Done. Remove it? Done. Update a page layout, add permissions to a permission set, wire up a trigger framework from scratch? All from the same place, all through conversation with an AI agent. The context switching between Setup UI and code editor that used to fragment my focus? Gone.

The shift isn’t incremental. It’s categorical. From “help me with this function” to “help me build this system.”

The organizations that recognize this will gain an advantage. The backlog of “we’ll fix that later” items that never got fixed? Now fixable. The process improvements that seemed too risky because of unknown dependencies? Now explorable.

The Risk You Need to Understand

Here’s where the nuance matters.

AI tools are incredible at generating logic. They’ll produce code that compiles, passes tests, and does what you asked. But they optimize for what you specify, not for what you should have specified.

If you feed a hyper-efficient AI into a messy, debt-ridden org without strict guidance, you don’t get sustainable results. You get high-speed legacy generation.

The AI doesn’t know that your sharing model is already too complex. It doesn’t know that adding another workflow trigger will push you past governor limits. It doesn’t know that the custom object you’re building duplicates functionality in a managed package you already own.

What you bring to the conversation determines what you get out of it. Clear architectural principles, understanding of platform constraints, awareness of existing technical debt: these matter more than ever. AI amplifies your approach, whether that approach is disciplined or chaotic.

The New Role

We’re no longer just writing code. We’re supervising systems that write code for us.

This requires a different skill set.

You need to define constraints before generation, not after. You need to review output critically rather than accepting it wholesale. You need to understand architecture deeply because AI will implement whatever architecture you describe, good or bad. And you need to maintain platform expertise because AI doesn’t inherently know about Salesforce governor limits or sharing model implications.

The architect role becomes more important, not less. Someone needs to ensure that the code being generated fits into a coherent system design. Someone needs to catch when the AI’s solution, while technically correct, violates organizational patterns or creates maintenance burdens.

Why This Matters Now

This isn’t optional anymore.

The ability to work effectively with AI development tools is becoming table stakes for technical professionals. Not because it’s trendy, but because the productivity gap between those who use these tools effectively and those who don’t is widening rapidly.

For organizations, this unlocks possibilities that were previously blocked by development capacity. That enhancement users have been requesting for two years? The integration that would save the operations team hours per week? The technical debt that’s been accumulating interest? All of these become addressable when development velocity increases by an order of magnitude.

For individuals, this multiplies what you can achieve. You can accomplish more, learn faster, and tackle problems that seemed too complex before. A senior architect with AI tools can do work that previously required a team.

So What Now?

I don’t see this as a threat to our profession. If anything, it’s the opposite.

The work that remains ours is the work that matters most: understanding the actual business problem, designing solutions that will still make sense in two years, making decisions that account for organizational context and long-term consequences. AI can generate code. It can’t tell you whether you should.

The architects who learn to work with these tools will deliver at a scale that wasn’t possible before. Those who dismiss them will eventually notice their peers shipping more, experimenting faster, and somehow never running out of development capacity.

The threshold has been crossed. The question isn’t whether to engage. It’s whether you’ll lead or follow.

---

This article expands on a LinkedIn post. The original: