limited·by·sleep
$ cd ~/published

Early in my career I was told not to use open source software

Early in my career, I was told not to use open source software. Company policy. Too risky, too uncontrolled, too much liability.

Then it was Stack Overflow. Don't copy code you don't understand. Don't trust answers from strangers on the internet.

Then ChatGPT arrived and the message was the same. Don't use it for work. Don't paste proprietary code into it. Don't trust what it gives you back.

Now it's AI coding agents writing code and committing changes that developers haven't fully reviewed. Same fear, same response. Ban it. Block it. Pretend it isn't happening.

To be clear, how you use these tools as a developer matters enormously. Blindly accepting code you don't understand is a problem regardless of where it came from. But that's a different conversation. What I want to focus on is the company policy side, because whether leadership approves or not, adoption is happening. You cannot stop it.

I've watched this cycle repeat for over fifteen years and the outcome is always identical. The tools win. Developers find ways around the restrictions because the tools make them more productive, and productivity is hard to argue with.

The amount of energy organisations pour into fighting adoption is staggering. Policy documents, compliance reviews, monitoring tools, disciplinary conversations. All to delay the inevitable by a few months while competitors gain ground.

This is where technical leaders who still code make a real difference. They understand what developers are actually using day to day, not what the policy says they should be using. That perspective is invaluable when setting realistic policy and explaining to senior leadership what's actually happening on the ground. I've found this to be the single most useful thing about staying hands-on as I've moved into leadership.

Most companies focus entirely on what they're trying to stop and never ask what they're actually trying to protect. If the real concern is IP leakage, solve for IP leakage. If it's code quality, solve for code quality. Banning the tool is treating the symptom and ignoring the cause.

Nothing stays the same for long. The only question is whether you adapt before or after it costs you.

follow via rss