The Interconnection Study AI Engineer Is a Study Engineer Who Audits the Automation

Why Does Automating Interconnection Studies Create a New Engineer Instead of Removing One?

Because the bottleneck moves rather than disappears. A 400 MW solar-plus-storage project sits in a cluster, two projects ahead of it withdraw, the restudy reopens the network upgrade allocation, and the study engineer who could have finished it in three weeks is running the same power flow cases for the fourth time. Automation collapses that rerun to hours. What it does not do is decide whether the result is right.

So the job that appears is not the job that disappeared. Hand-running cases stops being the work. Deciding which automated results can be trusted, which contingencies the case builder silently dropped, and which model assumptions the software inherited from a stale base case becomes the work. That is a supervision role, and it needs somebody who has been wrong about a study before and remembers exactly how.

The pattern is visible in what employers are actually writing. GridCARE, a grid-headroom startup selling faster paths to power for data center load, is hiring a Power System Engineer for interconnection studies and asks in the same posting for a passion for improving the grid integration process through AI and automation, for the engineer to partner with AI and automation teams to streamline study processes and improve accuracy, and for experience applying machine learning and AI applications to power system studies ¹. That is one requisition doing two things: a conventional study engineer, redefined around steering the automation instead of hand-running it.

The category is still forming, which matters for how you search. Almost nobody holds this title. The role is being written inside existing power system engineer and transmission planning requisitions, with the automation clauses added to the bottom of the responsibilities list. If you search by title you will find nothing and conclude the talent does not exist.

Which Backgrounds Produce This Engineer, Including the Unexpected Ones?

The reliable source is anyone who has personally produced a study another party relied on: utility transmission planning groups, independent system operator study teams, the interconnection consultancies that run overflow work for utilities, and the in-house teams at large developers. Those people have run PSS/E, PSCAD, PowerWorld or ASPEN in anger, and more importantly they have had a result challenged and had to defend it line by line.

What separates the good ones inside that pool is not tooling fluency. It is whether they have ever built anything to escape their own repetitive work. Ask what they automated and you get a clean split: engineers who wrote a Python wrapper around a case builder, scripted contingency file generation, or built a spreadsheet that reconciled two software packages' results, versus engineers who did the same case by hand two hundred times and never thought about it. The first group already has the instinct this job runs on.

The unexpected backgrounds are worth naming because resume screens drop them. Protection engineers are excellent here, since a career of coordinating relays is a career of asking what happens in the case nobody modeled. Nuclear and aviation people who worked under a formal verification and sign-off culture carry the habit of separating what was computed from what was checked. Power markets and congestion analysts read network results fluently and are unusually good at spotting an outcome that is arithmetically fine and physically absurd. Grid operations engineers who have sat in a control room know what a model gets wrong about the real system.

What transfers less well than people expect is a pure machine learning background. Model building is a real part of this job, but it is the part that is easiest to hire around or contract. The scarce half is judgment about power systems held by somebody willing to disagree with a tool. This is the same asymmetry that makes a forward deployed product manager work: the domain half is the slow half to acquire.

Screen for the Engineer Who Has Already Caught Their Own Automation Being Wrong

The single best question: tell me about a time your script gave you an answer you believed and it was wrong. Real answers have texture. The base case carried a transformer tap nobody had updated since an upgrade. The contingency generator skipped a breaker configuration because a naming convention changed mid-file. Convergence looked clean because the solver had quietly relaxed a limit. A performed answer stresses quality assurance without ever naming a failure.

The second tell concerns how the candidate uses an assistant in their own work now. Strong answers are specific about verification: it drafts the Python that assembles the case files, and the first thing done is running one known case through both the script and the old manual path and comparing the flows, because a wrong file that parses looks exactly like a right one. A candidate who describes an assistant as generally accurate on power system questions has not checked it against a real case, and this job is nothing but checking.

The third tell is how they talk about the sign-off. Ask directly what they would refuse to let the automation decide. An engineer who has carried professional responsibility for a study will answer immediately and narrowly, usually around anything that sets a network upgrade cost or a curtailment condition on an interconnecting customer, because that number becomes somebody's contract. An engineer who says the human should review everything has not thought about throughput, which is the entire point of the hire.

A working screen is one session, not a take-home week. Give the candidate a small real case with a seeded error, an assistant, and forty minutes, and ask for a written finding: what the result says, what would need to be true for it to be right, and what they checked. What you are reading for is whether they went looking for the assumption before they went looking for the answer, and whether they said out loud which parts they could not verify in the time available. Do not screen for whether their written application was drafted with a model. That question is unanswerable and it predicts nothing about whether somebody can falsify a load flow result.

Where Do You Find This Person, and Who Is Visibly Hiring Today?

Start with the venues this discipline already has rather than with a job board. IEEE Power and Energy Society chapters and regional conferences are where transmission planning engineers gather. So are the interconnection stakeholder meetings the regional transmission organizations run, which are public, attended by study engineers themselves, and a good place to learn who is frustrated with their current queue workflow. University power programs with strong grid labs remain a genuine feeder.

The employer side splits three ways today. Utilities and regional transmission organizations have the study volume and the institutional constraint. Large renewable and storage developers hire the same skill to check what the utility sends back, which is a good candidate source since the work makes people fast and skeptical at once. And a set of grid-headroom and study-automation startups is now hiring directly against this shape, GridCARE's posting being a concrete example of what that requisition looks like in the market as of 2026 ¹.

Because almost nobody holds the title, search on responsibilities. The people you want describe themselves as interconnection study engineers, transmission planning engineers, system impact study engineers or power system consultants, and the automation half shows up in a personal project, a conference paper or a repository rather than in a job title. Someone who published a talk on scripting contingency analysis is telling you exactly what you need to know.

One sourcing warning. Engineers who have only ever done AI work on grid data, without having produced a study somebody relied on, will interview extremely well on the automation half and will not catch the errors that matter. The interview should be weighted toward cases, not toward architecture, or the process selects for exactly the wrong half. The same failure mode shows up when hiring an AI security engineer on tooling knowledge instead of on adversarial instinct.

How Do You Price and Close This Hire Without Inventing a Band?

No published salary series exists for this title, so any point estimate you find is somebody's guess. Price against the established band you are actually competing with: senior power system or transmission planning engineer, at the level where a person already stamps or defends studies. That band is real, published inside most utilities, and known to every candidate in the pool. Adjust upward for the automation half instead of treating the title as new enough to reset the scale.

Expect that adjustment to be upward. PwC's 2026 AI Jobs Barometer, drawing on roughly one billion job advertisements, reports an average wage premium of 62 percent for roles requiring AI skills ². Treat that as directional across the whole economy rather than as this role's number, because a licensed engineering band moves more slowly than a software one. The practical consequence is simple: if you post the automation responsibilities at your standard study engineer band and a developer or a startup posts the same work with an equity component, you lose the candidates who have both halves, which are the only candidates worth running this process for.

What closes them is rarely the number alone. In interviews the recurring asks are authority and attribution. Who signs the study, what happens when the engineer overrules the automation and it costs a week, and whether the model outputs carry a record of what was checked. An offer that says the engineer owns the sign-off and the escalation path, in writing, beats a higher offer that leaves it implicit. Say plainly which decisions are theirs.

On location, treat it as genuinely mixed rather than defaulting to remote. The study software, the case libraries and the base cases frequently live inside a utility network with access controls that make remote work slow or forbidden, and some study data sits under critical infrastructure protection rules that are jurisdiction-specific and change; ask your own compliance and legal counsel what applies to your data before you write the posting. Developer-side and startup versions of the role are more often remote or hybrid, since the modeling stack is theirs. If your case data cannot leave the network, say so in the first conversation instead of the fourth, because it is the most common late-stage reason one of these searches restarts.

See a sample report >