Developer Tools

Pídele a un modelo que responda en JSON y la mayoría de las veces json.loads() funciona sin problemas. Los fallos son los que te cuestan una sesión de debugging: un comentario de una línea dentro del objeto, un code fence de markdown envolviéndolo, una clave escrita userEmail cuando tu código espera user_email. Un prompt más estricto (“responde SOLO con el objeto JSON, sin ningún otro texto”) hace que estos casos sean más raros. No los hace imposibles, porque el modelo puede ignorar la petición igual. La salida estructurada elimina la petición de la ecuación: le entregas a la API un JSON Schema, y este restringe el muestreo de tokens del propio modelo para que la respuesta tenga que ajustarse a él. ...

Guardas un archivo, Prettier lo reformatea, y ESLint marca de inmediato un error en la línea que Prettier acaba de tocar. Las dos herramientas están configuradas, las dos están activas, y en vez de ayudarte se pelean entre sí. Las dos herramientas hacen trabajos distintos. El problema es que ambas tienen una opinión sobre una sola cosa: cómo debe verse el código en la pantalla. Qué comprueba realmente ESLint ESLint analiza tu código en un árbol de sintaxis abstracta y ejecuta reglas sobre su estructura. La mayor parte de su valor viene de reglas que detectan bugs reales: una variable que nunca se define, un return inalcanzable después de otro return, un import que quedó sin usar tras una refactorización, una clave duplicada en un objeto que sobrescribe la primera en silencio. Son comprobaciones semánticas: ESLint lee lo que el código hace. ...

Por qué “parece correcto” no es una prueba para un prompt Ajustas el texto de un prompt que clasifica tickets, lo pruebas con los tres ejemplos que tienes abiertos en tu notebook de pruebas y lo despliegas. Una semana después, las quejas de facturación que antes caían en la cola correcta empiezan a caer en “pregunta”. No los tres casos que revisaste: los otros cuatrocientos que no revisaste. Nada falla. No hay ningún stack trace. El prompt, leído en voz alta, sigue sonando bien. ...

Qué hace realmente el function calling en un LLM Pregúntale a un modelo “qué tiempo hace ahora en Austin” sin ninguna conexión con el mundo exterior, y tiene dos opciones: decir que no lo sabe, o inventarse algo. El function calling le da una tercera opción: el modelo describe lo que necesita, se lo pasa a tu código y espera una respuesta real antes de contestar. El nombre es un poco engañoso. El modelo no llama a nada. Emite un bloque de datos estructurados que dice qué tool quiere y con qué argumentos, y tu aplicación decide si lo ejecuta y qué hace con el resultado. “Tool use” es el término más preciso, y es el que usa la documentación de Anthropic; OpenAI y Google suelen decir function calling. El mecanismo es el mismo bajo los dos nombres. El modelo solo produce una petición, nunca el efecto. ...

Ejecuta npm install en un proyecto, luego pnpm install sobre el mismo package.json, y obtienes dos árboles node_modules distintos y dos lockfiles distintos. Añade un compañero que usa Yarn y el repositorio termina con tres lockfiles en su historial, cada uno describiendo un árbol de dependencias ligeramente diferente. Los tres leen el mismo package.json y descargan del mismo registro de npm. En lo que no se ponen de acuerdo es en qué escribir en disco. ...

Qué le hace realmente un decorador a tu función Quieres medir el tiempo de cada función que llama a una API externa lenta. Puedes pegar llamadas a time.perf_counter() en cada una, o escribir la medición una sola vez y aplicarla en todas partes. Un decorador es la segunda opción: es una función que toma otra función, la envuelve en un comportamiento adicional y devuelve la versión envuelta con el mismo nombre original. ...

Instala dos proyectos de Python en la misma máquina y el segundo puede romper el primero. Uno necesita requests==2.28, el otro necesita requests==2.32, y pip tiene exactamente un directorio site-packages global en el que escribir. Gana la última instalación, en silencio. Te enteras cuando el otro proyecto empieza a lanzar errores que no tienen nada que ver con el código que acabas de cambiar. Un entorno virtual le da a cada proyecto su propio site-packages. No se toca nada global, y dos proyectos pueden depender de versiones incompatibles de la misma librería sin que ninguno se entere. ...

Qué hace diferente a un agente CLI de código de otro Pídele a un agente CLI de código que arregle un test que falla y no te va a responder con una sugerencia. Lee la salida del test, abre el archivo, edita una línea, vuelve a correr el test y avisa cuando pasa. Ese bucle es el producto, no la ventana de chat. El modelo que hay dentro del bucle se lleva la mayor parte de la atención, y también es la parte que cambia más rápido: los proveedores meten modelos nuevos cada pocos meses, y varios agentes te dejan elegir. Lo que se queda fijo es el harness que envuelve al modelo: qué herramientas puede usar, cómo gestiona el contexto, qué puede ejecutar sin preguntar, y dónde se ejecutan esos comandos. Dos agentes con el mismo modelo por dentro pueden comportarse de forma muy distinta por eso. El harness es lo que en realidad estás eligiendo. ...