A new software engineering role can enhance the efficiency of AI usage in your organization.
It is a strange time to be a software engineer. What we do today looks nothing like what we did a year ago. This has generated a substantial amount of fear, uncertainty and doubt across the profession. Talk to enough engineers and you will hear the same complaints. Organizations can’t keep pace with how fast tools change. Token costs are forcing “tokenmining” to replace “tokenmaxxing” as the dominant strategy. Individual developers can’t afford to experiment when their tokens and time are needed to ship product. The result: most development teams haven’t optimized for cost or output. They’ve merely adapted, unevenly, team by team.
How much is that costing your organization? It is hard to say precisely. The fix, however, isn’t complicated. Software teams need a new role dedicated to fixing the problem: The AI Process Engineer.
Enter The AI Process Engineer
I attempted to optimize my AI use and share it with my team informally with the hope that some of my processes would be adopted by the entire organization. Although I could prove my proposals were beneficial, it was difficult to get the rest of the teams to pick them up. They were shared as interesting ideas, but without a voice of authority, few adopted them. It became clear that an organization of any size needs at least one engineer who is tasked with keeping up with the rapidly changing AI landscape, understanding their organization, and making recommendations on how to best leverage tools across it. I call this role the “AI Process Engineer.” If we simply called it “AI Engineer” it would be confused with those who write models or agents. So, how would I define this role?
How Can You Afford Not To?
A CFO might immediately bristle at this idea. It looks like new headcount, or more realistically, an existing engineer pulled into a new role that may need backfilling. Consider the math instead. Say you have twenty software developers actively using AI. If your AI Process Engineer can improve their collective output by a modest five percent, that’s roughly a full developer’s worth of gain, for the cost of reassigning one.
The Architect Problem
A software architect likely isn’t who you want in this role. Architects are good at designing large systems and choosing technologies those systems need. On paper, they are a natural fit to lead this effort. However, architects don’t have to be as tactical, or as practical, as engineers are. An architect might have particularly good input on how AI can be used in software architecture itself. That insight is valuable, but most of your development staff are engineers, not architects. Day-to-day knowledge of where the inefficiencies actually live, and what each engineer experiences task by task, is critical to understanding how AI tools should be applied.
AI Process Engineer Must Deliver Code
This role requires a real trade-off. If you move an existing engineer into it, reduce their prior workload. Do not count on the output they were delivering before. That said, don’t eliminate it either. They should still own and deliver real code, at a smaller scale, in the space they came from. This keeps them grounded. Without it, AI Process Engineering becomes an academic exercise. The engineer stops feeling the consequences of their own recommendations and starts proposing things that don’t hold up in practice. They need boots on the ground to directly evaluate AI systems, standards, and procedures — not secondhand impressions of how well something works.
Delivering Code Is Not The Goal
AI, by its nature, is non-deterministic. We can’t simply ask model A and model B the same question, compare answers, and declare a winner. Prompts that work well in one model may fail in another for reasons that have nothing to do with which model is actually better. Context windows vary. Comparing two models well is serious work, even though it sounds simple. An AI Process Engineer may implement the same code task using several different models or procedures to determine what actually performs best. They may repeat this across multiple types of tasks to confirm results hold up. Here, delivering code is important. It grounds the work in practicality. The valuable output is not the code itself. It’s the understanding and constant iteration of the process that produced it.
Measure Whenever Possible
Opinions matter. Data matters more. The AI Process Engineer should be responsible for measuring the changes they propose as they roll out to the organization. This is a tougher challenge than it sounds. I’m sure you’ve heard “Token costs are constantly falling!” There is truth to that. The reality is often more complex. For example, Claude Opus 4.7 introduced a new tokenizer that can use up to 35% more tokens for the same text, even though the price per token didn’t change. Most teams never notice this kind of shift. They see the bill go up and assume something else is wrong. A successful AI Process Engineer has to figure out what to measure. Tokens? Cost per task? Cost per month across the org? Even before deploying a recommendation, they need a way to measure what they’ve been working with. Otherwise, you end up with the “well, system A feels better than system B” syndrome.
The AI Process Engineer Toolbelt
Most organizations restrict AI use for one of two reasons: cost or security. That’s understandable, but it works against this role. The more tools you allow your AI Process Engineer to use, the more likely they are to find something genuinely useful. They need a real budget to trial as many tools as possible. If your company standardizes on Claude, you still need a way to let your AI Process Engineer evaluate tools like Codex or Kiro, even if you never offer them to the whole organization. Likewise, the AI Process Engineer should partner with security to clear the way for research and to make sure whatever eventually gets deployed is something security has actually signed off on. There’s no point in creating this role if you do not free them to get the answers you need.
Conclusion
If you do not have an AI Process Engineer, it means every dev on your staff becomes one. That kind of broad experimentation may deliver results, but it cannot be controlled. Devs may be reluctant to experiment because they want their tokens for delivery. Worse yet, they may miss deliveries because they are more interested in experimenting. Without a process and people driving this deliberately, best practices get rolled out unevenly across your organization, and you never see the gains an AI Process Engineer could have delivered.
Photo taken on 401 Trail, Crested Butte Colorado