Vayum Arora leads growth at Weco AI, which builds agents that propose and test code changes against measurable goals. His work spans machine-learning engineering, product development and seed investing. His writing connects those experiences through concrete questions: why users distrust improving voice assistants, how investors miss unconventional routes to customers, and what an automated research system actually changes.
Engineering, products and investing
Vayum worked in machine-learning engineering and product leadership at Apple, contributing to foundation models behind applications including Siri and Search. He also founded a healthtech company and studied at Wharton. He joined Founder Collective in January 2025. There, he helped back Weco’s seed round, worked with its team, and subsequently joined the company to lead growth.
Investing challenged habits he had developed as a builder. In his account of his first hundred founder meetings, Vayum describes how technical sophistication could draw his attention away from whether customers understood a product’s purpose or had a reason to keep using it. One encounter changed his assessment of government sales: he nearly dismissed a company automating police reports, then learned it had reached twelve precincts by selling at police conferences. His expectation of slow procurement had obscured the company’s actual route to customers. He argues for developing an investment point of view while remaining willing to revise it through evidence and debate.
Why better voice models can still struggle with adoption
Vayum’s writing about voice adoption draws on his experience with voice systems at Apple. Users who learned to expect failures from assistants could continue limiting themselves to simple commands even after the technology improved. Better model capability therefore did not automatically produce broader use.
He contrasts open-ended conversations with tasks such as a delivery driver dictating a tracking number or a doctor recording notes. In these workflows, the user already knows what they want to convey, and the system has a limited job. His argument makes the choice of workflow central to adoption: successful interactions give people a reason to use voice again, while accumulated distrust can outlast the failures that created it.
Explaining what automated research improves
At Weco, Vayum’s technical writing explains both the mechanics of automated experimentation and the limits of claims about self-improvement.
Code changes that engineers can inspect. His fraud-detection case study describes an agent proposing modifications, an evaluator scoring them, and a search tree preserving promising experiments. For the authentication platform Vardera, changes included detecting contradictions between listing titles and metadata, combining interacting risk signals, and treating missing certification information as a feature. These examples explain what the search produced: changes to how the system represented and combined evidence of fraud. The resulting code remained available for engineers to review and version-control.
Two levels of improvement. In his explanation of Weco’s AIDE² work, Vayum distinguishes an agent improving task code from an outer loop improving the research agent itself. He presents the team’s reported results as progress toward more efficient automated research and separates them from “ignition,” where a system improves its own ability to improve itself. The distinction identifies which part of the system is changing and limits what the results imply.
Vayum also co-presented Parameter Golf with AutoResearch with Zhengyao Jiang, Dixing Xu and Dhruv Srikanth. Vayum and Dhruv connected the team’s research to a practical setup built around a modifiable source file, a fixed evaluation command and a measurable goal. The shared Mini Parameter Golf repository gives that setup a concrete application: language-model training experiments small enough to inspect while they run.
Weco AI turns language-model research into an inspectable search over code, then applies the same machinery to a Flappy Bird controller. The useful work lies in defining the evaluator, bounding experiments and knowing when to steer.
A useful AutoResearch setup specifies editable code, a replayable evaluation, the metric's direction, a search budget, a timeout and initial guidance.
Fast and cheap evaluations increase the number of affordable experiments; low noise makes score comparisons more trustworthy. None of those properties prevents reward hacking on its own.
The reported tokenizer breakthrough combined an outside contribution with accumulated agent work after a five-day plateau; continued autonomous search was only part of the process.
Flappy Weco combines multiple environments, hidden validation cases and restricted controller edits to make the score more closely reflect the intended playing behavior.