En un episodio reciente de President Curtis, el Presidente lucha por abrir una puerta en dos ocasiones separadas. Estas puertas no funcionan porque hay obstrucciones en el camino: un cuerpo inicialmente, y luego aproximadamente mil millones de dólares en oro. En ambos casos, ante la frustración, el personaje murmura "la estúpida cosa apesta". ¡Este no es un modelo razonable de puertas! ¡Las puertas no deberían "apestar" de manera inexplicable! Encontré estos momentos ridículamente hilarantes¹ pero tal vez mi cerebro estúpido simplemente apesta.

Jev: Hacer más puertas que apestan La Internet está agitada sobre Jev, un modelo de IA desarrollado por Type Safe AI, que valores tipificados con estimaciones de probabilidad. Las cosas importantes sobre Jev son, según puedo decir: es rápido y barato, puedes construir rápidamente sobre él, es rápido, y es barato. No soy particularmente bueno para entender qué tecnologías serán adoptadas. Todavía no entiendo² Slack. Espera. ¿Todavía tienes que hacer la parte difícil? Tal vez mi problema es esperar que los productos funcionen. Nadie que compra esto está ejecutando evaluaciones. simplemente preguntas opacas a Jev y obtienen respuestas opacas.

Con caridad, esto les permite marcar la casilla "impulsado por IA" y enviar antes del viernes, y cuando esto lógica hacia abajo, siempre pueden encogerse de hombros y decir "bueno, la IA comete errores." ¿Presupuestos de error? ¿Modos de falla? ¿Conjuntos de prueba? Todo eso puede manejarse más tarde. ¡El usuario puede descubrir la tasa de falla! ¡Ya envió!

Falsa confianza "Oh," el maniquí respondiendo a mi publicación responde, "¡no has considerado el hecho de que Jev te da puntuaciones de confianza!" ¿Qué vas a hacer con ellas? Para que hagas algo razonable con las puntuaciones de confianza necesitas tener tanto una comprensión de la calibración de esas puntuaciones de confianza como un modelo para los costos de la incertidumbre.

En el lado de calibración: la copia publicitaria principal de Jev se trata principalmente de cómo de bien puntúan en varios benchmarks, pero no sobre qué tan bien calibradas están sus puntuaciones de confianza. Hay un cookbook sobre cómo usar puntuaciones de confianza para subir un árbol de clasificación pero eso no es fundamentalmente sobre qué tan buenas son las puntuaciones de confianza. En el mejor caso, las personas usan puntuaciones de confianza de manera culta. En el peor caso, las usan como excusa por qué falló la llamada API. ¡El modelo solo estaba 73% confiado! ¡Eso significa que mi presupuesto de error es 27%!

Rendición de cuentas Cuando un botón se rompe en un sitio web, tengo un modelo sobre qué debería haber sucedido. Alguien rompió un contrato. Mi DNS está roto. Alguien envió basura que tiene errores de sintaxis de Java Script solo a lo largo de cierta ruta. Un manejador lanzó una excepción que no se esperaba que lanzara. Tal vez no tengo acceso para depurar solo un HTTP 500, pero espero que haya alguien cuyo trabajo sea entender por qué el endpoint está 500. La propiedad está bien definida aunque opaca³.

Para muchos usuarios, la experiencia real es aproximadamente solo "la estúpida cosa apesta." El software ya se siente caprichoso; más fallas solo cambian la tasa de frustración. Parece que no hay mucha pérdida en eliminar la posibilidad de seguir una falla a una causa concreta. A veces las cosas simplemente apestan. Esto lleva a la normalización de lo inexplicable.

Mi temor no es que más cosas fallen cuando las cosas se aceleran con el desarrollo impulsado por LLM. Fallarán. Ya lo han hecho. Tal es parte del precio de construir cosas de una manera novedosa. Mi temor es que "a veces simplemente apesta" se convertirá cada vez más en el punto final aceptado de las investigaciones. Esto es trágico porque el desarrollo acelerado por LLM puede ayudarnos a resolver algunos de estos problemas. Hay muchos flujos de trabajo de QA automatizados que no se escriben por falta de tiempo de ingeniería. La misma evaluación que te lleva la mayor parte del camino para reemplazar (o incluso justificar el uso de) Jev puede estar a unas preguntas de distancia.

La tragedia de la ingeniería de software hoy es que estamos activamente construyendo sistemas donde ni el usuario ni el constructor parecen tener interés en verificar si hay un cuerpo detrás de la puerta. Solo...