Three years ago, I wrote about the Iron Triangle of Software Development — the old project management model that says scope, schedule, and resources are locked in tension, and you can’t move one without moving the others. Back then, my main observation was about people: product managers guard scope, engineers ask for resources, and senior leadership defends the schedule, and the quality of the product quietly pays the price for that three-way standoff.
For the second session of our bi-weekly “connection hour” at Checkr — the same low-tech, no-sprint-talk hour I described in the first article of this series — we picked that old post of mine as the topic. Partly out of curiosity: does a framework from the pre-AI era still describe how software projects actually behave in 2026? And partly because I’ve changed my mind about a few things since I wrote it.
The model, briefly — and how mine has evolved
The classic triangle has three levers. Scope is what the software will and won’t do. Schedule is when it ships. Resources are the budget and the people. Change one, and the other two move.
In my 2023 post, I treated quality as a possible fourth dimension — an “Iron Quadrilateral.” My thinking has hardened since then. The version I presented to the team puts quality at the fixed center of the triangle, not on a fourth corner. Quality is non-negotiable; the three sides flex around it. And when a project hits friction, I now argue there’s a right order in which to flex them: schedule first, scope second, resources last.
Schedule first, because a moved date is the cheapest honest answer — it disappoints people but doesn’t deceive them. Scope second, because shipping less, done well, beats shipping everything, done poorly. Resources last, because of a lesson the industry keeps relearning: Brooks’ Law. Adding engineers to a late project usually makes it later. New people need context, and the people who have context are the ones who must stop and provide it. The exceptions are real — very large, long-horizon projects can absorb the ramp-up cost, and some work parallelizes well — but they are exceptions, not the default.
One clarification from our discussion that I want to preserve, because it reframed quality for several of us: quality is not a subjective “good product” feeling. Quality is delivering exactly what you committed. If you committed 30 of the 100 requested capabilities and delivered those 30 solidly, that is quality. The team pushed back with a fair nuance — an alpha product may legitimately trade polish for speed and breadth in a way a mature product cannot, so the quality bar may flex by lifecycle stage. We agreed a hard line exists somewhere; we did not agree on exactly where. I’m comfortable leaving that unresolved. The center of the triangle can sit at different heights for different products, but for any given commitment, it doesn’t move mid-project.
The three-way standoff hasn’t changed
What struck me most, three years later, is how durable the 2023 observation turned out to be. Engineers still instinctively reach for the resources lever — more headcount, more infrastructure, more time. PMs and designers are still the most flexible on scope, once genuinely pressed. And leadership and sales still anchor on schedule: “by Q3, or we lose the deal.” Each group optimizes the corner it feels accountable for. The tension isn’t a bug in your organization; it’s the shape of the triangle itself. AI has changed a lot about how we build software. It has changed almost nothing about this.
What AI actually changes
Here’s where the conversation earned its hour.
The dominant industry narrative says AI makes engineers 10x — some claim 100x or more — productive. If that were true at the system level, the triangle would effectively melt: schedule and resources would stop being meaningful constraints. Our team’s lived experience says otherwise, and the reason is worth being precise about.
AI has compressed coding time dramatically. But it has not compressed — and has arguably expanded — validation, review, and the cognitive load of holding a system in your head. The development time didn’t vanish; it moved. The overall speedup is real but modest, and nowhere near the headline numbers. I wrote about this shift in The Compression Problem: faster output, more tired engineers.
There’s a subtler trap inside this for leaders. One subsystem built three times faster does not make the whole project three times faster. Integration, review, compliance, coordination — the connective tissue of a project — doesn’t accelerate at the same rate as code generation. When leadership hears “AI made this component 3x faster” and quietly re-anchors the entire schedule on that number, the triangle snaps back hard. The schedule lever looks looser than it actually is.
And there’s a quality risk that didn’t exist when I drew the triangle in 2023: teams shipping AI-generated code that no one deeply understands. The code works — until it doesn’t, and then the incident is harder to debug because no human truly owns the logic. If quality sits at the fixed center of the triangle, this is the direction the modern threat comes from. It doesn’t arrive as a conscious decision to cut corners; it arrives as velocity nobody audited.
Not all work should sit at the same distance from AI
One framework from our discussion that I keep coming back to: categorize your work before deciding how much to let AI lead.
Category one is your bread-and-butter product — for us, that’s criminal screenings, where FCRA compliance sensitivity is the defining constraint. Here AI belongs in assistive mode: humans lead the thinking, the decisions, and the architecture, and AI accelerates the hands.
Category two is supporting and auxiliary work — internal tooling, data collection, support automation. The blast radius of a mistake is smaller, so AI can lead more, with humans reviewing rather than driving.
The caveat that makes this framework honest: if a category-two system feeds bad data into a category-one product, the distinction collapses. Errors cascade upward. The categories tell you where to place human attention, not where you’re allowed to stop paying it.
A new pressure on the resources corner
One more shift worth naming. For a decade, the resources corner of the triangle was mostly about headcount. AI is adding a new line item to it: the tooling itself. The industry is moving from flat-rate AI pricing toward usage-based token pricing, and at some point every engineering organization will face a version of the same question — at what usage level does the AI spend stop being obviously cheaper than the human effort it replaces? I don’t think we’re near that line yet. But “resources” in the triangle now includes a meter that runs while your agents do, and leaders who built their intuitions in the flat-rate era will need to rebuild them.
Where this leaves the triangle
So, is the Iron Triangle still iron? My answer after the session: the triangle survives, but the temptations around it have changed. The three-way standoff between scope, schedule, and resources looks exactly like it did in 2023. What’s new is a seductive belief that AI dissolved the trade-offs — that we can hold the schedule, keep the scope, skip the added resources, and let the tools absorb the difference. Our experience says the tools absorb less of it than the demos suggest, and what they don’t absorb gets paid out of the one thing I’ve now fixed at the center: quality.
Our next step as a team is to move this from theory to practice — building a rule of thumb from our own past projects for which lever to pull first in which situation, and socializing it upward so the framework is in the room when trade-off decisions get made.
I’ll leave you with the question we ended on: in your organization, when a project hits friction, which lever gets pulled first — and is that a deliberate choice, or just the corner of the triangle your loudest stakeholder happens to be standing on?
Leader's Whiteboard 