Last night, I had a late-night chat with a friend I’ve known for over ten years. We circled around one question: when AI rewrites the game, what software is actually worth building?
Let me be direct: no one knows exactly how the future will look. Right now, most people are running in full sprint with the lights off.
Running blind is not always wrong. I do it too.
But one thing is becoming clearer every day: direction can be tested by trial, but methodology cannot be dropped. Without methodology, you will hit walls that could have been avoided.
Since 2024, I have focused on Data Agent and moved from open-source Auto-Coder to today’s InfiniSynapse. I’ve hit enough walls to trust this rule now:
this year we narrowed “what software is worth building” into just three standards. I’m writing them down while it’s still hot.
First, what not to build: if you can build it in a week, don’t build it
Let’s draw the line first, then talk about direction.
If a general-purpose product can be built in a week, usually don’t build it.
Why? In this era, what used to take months has been compressed into days by AI. The moat is gone. A good idea that takes you one day can be copied with one good prompt the next day.
So what survives is clear: go deep, go narrow, go specific.
The middle layer—the “fast enough, not too hard, not too broad” space—is exactly where the danger sits. That’s where AI can catch up in one week, and that’s where most people get eaten.
1) Build for yourself
If you insist on building software, my first recommendation is: build for yourself first.
We are now in an era of truly personalized software. This is not a slogan; it is something I use every day.
A concrete example.
Two years ago, if I wanted to record and cut videos, I needed Screen Studio, Jianying, or another generic tool stack. The money for software wasn’t the big cost. The real cost was learning time and cognitive friction.
Every tool has its own behavior. You spend more energy adapting to it than adapting your work to it.
Today it is different.
I describe my own editing habits, the outcomes I need, the visuals I usually assemble—then ask AI to generate the tool behavior. By next morning, I have a video editor built exactly for me.
I no longer need to spend weeks learning to use it. It behaves like an extension of my habits, because it is one.
The same logic applies to translation, email assistants, and every day-to-day workflow: I no longer bend around generic software; I make software bend around me.
The biggest advantage of this is: this type of software has no market, and therefore no direct competitor. It serves only you, so it can’t be “copied first”.
From an execution perspective, this gives the highest immediate return:
- immediate efficiency gains,
- near-zero competitor pressure,
- immediate compounding from accumulated personal workflow improvements.
And this is not just about convenience.
Building software for yourself is an investment in yourself.
The same principle still guides me: you are the best investment in this cycle.
Whatever is risky in the external market is often not the best use of effort. Building for yourself tends to have stable upside and low downside.
As long as your personal output improves, the business gets stronger. Your personal workflow becomes the ceiling of your company.
So if someone says this is “not serious, just personal tooling,” remember this: in the AI era, this is one of the best ROI moves you can make.
2) Build what AI still can’t fully do
Second route: build what is still beyond AI’s reach.
AI is powerful where it has input. What AI cannot access is the boundary of AI capability.
Where is that boundary today?
- closed-source systems it cannot inspect,
- private enterprise data it cannot touch,
- trust, reputation, and physical delivery in offline/offchain contexts,
- heavily regulated workflows with hard compliance requirements.
These are not obstacles you can solve by adding a few prompts. They are structural boundaries. The gap is often in data and context availability, not model quality.
A lot of “hard-to-do” tasks are hard because the model can’t get the input stream the way a real team can.
There is one harder class, not as obvious: AI may “see” it, but still can’t replace the time needed to own and improve it. That’s where point three gets interesting.
3) Build beneath AI
Third and the one I am executing on right now: build beneath the AI layer.
Everyone is building Agents. Agents are the top-most layer and can be wrapped quickly. I’m not trying to build a new Agent wrapper. I’m building the subsystem right below where Agent behavior depends on stable structure.
Why does this have a moat?
Because good systems are co-evolved with users.
The same task has dozens of possible approaches. Which one is right? Even now, no one can answer that instantly. AI does not know either—not because it is dumb, but because the right answer usually does not exist until usage rounds produce it.
And usage happens over time, not in a day.
Today users say one thing, tomorrow they say something else, then we revise, then we re-deploy. One feature after another. Over a year, those repeated, disciplined corrections accumulate into a judgment of “this is the right way.”
That is the moat.
Not code snippets that can be copied. Not one-off benchmarks. A system shaped by years of usage feedback, edge cases, and correction loops. That sort of human-in-the-loop craft is not portable by prompt.
A less obvious practical point: Smart people are no longer scarce. What they lack is patience. Nobody likes to sit with hard problems for years. So “endurance” itself becomes part of the moat.
Give AI three more years and it still can’t build a true macOS. First, there is no open access. Second, even if it did, the product quality here is not built in one pass—it is the outcome of years of user feedback, not an overnight trick.
To bring it back to my stack:
When people talk about my Data Agent project, they often think they mean the visible Agent UI. In practice, I spend my effort on everything under it:
- I rewrote SQL as InfiniSQL;
- I rewrote knowledge retrieval as InfiniRAG;
- I rewrote the distributed SQL execution layer again and again.
The Agent is easy to wrap. The layer below it is where hard work compounds and where competition is hard to replicate.
That’s what I mean by moat with design taste.
Aesthetic sense is not a one-off talent. It is the result of repeated corrections: “this feels awkward” → “that feels right”. AI can imitate style, but it cannot replace repeated human correction over time.
Conclusion
AI brought software creation costs down dramatically. That is good news.
But it also made one thing more visible: what is still truly valuable.
It is now this:
- either software for yourself (build small and personal),
- or software outside AI’s data boundary, hard for AI to copy,
- or software built under AI, in the layer that requires long-run co-evolution.
The middle lane—the “one-week AI-copyable” zone—is the riskiest.
So yes, you can still run blind in the AI era. Just keep this map in one hand, otherwise collisions are guaranteed.
If you are using Cursor, Claude Code, or other Agents and want them to call InfiniSynapse directly for data analysis:
- download a command tool named
agent_infinifrom infinisynapse.cn/tools, - put it in PATH,
- set your API key once,
No pip install, no Node runtime, no persistent MCP service needed.
Then in Cursor / Claude Code, you do not need to write the full CLI command yourself. You can simply tell the Agent:
Use the
agent_infinitool to "calculate Q1 revenue and output the sales-recognized and finance-recognized numbers side by side."
The Agent can translate that intent into the actual agent_infini command, submit the task to remote InfiniSynapse, and return the result into your editor.
That is the clearest way I can show right now to call the harness under Agents, not only the Agent wrapper.
If you want the complete product, check infinisynapse.com (or infinisynapse.cn inside China). We have SaaS, desktop, and private deployment. For questions, email zhuhl@infinisynapse.com.
What I aim for remains the same: software that makes AI users more stable under the hood, not just noisier on top.