Vaibhav Gupta argues that AI pipeline code needs the same readability, process, and tooling standards as other production software.
2
BAML treats prompts as typed, verifiable code and generates interfaces for languages such as Python, TypeScript, Go, and Java.
3
BAML's editor tooling shortens prompt iteration by letting developers inspect rendered prompts, tokens, requests, and test results without leaving the editor.
Summary
Vaibhav Gupta explains why many AI applications remain demo-like after two years of rapid development. He sees prompt code written as large, dynamic strings, often mixed into business logic without the checks, formatting, and review practices used elsewhere in software. BAML addresses this by giving prompts their own language, type system, editor support, and code generation for other languages. Gupta compares the approach with React, which made HTML and CSS easier to verify inside application code. He also describes a prompt hot-reload loop in VS Code and Cursor, where developers can edit prompts, inspect the rendered request and tokenization, run test cases, and repeat quickly. The conversation covers BAML's cross-language design, production adoption, structured output parsing, streaming interfaces, and a planned orchestration system. Gupta is candid about the cost of building a programming language and the difficulty of earning developer trust.
AI pipeline code needs ordinary software engineering discipline
Vaibhav Gupta says the code around AI pipelines often looks as if it was vibe coded, even before that phrase became common. He compares this with established software, where companies use CI/CD, linters, and shared conventions so new engineers can read and change code safely. AI-generated code still needs pull requests and process. The problem is especially visible in backend systems that must fit into years of existing software and contain many small interactions. BAML began from Gupta and his co-founder seeing prompt code that looked like a temporary demo rather than code someone could maintain.
Gupta compares BAML's design with the move from server-rendered HTML strings to React. React made syntax visible to editors and compilers, which enabled checks, autocomplete, and clearer structure. BAML applies a similar idea to prompts. Developers retain the flexibility of English, while the system checks whether the prompt should produce a declared data model. Gupta describes a sentiment classifier that accepts a message and returns positive, neutral, or negative. Test cases can check that a message such as "I am incredibly upset with you" produces negative. If it fails, the developer can separate a model problem from a prompt problem.
An LLM should be treated as a calculator with an explicit contract
Gupta asks developers to stop treating an LLM as a magical box and instead view it as a powerful calculator. The input can be a transcript, and the output can be a defined list containing the doctor's medicine-related questions, the medicine involved, and whether the patient confirmed it. In this model, the prompt is the operator, similar to a plus or multiply sign. Different models are different calculators with different precision and trade-offs. The prompt becomes verifiable because the developer can check whether it produces the required data structure across test cases.
Prompts are business logic and should not be ordinary strings
Demetrios Brinkmann observes that strings are being used to control outcomes in a way they were not designed for. Gupta agrees that prompts deserve first-class treatment in code. They may contain conditional sections, loops, model-specific variants, and business rules, yet ordinary strings are usually short constants or values loaded from a database. He gives the example of a Delta Airlines chatbot, where a process should guarantee that every system message includes the company's identity. A custom Python class could help, but it would depend on every developer remembering to use it. Gupta prefers moving repeated burdens into the programming language and its process.
BAML uses one core implementation to support many languages
BAML code generates native-looking functions for the language a team uses. Gupta says the core is written in Rust, while generated interfaces can target Python, TypeScript, Go, Java, or other languages. He compares this with NumPy, whose performance-critical implementation is written in C and exposed through Python. Since the same BAML core powers each generated interface, features do not need to be separately reimplemented and maintained in every language. Gupta says this matters because large companies use many languages, and AI techniques discovered by one team can then be shared with others.
Editor feedback creates a fast prompt development loop
BAML's VS Code extension can show the rendered prompt while the developer edits the source. It can display test cases, token boundaries, and the raw request format for different model providers. Gupta compares this with React's hot reload loop: edit the file, inspect the result, change the code, and repeat. A developer can run a test case from the editor, compare the model's output with the expected result, then modify the prompt, input, or data model. Gupta says this matters because agent work is experimental, much like web development and data science in a Jupyter notebook.
Production use exposed needs that a small demo would hide
Gupta says the team was initially anxious about production deployments across different languages and environments, including a compatibility problem with Alpine containers. The more surprising signal was a customer with 25,000 lines of BAML code who asked for namespaces. That volume showed that a real codebase was depending on the language and needed ordinary language features. The team had also hired an early contributor who wrote 3,000 lines of BAML. Gupta says they design many features internally, write pseudocode, and then test the concepts with a community of more than a thousand people.
BAML targets difficult streaming and orchestration work
Gupta demonstrates a recipe generator whose interface shows which part of a response is being produced and lets a user interact with the partial result while it streams. He says current models and SDKs can support this, but the implementation takes a lot of code. BAML aims to reduce it to one line. He compares this with Tailwind, which made frequently used local styling easier to express. Gupta says the next larger project is an orchestration system for full workflows. It is intended to support conditionals, loops, human handoffs, and returning to the workflow, with the result exposed across programming languages.
