In September 2024, OpenAI released o1-preview, a model that changed the conversation about what AI could do with technical problems. Unlike earlier language models that generated text token by token, o1 could actually reason, working through multi-step coding challenges, debugging scenarios, and mathematical proofs without being explicitly told each intermediate step. Within weeks, it was solving coding contest problems that stumped typical developers and explaining infrastructure failures with the kind of systematic breakdown you’d expect from a senior engineer with years of experience on the job.

At the exact same moment, OpenAI announced a structural shift: the company was moving toward for-profit operations, stepping back from its nonprofit founding mission. The messaging was dense with assurances about safety and long-term alignment, but the shift triggered familiar anxiety in tech circles. If the most capable models are now operating under profit-driven incentives, and if those models can reason their way through problems that once required expensive human expertise, what happens to the people who built careers around that expertise?

That anxiety is real, and ignoring it would be dishonest. But I’ve been in IT long enough to know that the answer is not “the robots won.” It’s more complicated, more interesting, and actually more favorable to the people willing to think clearly about what’s changing and what’s not.

What o1 Actually Does, and What It Doesn’t

o1 is genuinely capable in ways earlier models weren’t. It can work through a production incident involving multiple layers: infrastructure logs, application code, database performance metrics, networking context. It can hold all of that in its reasoning process and surface the root cause, often faster than a human would. It performs well on security code reviews, spotting credential exposure patterns, injection vulnerabilities, and architectural flaws that require understanding both the specific code and the broader security model.

That’s worth acknowledging directly. If your primary work has been straightforward script writing, routine credential rotation, or pattern-matching on error logs, o1 can do those things at scale without sleeping. The labor market will respond to that, and pretending otherwise is not helpful.

But there’s a real gap between “this model can solve a problem” and “this model can own the outcomes in production.” o1 doesn’t manage stakeholders. It doesn’t balance security requirements against business velocity and then make a tradeoff decision that the entire team agrees to own. It doesn’t know your organization’s risk appetite, your compliance obligations specific to your industry, or the three failed projects that shape why your current infrastructure looks the way it does. It doesn’t wake up at 2 AM to watch a production incident unfold in real time and make calls about whether to roll back or push forward.

Most importantly, it doesn’t own the consequences. When your database is down for four hours, the damage is measured not just in the technical fix but in lost revenue, eroded customer trust, and team morale. The decision about how to prevent the next one is a human decision, one that has to account for budget, team capacity, and risk tolerance. A model can inform that decision brilliantly. It cannot make it.

Where Automation Actually Accelerates

The real shift is more subtle than wholesale replacement. What’s changing is the economic value of human time in IT work. Consider a senior engineer’s typical week five years ago: 30% of their time went to writing code and infrastructure automation, 20% to code review and security assessment, 20% to incident response and troubleshooting, and 30% to strategy, mentorship, and cross-team alignment.

With o1 and the models that will follow, that math changes. Code review might drop to 10% of their time. Troubleshooting might drop to 10%. Writing routine automation might drop to 5%. But here’s the part that matters: that 30% of time spent on strategy, hiring, retention, and alignment doesn’t shrink, because humans still have to decide which problems to solve and why. It might actually grow.

Organizations that are smart about this will redeploy the freed-up time: more strategic project work, more attention to team culture and retention, more deliberate capacity for mentorship and junior engineer development. The companies that fail at this transition will keep the same headcount but expect productivity to match the new tools, which is a formula for burnout and attrition.

Your preparation is about recognizing which side you want to be on. If you’re currently a tactical individual contributor in routine infrastructure work, you have a narrow window to move toward strategic work, team leadership, or specialized domains (security, compliance, advanced architecture) where the human judgment multiplier is higher. If you’re already doing that work, o1 is a force multiplier for you, not a replacement.

The Staffing Reality

There’s another fact that cuts against the automation anxiety narrative, and it matters a lot: IT and security teams are still severely understaffed across the industry. At the same time o1 is being released, major organizations are struggling to fill security engineer roles, cloud architect positions, and senior SRE jobs. The staffing shortage is not going away because a model got better at writing code.

What’s changing is the shape of demand. Organizations will increasingly want people who can own systems end-to-end, who understand the business context, who can mentor junior people through problems, and who can make good decisions when there’s uncertainty. They’ll want fewer people writing purely mechanical scripts and more people thinking about architecture, risk, and organizational learning.

That’s actually favorable news if you prepare for it. The competition for pure script-writing jobs will increase. The competition for strategy and leadership roles is real but not as acute, because those roles require judgment and context that still comes from humans.

There’s a related point worth making about how organizations actually adopt these tools, because it rarely goes the way the headlines suggest. In practice, most companies don’t fire their IT staff and replace them with AI overnight. What happens instead is slower and more interesting: teams start using reasoning models as a second opinion, a drafting tool, or a first pass at analysis. The person who knows how to integrate that into their workflow becomes more productive, and the person who ignores it falls behind gradually rather than immediately. Over time, the team that used to need six people for a particular workload might need four, and those four are doing higher-value work than the original six were. The people who got displaced are the ones who stayed in purely execution-oriented roles and didn’t adapt. The people who thrived are the ones who treated the model as a collaborator and focused their own energy on the parts of the job that require judgment, relationships, and institutional knowledge. If you’re reading this and wondering which group you’ll end up in, the fact that you’re thinking about it at all is a good sign, because the people who get caught off guard are usually the ones who assumed the question didn’t apply to them.

Your Response, Starting Now

If you’re worried about o1, here’s what you should actually do. First, spend a few hours learning what it can and cannot do. Try it on real problems from your own work. Ask it to debug something you’ve worked on, write an automation script, or break down a security issue. See where it shines and where it falls short. That’s not busywork; that’s calibration. You need an accurate picture of the threat and the opportunity.

Second, think about whether your current role has a clear path toward strategic work, or whether you’re on a treadmill of tactical, repeatable tasks. If it’s the latter, that’s not a judgment on you; it’s information you need to act on. Start moving toward roles where judgment, stakeholder management, and decision-making under uncertainty are core to the job. That could mean infrastructure architecture, security strategy, platform engineering, or technical management.

Third, keep learning technical skills, but be strategic about which ones. Prompt engineering and AI literacy are becoming baseline skills, and not just for the people writing AI products. You need to know how to work with models like o1, how to ask them useful questions, and how to verify their output. That’s a skill in itself.

Finally, pay attention to what the broader AI picture looks like. o1 is one point in time, not the final destination. The competition between OpenAI, Google, Anthropic, and others means capabilities will keep advancing. That’s actually okay for you, because widespread adoption of these tools means organizations will invest in learning how to use them well, and that’s where people who understand both IT and AI have outsized influence.

The Honest Truth

o1 and the reasoning models that will follow are genuinely significant. They make some IT work more efficient, some problems faster to solve, and some decisions easier to inform. But they don’t change the fundamental dynamic: IT work is about managing risk, aligning with business goals, and making decisions that live with consequences in the real world. Those are human jobs. The tools keep getting better, and the work keeps shifting upmarket, but the core truth holds.

If you’re willing to shift your focus from execution to strategy, from task-completion to decision-making, from writing code to owning outcomes, this is a favorable time to do it. The upside is real, and the timeline is still open. That’s not excitement or worry; it’s clarity, and clarity is what you build a career on.