14 min read
“We let the teams choose.”
I keep hearing that sentence from executives discussing AI coding platforms. It sounds healthy, and in the old software world it often was. You trusted skilled developers to pick editors, terminal setups, plugins, and local workflows because the tool mostly stayed with the person using it.
Now the tool sees the codebase, changes the codebase, remembers the work, produces evidence, routes model spend, and leaves artifacts other teams inherit. That is no longer local preference. That is production infrastructure.
The problem is not that developers have opinions. They should have opinions. The problem is that many executives cannot measure software production well enough to make the decision, so they turn the decision into a homecoming court vote with enterprise risk attached.
The tool with the loudest champions wins. The tool that feels fastest wins. The tool that has the cleanest demo wins. The tool that one respected principal engineer swears by wins. Everyone nods because “the developers like it” sounds more enlightened than “we do not know how to measure this.”
No hospital lets every surgeon bring their own operating room.
That sentence should be obvious. It is obvious in medicine, manufacturing, aviation, pharmaceuticals, finance, energy, and almost every serious production environment. A manufacturer does not let every plant pick its own quality system. A bank does not let every desk pick its own trade surveillance system.
The craftsperson matters because judgment lives in the person, not the platform. That is why leadership governs the system around the work.
A surgeon can have a preferred technique. They can push for a better robot, a better imaging workflow, a better scheduling model, or a safer way to handle pre-op. Good hospitals listen because ignoring skilled operators is how expensive people create stupid systems.
But the surgeon does not choose the hospital’s electronic medical record, imaging archive, sterile processing chain, robot vendor, audit trail, and post-op reporting model because “that is what makes me productive.”
The hospital respects the craft by governing the production system.
Software executives are doing the opposite with AI development platforms. They are letting every engineer, team, architect, principal, and vendor enthusiast pick a favorite platform as if this is still a text editor conversation.
It is not a text editor conversation.
It is becoming product lifecycle management for software.
That changes the economics. In a 500-engineer organization, three overlapping AI coding platforms at $40 to $80 per seat can create a visible bill in the tens of thousands a month. That is not the expensive part. The expensive part is losing one accountable record of how AI-assisted software is requested, generated, reviewed, secured, measured, and improved.
If the only thing leadership can see is the invoice, leadership will manage the invoice. That is how companies save money on seats while losing the production system.
PLM Is the Analogy. Measurement Is the Point
Product lifecycle management (PLM) is the governed system of record for how a product moves from idea to design, build, change, release, support, and retirement. In manufacturing, nobody treats that as a perk. Nobody lets the turbine engineer, the supply-chain lead, and the factory supervisor each pick a different system because one group likes a different workflow.
Most readers also read: The Engineers Who Can’t Use AI Agents Don’t Have a Tools Problem
Software leaders hear PLM and think CAD files, bill of materials, regulated hardware, change orders, and somebody in a polo shirt saying “Teamcenter” with too much confidence. Fine. Keep the eye roll. The category still found you.
For software, the plain-English version is simpler: the system of record for how work gets requested, designed, generated, reviewed, approved, measured, shipped, supported, and improved.
That is where AI coding platforms are moving. Call it PLM, application lifecycle management, an AI-SDLC system of record, or something a vendor will rename twice before the next renewal. I do not care which label survives the vendor slideware. I care whether the executive team understands the decision it is making.
Autocomplete alone is a smaller governance problem. The issue is the platform with source access, agent permissions, session memory, workflow automation, model routing, policy controls, test generation, delivery telemetry, cost attribution, and enough context to influence how the software lifecycle actually runs.
At that point, the tool is not only helping a developer type. It is changing what the company can observe about software work. What the company cannot observe is where executive folklore takes over.
That is why the current behavior is so strange. Leaders who would never let each product team pick its own cloud provider, CRM, ERP, identity platform, observability stack, or financial system are letting engineering teams assemble private AI software factories out of whatever tool felt best last Thursday.
That is not leadership. It is a Slack poll with source access.
The argument usually arrives dressed as developer autonomy. I have sympathy for that argument because it used to be right. I spent a lot of my career arguing against central teams forcing bad tools on good engineers. For years, the right answer was to get bureaucracy out of the way and let strong developers pick the local tools that kept them in flow.
That worked because the tool was mostly local to the person.
An AI development platform is not local to the person. It sees the codebase. It changes the codebase. It produces evidence, or fails to. It shapes the organization’s memory of how software gets built.
You can still call it an IDE if that makes the procurement form easier to route. It is not behaving like one.
Craft Autonomy Is Not Infrastructure Autonomy
This is where the conversation gets emotionally tangled.
Engineers hear “standardize the AI platform” and translate it as “leadership does not trust us.” That reaction is rational because many companies have earned that distrust. They standardized terrible tools. They turned governance into ticket queues. They used security as a conversation-ender. They made engineers beg for the equipment required to do the job, then acted confused when the best people left.
So be careful. This is not an argument for treating engineers like replaceable hands.
The surgeon analogy matters because nobody serious believes the surgeon is disposable. The surgeon is the scarce judgment in the system. That is exactly why the hospital does not bury them under incompatible infrastructure, mystery data flows, unreviewed vendor risk, and a different patient record depending on which operating room they happen to like.
Good governance protects craft from chaos.
Bad governance protects leadership from accountability.
That distinction matters. If your standard platform is weak, slow, underpowered, hostile to expert workflows, and chosen by people who have not built software since Subversion was a personality test, your engineers will route around it. They should. The organization created a bad system and the operators responded like operators.
But “let everyone pick whatever they want” is not autonomy either. It transfers an enterprise production-system decision to people closest to the workflow, but not accountable for the full risk, economics, commercial exposure, and measurement model.
The executive dodge is subtle. You ask the people closest to the work what they like, then you pretend their preference resolved the enterprise decision you did not know how to measure. That is not respect for engineers. That is using engineers as cover for a missing operating model.
Engineers own workflow truth. They own technical risk signals. They know whether a platform helps them move through a hard codebase, whether the model loses context, whether the agent makes brittle edits, whether the review loop is useful, and whether the local workflow is tolerable. Listen to that. If you do not, you will buy a beautiful enterprise coffin and ask engineering to climb in.
Leadership owns the enterprise consequence. The CTO owns technical fit. Security owns the risk controls. The CFO owns the economics. Procurement and legal own the commercial wrapper. Engineering owns workflow evidence. People leaders own role clarity and capability development. The executive team owns the operating model.
Listening to engineers is not the same as letting a vote choose the production system. When those decision rights collapse into “let the teams choose,” nobody is getting autonomy. The leadership team is avoiding the decision.
Fragmented Tooling Destroys the Measurement You Need
The first visible problem with every-team-picks tooling is security. That is where the argument usually starts because security can find the mess: personal keys, free tiers, source copied into web tools, prompt history tied to personal accounts, vendors nobody reviewed, and data residency nobody can answer. Security discovers it during an audit and everyone pretends to be surprised.
That problem is real. It is just not the whole problem.
The bigger executive problem is that fragmented AI tooling destroys your ability to learn as an organization.
Team A uses one platform. Team B uses another. The platform team built a wrapper because they are allergic to waiting. One senior architect has a local setup nobody else understands. The mobile team has a different model policy because their lead watched a benchmark video. Procurement approved two vendors, finance sees six charges, and your VP (Vice President) of Engineering is presenting adoption numbers that are mostly a seating chart with optimism.
Now the board asks what AI coding has improved.
Finance has vendor bills but no cost-per-outcome view. Security finds source code in personal accounts. Engineering has no comparable defect data. Procurement has no renewal negotiating power. The COO cannot tell whether release reliability changed. The CTO cannot prove which workflow produced better engineering results and which team simply had stronger people.
This is how a company spends money on AI and still cannot answer whether the software production system improved.
The platform was chosen on sentiment because the measurement system was too weak to support a better decision.
If you cannot compare lead time, review quality, escaped defects, rework, support load, cost per accepted change, audit evidence, and delivery predictability across the tools, “the developers prefer it” becomes the whole business case. That may be fine for a keyboard shortcut. It is not fine for the system that is starting to produce your software.
I keep coming back to putting tokens in the portfolio P&L because the token bill is only one visible line. The larger question is whether the company can tie AI labor and human labor to accepted outcomes. Fragmented tooling makes that harder, not easier. It turns software production into isolated booths, then asks finance to evaluate the factory.
That is not management. That is a popularity contest with a procurement trail.
Procurement Is Where the Popularity Contest Gets Expensive
Procurement often gets treated like the department that slows everything down until the vendor gives up or the quarter ends. Some of that reputation has been earned. Still, in this case, procurement is not the side quest.
An AI development platform carries commercial exposure that a favorite editor never carried.
Someone has to negotiate data-use terms, model-training restrictions, retention limits, audit rights, indemnity, termination rights, renewal discipline, offboarding support, and vendor consolidation. Someone has to know whether the vendor can support SSO, SCIM, role-based access, audit logs, approved model routes, source-access boundaries, prompt and session retention, secrets handling, generated-dependency policy, test-evidence standards, exception handling, and cost attribution.
That is not purchasing clerical work. That is production governance.
If each team picks its own tool, procurement loses purchasing power, legal loses contractual consistency, security loses a coherent control surface, finance loses a denominator, and engineering loses shared learning. I made the Salesforce version of this argument already; the PLM version is worse because the system now touches production evidence. The fact that one team is happier for three weeks does not offset the enterprise system you just failed to build.
This is also where global companies should stop pretending this is a domestic tooling decision. Data residency, GDPR, the European Union (EU) AI Act, sector-specific audit obligations, model routing, retention, and vendor-risk evidence matter. If you operate in finance, insurance, energy, pharma, healthcare, government, or any sector with formal audit obligations, the tool choice is already a governance choice.
A board does not need to approve the coding tool. It does need assurance that management can govern the system now influencing software cost, quality, IP exposure, security posture, and delivery capacity.
The board question will not be, “Which coding tool did the developers like?” It will be, “Who allowed the software lifecycle system to fragment into personal tooling decisions?”
That is the homecoming problem. Everyone can explain why they voted the way they voted. Nobody owns the outcome.
The Old Autonomy Model Solved Yesterday’s Constraint
The old developer-happiness argument was not wrong. It was calibrated to the old bottleneck.
When humans were writing most of the code by hand, cognitive load mattered differently. A senior engineer who had spent ten years inside Vim, IntelliJ, Emacs, Visual Studio, or a specific terminal workflow had real accumulated advantage. Forcing them into a tool they hated was not governance. It was self-harm with a policy memo attached.
That is why the better organizations gave developers room. Pick the editor. Pick the terminal. Tune the local environment. Remove pointless friction. Measure outcomes instead of compliance theater. I still believe that.
The mistake is assuming AI keeps the same boundary. The editor used to be where a human typed. The AI platform is where the organization captures context, produces code, routes inference, generates evidence, applies guardrails, records decisions, and increasingly teaches the next engineer how the system works. This is closer to the lifecycle system than to the keyboard.
The old autonomy model optimized for individual flow. The new operating model has to optimize for organizational learning without crushing expert judgment. You cannot solve that by asking every developer which tool they like. That gives you preference data. Preference data is not lifecycle architecture.
Your Best Engineers Should Shape the System, Not Each Own One
Do not lock engineers out of the decision. That would be the usual enterprise move, and the usual enterprise move is how you end up with a tool nobody uses except when screenshots are due.
Your best engineers should be deeply involved. They should test the platforms against ugly production work, not demo repositories. They should define good context handling, identify failure cases, decide where agent output needs human review, and have a formal voice in exception approvals.
Standardization without practitioner veto power creates shadow tooling. It also creates resentment, and resentment is how unofficial tooling survives budget cuts, audits, and executive memos.
But those engineers should shape one system.
Software needs mature input from practitioners without importing the meeting disease. Engineers can keep local workflow preferences, editor habits, prompt style, refactoring judgment, architecture debate, code review standards, and the right to propose exceptions when the default path is wrong. The platform is governed. Engineering judgment is not flattened.
That matters for people as much as process. A common platform can create common training, shared evidence, clearer job expectations, fairer performance measurement, and less anxiety than a tool free-for-all where only the most aggressive engineers benefit. If your AI rollout creates insiders and outsiders based on who found the best tool first, that is not autonomy. That is accidental workforce design.
If the system cannot support strong engineers, fix the system. If one engineer’s preferred tool is better in a way that matters, run the evidence through the lifecycle decision. Maybe the standard changes. Maybe the preferred tool becomes an approved extension. Maybe the exception stays local because the use case is narrow.
That is how mature organizations govern production systems.
Run the Ninety-Day Decision Like an Evidence Trial
Executives often treat this as a forever decision because tooling markets are moving fast. They are right that the market is unstable. They are wrong that instability excuses non-decision.
You do not need to pick the winner for the next decade. You need to pick the operating model for the next ninety days.
Assign an accountable owner. Include the CTO or CIO, VP of Engineering, security architecture, platform engineering, finance, procurement, legal, people leadership, and ten to twenty senior practitioners who still build enough to know when a demo is lying.
Pick one primary platform for AI-assisted software delivery. Give it enough access to be useful and enough governance to be defensible. Put serious engineers on production work inside it, not training exercises or toy work. Use work that was already on the roadmap and already has a value owner.
Define the minimum controls before the work starts: SSO, role-based access, source boundaries, model routes, prompt and session retention, audit logs, secrets handling, generated-dependency review, test evidence, exception criteria, cost attribution, and offboarding.
Measure the things that matter: merged pull requests tied to roadmap work, lead time from ticket to deploy, review iterations, defect escape rate, test coverage movement, incident follow-up quality, support load, cost per merged change, and whether the evidence produced by the tool survives your release process.
At the same time, keep an explicit exception lane. If a team believes another tool is materially better, make them prove it against the same lifecycle metrics. No vibes. No “the developers like it better” as the whole argument. Preference matters, but preference is an input to the decision, not the decision.
The first question for any AI program: what does this organization measure, and what does the measurement reward?
Ask a better question. Which platform helps the company produce accepted software outcomes with less rework, better evidence, lower operational drag, cleaner commercial control, and less anxiety for the people doing the work?
At day ninety, make the call again with evidence. Expand, adjust, replace, or create a bounded second path where the economics justify it.
That is different from standardization theater. Standardization theater says, “The platform is chosen, please comply.” Lifecycle governance says, “The platform is chosen for this operating window, the evidence will decide what changes, and exceptions have to prove they improve the production system.”
One creates shadow IT. The other creates organizational learning.
Stop Calling This Tool Preference
The language matters because the language is hiding the decision.
When you call AI coding platforms “developer tools,” you send the decision down into the organization. When you call them “PLM-like control planes for software delivery,” “software production systems,” or “AI-SDLC systems of record,” the decision moves back to the level where it belongs.
That does not mean the CTO decides alone. It means the CTO, CFO, COO, security, procurement, legal, product, people, and senior engineering leaders have to make one coherent operating decision instead of pretending a hundred local choices will add up to strategy.
The local choices will add up. They will add up to a system. The only question is whether you designed it or discovered it during an audit.
A surgeon’s craft is not diminished because the hospital governs the operating room. It is protected. The surgeon can focus on judgment because the system handles traceability, safety, inventory, records, billing, compliance, and learning.
Your engineers deserve the same respect.
Do not make them each run a private software factory and then call it autonomy. Do not make finance guess what the factory costs. Do not make security discover the factory after it is already in production. Do not make the board ask why the company has no lifecycle view of the most important change to software delivery in a generation.
Pick the system. Let the craftspeople shape it. Measure the outcomes. Keep the exception path honest.
If the best argument for your AI coding platform is “people like it,” you have not selected the platform yet. You have measured the campaign.
This is already becoming your software operating model. The only open question is whether leadership designs it now or explains it later.
Companion
