Chris Van Pelt says machine learning products need evaluation systems that show whether a new model or prompt is better than the previous version.
2
Weights & Biases grew from experiment tracking into data and model management, evaluation, and production monitoring based on problems customers raised.
3
Teams using LLMs should treat model inputs and outputs as untrusted, restrict permissions, sandbox generated code, and monitor for prompt injection and data leakage.
Summary
Chris Van Pelt describes how he and Lucas started CrowdFlower after using Amazon Mechanical Turk to collect labeled data for a search ranking model. After CrowdFlower matured, they saw that machine learning teams lacked good tools for tracking experiments, which led to Weights & Biases. The product expanded from tracking code, hyperparameters, and models into visualizations, hyperparameter sweeps, artifacts, evaluation, and inference monitoring. Chris also explains why he became CISO and gives practical security advice: use least privilege, scan containers and dependencies, and assess what data third-party vendors receive. For LLM applications, he warns about prompt injection, unsafe generated SQL or code, and weak access controls. He argues that software engineers working with models need formal evaluation because model failures can be subtle and may not raise errors.
CrowdFlower began with the problem of collecting reliable labeled data
Chris Van Pelt says he and Lucas met at Powerset, where Lucas worked on the search ranking algorithm. The team needed labeled examples, so they used Amazon Mechanical Turk. A task showed a query and a search result, then asked a person to rate the result from 1 to 5. Chris and Lucas built internal tools for quality control and realized other companies might need the same workflow. CrowdFlower started in 2007, before machine learning had become a common product category. Chris says the company was initially too early, and he and Lucas had to learn sales, hiring, and business operations while changing the product several times.
A labeling product can become a consulting business if its pricing is not designed carefully
Chris says CrowdFlower's first major mistake was selling its microtask tooling to companies as a way to solve individual labeling problems. Customers wanted to buy a defined set of labels, so the company drifted into consulting. Chris learned that this model made recurring revenue difficult because the work was tied to individual projects. The company spent about ten years going through ups and downs before it found a model that worked. After bringing in another CEO, Chris and Lucas were able to step away and consider what to build next. That period also gave them time to return to machine learning fundamentals.
Weights & Biases started as a simple way to track machine learning work
After CrowdFlower, Chris and Lucas saw deep learning becoming practical, especially in computer vision and autonomous systems. Lucas taught deep learning classes and worked on a robot grasping problem during an early internship at OpenAI. They noticed that teams lacked basic tools for recording what they had done. The first Weights & Biases idea was to let Lucas track the code version, script, hyperparameters, and generated model for his grasping experiments. Chris built a rough working prototype in about a month. The initial product was not a broad platform. It focused on keeping experiment information together and making it easier for several practitioners to work from the same record.
Visual experiment charts became more valuable than the founders first expected
Chris says the early product was mainly about recording experiments, and he initially thought TensorBoard might already handle visualizations well enough. Users quickly showed that they wanted loss curves, accuracy curves, and other charts directly connected to their tracked runs. Hyperparameter sweeps became another unexpected source of demand after Toyota Research Institute asked for easier sweep execution. Weights & Biases did not try to replace every customer's infrastructure. Instead, it made agents easy to run in Kubernetes, Slurm, or a homegrown orchestration system, then added visualizations and open-source implementations of published hyperparameter methods. The product later added Artifacts for versioned data and model management, evaluation tools, and production monitoring.
Security controls need to exist before a machine learning company becomes large
Chris became CISO after repeatedly working with information security teams during large CrowdFlower deals and after seeing the financial damage that small bugs could cause. He recommends starting with least privilege, especially when granting engineers access to cloud accounts. Permissions should be limited, managed through Terraform where possible, and temporarily elevated when needed. Teams should scan Docker containers for CVEs, keep dependencies current, and maintain a vulnerability management process such as Dependabot on GitHub. Chris also advises tracking vendors from the start. Before sending data to a third-party service, a company should classify the data and check whether the vendor has suitable security attestations, such as SOC 2 Type II or ISO 27001.
LLM applications require strict boundaries around data, code, and model behavior
Chris describes enterprise LLM use as an unsettled security problem. Companies are concerned about privacy, security, and whether model responses are truthful. Some use private Azure deployments rather than a shared ChatGPT environment. He calls prompt injection an unsolved problem because an attacker can escape a system prompt and cause unexpected behavior. The risk grows when model output controls functions, generates SQL, or produces executable code. Chris says inputs and outputs should be treated as untrusted. A database query must run with the same access limits as the user who requested it, and generated code needs a carefully restricted sandbox. Monitoring can reveal prompt injection attempts, leaked personal information, and hallucinations.
Software engineers need formal evaluation because model failures can be quietly wrong
Chris says the rise of LLMs has brought software engineers into work that previously belonged mainly to machine learning engineers. Anyone calling model APIs or using open-source models needs a formal way to evaluate changes. This is similar to search ranking, where a team must measure whether a new model or prompt is better before deploying it. Traditional metrics may not fit every use case, and Chris says evaluation is often highly specific to what the model is asked to do. A thumbs-up or thumbs-down signal is not enough on its own. Teams should at least track outcomes over time so a new model or prompt cannot quietly damage the business problem it supports.
Weights & Biases uses demos to test product ideas before building them fully
Chris calls the company's product process demo-driven development. When the team has an idea, it builds a convincing prototype even if some parts do not work yet. The team then shows it to a friendly customer, explains the intended workflow, and listens for reactions and changes. If enough customers seem likely to want it, the team builds a functional version. Chris says that is when the real work begins. The product needs repeated changes based on customer use and collected data. He also warns against adding every requested feature in enterprise software, because the result can become disconnected. Weights & Biases built its open-source Weave toolkit to make evaluation features easier to change and customize.
Open-source models, multimodal systems, and agents are the parts of the LLM market Chris is watching
Chris is especially interested in open-source models that can run at the edge, along with companies fine-tuning smaller models. He also sees promise in multimodal systems that combine images and other modalities. Agents are less capable than people want today, but he says they are already interesting enough to encourage continued experimentation. As models improve, agents that can perform a wide range of tasks could become powerful and also create safety concerns. Chris does not claim to know where the market will settle. His comments focus on the technical directions that seem most likely to create new product and security questions.
"Bugs are so subtle with these ML models because they are not going to error, they are not going to throw an exception, they are just going to probably be subtly wrong."Chris Van Pelt42:23
Who should watch
You are building an LLM application that can query databases, call tools, or execute generated code, and you need practical security checks.
Your team is adding LLM features but has no reliable way to compare prompts, models, or releases before deployment.
You want to understand how an MLOps product grew from experiment tracking into evaluation and production monitoring.
