Organizational Capability Is the Real Moat for AI Companies | Conversation with Palona AI Co-founder 任川
Summary
曲凯 argues that organizational design may become the competitive advantage and moat that next-generation startups have over traditional companies; Palona AI has about 20 people, no full-time PM, and at least 90% of its code is generated by AI. 任川’s core idea is not “use AI to make people more productive,” but to default to AI handling the entire workflow—documentation, testing, design, coding, review, monitoring, and more—with humans filling only the gaps AI cannot yet cover; the standard is that “human plus AI must produce more than AI alone.”
This workflow trades the certainty of traditional processes for higher iteration speed: Google’s average 1–2 day code review has been compressed to about 10 minutes at Palona AI. Since the start of the year, the company has stopped requiring human review; code can be merged once CodeRabbit AI approves it, with production issues handled through rollback, revert, or direct fixes. But 任川 stresses that this is not a blank check for AI: the team gives AI less autonomy on infra work and adds checks during on-call.
The truly scarce talent is not a specialist in a single function, but a combination of context provider, fast learner, and hands-on builder. What models often lack is not intelligence but high-signal business knowledge; the human role is to learn the minimum necessary context quickly, encode experience into context AI can use, and own the final result rather than passing intermediate work to the next function. 任川 also cited 刘小排, Anthropic’s “top user globally”: he pays $200 a month for the Max Plan and can consume up to $50K worth of tokens, using the Claude API virtually 7×24.
Organizations should move from dividing work by process to dividing it by outcomes, because handoffs between people can easily become the bottleneck in an AI workflow. The person responsible for the consumer experience can edit the backend directly; engineers also visit restaurant owners, work on the product, design, and go-to-market. 任川’s rule is to let one person own work end to end wherever possible, embedding consensus in the codebase instead of repeatedly meeting to align.
Palona AI is velocity first: the engineering team ships a 60-point version, then specialists such as designers push it to 80, 90, or even 100. Rework used to be expensive, so there was a rational case for meeting first and getting the full design right; now, “talk is cheap, but code is cheaper,” and a working product has become the more efficient medium for discussion.
De-product-managing a small team does not mean eliminating specialization forever; the organizational model at scale remains the episode’s biggest open question. 任川 would not claim that PMs will still be unnecessary at 50 or 100 people. A separate sample of a company with about 150 people also suggests that while it may have only about 2 PMs, security, QA, testing, and platform engineering re-emerge as scalability and developer experience become issues.
One direction 任川 is still exploring is a small group of partner-like core members supplemented by specialized contractors, which may fit an AI-native organization better than a traditional full-time pyramid. Core builders are highly valuable and the company depends heavily on them, making the conventional “every role must have a backup” model difficult to sustain. 任川 also advises founders not to rush into hiring: “You hire someone and discover you’re even busier than before,” so the existing partners should first use AI to absorb the incremental workload.
Deep dive
1. Restaurant phone calls are a hard test of agent reliability
任川 said Palona AI uses AI to answer calls for U.S. restaurants, handling reservations, orders, and routine inquiries end to end so the restaurant’s phone “doesn’t have to ring anymore.” Local call-handling staff cost at least about $25 an hour, making the value of automation directly comparable to labor costs.
Its differentiation is a 95%–98% reliability target, versus roughly 70%, which is already considered good for a typical AI agent product. The former means restaurants can stop scheduling someone to watch the phone, rather than treating the product as an assistive tool.
曲凯 said Palona AI was founded last April, has about 20 people, no full-time PM, and roughly 90% of its code is written by AI; in the later Q&A, 任川 estimated the figure at least 90%. The episode did not unpack the technical details behind that reliability, instead turning to the organization underneath it: the company is trying to work AI-native from day one rather than operate like a traditional software company.
2. Ten-minute code review rewrites the cost function of “get it right before shipping”
任川 used Google as the benchmark: even after years of optimization, its average code review still takes 1–2 days. Palona AI uses CodeRabbit AI to compress the same step to about 10 minutes, and after more than half a year of testing, believes both efficiency and outcomes have held up well.
The company began introducing AI review around June or July last year and stopped requiring human review at the start of this year. Once AI approves the code, it can be merged. The engineer who wrote the code still owns the production outcome, so when AI catches an issue early, “people are especially grateful to the AI,” rather than treating the feedback as a colleague nitpicking.
The key is not only faster review, but sufficiently fast recovery: when something breaks, the team can roll back, revert, or fix it directly in production. When every change sits for 1–2 days, this kind of high-frequency trial and error is infeasible; with a 10-minute cycle, the risk-reward equation changes.
The team does not evaluate its review tool mainly through hit rates, false-positive rates, or similar metrics, but by engineers’ subjective utility. Its experience is that VS Code Copilot is not good enough, Cursor and BugBot are not especially good either and sometimes “just make things up,” while CodeRabbit AI fits the current workflow better.
3. Default to AI for the full development cycle; humans must justify the exceptions
任川 deliberately says “development work,” not coding: documentation, test plans, design documents, code, code review, deployment, and monitoring all start with the assumption that AI handles them. Current models obviously cannot do everything, so humans fill the gaps—but the starting point cannot be “humans do it by default, and occasionally AI can improve productivity.”
Linear and Devin demonstrate a new unit of work: create a Linear task and assign it directly to Devin, which produces the code automatically. People do not even need to open an IDE, and can send out 10 tasks at once to generate 10 codebases in parallel. That is no longer the traditional engineer’s one-item-at-a-time cadence.
On the monitoring side, the team uses incident.io to aggregate logs from AWS, Datadog, and other sources, analyze them automatically, send alerts, and provide some post-incident analysis. It currently covers about 40%–50% of the relevant work. The company has no dedicated SRE; some engineers handle operations with the tools.
任川’s view of Claude Code is that “as long as there is an SOP, there is no task Claude Code cannot complete.” It is capable, has an SDK, is easy to extend, and does far more than coding. He also cited 刘小排, Anthropic’s “top user globally”: he spends $200 a month on the Max Plan and can consume $50K worth of tokens, using the Claude API essentially 7×24.
When preparing this talk, 任川 still recommended Claude Code, but said Anthropic “seems to have” restricted domestic use last week.
4. The bottleneck for AI teams is shifting from skills supply to context supply
任川 flipped the usual narrative: “It’s not AI tools making people more productive; it’s people making AI more productive.” In more than a year of practice, it has been common for new people to slow down AI or the entire team. The minimum bar is therefore not human participation, but that “the output of human plus AI must be greater than AI alone.”
The premise of Context Engineering is that the underlying models are already very strong; agents and workflows fail more often because context engineering fails. The audience’s challenge around legacy code was pointed: if even people who have maintained the system for years cannot untangle its complexity, how could AI understand it? 任川 did not deny the difficulty. He located the issue in the accuracy and signal-to-noise ratio of the context.
Business context is equally irreplaceable. Someone on the team regularly worked shifts at restaurants over the summer, gaining firsthand knowledge of restaurant operations that may not exist in the model’s training data. The human contribution is to convert that experience into information the model can use, not to compete with the model on memory.
If product requirements are written into a Python
__init__file—including the service’s purpose, inputs, outputs, and required functionality—AI review can check whether the implementation is complete. For a small module or bug fix far removed from the original requirement, the corresponding context is missing, and the model may not be able to judge the product logic.
5. The new engineer learns only the minimum necessary—but owns the final result
Being a “fast learner” does not mean quickly making yourself smarter than the model. 任川 put it bluntly: “Humans can no longer be smarter than AI.” The team cares more about whether the problem and goal are clearly defined. Once they are, it assumes the person can quickly acquire the minimum necessary knowledge and use AI to solve the problem.
The third requirement is to be a hands-on builder. Even if someone owns only part of a large product, they must be accountable for the final result and the full workflow. Doing only the initial research or information gathering and then handing off the output recreates context sharing and immediately drags down an AI-native team.
As a result, the boundary between engineer and PM is beginning to disappear. 任川 knows PMs who did not originally code but now use AI coding tools fluently to build products. The future may be neither “everyone is an engineer” nor “everyone is a PM,” but “everyone is simply a builder.”
6. Divide work by outcomes to eliminate the relay between frontend, backend, and product
Palona AI organizes small teams around outcomes such as the merchant experience and consumer experience, rather than creating separate frontend, backend, research, and operations pipelines. If the person responsible for an experience sees that the backend is affecting the outcome, they edit it directly instead of waiting for another team.
Engineers even visit restaurant owners to ask whether the product works and what is missing. In the traditional chain, information may travel from the customer to sales, PM, and engineering before returning with “we can’t do that.” After repeated retelling, the information has already drifted; direct contact leaves first-hand context with the person actually executing the work.
任川 concentrates daily meetings into the middle 3–4 hours and keeps the rest of the day as meeting-free as possible. Each person can submit about 3–5 pull requests a day, write the code, receive AI review, and merge it independently. The principle is to “minimize alignment between people”; when consensus is needed, encode the rule in the codebase.
He did not claim the current model is final. Specialization may return, but not by slicing people up according to Industrial Age or internet-era processes. His guess is that AI may eventually handle 95%–98% of the workflow, with humans filling only what it cannot complete.
7. No full-time PM shortens the decision chain; it does not eliminate product judgment
Palona AI has about 20 people and no full-time PM. Engineers also do product work, while the CEO or head of engineering takes on PM responsibilities directly. 任川 admits he “doesn’t really know” whether this remains viable at 50 or even 100 people; the conclusion applies only to the current small-team experiment.
曲凯’s question was specific: traditional engineers are seen as good at code but relatively introverted, while PMs understand users, communicate, and synthesize requirements. Is combining both responsibilities in one person prohibitively hard to hire for? 任川 agreed that it is “definitely not easy to hire,” but believes ownership of the product, the ability to learn AI, and accountability for outcomes may become essential.
Another participant cited a company of about 150 people with roughly 2 PMs. Once engineers are told there is a PM, many questions they could have decided themselves get elevated into “business decisions.” The PM then has to come back for technical and data input, so the two still decide together—only with more back-and-forth and weaker ownership.
His view is that there is no reason a smart, strong problem-solver should be able to make a good engineering decision but not a good business decision. As the company grows, however, security, QA, testing, and platform engineering will still emerge naturally around cross-functional issues such as scalability and developer experience.
8. Velocity first turns code from an expensive deliverable into an alignment medium
The engineering team initially owns development, product, and design, rapidly shipping a 60-point version of a new feature instead of immediately finding a PM or designer. Specialists then improve the working product to 80, 90, or even 100. That is “velocity first.”
The old process—hold many meetings, complete the design, then start building—was not purely inefficient. Coding used to be expensive, and repeated rework could break an engineering team. Now that code generation is extremely cheap, 任川 rewrites the old saying: “Talk is cheap, but code is cheaper.”
The 60-point product gives everyone a working object around which to align, helping explain how the team built a complex system in about a year. It does not mean quality stays at 60; it moves professional optimization from a pre-launch gate to a second phase informed by actual feedback.
9. What large companies struggle to copy first is organizational constraint, not just the tool gap
One audience member argued that this approach may work only for teams of a dozen or 20 people. Large companies such as Douyin also have internal coding tools, yet still move through a pipeline of user research, product design, development, and testing. 任川 acknowledged that the model may not work at scale; he has only a little more than a year of experience and is “not that certain” about the future.
His explanation is that large companies face constraints beyond technical efficiency. He cited “today’s” example of the Microsoft CEO apologizing for excessive layoffs and needing to rebuild employee confidence. To his knowledge, Google has small teams working in similar ways, but shifting an organization that large is an entirely different challenge.
The more aggressive view is that perhaps “we won’t need companies that large anymore.” One-person unicorns are already being discussed, and the amount a few people can accomplish is hard to believe. 任川 is only “fairly skeptical” that a 100,000-person company will still be needed to build one product; he did not present that as a firm forecast.
曲凯 drew an investing and founding implication: in the medium term, organizational design may itself be the startup moat. Large companies need layoffs and reorganizations to turn, while a new company can let a small number of builders own work end to end from day one. 任川 described Palona AI as “fairly pioneering, but not niche,” and not yet the most aggressive example.
10. Hiring, risk controls, and employment relationships all need to be rebuilt around ownership
Palona AI does not rely on a one-hour interview. It gives candidates 2 days to take home and build a product that would be nearly impossible without AI, followed by a 30-minute review of what did not work and how they would adjust the prompt or instruction. The team is also testing a one-hour exercise to understand a large project filled with hidden traps, watching whether candidates can use AI to improve it quickly.
曲凯 asked why candidates with strong backgrounds would spend 8–10 hours on a take-home. 任川 said roughly one in 10 completes it after receiving the assignment, which is itself a filter. The company generally does not make exceptions based on a résumé; a referral may justify an adjustment. Another participant described a paid model: first screen for high-probability candidates, then pay about 30% of the market rate—for example, RMB1,500 for a PM assignment normally worth RMB5,000—to avoid the feeling of being exploited for free labor.
Experience is not automatically a positive. 任川 has seen seniors who spent 7 or 8 years at Google and were fluent in Vim or Emacs but unwilling to adopt AI coding tools. By contrast, young graduates who were already dependent on ChatGPT in school adapt more naturally, though he explicitly warned that the sample is very small.
Responding to questions about P0/P1 incidents, dirty data, and user compensation, 任川 did not address each risk individually. He reiterated that defaulting to AI is a principle of thought, “not blindly using AI for everything.” IaC lives in the repo and can be generated by AI, but infra work receives less autonomy and may get additional human checks during on-call; frontend product code is more often shipped directly, with issues fixed afterward.
One direction 任川 is still exploring is a small group of partners supplemented by specialized contractors. Core builders are highly valuable and the company depends heavily on them, making the conventional “every role must have a backup” model difficult to sustain; they therefore need partner-like treatment above that of ordinary employees. Specialized contractors can provide domain expertise to multiple organizations without selling their time full time to one company.
His counter-advice to hiring anxiety is: “Instead of hiring, improve yourself.” If the existing partners truly use AI well, they may already cover the roles the company planned to add. In reality, teams often hire as soon as they get a little busy, only to “hire someone and discover they’re even busier than before.” Another participant added that strong candidates are often intrigued by a distinctive, difficult interview rather than persuaded by low-friction hospitality.