Most Program Managers Use AI Like a Search Box. The Job Is Knowing Which Tasks to Hand It.

It’s 4pm on a Friday.

You are staring at a Jira export, three Slack threads, your standup notes from Tuesday that already feel ancient, and a risk log that is somehow both too long and too vague.

The status update for the steering committee is due in an hour.

You paste it all into ChatGPT, ask for “a clean exec summary,” and what comes back is polished, professional, and honestly a little better than what you would have written, tired at 4 pm on a Friday.

You ship it. You feel, for about three seconds, like you just cheated. In a good way.

I’m a Technical Program Manager, and I have done exactly this. So have most of the program managers, project managers, and team leads I respect. Letting AI write the first draft of our work life has become a daily habit and on most days nothing goes wrong.

Here is the thought I want you to sit with before scrolling any further, because it took me an embarrassingly long time to take it seriously:

The thirty minutes you saved on that summary are not the most important thing that just happened. The most important thing is whether the thing you sent was correct. And on the days it is not, you may not be able to tell.

If you have ever opened a Monday-morning email asking a polite question about “the issue you mentioned” in your Friday update, scrolled up, and felt the small cold drop of realizing that the line they’re asking about didn’t come from you (the model added it, and the source it referenced wasn’t even in your inputs), you know exactly what I mean. If you have not had that conversation yet, you are statistically about to.

That gap is the skill nobody is teaching you. It is also the one thing that is going to separate the leaders who compound their careers using AI from the ones who keep wondering why their “AI productivity” never seems to translate into anything that lasts.

Welcome to Code Like a Girl, the community where women in tech come to be seen, heard, and championed as they walk this path together.

If you are a woman in tech who has been called "slow" for asking the second question, this is where you find the people who know it was never a flaw.

In 2023, researchers from Harvard, MIT, Wharton, and BCG ran one of the cleanest experiments anyone has done on AI at work. They gave 758 BCG consultants access to GPT-4 and let them tackle real consulting tasks. The study was peer-reviewed and published in Organization Science in 20261.

On tasks inside what the researchers called the “jagged technological frontier,” consultants using AI were about 25% faster and produced work rated roughly 40% higher in quality. A real, measurable lift. The kind of result that, if you saw it on a dashboard, would justify your AI adoption budget for the year.

Then the researchers built a task that looked like it sat inside the frontier and actually did not. On that task, consultants using AI were 19 percentage points less likely to reach the correct answer than the ones working without it.

(Source: ChatGpt)

Read that one more time. The tool did not just fail to help. It pulled smart, experienced consultants confidently toward a wrong answer they would not have reached alone.

The line between what AI does brilliantly and what it does confidently-but-wrongly is jagged. It is not visible from where you are standing. And here is the part most of us miss when we read studies like this: nobody in your organization has been hired specifically to draw it.

Think about your own org for a moment. There is somebody responsible for code quality. Somebody responsible for legal review. Somebody whose entire job is keeping the budget honest. There is no one whose job description currently reads “verify whether the AI’s draft is hallucinating before we ship it upward.” Which means it falls to whoever is closest to the work and the consequences. Which means, often, it falls to you.

The job is not to “use AI more.” The job is to know, task by task, which side of that jagged line you are on, and to build your workflow so the model does the inside-frontier work and a human owns the outside-frontier calls.

There is a thing that happens to women who lead, especially women who lead anything technical, and I’m willing to bet you know the exact conversation I’m about to describe.

You are in a room where a decision has to be made. You ask one more question. Maybe two. You want to see the assumption sheet. You want to know who built the model, on what data, how long ago. The room shifts a little. Somebody, kindly, uses the word “thorough.” Somebody else, less kindly, uses the word “slow.” You watch a male peer ship a less-considered version of the same decision the following month and get described as “decisive.”

You have learned, over time, to apologize for the instinct to verify.

The jagged frontier is the moment that calculus inverts.

The skill that suddenly matters most in an AI-saturated organization is the exact one you have been told is slowing you down. The instinct to ask “is this actually true?” before forwarding the polished thing upward. The willingness to pressure-test a draft that reads fine. The discipline to own the call the model cannot make.

I am not saying this to make you feel better. I am saying it because the next eighteen months are going to sort organizations into two groups. The ones whose leaders shipped AI-generated speed without verification and ate the failure cost. And the ones whose leaders ran the speed through a judgment layer and compounded the gain. The second group will be staffed disproportionately by people who already knew how to hold both halves at once.

That is you. You are not behind on AI. You were trained for this.

(Source: ChatGpt)

These are three workflows I run on real program work. The patterns transfer. Pick one and try it on something already on your desk this week.

You already know this one. It is the scene we opened with. Synthesizing structured-but-messy inputs into one coherent page sits squarely inside the jagged frontier, exactly the kind of task the trial showed AI doing roughly 40% better. So I hand it over with this prompt:

"You are my program chief of staff. Below are this week's raw inputs: [paste Jira status, standup notes, Slack threads, risk log]. Produce a one-page executive status update with exactly these sections: Overall status (Red/Amber/Green plus one sentence), Key progress (three bullets), Top risks (each with owner and mitigation), Decisions needed from leadership, Next week. Use only facts present in the inputs. If a section has no supporting input, write 'No update.' Do not infer or invent specifics."

The last two sentences are the entire guardrail, and they are non-negotiable. Without them, the model will helpfully fabricate a plausible risk owner, a date, or a percentage that was never in your inputs. It will read perfectly. That is the outside-frontier failure mode hiding inside an inside-frontier task: the synthesis is fine, but the moment it fills a gap with invention, you are shipping a confident error upward.

The first week I ran this version, the model invented a “data quality issue in a downstream pipeline” complete with a fake owner name. The pipeline was not in my inputs at all. If I had been tired and trusting, that line would have gone to my VP and triggered a Monday-morning conversation I did not need.

The trade you are making: the hour becomes about five minutes plus an honest read-through. The format is identical every week, which is its own quiet win, because steering committees read patterns, not prose.

What you own → the read-through. Five honest minutes asking “is anything in here invented?”

You know this person. They sent over “just some thoughts” that turned into four pages of rambling that mention three different priorities, contradict themselves twice, and end with “let me know what you think!”

The traditional path is an afternoon of teasing out stories and acceptance criteria, and you will still miss edge cases because you are doing it tired and linearly. Drafting structured artifacts from unstructured intent is inside the frontier. Mike Cohn, who helped define the user-story format, published a prompt approach for this in early 2026 that matches what actually works2.

Step 1: "You are a business analyst writing clear, high-quality user stories. Convert the requirements below into user stories in the format 'As a [user], I want [action], so that [benefit].' Apply the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable). Output stories only, no commentary. Separately, flag any requirement that is ambiguous or internally contradictory. [paste doc]"

Step 2: "For each story above, add acceptance criteria in Gherkin format (Given / When / Then)."

The highest-value output is often the last “flag what is ambiguous or contradictory” list. The model surfaces the questions you need to ask your stakeholder. It does not answer them for you. Cohn says it plainly: AI “won’t replace the need to talk with real users, make judgment calls, or exercise product sense.” The stories are a draft to pressure-test, not a backlog to commit.

What you own → the conversation with the human who wrote the rambling doc. The list of contradictions the model just gave you is a gift. Walk into that meeting with it.

Look at your team’s current risk register. Be honest. How many of the items have been there for six months without being updated? How many were copy-pasted from the last program? How many made anyone in the standup actually nervous?

Risk registers go stale because the people closest to a project are the worst-positioned to see how it fails. Your team has already convinced itself the obvious risks are handled, and the second-order risks live in the blind spot of your own context.

The pre-mortem (imagine the project has already failed, then work backward) is a well-established technique from Gary Klein. Using AI as the adversarial brainstorm partner plays directly to its inside-frontier strength: breadth.

"It is six months from now and this project has failed. Here is the plan: [paste scope, timeline, dependencies, team, key assumptions]. Run a pre-mortem. List the ten most likely reasons it failed, grouped by category (technical, dependency, resourcing, stakeholder, external). For each, give one early-warning signal I would be able to see in the next 30 days, and one concrete mitigation."

This was the one that surprised me most. The model surfaced a stakeholder-coordination failure mode on a recent program that I had genuinely not considered, because the people involved were people I was in standups with every other day and my mental model of them was too charitable. The breadth of the model’s generation made up for the narrowness of my own attention.

What you own → the likelihood and impact scoring. The model does not know your stakeholders or your political reality. You do. Take its breadth, apply your judgment. Never paste its ranking straight into the steering deck.

The temptation, after reading this, is to walk away thinking “AI drafts, I edit.” That undersells what is actually happening.

In 2025, 42% of companies abandoned the majority of their AI initiatives, up from 17% the year before3. Roughly 95% of enterprise gen-AI pilots showed no measurable P&L return4. Read the reasons (poor data, weak risk controls, unclear value) and you find one pattern: teams automated the easy half (the drafting) and skipped the hard half (the judgment about whether the draft was right, and whether it actually moved anything).

Atlassian’s 2026 data has a CTO saying the quiet part out loud: “Just because a developer gets 20% productivity improvement from AI doesn’t mean the entire cycle gets 20% gains.”5 That is the jagged frontier at the level of a whole program. Local speedups do not automatically become system throughput. Somebody has to own that translation. That somebody is a program manager. Often it is a woman. Often the organization has not officially given her the authority that the responsibility implies.

If you have been worried that you are “behind” because your relationship with AI is more cautious than the loudest voices in your feed, here is what I want you to hear: the cautious instinct is the skill. The discipline to check, to verify, to ask the second question is not a tax on your speed. It is the thing that turns the speed into something real, and keeps it from blowing up on a Tuesday.

Pick one of the three workflows. Run it on real work this week. Pay attention to the moment your finger hovers over send, and notice what you would catch if you looked one more time.

Then look one more time. That moment is the job. It always was. The tools just made it easier to skip and more expensive when you do.

(Source: ChatGpt)

If you are a senior manager, a project manager, or a woman leading any kind of technical program, the question is not whether your organization is deploying AI. It is. The question is whether anyone in your organization has explicitly owned the line between what AI drafts and what a human decides. If the answer is no, that is your highest-leverage open contribution right now. No one is going to hand it to you. You pick it up.

That is already you. You are just being asked to do it more visibly now.

We're grateful to Sumaiya Shrabony for sharing her work here. If you want program leadership written by someone who names the judgment call most orgs leave unassigned, her writing is worth following.

Sumaiya named the line no one in your org has been assigned to draw: what AI drafts, and what a human has to decide.

Code Like a Girl is the community for women in tech who already carry that judgment and are ready to be paid, promoted, and recognized for it.

Subscribe for free and join our Rise Together Thursday chat. It’s a community where women in tech share their latest work, spotlight another woman’s post, and support one another through thoughtful comments and restacks.

You’ll come in with work that deserves more attention and leave feeling seen, supported, and connected.

Every data point in this essay is from a primary, dated source. Archived links are included so the citations stay verifiable.

Background reading referenced in the piece (no specific stats cited):

• Gary Klein on the pre-mortem technique. Klein, G. (2007). “Performing a Project Premortem.” Harvard Business Review.