The most technically impressive person in the interview might not be the person I’d trust with the app.
A shift cooking dumplings helped clarify why.
For the first six months of this year, my weekend project was selling dumplings at a farmers market. One weekend, I took over a shift as the chef.
We had one big electric frying pan, several fillings, and dumplings that all looked the same. As some came off and others went on, keeping track of which belonged to which order became a job of its own.
You’re cooking, taking orders, talking to customers, and explaining the fillings to someone who just walked up. Somewhere in there, you’re supposed to remember where every dumpling belongs.
So I built a visual map of the pan into our software. Each dumpling has a position, a filling, and an order attached to it. You can add five at a time for a standard order or individually for a mixed order.
It took an evening to build. We’ve used it during actual service.
I did the job, experienced the problem, decided what would solve it, and built the solution. One person carried the understanding all the way through.
AI makes it more practical for that person to own the application. That should change who we hire—and when we add a second developer.
What another developer adds
Adding someone brings capacity. It also brings another interpretation of how the application should work.
Where does a feature belong? How should a process behave? What should the user have to do next?
Even on teams of two or three, those interpretations can leave seams. One feature behaves one way. Another introduces a different set of conventions. Both work individually, but moving between them means learning the application again.
I’ve seen this with very experienced developers. Technical ability doesn’t automatically produce an understanding of the whole app, or an interest in how a person actually uses it.
Before AI, the volume of implementation work often made those coordination costs unavoidable. One person could only get through so much in a day.
One person still has limits. But I think AI has moved the threshold at which another developer becomes necessary. I’d want to understand that limit on the actual project before staffing around it.
The person I’d start with would need to do more than implement requirements. They would need to recognize when the requirements were missing the point.
I spent six years on the receiving end
Before spending the last nine years developing software, I spent six years working in finance and using business applications.
One job involved moving forecasts from Excel into the system of record: six to twelve months of hours for somewhere between 30 and 300 people.
With a well-designed system, that could potentially be one copy and paste.
Instead, pagination limited how much I could paste at a time. The system also automatically sorted the data into an order its developers apparently considered logical. Every time I pasted another batch, I had to re-sort my spreadsheet to match.
The data was already there. The work was already done. The software created more work because somebody hadn’t understood how the information actually arrived.
That experience informs how I build at Kinetech, where I develop software primarily for governments, especially health and human services departments.
What is this person trying to accomplish? Do they think in terms of a case, a family, a program, or a funding source? What information do they need in front of them? What do they already understand about the application?
Those questions affect whether the software helps someone finish their work or gives them another process to manage.
Go do the job
You cannot get all of this from a demo.
Sit beside the person doing the work. Follow the process through the spreadsheets, emails, and workarounds that surround the official process. Better yet, where you can, do the job yourself.
The pan feature became obvious when I worked the shift. Sometimes the improvement is smaller: watch someone struggle to clear a default zero before entering a number, and you realize the field should start empty.
My test is to take a real use case and work it end to end. Try the simple version, the complex version, and the point where something unusual happens. Include the other people who participate in the process.
If it doesn’t work in the actual use case, it doesn’t work. I don’t care how neatly it satisfies the written requirements.
This is also how I check AI-assisted work. AI can produce a bolted-together mess. Someone still has to notice that a feature is in the wrong place, that a workflow contradicts the rest of the application, or that the user is doing unnecessary work.
That person can now handle much more of the implementation, too. The responsibilities still include testing, security, deployment, and support. Asking an agent to review something is a step in that work, not proof that it is correct.
Does this extend beyond a dumpling business?
Before AI was part of our development workflow, I built a COVID mortgage-assistance application for Michigan.
We had just completed a rental-assistance solution, so I had a substantial starting point. The programs were closely related, but adapting the application still required material work: roughly three to four months to go live, followed by another three to four months after launch.
I was the primary developer and owned the application end to end. When someone else helped, I worked through their contributions, adjusted them to fit the rest of the app, and checked them before they went live.
I’d already proved that one person could own the whole application. The problem was that I was working two shifts to do it.
I started around 6:30 in the morning to develop before meetings. From roughly eight until three, I gathered requirements, answered questions, troubleshot work in the test environment, and coordinated decisions. Then I went back to building, often until seven or eight at night.
The conversations were how we figured out what to build. Getting the implementation done around them required an extraordinary number of hours. And this was already on a low-code platform.
Today, I believe AI-assisted development could let me deliver comparable work on roughly the same project timeline, with something much closer to a normal working day.
That is an expectation based on what the Michigan work took and what I’m building with AI now. It is not a result I’ve demonstrated by repeating that project with AI.
What interests me is keeping that hands-on ownership without requiring another shift to get the implementation done.
They kept asking us back. We’re now on our fifth engagement. I believe the coherent experience helped, but the trust came from taking responsibility for delivery, including when something needed fixing.
Ownership doesn’t mean working alone. The business still has to participate, and some projects need specialist help or concurrent development to meet a deadline. I would want a specific reason to add another developer, grounded in the work that needs doing.
Here’s who I’d hire
Show me an application you built. Explain the use case. Walk me through it and tell me why you made those choices.
Did you keep the information the user needed close at hand? Do similar actions behave consistently? What did you change after watching someone use it?
I want someone who notices the repeated re-sorting, understands why the chef is losing track of orders, and takes responsibility for fixing it. Someone who personally uses the whole application before handing it over.
That person might be an experienced developer. They might be a business expert who has learned to build with AI. Either way, I want to see their judgment in working software.
Give that person the tools, access to the users, and ownership of the whole experience.
Then make the case for hiring a second.
More writing → /blog