Salesforce reports research-agent gains in models and code Salesforce reports research-agent gains in models and code

A patch comes with an experiment

The project’s October research pages describe AutoR&D-Engineer starting with a repository and an engineering goal. Its published examples include pandas, hnswlib and USearch, alongside Salesforce’s own training infrastructure. The output includes a proposed implementation and measurements against the previous version. For pandas, one change avoids creating a temporary label array while keeping the numerical reduction kernel. Salesforce reports a median speedup of 1.38 times across 40 benchmark cells for that change. The important unit is the named workload with its correctness checks, rather than a blanket claim that the entire library became faster. A result attached to a patch also gives maintainers something concrete to inspect before accepting it.

Training begins with a cheaper test

TrainForge takes a baseline model, target task and compute budget. Its project page describes a staged process: a small adaptation test comes first, followed by a short full-parameter run and then full training for promising ideas. Evaluation datasets remain separate from training. The system records results and uses them to choose its next proposal. Its guided demonstration also distinguishes illustrative research lineage from measured screens. That distinction matters because an animation of iterative discovery cannot establish the provenance of every experiment it depicts. The public page says the interactive platform is coming soon. A research demonstration and a tool available for general customer use are different stages.

Retrieval is the immediate application

The November account says the agents improved an existing embedding model and developed SFR-Embedding v4 from EmbeddingGemma 2. Salesforce reports an approximately 80-hour research cycle. Embedding models convert material into numerical representations for retrieval. The engineering question is whether a measured improvement changes which useful records the application actually returns.

The release decision remains a separate step

Meta described a related boundary in its November 11 account of Intelligent Delivery. Its agents inspect source code, design documents and experiment history, then propose and test changes to advertising infrastructure. Engineers approve the final change before deployment. The two accounts address different systems, so their performance numbers cannot form a ranking. They do show a useful separation between searching for an improvement and granting permission to ship it. A team can automate many experiments while retaining a distinct release decision. That separation gives an operator room to reject a technically successful change when its operational costs or risks do not fit. The acceptance test therefore belongs to the application owner. A benchmark can measure one improvement without deciding whether that change deserves the next production slot.