Building with AI: The Constraints Have Changed

Speed used to be the problem. Now it's the risk: the new car gets anywhere fast, including the wrong place.

The old car was the kind most people have owned at some point. Hands at ten and two, coaxing it up the mountain grade in the right lane while trucks passed. A check-engine light that came on and stayed on. Any repair beyond an oil change meant the dealership: an appointment next Thursday, two days to diagnose it, a part on order, a week without the car. You planned every trip around what it could handle. You left early, skipped the scenic detour and left the bikes at home.

The new car is a different machine. It drives itself: tell it where you want to go and it takes the highway at ninety, passing everything, eager to keep going. When a tire goes, a pit crew is beside you before you've finished pulling over, and you're back on the road in minutes.

That new car is what AI agents have done to building software. An agent is an AI system that can write code, run it, read the errors and fix them on its own, across the database, the interface and the infrastructure, while a person directs the work.

The economics changed with it. Work is limited by whatever is scarcest. For a long time, the scarce thing in software was skilled human time, and it decided what got built. Agents have made that time far less scarce. The constraints didn't disappear, though. Each old one turned into a new one:

Spread out a map and mark everywhere the old car could reach in a weekend. It's a small circle around home. The new car's circle covers most of the map. That's the real opportunity: more of the business gets software built around how it works, more questions get answered properly, and one person can cover ground that used to take a team. A car that drives itself the wrong way only gets lost faster, though. The payoff comes from getting the new constraints right, so that every trip heads somewhere worth going. Point it right first. Then scale.

From driving every mile to choosing the destination

In the old car, the trip moved only when you did. Eight hours behind the wheel, a gas-station coffee going cold in the cupholder, the same stretch of interstate for three hundred miles. Stop to rest and the trip stopped with you. By evening you weren't choosing where to go anymore; you were choosing where you could still get to before dark.

Building software worked the same way. A person wrote every line of code, every query and every configuration by hand, and each hour of that work moved the project a little further down the road. Because all the effort went into making progress at all, the hours decided the destination: you built what the time could reach.

The new car drives itself, and it never eases off the gas. Neither do agents. Ask for a feature and you get it, complete and working, plus extra code you didn't ask for, a second version of something that already existed and a slightly different approach from the one the rest of the application uses. Each of those detours looks reasonable as it happens. Together they carry the application somewhere you never meant to go, and they get there fast.

I watched that happen with the sharing feature in a trip-planning app. I meant for it to use Apple's built-in sharing. What got built was a custom path running alongside it, and the two paths fed each other until one trip's places had multiplied to 545. I wrote about that repair separately. The car was doing exactly what it was built to do: driving, quickly, in the direction it had been pointed.

So my time has moved from driving to navigating. Before the trip starts, I settle the big decisions so the car isn't left to pick the destination: which built-in features the app should use, which patterns it follows and what's out of scope. Those go in writing, in the project, where the agent reads them before it starts. Along the way, I check where we are and correct course:

• "Help me cut dead code and make this more concise."
• "Let's modularize this and make the components reusable."
• "Audit this feature for consistency with the rest of the app."
• "Do a code review of what changed."

The faster the car, the more often you need to check that you're still headed where you meant to go.

From the dealership to reading the map

The old car had a hard limit on what you could do yourself. You could check the oil and change a tire. Anything involving the transmission, the electrical system or that check-engine light went to someone who knew how.

Software had its own dealership. A real application needed someone who knew databases, someone who could build an interface, someone who understood the cloud and someone to test it. If you didn't have those skills, you built only what yours covered, or you waited until someone who had them was free.

The new car comes with everything. Between the car and the pit crew, every system is handled, and you can drive anywhere without knowing how any of it works. That's also how people get lost. You can follow the navigation across the country without ever knowing where you are, right up until the signal drops on a mountain pass and you have no idea which way is north.

The same thing happens with agents. You can take a request from someone in the business, hand it to an agent and get working software back without understanding how it works. Then something breaks and you can't say where you are.

So I stay close enough to read the map. I don't need to be the specialist for every system; I need to understand how the pieces fit together, which is closer to an architect's job than a mechanic's. Much less is new than it looks. A record still has an owner, a queue still has to deliver its message, and a change on one device still has to reach the other. Those familiar ideas are enough to ask good questions. When I don't follow something, I ask directly: "I don't understand the jargon. Please explain this in plain language." The answer usually takes a minute, and it keeps me able to explain the system I'm responsible for.

From waiting on repairs to watching the dashboard

In the old car, problems were slow. You noticed the rattle, made the call, waited for the appointment, waited for the diagnosis and waited for the part. The repair was the bottleneck, and you always knew something was wrong because you were the one waiting on it.

Software support kept the same schedule. Someone noticed an issue, someone else tracked down the cause, and the fix had to be written, tested and released. Each step waited on a person with the right skills and a free afternoon, so a single bug could take weeks.

The pit crew changes that completely. Agents can find the cause, write the fix and test it in the time it used to take to schedule the first meeting. Once fixing is that fast, the bottleneck moves to noticing. And at ninety miles an hour, a good car feels smooth right up until the temperature gauge is in the red.

That's the trap. An agent's report that a feature is done describes the code, and a passing test suite can still miss the path the feature actually takes. One of my apps had a chat assistant whose tests passed, and the first time anyone actually held a conversation with it, it made up a ticket price and a weather forecast. Nothing on the outside looked wrong until someone checked the gauges.

So I check them, on the real thing: the real device, the real data, a real conversation. The pit crew can fix anything I find, quickly. Finding it is still my job, and I wrote about how in How I Check That It Actually Works.

From owning it by the year to paying by the trip

You never thought about what a single trip in the old car cost. You paid for it by the year: the car payment, the insurance, the repairs. A drive to the coast didn't come with a bill.

Software had the same blind spot. The cost was people's time, and time disappeared into salaries. Nobody knew exactly what went into a report or how long it really took. Work competed for hours, and the question was always whether anyone had time.

The new car runs on fuel, and every trip ends at the pump. The machine prints a receipt: the gallons, the price and the total for that drive and nothing else. You know exactly what the coast cost.

Agents work the same way. Their usage costs money, so every piece of work has a price, and I can estimate it before leaving. Once I understand the requirements for automating a manual process, I can say roughly what it will cost. A custom application for one team's workflow might come to around $1,000 in agent usage. A report that answers a complex business question might come to around $200. Those are my rough estimates for those kinds of jobs, and I can say them out loud before starting. The time gets measured too. Work that used to fill an unknown number of days now has a clear start and finish, so both the price and the duration are on the receipt.

That changes the question from "is there anyone with the time to do this?" to "is this trip worth the fuel?" It's a better question, because it can be answered: compare the cost with what you get at the other end and decide one trip at a time. Where the car fills up matters too. Exploratory work on a shared cloud platform burns capacity that production reports depend on, while the same exploration on a laptop costs next to nothing, which I covered in Give the Agent a Working Environment.

Because each trip is affordable and fast, you take far more of them. My existing work takes much less of my time, and I've stretched across more of the business than I ever could in the old car.

From skipping the detours to keeping what you bring home

Every trip in the old car was planned around its limits. You took the direct route, skipped the scenic detour and left the bikes and the kayak at home.

That's how software scope got decided too. Teams delivered the minimum that answered the request, and the rest stayed on the list: the explanation behind a number, a real application instead of a spreadsheet, data brought together from across the organization, reporting built around what each group actually needed. Everyone could see those detours from the highway. Nobody had the car to take them.

The new car takes every detour. Bring the bikes, the kayak and the camping gear, and stop at every overlook on the way. It also means coming home with everything you brought along, and all of it needs a place to live and someone to look after it.

Everything you build with agents is still yours to keep running. Each application, report and alert needs attention when a source changes, a dependency updates or the business process shifts. The pit crew makes the repairs fast. Deciding what's worth keeping, and what was a detour you don't need to take again, is the owner's job. The SaaS post covers when that ownership is worth taking on and when buying is still the better deal.

Point it the right way, then go further

Before any trip, I check the five constraints the new car raises:

• Direction: do I know where this should end up, and where it should stop?
• Understanding: will I be able to explain how it works once it's built?
• Verification: how will I know it works?
• Measured cost: what will this trip cost, and is it worth it?
• Ownership: who keeps it running, and what happens when the process changes?

Those checks take minutes, and they decide whether the car arrives somewhere useful. Then I take the shortest trip that answers the real question and make it cheap to try.

Once a trip proves itself, the next one goes further, and this is where the new car really pays off. In the old car, each destination took weeks, so you picked one and lived with it. In the new one, a trip that works becomes a route you can drive again. One team's workflow becomes an application, then the next team's, and the next, until the map is covered with places you go regularly instead of one place you went once. A report that keeps getting used grows into a data app, and a workflow that keeps getting used grows into a business application. The constraints don't go away as you scale. Each new destination still needs a direction, someone who understands it, a dashboard, a fuel budget and an owner. Get those right on the first trip, and the second and third go faster.

A real trip: the Cadillac in the garage

Plenty of companies already own a Cadillac and barely take it out of the garage. Microsoft Fabric is the one I know best. It's a Cadillac of services: data pipelines, notebooks, semantic models, reports, monitoring, alerting and apps for sharing it all, on one platform the company already pays for.

In the old car, the trip was short. Get the data into Fabric through a pipeline and build a report. All the data was there, and the report showed one slice of it. Anyone who needed a different view had to write their own SQL or make do. We had a Cadillac in the garage and drove it to the end of the block, because that was all the time allowed.

With agents, the same project can take the whole trip:

• Reports analyze the data from many more angles instead of one.
• Monitoring and alerting catch problems before someone notices them in a meeting.
• The pipelines handle more edge cases and adapt when a source changes.
• A robust, flexible semantic model gives everyone the same definitions.
• Several reports serve different audiences from that one model.
• An org app shares them with the right people under proper governance.

Every one of those features was in the garage the whole time. What changed is that the car can now drive itself there, and the new constraints decide how far to take it.

Direction decides which reports and alerts are worth building at all. Understanding means I can explain the semantic model to the people relying on it. The monitoring and alerting are the dashboard, built into the work itself. The measured cost includes the platform's capacity, so I watch capacity usage and tune the workloads to get the most out of what the company already pays for. And ownership is why the pipelines are sturdier and the reports are shared through a governed app: they're built to keep running when something changes.

The car drives itself now. Point it in the right direction, and it can take you to far more places than the old car ever could.