Your Future AI Developer Probably Already Works for You

Companies are making a mistake by trying to hire 'AI developers' for roles that haven't finished taking shape, argues Mark Ang, CEO of GoBolt, who says the best AI builders may come from operations, finance, and logistics rather than computer science. GoBolt is on track to eliminate roughly 2,000 hours of engineering work per week through AI-assisted development and workflow automation, without eliminating engineers.

Every technology revolution changes the workforce. The internet created web developers. Cloud computing created cloud architects. Cybersecurity became its own profession. Artificial intelligence will undoubtedly create new roles too, but I think we’re making one fundamental mistake: we’re assuming we already know what those roles are. Companies everywhere are trying to hire “AI developers.” Recruiters are searching for candidates with AI experience, executives are rewriting job descriptions, universities are racing to launch AI-focused programs. The problem is that practical enterprise AI has evolved faster than any established profession could form around it. Most organizations are hiring for a role that hasn’t finished taking shape. Instead of asking where to find AI developers, we should be asking what kind of people are actually going to become them. AI Starts With Modeling Reality Over more than thirty years building software-focused companies, I’ve become convinced that the defining trait of great developers was never their ability to write code. It was always their ability to understand reality well enough to model it. If you’re building software for a manufacturer, you have to understand how production actually works. If you’re building a CRM, you need to know how customers relate to opportunities, invoices, and payments, and where the exceptions live. Good software is a faithful model of reality. When the model is wrong, elegant programming just automates bad assumptions. AI doesn’t change that. It reinforces it. Large language models can generate code, summarize information, and orchestrate workflows with astonishing speed, but they don’t understand your business. They don’t know why experienced employees quietly bypass a documented process because it stopped reflecting reality years ago, or which approvals exist because of regulation versus culture versus simple inertia. Before AI can improve a workflow, somebody still has to understand that workflow well enough to take it apart. We’re seeing the scale of this firsthand. Inside our own engineering organization, we’re on track to eliminate roughly 2,000 hours of engineering work every week through AI-assisted development and workflow automation. That’s not a small efficiency gain, and it doesn’t mean we’re eliminating engineers. We’re growing faster than we can hire. AI is removing the drudgery so talented people can spend more time on harder problems, which is really the whole debate in miniature: AI isn’t replacing software development, it’s replacing the repetitive parts of it, the way high-speed production lines replaced repetitive manual assembly without replacing the engineers who design the line. The Best AI Builders May Never Call Themselves Developers This is why I don’t think the next generation of enterprise AI builders will come exclusively from computer science departments. Some will, but because they think in systems, not because they know a particular language or framework. Others will come from manufacturing, operations, finance, and logistics, because they’ve spent years learning how complicated organizations actually work. The manufacturing engineer who’s spent a decade removing bottlenecks, or the finance analyst who’s built increasingly sophisticated spreadsheets because commercial software never quite fit the business, may already have the most valuable skill AI development requires: they understand the problem before they think about the technology. We’ve seen this inside our own company. Cody Cecchetto, our Director of Engineering, didn’t get deeply into AI because it was assigned to him or because “AI developer” appeared in his job description. He got fascinated by it because he immediately saw how it could improve work he already understood inside and out. He wasn’t chasing a technology trend; he was chasing a better solution, and he couldn’t stop pulling at the thread. That’s a personality trait, not a certification. It’s the same instinct that defines a great mechanic. Great mechanics don’t just replace parts. They understand how every component interacts, mentally take the system apart, isolate the real source of a problem, and predict what happens when one variable changes. AI rewards that same instinct—people who understand relationships between parts, not just isolated tasks. Instead of asking candidates how many years of AI experience they have, which is a nearly meaningless question today, I’d ask whether they naturally take complex systems apart, improve broken processes without being asked, can explain a complicated business clearly enough to redesign it, and show the kind of relentless curiosity that keeps them chasing a problem after everyone else has moved on. That has real consequences for hiring. Frameworks and models will keep changing. That ability won’t. Universities face the same trap: a narrow AI degree built around today’s tools will always be chasing a moving target, while systems thinking and the ability to model reality accurately will still matter in five years, whatever the tools look like by then. AI is so new that nobody has twenty years of experience building it into every function of an enterprise. Nobody’s ahead on tenure, only on curiosity, and that should be encouraging for people entering the workforce. The companies that build the most valuable AI over the next decade will find their best AI builder already down the hall: the engineer who understands how the product actually gets built, running experiments on a workflow nobody asked them to fix, because they couldn’t stop thinking about a better way to do it. Hand that person a more powerful tool, and they’ll do what they’ve always done – keep pulling at the thread until the system works the way it should.