AzamSharp
Developers Are Safe… Thanks to Corporate Red Tape
By the end of 2026, AI will write most of the code and software developers will be obsolete. There is no need to learn programming because you will be replaced by an AI agent. We have all heard these kinds of crazy headlines. I am here to tell you that the reality is quite different.
This post is a result of my tweet that got 80K+ views and 258 plus comments. The responses were passionate, but they also confirmed something I have seen over and over again in real enterprise environments. The world of corporate software development does not move at the speed of Twitter headlines.
jQuery Exception Paper Work
Let me first tell you a little story. Long time ago, I was working at an oil and gas company in Houston, Texas. The codebase had been implemented by an offshore company and it was an absolute mess. It was a .NET web application with hundreds of JavaScript files, and each file contained at least 5000 lines of code. A lot of that code was simply recreating effects and user interface components that could have easily been implemented using a third party library like jQuery. Yes, this was a long time ago.
After working with the code for a couple of days, I suggested that we should use jQuery to speed up development and avoid rebuilding the same things over and over again. My manager told me that we could not use any third party dependencies unless I filled out an exception paper work request. I had to indicate in detail the purpose of the library, where it would be used, which functions would be used, and which files would be altered. It was not a casual approval. It was a formal process.
I completed the paper work. Two weeks later, jQuery was granted an exception and I was allowed to continue the work, this time moving much faster. Two weeks for a tiny JavaScript library. That was the reality.
You might think this was an isolated incident. Unfortunately, it was not.
Stay Outside the Office
Here is another one. I was working at a very large oil and gas company and was tasked with creating an iPhone app. This was during the Objective C days, around iOS 3. The app was meant to be deployed internally using an Apple Enterprise account. After I finished the app, I discussed deployment with my manager. I told them that I had deployed personal apps before using a personal account, but I had never done an Enterprise deployment.
I suggested that they log into the Enterprise account and sit with me so I could see the interface and guide them through the process. They refused. They would not allow me to see the Enterprise account login due to security concerns. Instead, they made me stand outside their office while they logged in. They described what they saw on the screen, and I had to tell them what to click. If you see a Next button, click that. Enter the app name. Upload the build. I deployed an enterprise app by listening to someone narrate the screen from behind a door.
Agile Development Is Not for Us
At another very large finance company, I was consulting on a greenfield iOS project. The company was not familiar with Agile principles, so we conducted an introduction session explaining sprints, scrum, velocity, and iterative development. We walked them through how Agile could improve feedback cycles and delivery speed.
After the session, they told us that Agile seemed too complicated and that they would rather stick with their existing process, which was waterfall. This was for a brand new mobile project, yet they preferred the comfort of a rigid, document heavy approach over adaptive development. Change, even when beneficial, was seen as risk.
Pandas, Matplotlib, Scikit Learn Oh My
One of my friends who works at an enterprise company told me that they had to go through several levels of clearance just to install and use Pandas, NumPy, and Matplotlib. The concern was that these libraries might somehow steal data. These are widely used open source libraries that power research, analytics, and machine learning around the world, yet they were treated as potential threats requiring formal approval.
The point of these real stories is simple. When tools as basic as jQuery require weeks of approvals, how can we assume that the same companies will welcome AI tools with open arms? These are the same companies that provide limited access to online AI tools. These are the same companies where YouTube and Stack Overflow are blocked. These are the same companies that built their own internal code repository instead of using GitHub.
Final Words
You might say that these companies will eventually be replaced by forward thinking organizations that embrace AI agents and automation. That sounds nice in theory. In reality, I am talking about insanely large companies. Their coffee budget is larger than some smaller competitors’ entire operating budgets. They are not disappearing anytime soon.
And let me be clear. The stories I shared are only a few examples. This kind of red tape is extremely common, especially in non IT companies such as oil and gas, healthcare, finance, manufacturing, and other highly regulated industries. In these environments, compliance, risk management, security audits, and approval chains are not optional. They are built into the culture. Nothing moves fast. Every new tool, every dependency, every external service goes through layers of review. AI will not magically bypass that structure.
As much as we may complain about how slowly these organizations move and how resistant they are to adopting new technologies, that same resistance is what slows down radical change. These will be the companies that move cautiously with AI agents. These will be the companies that continue to rely on experienced human developers who understand business rules, compliance requirements, risk management, and the real consequences of mistakes.
AI will absolutely change how we work. It will make us faster and more productive. But the idea that developers will be wiped out overnight ignores how corporate systems actually function.
Stay strong and keep coding 😉