From Engineer to Builder: One-Person Companies and Product Thinking in the AI Era

This English version was machine-translated from the Chinese original. Technical terms may require verification.

In my last article on Generating AI, I wrote a judgment: AI will not simply end the job, it is more likely to change the division of tasks and generate more demand. For programmers, codes, files, data studies, draft designs and demo are cheaper. The result is not necessarily a reduction in work, but rather a faster way for individuals to try to do what they used to do, which they did not have time or capacity to do.

The questions in this article can also be addressedModel Is Good End: 2026, AI, which is really scarce, is an application rather than a larger model.、From designer to Agent Builder: Look, do, think.How the concept of a relatively close read together is developed in different contexts.

One example: as Coding Agent or LLM gets stronger, I feel more often that a project or tool is not satisfactory to me, and I want to do some of the changes I like. The number of projects that I personally have been focusing on is also growing. And 2024 and the first half of 2025, these ideas will probably not come into my mind. It is too hard for me to solve it.

Traditional Software Engineer is approaching Builder. Past software engineering was defined by organizational division of labour: product demand, design interaction, engineer performance, testing for quality, operation and sales for user outreach. Engineers mostly solve problems that others have defined well.

AI expanded the scope of work that individuals can accomplish independently. An engineer can now run a smaller product link by means of tools to handle part of the research, design, development and operation tasks. The Builder is the person who can choose the problem, make the product, find the user and continue to adjust on the basis of feedback, not just write more codes.

When the code gets cheaper, the engineer's value moves forward.

Anthropic Economic Index observed that AI is used mainly in cognitive tasks such as software development, technical writing, etc. At this stage, it is more about changing specific tasks than replacing the entire career at a time. Google DORA 2025 also noted that the benefits of the AI tool were related to the original team approach, feedback mechanisms and quality standards. Tools can accelerate implementation and may also allow for the faster accumulation of existing process problems.

Microsoft 2026 Work Trend Index describes a new division of organizational tasks: AI and angent assume more implementation, and humans take responsibility for intent, judgement, quality standards and job design. Putting it on personal developers means that many judgements need to occur earlier. The code is written with consideration of what is worth realizing, who uses it, how to validate it, and where the first users came from.

A demo that runs is not a product. AI makes demo cheaper, and makes people quickly pile more output in the wrong direction. The past was at least tired of doing the wrong thing, and now a weekend is a weekend to make something beautiful but uninquiries, which requires engineers to reach users and markets earlier.

OPC: One ' s smallest corporate system

The OPC here is not a legal concept, but a working definition used here: one is responsible for selecting issues, defining products, maintaining user relationships and managing revenue, and entrusting partial implementation to AI and external services. Freelance is usually delivered on time or project basis, while OPC attempts to operate products that can be resold or delivered over time, such as software, plugins, templates, content products, automated services or vertical workflows.

The term “one unicorn” is attractive, assuming that an individual can complete development, design, content, customer service and data analysis with AI. However, the tool chain cannot duplicate the whole organization without cost. For most people, the more realistic starting point is to make a small product that can be maintained and charged on a sustainable basis, rather than first pursuing the unicorn.

More pronounced changes occur in the functions of companies. Part of the development, design, customer service, deployment, payment, distribution and data analysis can be entrusted to AI, automation, SaaS, cloud services, outsourcing or platform markets. Without having to form a full organization on the first day, entrepreneurs can first find users and problems and then access these capabilities as needed.

An OPC to build up four capabilities. First, it identifies the clients and the specific issues; second, it is duplicated by software, templates, automation or content products; then it is price, payment mode and renewal or repurchase justification; and lastly, it is continuously looking at data on usage, retention, refund, customer service and conversion. Early products may not have all the capabilities at the same time, but a chronic lack of income or feedback mechanisms makes it difficult to become sustainable businesses.

It is easier for ordinary engineers to start with a narrower range of products, such as mini-SaaS, browser plugins, developers' tools, industry templates, automated scripts, or to make internal and repeated work streams into external tools. The selection of the topics begins with the question of whether a specific population is repeatedly confronted with the same type of problems and whether the product can be used to save time or costs.

Support is less costly, easy to automate, and delivery is stable, and operations that clearly capture the entry are more suitable for small teams to start. AI could delay the expansion of the organization without eliminating cash flows, maintenance, trust, access and compliance issues. The tool reduces the cost of implementation and the need for it remains to be independently validated.

Conversely, not all operations are suitable for starting with OPC. Neither the over-the-counter delivery, heavy sales, strong compliance, heavy-services, long implementation cycles, nor operations that rely on large-scale network effects should simply be conceived of as “one person plus AI”. It is better to start with narrow issues, light delivery, clear access and measurable gains.

Product thinking: First find real pains, then write more codes

For traditional programmers, difficulties often arise in the choice of problems. Engineers can easily start looking for a product that can be put on a new frame, a strong model or a beautiful structure. Users usually do not pay for the novelty of technology, but are concerned about whether the product saves time, lowers costs, increases income or reduces trouble.

Marc Andreasen discusses the problem-mark fit in the “The only thing that matters” to remind entrepreneurs to prioritize market demand. When demand is clear, imperfect products still have the opportunity to continue to improve; when demand is not present, it is difficult to create users with the same elegance as technology. AI makes it easier for the demo to produce and for the team to rapidly increase its input in the wrong direction.

Before proceeding to development, Builder needs to ascertain who has encountered problems and whether the counterparty is willing to pay, spend time or bear the costs of relocation. Don't open it yet. Write on a page to identify who the user is, whether the user, payer and decision maker are the same person, what the current scheme is, how often the problem arises, and where you can find the first interviewee. It's not clear, and the fastest development is just expanding speculation.

a16z suggested that the program-user fit should precede the program-mark fit. For the individual Builder, it would be more useful to find a few specific users first than to estimate a large market. The ability to interview, to hear the same question repeatedly and to obtain a trial or advance offer indicates that the product has at least the starting point for continued validation.

Cut your little tags off the steady track.

Independent development does not have to start with a big DAU track. The term “small DAU” is not the less user there is, but the first to find a limited group of users with stable demand and direct access. They have been repeatedly confronted with the same problem, and are already investing time, budget or bearing the wrong cost; small user groups can support a small product that is long-serving, provided that the problem is high enough or that it is of a single value.

Another more steady starting point is the new tag cut from a stable track. Do not create a need for “AI can do something” in a vacuum, and do not compete with the general product for all users at the outset; first, find the areas where there is a workflow, where there is a fee and where there is a distribution portal, and then cut it down by the user role, the trigger moment and the final delivery. The main track provides demand, budget and common language, small labels provide clear location and access to the first user.

This step requires market research, rather than opening up several competitive sites. At the very least, it is necessary to ascertain who actually used it, who paid, who decided on the procurement and who bore the wrong cost; what methods they now perform their tasks, how often problems occur, whether the delivery results are acceptable or not; and where the first users are assembled and why they are willing to give you a trial or interview. The market research here is also essentially a much earlier test: It is not about whether the product can run, but whether the problem is worth the time to resolve.

The next upgrade of the model will be put in this level of judgement. Will it crush your value into a universal feature, or will it add value to the processes, data, services and distribution that you already have? AI makes the cost of doing demo less and makes the cost of choosing the wrong issue more and more easy to ignore.

The MVP is used to validate key assumptions at lower cost, not simply to delete functions. The validation is conducted by observing the existing solution of the user, the willingness to pay or relocate, the first user sources, and the part of AI that actually reduces the cost of delivery. The project also requires the early installation of a continuation and cessation signal. Low-attractive products can first observe trial, feedback or payment for two weeks; B2B or vertical industries usually have longer certification cycles, which can be used for four to six weeks of examination interviews, pilot intentions and decision chains. These cycles are only initial arrangements and need to be adjusted to the sales and use cycles.

Distribution should start at the selection stage

Technicians often keep the extension after the product is completed. The problem with this is that even if the product is operational, it may not always be possible to find the first users. The distribution method needs to be discussed at the selection stage.

For the individual Builder, distribution is not just an advertisement. Content, open sources, plugin markets, SEOs, communities, app stores, B2B outbound and direct contact in vertical work-scenes can bring users. The choice of which option depends on where the first users are and why they trust the product.

An idea, when it comes to the first time, is to examine where potential users are gathered, through what channels they find products, why they are willing to experiment and whether channels can be used again. If these questions are not answered at all, the business model lacks a path to connect the product to the user.

Different products require different channels. The SEO-type product needs to respond to searchable questions; open source or developer tools need to display repo and integrated scenes; plugin products need to fit into the marktplace; B2B outbound requires clear ICP and trigger events. These conditions in turn affect functions, pricing and product patterns.

Without a steady entry point, small products can easily be stopped at the local project stage. AI reduced production costs, but it took time to gain attention and trust.

From the power cage to the authentication system.

Builder still needs basic engineering. Systematic understanding, testing, deployment, security, data, observability, cost control and long-term maintenance determine whether demo can become a stable service. AI can speed up the code, but it does not automatically guarantee accuracy and does not assume responsibility for the developers for user data, failure of payment, leaking of privileges and interruption of services.

The change is that engineering capacity needs to enter a more early feedback process. First contact users and judgement needs, then minimize validation and decide to continue, contract or stop on the basis of feedback. In addition to the work work done, engineers are required to practice user interviews, needs assessments and channel selection.

In addition to simple Coding, AI can also participate in interview summaries, competition lists, draft landing pages, release papers, the collation of customer service issues and weekly round-ups of indicators. Putting these tasks into a fixed process would make them easier to reuse than if they were to be inspired by the model on a temporary basis and would also reduce the cost of organizing information and preparing experiments on a continuous basis.

The engineer moved to Builder, where the work was first reordered: starting with the specific user, with minimal validation of the pay-for-pays scene and continuing to bring back the data and feedback from the use on-line. Business knowledge could be progressively replenished, but certification could not wait until all products had been completed.

Both OPC and Builder ultimately require individuals to design a minimum working system. AI is responsible for partial execution, quality assurance of engineering capacity, distribution channels to users, and MVP for validation of assumptions. The code is still important, but writing it is only one part of the validation process.

When the code is cheaper, engineers can put more time on whether the problem is worth solving, who wants to use it, and how to verify it as soon as possible. From Engineering to Builder, it is not technology that is abandoned, but that it allows engineering capabilities to reach users and market feedback earlier.

References

• Anthropic, The Anthropic Economic Index
• Google, How are developers using AI? Inside our 2025 DORA report
• Microsoft, 2026 Work Trend Index Annual Report
• Fortune, Could AI create a one-person unicorn?
• Marc Andreessen, The only thing that matters
• a16z, Product-User Fit Comes Before Product-Market Fit
• Blake Masters / Peter Thiel, CS183 notes: If You Build It, Will They Come?
• Lean Enterprise Institute, Lean Startup