Developer, I owe you a cleaner explanation than the one you got in the town hall.
You heard me say we needed to adopt AI. You saw the license rollout, the training plan, the acceptable use policy, the security guidance, the lunch and learns, and the dashboard that made it look like the company had finally decided to move.
Then you used the tools on real work and saw the obvious thing.
The code moved. The company did not.
You generated the test harness nobody had time to write. You explained the old service better than the wiki did. You took a feature that usually becomes a six-week planning object and made a working slice in three days. Then you watched the same architecture review ask for one more pass, the same security exception require the same form, the same release calendar say no, and the same business owner protect the quarter they already promised.
From your seat, the conclusion is simple.
I do not mean it.
I understand why you think that.
I am asking you to understand the part of the job you do not see.
I want predictable more than I want faster. I do want better software. I want fewer meetings, cleaner systems, shorter lead times, less manual testing theater, less ceremony around obvious changes, and fewer engineers spending their afternoons explaining to a ticketing system what they already explained to three people.
But if you ask me what I am paid to protect, the honest answer is not speed.
It is predictability.
In regulated environments, predictability is not caution for its own sake. It is how you keep audit, security, legal, and customer risk promises intact.
Faster is nice. Predictable is something I can bet on.
A slower system I can forecast will beat a faster system that creates surprises I cannot contain. That is how executives think when the quarter is real, the customer commitments are real, and a board member can turn one bad surprise into three months of defensive work.
I can defend a delivery system that is slower than I want but behaves the way I expect. I can plan around it. Finance can plan around it. Sales can plan around it. The CEO can speak around it. Customers can be managed around it.
I cannot defend a delivery system that becomes fast in one pocket, unpredictable everywhere else, and politically expensive the moment the demo touches production.
That is the tension you are running into.
You are showing me speed.
I am asking whether that speed can become something the company can trust.
Greenfield AI is not the problem. Yes, AI in a greenfield can give me what I want.
A clean codebase, a small team, direct customer access, a short path to production, a test suite everyone trusts, and a product owner who can decide without three layers of translation. That is exactly where AI can make software feel smooth instead of merely fast.
I understand why you look at that and say, "Why don't we just work that way?"
Because this is not greenfield.
This is a living company with old systems, unmerged acquisitions, peak season freezes, customer promises, data rules, release calendars, security exceptions, budget cycles, and teams whose incentives were written for a different era of software.
When you show me a three-day slice, I do not only see the code. I see the identity system it touches, the data contract nobody has owned since the acquisition, the checkout, fulfillment, clinical, or operational path that cannot degrade during a critical business window, the manual reconciliation process hiding in Finance, the vendor support agreement that says one thing and behaves like another, and the Vice President who will ask why your team gets to skip a gate their team still has to pass through.
That does not mean your work is wrong.
It means your work creates obligations.
In a merged company, those obligations multiply. A clean AI-assisted change in one legacy product can expose a billing rule from Company A, a data retention promise from Company B, and a customer workflow Company C never documented but still depends on every day.
We operate in low trust. This is the sentence people do not like saying out loud.
We operate in low trust.
That does not mean I think you are untrustworthy. It means the system around you has taught everyone to verify, re-verify, escalate, document, route, approve, and protect themselves before they believe anything is safe.
Half our systems were written under incentives that rewarded delivery over ownership: lowest bid contracts, rushed acquisition teams, exhausted contractors with no domain context, internal teams measured on local delivery instead of long-term stewardship, vendors that changed names twice, and project groups that disappeared the day after go-live.
The code compiles. That is not the same as the system being understood.
The dashboard is green. That is not the same as the risk being gone.
The documentation exists. That is not the same as the documentation being true.
The test suite passes. That is not the same as the customer workflow being protected.
The experiment lift is real. That is not the same as the customer workflow being protected at scale.
Low trust means I assume the integration has a side effect nobody remembers. It means I assume the service returns a success code when the business process failed. It means I assume the team named in the ownership file has not owned the thing for four reorganizations. It means I assume the temporary exception became infrastructure because nobody wanted to fund the real fix.
AI can help expose that mess. It can explain code, draft tests, find patterns, and make a capable engineer faster.
But AI does not magically turn a low trust delivery system into a high trust one.
Before I let AI-assisted work change a production path, I need ownership, rollback, audit trail, security review, support readiness, and a named person who understands the business consequence if the change is wrong.
And when the work touches real systems, treat the agent output as untrusted until data exposure, dependency changes, generated code provenance, and the review trail are clear enough to defend.
That part is operating model work.
Why I contain the pilot. This is the part you experience as hypocrisy.
I say the company needs AI. Then I put your work in a pilot.
I give it visibility, training, executive sponsorship, and a dashboard. I let people present the demos. I let everyone feel the future for six weeks.
What I do not give it is full authority.
You want the pilot to remove unnecessary approval drag, embed security with decision rights and audit responsibility, change funding from annual project allocation to product flow, make architecture advisory instead of blocking, and move product decisions closer to the people writing the code.
You are not wrong.
That is the real work.
The test is whether the pilot is creating evidence for an authority change, or merely creating a demo we can praise while leaving the system untouched.
It is also the political fight.
If I give one team that authority, every adjacent team asks why they do not have it. If the work goes well, the operating model is on trial. If the work goes badly, I own the risk. If the work exposes that we have been spending two quarters on what can be done in two weeks, I have not created a productivity story. I have created an accountability problem.
That is why pilots are allowed to learn but not allowed to threaten.
I am not proud of that sentence.
I am telling you because it is true.
Do not miss the opportunity inside the compartment. Here is the part I do not want you to miss.
I am giving you time and funding to get genuinely good at this inside a compartment the company can tolerate. That may feel small compared with the transformation speech, and I understand why, but it is not nothing.
Use it.
Get great at directing agents against our actual systems. Learn where they help and where they lie. Learn how to turn vague work into clear instructions, how to read generated code without trusting it blindly, how to build tests that expose the old assumptions, how to document the hidden dependency before it hurts someone, and how to make the next person faster because you left the work clearer than you found it.
That skill will matter here if we manage to move authority.
It will matter in the next role, team, or company if we do not earn the right to use it here.
And you need to weigh that honestly. AI may not get good here as fast as you want. It may take years, maybe a decade, for this company to move from licensed tools and bounded pilots to a high trust operating model where capable people can build with the authority the work requires.
That is not a reason to waste the opportunity in front of you. It is a reason to be clear about the bargain. Use the time. Use the funding. Build the skill. Build the judgment. Build the receipts. Then decide, with a clear head, whether this company is becoming a place where that skill can compound or whether it is becoming the place where you learned enough to leave well.
I am not offended by that. I would rather be honest with you. You can become excellent here and still decide the best use of that excellence is outside this company. That is not betrayal. That is what capable people do when the room they are in cannot use the capacity they have built.
I will not call leaving disloyal if that becomes the rational move. Capable people notice when a company asks for transformation but refuses the authority changes transformation requires. My job is to make staying here a rational choice, not to ask you to subsidize our indecision.
I may not be here in five years either. Leaders make the same calculation. Maybe I retire. Maybe I find a smaller place where the distance between decision and action is short enough that building feels like building again. Maybe I simply decide I have done what I can inside this constraint.
So why would I ask you to pretend your patience has no price?
I am making the same bargain from the executive seat. I am working inside the constraints, moving what can be moved, creating proof where proof can survive, and deciding how much political cost the next step is worth.
And I will tell you something else you may not expect from someone in my seat. This job is less about invention than constraint management. That does not make the work fake. It means any AI change that matters has to survive budget cycles, release gates, customer commitments, risk owners, and succession politics before it becomes normal operating practice.
So let us be pragmatic together.
Let us pick the work we can actually accomplish today with AI. Let us make tests better, documentation truer, old systems more legible, small workflows smoother, and real delivery evidence harder to ignore. Let us use the compartment without pretending it is the whole company.
Then you can use that experience to grow inside the company if the company earns it, and outside the company if it does not.
That is not cynicism.
That is the honest bargain.
My incentives are not as clean as my speeches. You hear the speech. I live inside the incentives.
The CEO wants an AI narrative for the board, but not a workforce surprise. Finance wants margin discipline, but I cannot take an unproven productivity claim to the board. The security chief wants no leaked source, no unreviewed dependency path, no tool approval gap, and an audit trail the company can defend when someone asks how AI touched production. The general counsel wants discoverability handled. The business unit president wants customer commitments protected. The product leader wants the roadmap to survive promises Sales already made.
All of those people are often right.
The People team is already seeing the anxiety in surveys, skip levels, and retention risk. A faster pilot that makes roles feel disposable is not adoption. It is trust debt.
That is what makes this hard.
There is also my own politics.
Some of my direct reports want my job. That is not a scandal. That is how succession works. The CEO's former Chief Technology Officer from the last company is still in the background too. Maybe not openly campaigning for anything, maybe not even thinking about this company every day, but close enough that everyone knows who gets called if I turn a promising AI program into a board level mess.
So when you bring me a demo that proves the old process is too slow, I do not only see the future. I see the people who will use that future to argue that I failed to move sooner, moved too recklessly, protected the wrong leader, threatened the wrong business unit, ignored the wrong control, or created the opening someone else was waiting for.
That does not make me noble.
It makes me careful.
And careful is not the same as opposed.
What I need from you. If you are an individual contributor, I need you to keep building proof, but I need you to understand proof is not the same as permission.
Show me the code. Show me the tests. Show me the before and after. Show me where the wait happened after the technical work was done. Show me which approval added safety and which approval added only delay.
Show me the control that still held, the risk that went down, and the failure mode you removed.
Do not just tell me AI made you faster.
Tell me whether it made the delivery system more predictable.
Give me measures I can defend: lead time after code complete, approval wait time, escaped defects, rework, release failure rate, manual handoffs removed, and customer impacting incidents avoided. If the work is faster but the control system cannot trust it, I cannot scale it. If the work is faster and the evidence shows the system became safer and more predictable, I have something I can take into the room.
If you are a manager, I need you to stop treating every blocker as executive cowardice and start naming the exact authority that would need to move. Release authority. Security authority. Architecture authority. Product authority. Funding authority. If you cannot name the authority, you are still arguing at the level of vibes.
If you are an eager director, I need you to understand that a beautiful demo can become a weapon pointed in every direction at once. It can help your team. It can embarrass another team. It can threaten a peer. It can create a board question. It can imply a headcount promise Finance will ask me to defend before we know whether the result survives contact with the rest of the company.
I am not asking you to slow down because I dislike the future.
I am asking you to help me make the future boring enough to survive.
The honest bargain. Here is the honest bargain.
Keep learning the tools. Keep building the muscle. Keep finding the places where code now moves faster than the organization. Keep the evidence clean, specific, and hard to dismiss.
This workflow reduced test writing time from three days to three hours. This refactor made the dependency graph visible. This production change still waited seventeen days after the technical work was done. This team could have shipped if Security had decision rights inside the team instead of arriving after the work was already politically committed. This customer workflow shipped, but first-call resolution stayed flat. This dispatch change cut planning time, but on-time delivery did not move. That is the difference between engineering evidence and operating evidence.
That evidence matters.
It may help me move authority. It may help your manager protect the team. It may help your next company if this one cannot cross the line. It will definitely sharpen your judgment.
But do not donate your life to a decision the company has not made.
Do not spend every night proving a future I have not yet accepted the political cost to buy. Do not let a pilot use your ambition as unpaid financing. Do not carry the moral weight of a transformation whose owners still want the benefits without the fight.
Be useful. Be honest. Be patient where patience is earned.
And when patience turns into theater, be clear-eyed enough to know the difference.
I am not moving slowly because I think AI is fake.
I am moving slowly because, in this company, speed without trust is just another way to create a surprise.