If you think AI is coming for your job, you are the person best placed to take it
Twenty years of enterprise development taught you something a model has only read about. That turns out to matter more than anyone expected.

“A model has read about that. It has not stood in it at half past six on a Friday.”
The developers most convinced this technology will finish them are, in my experience, the ones with the deepest advantage in it. They cannot see it because they are looking at the wrong part of their own work.
You have spent two decades on the Microsoft stack. C# and .NET, Power Platform, integration work, the long unglamorous business of making systems that were never designed to meet each other exchange data without losing anything. An announcement lands about the company's AI initiative and you get the same feeling you had when everything was going to the cloud, and before that when everything was going to be outsourced, and you wonder whether the thing you are good at is about to stop being valuable.
I understand the feeling. I would say it is aimed at the wrong target.
What you actually know#
You did not spend twenty years learning syntax. Syntax was the cheap part, and you have picked up four or five languages without particularly noticing.
What you accumulated is something considerably harder to replace: an instinct for how technology meets a business problem. You know that the requirement as stated is never the requirement as needed. You know which integration will break first and roughly when. You know that the exception handling nobody wants to pay for is the bit that determines whether the thing survives contact with actual users. You know, without being able to fully justify it, that a particular approach is going to cause pain in eight months, and you are usually right.
That last one is worth sitting with. The senior engineer's hunch, unjustifiable and correct, is not mysticism. It is compressed experience of things that went wrong, and it exists in you because you were in the room when they went wrong. A model has read about that. It has not stood in it at half past six on a Friday.
There is only one way to acquire that instinct, which is to be present for failures. We learn from our failures rather than our successes, and you have a fuller library than almost anyone.
The translation is smaller than it looks#
Set aside the mystique for a moment and look at what working with these systems actually involves.
You send a request to a service and handle the response. You have done that ten thousand times. The response is less predictable than a typical API return, so you validate it more carefully and design for the case where it is wrong, which is exactly the discipline you already apply to any integration you do not control.
Orchestrating multiple agents is workflow design with more capable steps. You have built that in Power Automate. The boxes make better decisions now and are less reliable about it, which changes the error handling rather than the shape of the thing.
Getting good results out of these systems is requirements definition. Being precise about what you want, what form it should take, what constraints apply, and who the output is for. That is the skill you have been exercising against difficult stakeholders for twenty years, now applied to something that cannot read your face when it has misunderstood.
None of this is a new profession. It is your profession with the tedious middle removed.
The bit worth being honest about#
I should name my own bias here, because it runs through everything I write on this subject. I am optimistic about people's appetite to learn, probably more optimistic than the evidence supports, and it is the thing I get wrong most often.
Some people will not do this. Not because they cannot, but because adapting is uncomfortable and it is easier to be aggrieved. I have watched capable people spend more energy explaining why the new thing is overhyped than it would have taken to learn it, and I understand the impulse, because being suddenly junior at something after years of being the person others asked is genuinely unpleasant.
But there is a trap in that response worth naming plainly. When practitioners announce loudly that this technology makes their work worthless, they are corroborating the vendor's pitch in front of exactly the audience it was aimed at. The people signing the cheques do not hear a warning. They hear the expert confirming that the expensive humans are optional. You are feeding the wrong animal, and when it is fed it will bite the hand.
If you want to make the opposite case, the way to do it is to be visibly better with the tools than anyone who arrived without your background. That argument cannot be dismissed as self-interest, because it is demonstrated rather than asserted.
The window is not staying open out of politeness#
A new group is coming into this work from other backgrounds. Some are from analytics, some from operations, some from nowhere near technology at all, and a proportion of them are very good. They are not weighed down by having done it the old way, which is a disadvantage in ways they have not discovered yet and an advantage in ways that are immediately obvious.
They will take this opportunity if the people already holding the domain knowledge will not. That is not a threat, it is simply how these transitions have always gone, and I have watched enough of them to have stopped being surprised.
So if someone would rather sit this one out, c'est la vie, that is a legitimate choice and they are entitled to it. But it is a choice, and it should be made consciously rather than arrived at by drift.
The pairing that actually works is not a person replaced or a person assisted. It is your hard won miles doing the judging while the machine handles the grunt, and I think anyone who gets there properly discovers it is the most interesting the work has been in years. It certainly has been for me.
Bring us the problem.
A short, no-obligation call. If we are not the right fit, we will say so and point you somewhere better.