Large language models are improving faster and faster, and AI can handle more and more tasks. In software development, for example, AI can already contribute to requirements analysis, solution design, coding, and testing. As these capabilities continue to improve, the way software is developed will change too.
If AI goes further and performs physical work through robots, how might home life, business operations, and service industries change?
Consider how human society works today. Complex work is usually divided among people with different specialties and roles, who collaborate to deliver the result. Might future AI develop a similar division of labor?
Following this line of thought may help clarify which technologies and services will be needed in the future, and which projects fit that direction and can be built now. That is what “Model the Future, Act in the Present” sets out to explore.
When robots enter the home
Programming is just one example. If AI can do physical work through robots, its impact on everyday life will become more direct.
Imagine robots that can reliably handle common household chores at prices ordinary families can afford. Having a robotic assistant might become as natural as owning a washing machine today. Cleaning, tidying, moving objects, and some everyday assistance could all be handled by it.
Before that can happen, robots still need to overcome challenges involving reliability, battery life, maintenance, and cost. Improvements in manufacturing efficiency will also affect how quickly they reach ordinary households. For now, I will set aside employment and social institutions and focus on a technical question:
What knowledge and capabilities would such a robot need locally? And whom should it turn to when it cannot solve a problem?
A household robot needs to know the layout of the rooms, where things usually belong, and its owner's habits. This information can be stored locally. Recognizing its surroundings, controlling its movements, and doing common chores also require suitable on-device capabilities.
But tidying a room does not require it to have the strongest specialist capabilities in every field. It can look up unfamiliar information, use tools for specialist tasks, or ask a more suitable model for help.
This resembles how people solve problems. We rely on experience for everyday tasks, look things up when something is unfamiliar, and consult specialists for professional questions. We do not expect everyone to be an expert in every field.
Future robots may therefore work in a similar way: keep everyday capabilities and personal memory locally, then connect to the cloud for more knowledge or specialist help when needed.
General knowledge and personal memory need to be handled separately. A method for tidying a room can be shared; a particular household's object locations, habits, and daily records need clear rules about who may access them and how they may be used. A cloud connection does not mean uploading and sharing everything that happens at home.
Will AI specialize as human society does?
Following this line of thought, future AI may develop a division of labor much like human society.
Industrial society divides complex work into stages, assigns them to different people, and brings their work together through collaboration. AI is becoming more capable, but tasks still differ in the knowledge, speed, cost, and reliability they require.
This specialization may first develop across industries.
Medicine, law, and engineering deal with different problems and need different information, tools, and grounds for judgment. AI serving these fields will have different professional requirements too.
Specialization can also happen within an industry.
In software development, design clarifies requirements and decides on an approach; coding implements it; testing checks behavior, edge cases, and failures. Different AI roles could take on these responsibilities.
A design AI proposes a plan, a coding AI implements it, and a testing AI checks the result. When a problem is found, the work returns to design or coding for correction.
Different roles do not necessarily mean separately trained models. The same foundation model can take on different responsibilities using different information, tools, and permissions. What matters is what each role is responsible for, what it delivers, and who takes over next.
Whether a task needs that many roles depends on the results. Some problems can be solved by one model; others are worth dividing up. The value of specialization needs to be judged by results, time, and cost.
Specialization needs shared specifications and verification
When several AI roles work on one task, they first need to follow the same specifications.
Which requirements guide the design? Which modules may the coding role change? How does testing decide that the task is complete? Which decisions are settled, and which questions still need discussion?
If these are unclear, more AI participants may simply produce more disconnected work. Code can be generated quickly and still be difficult to assemble into a project that remains maintainable.
This is why specification-driven development is becoming more important.
In the past, some conventions could remain in developers' heads, with a team relying on mutual understanding. As AI speeds up implementation and more roles participate, unwritten requirements become more likely to cause disagreement and errors.
Agreement among several models cannot replace actual verification. If they all accept the same mistaken premise, they may reach the same wrong conclusion.
In the editor tools I develop, AI can help interpret requirements, generate code, and explain reports. Check programs read actual data, apply explicit rules, and provide results. Developers define goals, review proposals, and keep improving the tools based on real use.
The faster we generate, the more specifications and verification need to keep up. Otherwise, we may increase both output and the problems we will have to deal with later.
From industry specialization to company-specific AI
If AI has learned an industry's knowledge, can it immediately go to work in any company?
Probably not.
Even an experienced programmer joining a company needs to learn its project architecture, business context, and development processes. AI working inside a company needs this background too.
A general model knows what projects, departments, and approvals mean. It does not inherently know who owns which project in a particular company, which systems may be changed, why a proposal was rejected, or which information is restricted to a particular team.
Each company may therefore have its own AI that understands its business.
It would need more than product descriptions. Organization structure, job responsibilities, business processes, internal standards, past decisions, and even trade secrets could all be part of what it needs to know.
For example, a development assistant handling a change request needs more than an understanding of the code. It needs to know the current release constraints, which modules other teams maintain, and which checks the change must pass.
A business assistant handling customer issues also needs to know the company's service commitments, approval processes, and previous handling records.
Which information company AI may access and which actions it may perform both need permission controls. Knowing something does not mean it may share it with every employee; connecting to a business system does not mean it may perform every action in that system.
Who would build and maintain this kind of AI? There are two main approaches.
A supplier provides the foundation model; the company manages it
The model supplier provides general language, reasoning, and multimodal capabilities. The company connects its own knowledge base, business systems, and tools, trains and customizes as needed, and takes responsibility for deployment, permissions, updates, and maintenance.
The company can decide which data to connect, what AI may do, and how the system runs. It also takes on the associated development and maintenance work.
This could be an important route for companies with technical teams that want control over core data and operations.
A supplier provides a complete solution; the company pays to use it
The supplier brings together models, knowledge access, tool connections, role collaboration, and ongoing operations. The company provides its information and business rules, configures employee and department permissions, and gradually uses the system for development, operations, or internal services.
This could give companies without a dedicated AI team access to AI that understands their business.
The company pays for an AI service that handles real business work and is maintained by the supplier. Beyond model capability, it needs to consider which tasks the service can complete, how reliable the results are, and how problems are handled.
When internal information is involved, both sides need clear answers: what data may the supplier access, may it be used for other training, how is each company's data kept separate, and how can it be retrieved and deleted when the relationship ends?
These approaches can be combined. A company can manage AI involving its core business itself and use hosted services for other work. The choice depends on technical ability, business requirements, and long-term cost.
Models can change; what a company has accumulated should remain
Having company-specific AI does not necessarily mean training a foundation model of its own or training all its information into model parameters.
Company knowledge can live in a knowledge base, business actions can be performed through tools, and permission rules and long-term memory can be maintained separately. These can then be brought together as each task requires.
Foundation models can keep improving, while the company's knowledge, rules, and working experience remain.
Changing models should not require explaining the organization structure from scratch or losing business rules already confirmed. Proven ways of handling work should also support later tasks within the permitted scope.
Inside a company, the system needs to choose more than a model. It also needs to decide which role handles a task, which tools it uses, and which information it may access.
Returning from the future to what is worth doing today
If this division of labor gradually emerges, the directions worth investing in today become easier to see.
How can we organize company information so AI finds the right facts? How can personal and company experience be retained over time? How can we connect business systems and control permissions? How can AI roles hand work to one another and confirm that a task is actually complete?
These are problems we can start working on now.
Foundation models will keep improving. Getting AI to handle a particular job well also requires someone to connect the information, tools, processes, and ways of checking the result.
One direct question is: can the system decide how to solve a problem itself, reducing the choices users have to make before using it?
Answer simple questions directly, look up missing information, call a suitable model for specialist help, and use tools when action is needed. When a task cannot be handled reliably, explain that clearly or ask for further help.
This requires more than deciding whether a question is easy or difficult. Some need current information, others need specific tools or longer reasoning, and some need human confirmation. The system needs to recognize these differences and check whether its approach works.
Future general intelligence could have one interface for users, with different models, tools, and roles collaborating behind it.
Yingying: starting with model selection
This is also why I am developing Yingying.
Yingying is an Android AI chat app I am developing. Users ask questions within the same conversation, and the server selects the reply model and reasoning effort based on the question and conversation context.
Models have different strengths in capability, speed, and cost. Many users care about whether their problem gets solved and do not want to study model names and reasoning settings before every question.
I want Yingying to take on some of that selection work, letting users focus more on what they want to accomplish.
After addressing model selection, I can gradually explore having it call specialist tools, split tasks into parts, and check whether the work is actually complete.
For me, this is a first step toward general intelligence: let the system make some tool choices for the user, then use real-world experience to check whether those choices work.
The household robots, collaboration among development roles, and company-specific AI discussed here are still future scenarios. Yingying starts with one concrete problem within that picture and builds experience step by step.
You can download Yingying (Android APK) to try it. The app requires account sign-in, and model calls are billed by actual usage. Billing rules and prices are available in the app.
The future may not unfold exactly as we imagine it today, but exploring it can help us choose a direction. Doing the work is how we find out which judgments hold and which ideas need to change.
Model the future to give action a direction; act in the present to put those ideas to the test.