I'm building more software than at any point in my career, and I'm writing none of the code behind it.
Picture a film set at six in the morning. Electricians are rigging lights forty feet up. A sound mixer is chasing a hum from the generator. Someone from continuity is photographing every coffee cup on the table so it's in the same place after lunch. Wardrobe, makeup and the camera crew are all working, and an editor is waiting back at the studio to cut it together. A two-minute scene takes dozens of people who never appear on screen.
For most of my career, I was one person with a camera. I could shoot good scenes: a Python script that collected the data, a pipeline that cleaned it, a model that organized it, a report that showed it. Each one was useful, and none of them was an application a team could run its work in. That took a backend developer, a frontend developer, someone for the infrastructure and someone to test it. I didn't have the crew to make the film, so I shot scenes and handed them to whoever could carry the story forward.
Coding agents changed who's on set. An agent works across the database, the API, the interface, the tests and the deployment in a single session. My job moved from operating one camera to producing: deciding what we're making and who it's for, watching what comes back, and deciding when it's ready.
This post is about one kind of film in particular: operational applications. That's the software people use to do their work and keep its records: setting the work up, carrying it out, recording what happened and producing what the next person needs. Reports and other ways of exploring data are a different production, and I cover them separately.
The film was always too big for the crew
Every team has a process that should be software and isn't. Usually it lives in Excel, with a few other tools stitched around it by hand: an email to set something up, a call to do the work, a spreadsheet to record it and a document someone assembles afterward to report it. Each step works. The person in the middle carries everything between them.
Excel ends up at the center because it's already there. It's on every computer, the company already pays for it, and it's genuinely powerful. A capable person can build a tracker, a small database, a calculator and a report in one workbook. So it gets stretched to cover whatever the team needs next, well past the point where a spreadsheet is a comfortable home for the work.
Buying dedicated software is the other option, and for a small process it's often too expensive or too broad. A product built for many customers asks the team to adapt to it, as I described in the SaaS post, and much of what gets called onboarding is people learning those adaptations.
The option that would actually fit, software built around the process, was out of reach for a different reason: assembling it. Writing the application's code is one skill. Around it sits the architecture that turns code into something people can rely on, and each piece is its own department on the set:
- The interface is the set: everything the audience actually sees and touches.
- The database is continuity: the record that keeps today's scene consistent with yesterday's.
- Accounts and permissions are the door staff, deciding who gets in and where they can go.
- Hosting is the theater, somewhere people can actually watch.
- Logging is the clapperboard at the start of every take, a label so you can find out later what happened.
- Monitoring is someone in the projection booth during the screening, noticing when the picture drops.
- Performance is pacing: whether it moves fast enough that the audience stays.
Every one of those departments has to be set up, configured and kept working with the others, and a mistake in one shows up in another. Finding people who know each piece and coordinating their work is a team's worth of effort. For a group with one awkward process, nobody could justify hiring that crew, so Excel stayed and people kept stitching the rest together by hand.
That's the part agents change. Every department still has to be run well, but one person can now oversee them all, and the small, specific applications that never justified a team become buildable.
Producing one: a telehealth platform with a crew of two
My co-founder is a physical therapist and had the idea. I'm the technical half of a two-person company. The idea was to fix one of the most manual parts of a therapist's work: measuring range of motion, how far a joint moves.
The traditional process is manual from start to finish. In person, a therapist holds a goniometer, a hinged ruler, against the joint and reads off the angle, and two people measuring the same joint can get different numbers. Remotely, it becomes a stack of separate steps: a video call, screenshots of the patient mid-movement, an angle measured by hand from each screenshot, and a PDF report assembled afterward. Comparing this visit with the last one means finding the last report.
My co-founder wasn't relying on a goniometer alone. Products that measure range of motion with a camera already exist, and he was paying for one. It measured the angles. It didn't produce the report he wanted to hand a patient, it didn't chart a patient's progress across visits the way he follows recovery, and it came with features built for other kinds of customers that he never used. He was paying for a whole product that covered one step of his workflow, and the rest still happened around it by hand.
The Range of Motion Tracker is built around the whole workflow instead. A therapist runs a session in person or over video, computer vision in the browser measures the joint as the patient moves, and the session becomes a report and a running record of progress over time. Therapists assign exercise programs from the results, patients follow their programs and progress in their own portal, and practices manage their therapists and patients as an organization. It's built for clinical practices and for workplace programs that track mobility for people in physically demanding jobs.
That's a long crew list for two people: video calling, computer vision, the geometry for dozens of movements, patient records, exercise programs, report generation, separate portals for therapists, patients and administrators, and organizations that keep their data apart, on top of every department in the list above. Before agents, building it would have meant hiring most of those specialties before learning whether practices wanted it. Agents built it, and neither of us writes the code.
The split between us is the split between the script and the production. My co-founder knows the material: what a valid measurement looks like, what a therapist needs to see after a session, what patients will and won't do between visits. I turn that into decisions the crew can build from: what a session is, what the report contains, what each role can see and do, where the data lives and how it's protected. The agents build it.
Watch the footage, then reshoot
On a film set, the producer watches each day's raw footage the next morning and decides which scenes need to be shot again. Building software with agents works the same way. The requirements come into focus while you watch the application run.
The first version of anything an agent builds tends to look finished. The layout is clean, the colors are consistent and the buttons are where buttons go. That polish arrives early, and it can hide whether the application is useful yet. The real test is whether it does the job for the person using it, and that only shows up when someone uses it.
The platform has been reshot many times, and every reshoot was about what it does for the people using it. The report changed until it was the document my co-founder wanted to hand a patient. Progress tracking grew from a list of past sessions into charts that show where a patient is improving and where they've stalled. Once the measurements were right, the platform added exercise programs, and then a portal where patients follow their own programs and progress between visits. Later, the same measurement tools opened up to workplace programs that track mobility for physically demanding jobs. Under all of that sat a long series of smaller reshoots to screens and layouts: the work of getting from a screen that looks right to one a therapist can actually run a session from.
Each round taught us something we couldn't have written in a requirements document beforehand. Requirements documents existed partly because building was expensive. When each version cost weeks, you had to get the plan right first. When a reshoot costs a day, watching the application in use can write much of the specification. What we learn still needs to be written down, in the repository where the next session will read it, or the agent will happily rebuild the version we already rejected.
What the producer still owns
The agents supply the crew. Several responsibilities stay with whoever is producing, and a platform that holds health information raises the stakes on every one of them.
The records. A report that shows a wrong number can be fixed and refreshed. A platform that records a wrong measurement has changed someone's clinical history. Deciding what a valid measurement is, and checking that each one matches how the movement is clinically measured, is producer work. One review found two opposite ankle movements producing the same reading. A number appeared either way, and only a check against the clinical definition caught it.
Who can do what. Therapists, patients and administrators each get their own view of the platform, and one practice's patients have to stay invisible to every other practice. The agents built those boundaries. Deciding where they sit, and that they hold no matter what, was mine.
What the business promises. Storing patient health information comes with obligations: how it's protected, who can access it, what patients consent to, and which outside services are allowed to touch it. Agents helped research those requirements and built the consent and audit features. Deciding what the company commits to, what's ready to sell and what blocks a launch is a decision for the two people whose names are on it.
Whether it works. An agent's report that a feature is done describes the code, and I've learned to ask for evidence of how the feature ran before I accept it. I wrote about how I check separately.
The working environment. The agents work more independently when the project's decisions, conventions and checks are already in place. Preparing that is part of the job, which I covered in Give the Agent a Working Environment.
Final cut
The deliverable has changed. I used to hand over a script, a pipeline or a report and let someone else carry the work forward in email and spreadsheets. Now two people can produce a platform: the place where the work happens, from setting up a session to recording it, reporting it and following up, built around how the people using it actually work.
That changes where I start. I look for the process held together by a call, a few screenshots, a spreadsheet and a document someone assembles by hand, ask what the people doing it would want if the software fit them, and produce that. The agent builds every take. I decide what the workflow should do, watch it run, call the reshoots, and decide when it's ready to ship.
The crew is ready. Pick the process worth producing.