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 left early, skipped the scenic detour and planned every trip around what it could handle. Some places stayed on the map because getting there was more trouble than the trip was worth.
The new car is a self-driving race car. It takes the highway at ninety, covers distances you wouldn't have attempted before and comes with a pit crew for rapid diagnosis and repairs. Suddenly the weekend has room for somewhere you've never been, a detour to see what's there, even a second trip if the first place wasn't what you hoped.
That's what agents have changed about building software. They can write code, run it, investigate unfamiliar systems and attempt repairs while a person directs the work. A manual process that never justified a development team can get its own application. Several working alternatives can help us choose what people actually need.
For a long time, skilled human time decided which ideas became software. Now more of my attention goes into deciding where to go, understanding what arrives and choosing what deserves to stay:
| The old car | The self-driving race car |
|---|---|
| Hours: progress required driving every mile | Direction: decide whether to explore or follow a chosen route |
| Specialists: unfamiliar systems meant waiting at the dealership | Understanding: learn how the route and the important systems connect |
| Slow fixes: diagnosis and repairs could take weeks | Verification: notice problems and check whether repairs worked |
| Scarce attempts: another approach meant more development hours | Measured cost: budget for exploration and evaluate what each attempt earns |
| Limited range: few ideas justified the journey | Ownership: choose which of the many things you can build deserve ongoing care |
From driving every mile to choosing the destination
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.
An unfamiliar software error could consume an afternoon in much the same way: reading documentation, testing possible fixes, trying to understand a system you'd never worked with. Learning a framework competed with finishing the feature that needed it. The hours available decided how far the project could go.
When every trip was that expensive, it made sense to choose carefully before leaving. Requirements meetings and mockups narrowed the options because building even one working version was a substantial commitment.
The new car lets me visit a few places before choosing. Sometimes I know exactly where I want to go; other times, working software can help me discover the destination.
Consider a department with meeting notes, process documentation, existing Power BI reports and an awkward handoff between people. Everyone wants a better process, but one person wants a list of exceptions, another wants a guided sequence, and another wants to start from a customer record.
We could ask an agent to build three small, working alternatives using the same sample records. Have someone use each to complete the handoff: find the item, understand what's missing and pass it to the next person. A screen that looked convincing in a mockup may become frustrating on the third item. Another may reveal an unspoken requirement: the next person needs to see why the previous decision was made.
Each trip has a purpose and a boundary. We can leave live integrations out while testing the interaction, discard two versions and refine the third. We might even discover that the original report only needed a small change. Those attempts have given us something to decide from. The notes from that trial become requirements for the chosen version: keep the decision history, show it during the handoff and check that the next person can find it.
Once we choose, the challenge becomes staying on course. The race car can take an unintended turn and cover miles before I notice. Given the same request, an agent may choose a new library, another service or a second path the application never needed. Each decision can look reasonable on its own. Together, they can change the architecture without anyone intending to.
I watched that happen with sharing in a trip-planning app. I meant for it to use Apple's built-in iCloud sharing. What got built was a custom path running alongside the app's normal storage, and the two paths fed each other until one trip's places had multiplied to 545. I wrote about that repair separately. The custom path could look workable on its own. Its interaction with the existing system was where the damage appeared.
For delivery work, I put the boundaries in the project: which built-in features to use, which components to reuse and what's out of scope. Tests capture behavior we need to preserve. Periodic reviews check whether the changes still fit the architecture, before a succession of plausible detours carries it somewhere else.
An experiment needs room to try alternatives; a chosen implementation needs consistency.
From the dealership to understanding the route
The self-driving race car drops me at the destination. The application is running, the screens work, and I can show it to someone. But I may be unable to say which system owns a record, how a change reaches another device or what happens if the connection fails halfway through.
Before, I learned much of that by writing the queries, configuring the services and investigating the failures myself. Now the car can get me there before I've learned the route.
The department's notes, reports and process documentation can become a working application spanning technologies I couldn't have assembled alone. People can try a workflow that carries the handoff through, beyond the report that described it afterward.
A working screen gives them something useful to evaluate. It gives me a different set of questions: where did these values come from, which assumptions connect them, and what did the agent introduce to make this work?
I hadn't built sync before. The trip app's sharing interface worked before I understood the storage paths underneath it.
So I make reading the map part of the work. I don't need to be the specialist for every system; I need to understand how the important pieces fit together, which is closer to an architect's job than a mechanic's. A record still has an owner, a message still needs to arrive, and an interrupted update needs a defined outcome.
If a screen says a handoff is complete, I want to know whether that means a database record changed, a message reached the next person or both. If the message fails after the record saves, where does the unfinished work appear? A diagram earns its place when it lets me follow that item and see where it could stop.
The agent can help. I ask it to trace one record from its source to the screen, identify what can change it and explain why a new service was introduced. If the answer is jargon, I say so: "I don't understand the jargon. Please explain this in plain language." Then I ask it to show where that explanation lives in the code or configuration.
I'm learning from a system that has already been built, alongside learning by building it. I need enough of the map to explain the major decisions and recognize when a proposed change sends us down an unexpected road.
From waiting on repairs to watching the dashboard
One of my apps had a chat assistant whose tests passed. Then I had the coding agent hold a conversation with it. Asked which nights had no hotel, it named nights that were already booked. Asked about tickets and weather, it invented a price and a forecast, despite instructions against doing that.
The engine ran. The directions were wrong.
With the old car, getting a repair done could consume the week: appointment, diagnosis, part, another call to the dealership. An agent can often investigate an error, propose a correction and rerun tests far faster than I could work through those steps manually. Difficult problems still take investigation, and the first repair may be wrong. But much less of my time goes into performing every attempt.
A mechanic saying "done" doesn't establish that the rattle is gone.
Tests and logs give me instruments to work with: whether a request failed, where it stopped and whether resource use is climbing. They can also leave something important out. The chatbot's passing tests hadn't established that it could distinguish booked nights from unbooked ones or refuse to invent a ticket price.
So I check the real device, the real data and a real conversation, along with feedback from the people doing the work. An automated check can establish that a response arrived. The person using it needs the answer to be right.
After a repair, I repeat the interaction that exposed the problem and check nearby behavior the change could affect. Where possible, the failure becomes a repeatable check for future changes. The dashboard gets a gauge for something we previously couldn't see.
The pit crew makes another attempt easier; driving the car again establishes whether it helped. I wrote more about that work in How I Check That It Actually Works.
From scarce development hours to affordable trips
When a drive to the coast takes all weekend and a repair bill might follow, I want a good reason to go. If another short trip is affordable, I can visit somewhere, decide it wasn't for me and try a different place.
The three prototypes earlier become practical on those terms. A version we abandon may have revealed that the workflow was wrong before we committed to building the whole thing. Now I need to decide whether the next attempt is likely to teach us anything new.
If people reject the exception list because they need to work customer by customer, another color scheme won't answer that objection. Trying the customer view might. Cheap execution gives me room to test the difference, and a reason to stop polishing the version that answered its question already.
I still measure what those attempts cost. In my own work, rough estimates might be around $1,000 in agent usage for a custom application for one team's workflow, or around $200 for a report answering a complex business question. Those are personal estimates for particular kinds of work. Requirements discovery, verification, infrastructure and ongoing maintenance add to them.
I can still budget an experiment and track the time I spend directing and reviewing it. If a cheap implementation consumes days of review, that belongs in the decision about another attempt. So does whether someone can actually use the result.
Where I fill up matters. Repeated queries against a suitable local dataset can avoid metered cloud warehouse compute or competition with shared reporting capacity. The laptop, data preparation and agent usage still cost something, but another local query can be much easier to justify. I covered that setup in Give the Agent a Working Environment.
I can afford more trips now. Some produce a useful answer, some suggest a different route, and some have nothing more to offer. A small investment in the last attempt makes it easier to leave it behind.
From limited range to owning what you build
The race car can take the scenic detour and stop at the overlook I used to pass. Coming home, though, everything I bring back still needs a place to live and someone to look after it.
A team that could once build one application may now try several, automate handoffs and give small processes tools that fit. An explanation behind a number, a reporting tool for one group, a replacement for a spreadsheet: more of those destinations are within reach.
Ownership was always part of custom software. What changed is how quickly I can accumulate things that need an owner.
Each retained application needs someone to manage access, notice failures and help its users. Dependencies and business requirements change. An agent can help make those repairs, but someone has to decide which commitments are worth maintaining and when to retire a system while preserving the records that matter.
The question that used to stop the idea was "Can we afford to build this?" More often now, I reach another question: "Is this useful enough that we want to own it?"
Some prototypes answer a question and can be discarded. Some remain useful as small personal or team tools. Others attract regular users and acquire records people need tomorrow—the transition I covered in From Prototype to Production. Those applications need someone to show up when they fail. The SaaS post covers when that ownership makes sense and when buying is the better deal.
Doing more with the platform we already have
Microsoft Fabric is the platform I know best for seeing this change. With limited development time, a reasonable project could stop at one pipeline and one report. The data arrived, the report answered the request and the team moved on. The platform could support shared models, other reporting views, monitoring and alerts. Someone still had to build them.
On one integration project, data from an external system needed to join to ServiceNow tickets for Power BI reporting. I gave the agent local extracts to explore. It investigated unmatched records, found inconsistent identifier formats and tested revised mappings against row counts and known totals. That work helped establish the joins and measures the shared implementation would need. I described the process in Give the Agent a Working Environment.
For a workflow like that, the next question could be what people do with the exceptions. If someone filters a report every morning and sends colleagues a list, the report still leaves that handoff to them.
With agents, we could try a view organized around those decisions. A shared semantic model would keep relationships and calculations consistent across the team's report and a manager's summary. Checks could flag missing inputs, and an alert could bring an urgent exception to the person responsible. The team could use a small version before deciding how much more to build.
That gives the platform's existing capabilities a job. A completed refresh still needs reconciliation against known cases. A new view needs to agree with the shared definitions. Additional workloads use capacity, and someone needs to respond when an input stops arriving. An alert nobody acts on is another thing to maintain without much return.
We might keep the new view and skip the alert. We might find that clearer definitions improve the original report enough. More development capacity lets us investigate those options instead of stopping where the available hours ran out.
Point it the right way, then go further
Cheap trips let me explore, but I need to recognize what each one taught me. Understanding the route helps me spot a problem; checking the result tells me whether another attempt is worthwhile. When something proves useful, I decide whether to keep it running.
Sometimes I take several short trips before choosing a destination. Sometimes I hold a chosen route steady while the agent handles the driving. More of my work is in those decisions now.
The old car made me choose from the places I could reach. The new one lets me explore places I used to leave on the map, then decide which are worth returning to.