Everyone is obsessed with ChatGPT. But those of us who program know that a chat box on a website isn't enough to automate processes. We want to use the API for these models. And that's where a serious problem arises: Language Models (LLMs) like GPT-4 are stateless. They have no memory. If you make an HTTP call to their API, they don't know what you told them in the previous call.

Suddenly, a new discipline has become trendy: "Prompt Engineering". Some sell it as an esoteric art of whispering to AI, but it's nothing more than injecting the right context. And to manage that context, a Python framework has been born that is taking the world by storm: LangChain.

Chaining uncertainty

LangChain is an orchestrator. It allows you to connect an LLM with other data sources and create "Chains". Instead of writing linear, deterministic code with if/else statements, you design a template (PromptTemplate) and let the linguistic model reason out the next step.

For example, you can create an "Agent" and give it access to tools (a calculator, a Wikipedia search, and access to your database). 

from langchain.llms import OpenAI
from langchain.prompts import PromptTemplate
from langchain.chains import LLMChain

# Instanciamos el modelo
llm = OpenAI(temperature=0.7)

# Creamos una plantilla donde inyectaremos variables dinámicamente
plantilla = """
Eres un asistente experto en bases de datos.
Dada la siguiente estructura de tabla: {esquema_bd}
El usuario pregunta: {pregunta_usuario}
Escribe la consulta SQL exacta y nada más.
"""

prompt = PromptTemplate(
    input_variables=["esquema_bd", "pregunta_usuario"],
    template=plantilla,
)

# Creamos la cadena que une el Prompt y el LLM
cadena_sql = LLMChain(llm=llm, prompt=prompt)

# Ejecutamos inyectando el contexto
resultado = cadena_sql.run(
    esquema_bd="Ventas (id, importe, fecha, cliente_id)", 
    pregunta_usuario="¿Quién gastó más ayer?"
)
print(resultado)

Reflection: The chaos of probabilistic code

Programming with LangChain is mind-blowing, but it's a debugging nightmare. Our whole lives as engineers we've written mathematical functions where an input A always returns an output B.

Pair-programming with Copilot was the first step, but building applications where the core logic is handled by a probabilistic engine that sometimes "hallucinates" is a somersault. If the model decides that today its probability dictates writing a slightly different SQL that breaks the application, you're toast. The flexibility to solve ambiguous problems is enormous, but the structural fragility of these new applications is going to give us a lot of headaches in production.