Stop Waiting for the Next Model
SkyHaven Group · Field note · AI systems · Building
Stop waiting for the next model.
I’m tired of watching capable people wait for a better model while smart people spend their days copying data between systems. We already have enough to start.
I keep hearing the same sentence: “We’re waiting for the next model.”
Waiting for what?
The next model will be better. Of course it will. Use it when it shows up.
The models we have today can read documents, write code, call APIs, query databases, watch queues, compare records, and move work between systems. A few years ago, we would have called that science fiction.
Now we use it to write cleaner meeting notes.
That gap drives me crazy.
I see technology that can remove whole layers of administrative drag. I also see people sitting on their hands because they can’t draw the final architecture yet, don’t trust every model response, or think one more release will make the decision obvious.
It won’t.
You don’t need the final architecture. You need one real problem, one person who understands it, and enough nerve to build the first version.
01 / We have enough
Put the model to work.
I don’t believe every claim people make about AI. You shouldn’t either. Models make things up. Agents fail. Permissions matter. Bad automation can make a mess faster than a person can.
None of that changes what the tools can already do.
Put a model inside a harness. Give it tools, narrow permissions, logs, and clear places to stop. Connect it to the inbox, shared drive, database, ticketing system, CRM, or whatever actually sits in the path.
Let it read, compare, transform, draft, and route. Make a person approve the actions that carry real consequences.
Now the model stops acting like a chat window and starts carrying work.
That shift matters. For decades, teams spent months building scaffolding before they could test the idea. Today, a small team can put a working version in front of the expert while that expert still sits in the room.
02 / Take it off the plate
Stop making smart people do stupid work.
I mean the work, not the people.
I’ve watched capable people become the integration layer between systems that should already talk. Someone downloads a report. Someone cleans the columns. Someone copies the values into a workbook. Someone updates a slide. Someone emails it to another person, who enters the same information somewhere else.
Everybody knows the process makes no sense. Everybody still does it because “that’s how it works.”
That is stupid work. The person doing it may understand the business better than anyone else in the building. We should not spend that person’s time moving cells.
Take this off the plate.
These tasks don’t need more attention. They need a connection, a rule, and an exception path.
- Download the same report every morning.
- Copy fields from an email into a spreadsheet.
- Move a CSV from one system into another.
- Reconcile two tools that both claim to be right.
- Rebuild the same status update every Friday.
- Hunt through a shared drive for the latest file.
Connect the systems. Let the harness collect and reconcile the data. Send the exceptions to a person. Keep the person at the point where judgment matters.
Use people to investigate, decide, design, fix, negotiate, and build. Stop using them as middleware.
This isn’t a headcount argument. It’s a time argument. Every hour we give back to an expert becomes an hour they can spend on work that actually requires an expert.
03 / The experts are the point
AI makes expertise more useful.
A harness can read ten thousand files. The expert knows which file lies.
The operator knows the alarm sits inside the approved range and still looks wrong. The engineer knows a field changed meaning in 2017 and the schema never caught up. The finance person knows FINAL_v7_USE_THIS_ONE.xlsx contains two macros that quietly carry the real business process.
The model can help with the volume. The expert supplies the judgment.
Put the expert next to the builder from the first day. Let them try the workflow. Watch where they hesitate. Ask why they reject an answer. Follow the ugly edge case.
A sixty-page requirements document can’t give you that. A working system can.
This part excites me more than the model itself. People who understand complex systems can explore again. They can test an idea while it still feels rough. They can change the software when reality proves them wrong. They can spend more time on the part of the work that actually requires them.
04 / For the people on the fence
You can move without betting the company.
Some hesitation makes sense. You have real data, real customers, and real consequences. You should not hand an agent production credentials and hope for the best.
So don’t.
Start with read-only access. Pick one repeated handoff. Let the harness gather the records, compare the systems, prepare the draft, or build the report. Log every action. Keep the current process running beside it. Make a person approve the final step.
Then look at the evidence. Did it save time? Did it miss anything? Where did it need help? Tighten the boundary. Add the check. Expand only after the system earns your trust.
You don’t need faith in the whole AI story. You need a real workflow and a fair test.
Use caution to shape the system. Give the harness narrow permissions. Separate read from write. Put approval gates around consequential actions. Keep logs. Test the failure cases.
But don’t turn caution into a permanent excuse. You build a safe system by defining its boundaries, watching it work, and fixing what fails.
05 / Build the first real version
Build something ugly enough to tell you the truth.
People keep waiting for clean data, the right vendor, the stable model, the perfect use case, and the final architecture.
They overvalue the architecture they can explain on a slide and undervalue the rough version that touches the actual process.
The first version will hit the bad date. It will find the approval that happens by text message. It will discover that the shared folder serves as the real system of record and that one person holds the entire process together with three macros and an inbox rule.
Good. Now you found the real system.
Fix the boundary. Add the check. Change the workflow. Run it again.
You won’t think your way into certainty. You will build your way into understanding.
06 / The next model is not a plan
The next model will help the builder more than the waiter.
Another model will arrive. Let it.
People act as though a better model will invalidate the work they do today. It won’t. You may swap the model. You will keep the connections, permissions, tests, exception paths, workflow, and trust you earned with users.
Most of the hard-won knowledge lives outside the model.
The teams building now will know exactly where the next model helps. They will have real users, real failures, and real work ready for it.
The teams that wait will still have nothing connected.
Waiting no longer protects you. It just leaves the work on people’s plates.
