Traditional “developer” still carries the old club signals for many people: CS degree, deep language fluency, holding a call stack in your head, shipping customer-facing product code. IT Pros spent years saying the opposite out loud —“I just write a little PowerShell,” “I only do KQL,” “I glue things together”—as a way to stay in their lane and avoid scope creep. That habit is sticky. Even when the tools now let you stand up a repo, generate tests, and ship something useful before lunch, the internal voice still asks for permission.
AI didn’t invent a new job. It made the old one harder to hide.
What actually makes the shift feel real
Comfort doesn’t come from a title change. It comes from ownership of artifacts:
- You specify the outcome in the same language you’d use with a competent junior.
- The model drafts.
- You read it, break it on purpose, constrain the identity and tool surface, log the actions, and can explain it when it fails.
- You put it in a repo with a README that notes the identity it runs as and why it exists.
That last step is the identity move. A script on the desktop is a trick. A reviewed, testable, documented tool is software. Once you’ve done it a few times—especially something that deletes tribal knowledge for the next hire—the question “Am I a developer?” starts to feel like a category error.
The broader industry is already redefining the role even for people who came up through pure software engineering. Advanced AI users describe themselves less as code producers and more as orchestrators or “creative directors of code”—defining intent, guiding agents, resolving ambiguity, and verifying correctness. Domain knowledge (the systems, the failure modes, the blast radius, the business unit that still has a legacy VPN exception) is the scarce resource. Syntax never was. IT Pros already live there.
On the naming ideas
“Developer” is fine once the work qualifies you, and the article’s stance is the strongest one: stop waiting for permission.
If the pure title still feels like borrowing someone else’s credential, the hybrids you mentioned are practical bridges:
- IT Developer is the cleanest. It keeps the domain expertise front and center while claiming the development work. It signals “I build software that lives inside and against the systems I already understand.” It is accurate, searchable, and doesn’t require pretending you spent your twenties writing consumer apps.
- Developer Pro works if you want the professional/operations connotation stronger, but it can still sound like “pro developer” to some ears and may not reduce the imposter friction as cleanly.
Either is better than continued self-erasure. Plenty of people already update LinkedIn and résumés with outcomes (“Developed automation that reduced X by Y% using PowerShell + Copilot”) rather than waiting for a formal title change. The market is increasingly hiring for problem understanding + AI fluency over pure language speed.
Practical path to comfort
- Ship one small, owned artifact this week (the weekly report, the offboarding checklist, the KQL you retype from memory).
- Treat AI as a pair that drafts; keep the judgment, auth path, secret handling, and rollback on you. That’s AI-assisted engineering, not pure vibe shipping.
- Put it where others can see it (internal repo, GitHub, a short write-up).
- Notice that software engineers are now discovering the operational and security instincts you’ve had for years. You’re not late. In many cases you’re early.
The people who understand the systems can now change the systems without waiting in someone else’s backlog. That has always been part of the IT Pro job. The tools just made the “we’re not real developers” apology optional.
You already know which shortcuts get people paged. What are you going to build with that?