tldr;
Warning - Long read ahead. Set aside some time.
A T-shaped engineer has one deep stem and a wide bar of adjacent knowledge. The bar used to take years. AI now lends it to anyone with a prompt, and the early research says little of it sticks on its own.
My estimate for a working Workday engineer: 15-20% less time in year one, or 6 to 8 hours a week. I can’t find anyone who has actually timed this on Workday. The math and my assumptions are below, so go ahead and argue with them.
20% off testing and compliance tasks is realistic. Across a whole week, that same 20% is about 6%.
Turning messy documents into structured data is the strongest single case I found: about a third less time with checking included. It comes in project-size lumps, so it sits outside my weekly number.
I walk through the numbers from every vendor I could find, including who’s selling what.
Rent as much bar as you can check.
At Rising’s Extend session, a presenter got to a live app in about four hours and ten minutes, debugging included. Internal mobility nominations. Manager sees their direct reports, with tenure, promotion history, and compa ratio, then nominates one and the BP routes up for approval.
Developer Agent generated the pages, the WQL, the business object, the security domain, and the BP. I’ve been doing this for over twenty years, and I sat there taking pictures of the screen like a tourist at the Bellagio fountains.
Then the inbox came up. Sitting in it: “Business Process Definition Error for Nominate for Internal Mobility.”
Dev tenants throw errors. That’s what they’re for, and I have no idea whether that one got fixed ten minutes later. Everything else on that screen impressed me. The error line is the one I kept, because somebody had to know what it meant, and whether it mattered, and that somebody was not going to be the agent.
What I mean by T-shaped
I’ve handed out the T-shaped advice for years and I’m not sure I’ve ever defined it, which is a very consultant thing to do. The term floated around McKinsey in the 1980s, David Guest put it in print in 1991, and Tim Brown at IDEO made it famous. Two lines.
The stem is your depth. It’s what you could fix at 2 a.m. without opening a ticket. Mine is Recruiting and Talent. I can tell you why a candidate is stuck on a step, which condition rule did it, and (on a good day) who asked for that rule and why.
The bar is your reach. Mine is enough Compensation to know my offer step has a downstream, enough Studio to read an integration I didn’t write, and enough security to deduce why a field just showed up for the wrong role.
In the original idea, the bar is the ability to work with experts in other fields. I can’t run your payroll. I just know to call you before I change the field your interface reads.
Workday is hard on people without one, because one data model and one security model mean nobody’s module is really theirs. The pure specialist fixes a comp problem and breaks my recruiting report. The generalist has read every release note and can’t fix anything at 2 a.m. The T is the person you drag into the room when both of those have already happened.
(There’s also a comb, for people with depth in many areas. I hold Workday Pro certs in Recruiting, Talent, Compensation, and Studio, so on paper, hi.)
Then I ran the 2 a.m. test. I haven’t run a merit cycle in eight years, and it’s been about that long since I troubleshot MVEL. I can still read XSLT and work my way through Studio, which is a long way from being the guy you page. Those are worn teeth, and my LinkedIn has no idea. And don’t get me started on payroll. I haven’t run a payroll since before the Obama administration, so my knowledge is limited to what I may break downstream. If I have payroll questions, I call my phone-a-friends.
All that being said, point a tool at a worn tooth and it feels sharp again in about ten minutes, but hold that thought for a minute.
We used to pay cash for the bar
The bar took years because you bought it with broken integrations. It was expensive, so it was worth something.
Then BCG handed 480 consultants a Python task. With GenAI they hit 86% of the benchmark set by actual data scientists, 49 points better than consultants working without it. One engineer in Anthropic’s internal study described the same feeling: “I can very capably work on front-end, or transactional databases, or API code, where previously I would’ve been scared to touch stuff I’m less of an expert on.”
Swap in Extend and WQL and you have the Developer Agent pitch. I do a smaller version of this myself (I can read the XSLT, and past that the agent is doing a lot of the walking).
Stop reading there and you’d conclude the bar is free. Plenty of vendor decks have.
Then they took the tool away
BCG gave everybody a follow-up coding question. The consultants who had just done the coding task with AI scored the same as the ones who never touched it. BCG’s word for this was “exoskeleton.”
It’s one question and nobody warned them it was coming, so don’t carve it in stone, but it rhymes with what Anthropic found when it ran 52 mostly junior engineers through a library they didn’t know: 50% on a quiz with AI, 67% without, minutes after the task, with the biggest gap on debugging. (Disclosure: Anthropic makes the tool I use most, and yes, I used it on this piece. Season accordingly.)
I can’t shake that last part. The skill that fell furthest is the one you’d need to supervise the thing.
So the bar is rented now, and the real rent is when you realize you can’t tell the tool is wrong.
Your stem is not a force field
I’d love to tell you twenty years of tenant scars make you immune.
BCG also gave them a predictive modeling task beyond what the tool did well. A background in coding or statistics didn’t rescue them, and the people using the tool were more likely to get led astray than the people working without it. A Harvard-led study of 758 BCG consultants is worse. On a task outside AI’s range, correct answers fell from 84.5% without AI to 70.6% with it. Give them a prompting overview first and it dropped to 60%.
(Prompt training. The thing half of us just put in the 2027 budget.)
Depth still pays. BCG’s moderate coders beat the novices by 10 to 20 points and matched the data scientists on two of three tasks. It only pays when you actually use it, though, and the tool gives you no signal that today is the day. My read, with no study behind it: rent as much bar as you can check.
What checking looks like in a tenant
Go back to that nomination app. I don’t know how the demo handled any of these, and that’s the point. These are the questions I’d ask before it got anywhere near my production tenant:
Security. The agent generated a domain. Who’s in it? Can anyone who reaches that page see a compa ratio for people outside their own org?
Routing. It routes to the manager’s manager. What happens when that position is vacant, or when the nominator’s manager is out and delegated, or when the nominator sits at the top of the org?
Definitions. The app shows “promoted in the last three years.” Does that count as a lateral with a grade change? Does Comp define promotion the same way, or are you about to have two answers in two reports?
The downstream. It created a new business object. What reads that next year, when you’ve forgotten it exists, and did anybody write down why it’s there?
No prompt course teaches those. Routing I can answer from the stem. Security I can only answer because of the bar, and definitions means a phone call to Comp. That’s what the T was always for.
The number I owe you
In March I told you AI saves me roughly 15 hours a week, and I never put a stopwatch on it.
METR put one on 16 experienced developers in early 2025. They felt 20% faster and measured 19% slower. METR now says developers are likely faster than that today, and that its newer data can’t say by how much, but the gap between the feeling and the clock should make all of us (me first) a little quieter.
The rest of the evidence I’d point you to is on one chart. These studies don’t measure the same thing, so read the shape and leave the decimals alone.
Chart sources: Anthropic, Microsoft, Noy and Zhang, Cui et al., Stanford, all work and complex code, Stanford, matched teams, METR.
Nobody here studied Workday. The closest is Microsoft’s trial of 162 identity admins, on four console tasks, using Microsoft’s own agent, freelancers, and a simulated tenant. (That 43% holds accuracy constant. The raw gap in their table is closer to 35%.) And notice the bottom of the chart, because complex work in an existing system is a fair description of every tenant I’ve ever loved. Cui’s field experiments also split by tenure at Microsoft: short-tenure developers gained 27-39%, long-tenure 8-13%. It’s noisy and not statistically significant, but if you’ve been reading this newsletter for a while, I know which group you’re in.
So… I built my own estimate, task by task. These ranges are my judgment from those studies, and they aren’t measurements.
I walked into this piece believing AI-enhanced engineers pick up 20% from testing and compliance alone. On the tasks themselves, that holds. To see what it does to your week, multiply each task’s share of the week by its reduction:
I put testing at a fifth of the week and compliance docs at 8%. The rest of the split is my guess: config 25%, requirements and design 15%, tickets 15%, Extend and integrations 10%, training docs 7%.
To get 20% off the whole week from those two tasks alone, they’d need to shrink by 71%.
Add it up and you get 12 to 34%. Those are the outer bounds, every task at its worst or every task at its best, and neither is going to happen. I’d plan on 15-20% in year one, which on a 40-hour week is 6 to 8 hours.
I told you 15. The top of my own range is under 14. Consider me humbled (thanks, math!).
The row I left off the chart
One job stayed out of that math on purpose, and it may be the strongest case in this whole piece. Turning a mess into actionable data.
Job descriptions into job profiles. Policy PDFs into eligibility rules. The acquired company’s 40-tab workbook (with the tab called “FINAL v3 USE THIS”) into something an EIB will accept. I’ve been through about a dozen implementations, and this is the work that destroys the weekends nobody put in the plan.
The best evidence I found comes from medicine, in Annals of Internal Medicine. Six evidence reviews, 63 studies, 9,341 data items. One team extracted by hand, and the other let Claude go first and then checked its output against the source. (Yes, Claude. Same disclosure applies.) Median time per study, with checking counted, went from 125 minutes to 84:
Errors came out about even, 9.0% with AI against 11.0% by hand. One of the six reviews got slower, which I find more convincing than if none had.
A tiny veterinary preprint (nine students) clocked raw extraction, with nobody checking, at 34 times faster. Keep both numbers side by side when the demo starts. 34x is the tool. A third is the job.
I kept it off the chart because it comes in lumps: a conversion, a divestiture, a job architecture cleanup. Take a 200-hour cleanup (use your own number) and a third is about 65 hours back, so in a project year my 15-20% runs low. (I checked. A 40-hour week of nothing but this comes to 13 hours. Still not 15.)
Then the catch. In one structured output benchmark (a vendor’s, JigsawStack, so season to taste), models hit near-perfect schema compliance, and the best value accuracy on text was 83%. Their description: “The JSON is valid. The type is correct, but the data is wrong.”
We have a name for that. It’s an EIB that loads clean with the wrong grade on it. In the Annals study, the most common error was data that never came over at all (5.5% of items), and those misses got past the human checker too. A row that never arrived doesn’t throw a validation error.
This is where the stem comes back. Somebody has to define the target before the tool runs: which fields, what “manager” means in this tenant, what to do when the source says nothing. Mapping to your own taxonomy is harder than lifting a date off an offer letter, too. The closest study I found, Turkish job postings matched to ESCO skills, topped out at 0.56 out of 1 end to end. Different language, different taxonomy, and I’d still look hard at any job family mapping I hadn’t checked.
So reconcile the counts back to the source, then pull a random sample and compare it by hand, and do both before the load, because a clean load only proves the file was right.
Every vendor I know, and the number each one is selling
I couldn’t find a published method behind a single one of these numbers, and you’re the one who’ll get asked to hit them. So ask the same three questions of each: compared to what, measured by whom, and does it count the rework?
Workday Developer Agent builds apps and agents from plain language. Workday says 12-40x on coding tasks and 8-10x on timelines. In the same blog post, a customer describes “a functioning prototype in weeks.”
Mando works in the browser, turning what admins do into docs, training, audit trails, and tests. Its customer stories claim a day of documentation cut to one hour. It also built SOR-Bench, a benchmark of 2,214 Workday questions, which is useful and also the student grading the test. (Two friends of mine are customers and are quoted on its site. They don’t work for me, and I don’t work for Mando.)
HappyPath generates tests from your BRDs and runs them with agents, and it’s primarily aimed at implementation partners. It says 66% savings on testing, 90% less manual work, and 93% less documentation time, with “your savings may vary” attached.
Opkey does test automation with self-healing and impact analysis, and now 100+ agents across design, config, and testing. Its headline says release testing goes from six weeks to three days. Testing effort savings show up as both 80% and 85%, depending on the page.
Tricentis Tosca says up to 85% less manual effort on initial test creation, from internal tests and an open beta. That post focuses on SAP Fiori, so confirm the agents cover Workday before you get excited.
Kainos Smart Test reported an 80% cut in update testing effort in a 2023 customer story, about plain automation. Keep that one handy, because it’s the baseline. If you’ve already automated, ask what the AI part adds.
The rung I’m worried about
Tickets. Reports. UAT scripts. Job aids. It’s boring work, and it’s how I learned, since nobody gets into HRIS on purpose. It’s also how you grow a stem. Those are the first tasks the tools take from us.
Stanford and ADP have employment for 22-to-25-year-olds in the most AI-exposed jobs shrinking 3.8% a year, against 2% growth in the least exposed. Economists are still fighting about why, and none of that is Workday data. I still can’t answer the obvious question. If the agent takes the tickets, where does the next comp expert come from?
What I’d do Monday
Crawl. Draw your T, with all of your worn teeth included. Be honest about which parts of the bar you could explain with the tool closed. Then time one real task this week, with AI and without, and check the rework two weeks later. Your gut is the instrument METR just embarrassed.
Walk. Pick one piece of bar you’re renting right now, like WQL or an Extend app. Write the test before you see the output, using the four questions above. Make the agent explain itself, then break it in a sandbox. In Anthropic’s trial, people who asked conceptual questions scored 65% or better, and the ones who delegated or debugged through AI stayed under 40% (small groups, no causal claim, still). Personal dev tenants are in open beta, and you sign up with a personal email, so you don’t need anyone at work to sign off.
Run. Turn one rented skill into an owned one, then pass it down. Hand your newest analyst the failing test and keep the fix to yourself. Put a name and a review cadence on every agent, because at our Share-a-thon table in October, 0 of 12 had a governance structure for a rogue agent. (None of them had an agent in production, either. Yet.)
Own the stem. Rent the bar. Check everything you rent.
The agent can build the app in four hours and ten minutes.
Somebody still has to read the inbox.
— Mike
Director HR Tech | Paying Rent on the Bar
The Department of First Things First. For the people who do the work.
P.S. The bar’s rented at my house too. I build parametric parts for the basement print lab in OpenSCAD through Claude Code, and I would flunk a quiz on OpenSCAD. Worked great until the side tables for the tennis club started delaminating in ABS, which no amount of code was going to fix. PETG did. I’d love to say I knew that going in.