Hace seis meses, recibí Es de nuestro CTO, brillando con el tipo de urgencia que hace que todo el día cambie. que "Team, we need an AI strategy! Let's get a smart summarizer on the dashboard. What's the fastest we can get an MVP out with GPT-4o-mini?" Y ¿sabes qué? Fue emocionante. El mandato era simple: "AI sobre todo. Ahora." Como desarrollador, mi mente ya estaba en la carrera. Yo sabía que podría hackear un prototipo al final del día. Algunas líneas de Python, una llamada de API y presto - un poco de magia de AI. En los seis meses que siguieron, mi equipo y yo nos convertimos en una fábrica de características. enviamos una búsqueda inteligente, un chatbot de servicio al cliente, una herramienta para analizar los comentarios de los usuarios, un generador para el flujo de marketing... 15 características en total. Pero no estábamos innovando, estábamos poniendo una trampa para nuestro propio futuro. Hicimos lo que pedían, pero la velocidad creó una montaña de deuda tecnológica invisible que casi arrasó a todo nuestro equipo de desarrollo.Esta es la historia de los errores que cometimos, y el sistema de tres pasos que estamos usando para cavar nuestro camino. Parte I: Cómo nos enterramos en la deuda tecnológica Este nuevo tipo de deuda tecnológica es escondida. No parece un código desordenado. Parece limpio, simple y moderno. Pero fue una serie de bombas de tiempo, cada una de las cuales se golpeó gracias a tres asesinos silenciosos. Error #1: el síndrome de "juguete nuevo brillante" En la corriente loca, cogimos cualquier herramienta que fuera la más nueva o la más fácil. Para el resumidor, fuimos con OpenAI porque todo el mundo estaba hablando sobre ello. Para el chatbot, otro equipo ya había jugado con Anthropic, así que usamos eso. Para una característica de traducción simple, alguien encontró alguna API obscura que era barata. No teníamos un plan, ninguna estrategia, sólo un deseo de velocidad. Individualmente, el código para cada característica parecía bueno.Pero cuando se aumentó, fue un caos puro.Estábamos luchando con un puñado de diferentes claves de API, diferentes SDKs y diferentes facturas para pagar.Cuando un usuario se quejaba de que los resúmenes eran lentos, toda una investigación se iniciaba solo para averiguar cuál de nuestras media docena de proveedores estaba bajando la pelota. El verdadero dolor se produjo en tres meses, cuando uno de nuestros principales proveedores decidió doblar sus precios durante la noche. Intercambiarlo no fue una solución rápida. Error #2: Los Prompts frágiles y el juego de "¿Quiénes culpamos?" Tratamos nuestras solicitudes como si fueran sólo otra línea en un archivo de configuración. No eran. Fueron sugerencias frágiles y susurrosas a una máquina que no entendíamos. Para nuestro resumen de comentarios, teníamos una solicitud que se sentía como una obra de arte: Fue como un encanto. Summarize the following user feedback into a single, positive-sounding sentence. Hasta que, un martes, no lo hicieron. El proveedor de API había empujado una actualización silenciosa a su modelo. Sin advertencia, nuestros resúmenes de "sounding positivamente" comenzaron a sonar... sarcástico. La lógica entera de nuestra característica se rompió, pero no una sola línea de nuestro código había cambiado. Sin linterna, sin análisis estático, nada podría habernos advertido. Es lo que ahora llamo una "dependencia semántica", y es una pesadilla total para debugar. Un cliente se quejaría de un extraño resumen fuera de la marca. ¿Qué debía hacer? No se puede pegar un punto de ruptura dentro de un LLM de código cerrado. No se puede ver lo que está sucediendo. Mi rutina diaria se convirtió en un ciclo frustrante de adivinación: 
 
 
 
 Bueno, vamos a intentar reescribirlo por décima vez... ¿Es la entrada del usuario? ¿Quizás escribieron algo extraño... un caso de borde? ¿La API sólo tiene un mal día?Hora de revisar su página de estado de nuevo... Esto no es ingeniería. Es la adivinación moderna. Estaba en el gancho de una característica cuyo cerebro era una caja negra completa. Error #3: Usando un Nuke para matar a una mosca Esa llamada de API simple era un cheque en blanco, y los escribíamos como locos. Para una de nuestras herramientas internas, simplemente clasificando los boletos de soporte, usábamos uno de los grandes modelos de propósito general. Finalmente nos dimos cuenta de que estábamos usando un núcleo superinteligente para matar a una mosca.Un modelo mucho más pequeño, ajustado y de código abierto, incluso un puñado de Las declaraciones habrían sido diez veces más rápidas y cien veces más baratas.Pero en la "Fábrica de características", todo lo que importaba era sacarlo de la puerta.Hemos terminado con costes elevados y rendimiento lento para una función que nunca necesitaba tanta potencia de fuego. if/else Parte II: Digging Our Way Out Alrededor de seis meses después, las cosas comenzaron a desmoronarse. Impulsar una nueva característica rompió una vieja. Nuestros costos estaban por todo el lugar. Y honestamente, el equipo estaba ardiendo de combatir los incendios. Teníamos que parar, respirar y comenzar a diseñar una solución. Paso 1: Realizamos un "triage de la deuda tecnológica" Nos reservamos una sala de reuniones para toda la tarde, colocamos todas las 15 funciones de IA en un tablero, y las grabamos en una red de 2x2 simple. (En serio, dibuje esto en un tablero blanco. Es un cambiador de juego. recomiendo crear una imagen de red simple 2x2 para insertar aquí) 
 
 
 X-Axis: ¿Cuánto importa esto para el negocio? (Bajo a Alto) Y-Axis: ¿Cuánto de un caos técnico es esto? (Bajo a Alto) Esa tarde trajo mucha claridad. 
 
 
 
 Top-Right (High Impact, High Debt): El chatbot del cliente, por ejemplo. Bottom-Right (Bajo Impacto, Alta Deuda): Que estúpido "fun fact" generador en la pantalla de inicio de sesión. hemos decidido matarlo. Los otros dos cuadrantes: Nosotros decidimos dejarlos solos.Si no se rompió, no lo arregle. Paso 2: Construimos un “gateway de IA” centralizado Nuestro primer gran proyecto fue solucionar el problema de “demasiadas APIs”.Hemos construido un servicio interno simple con el que hablan todas nuestras otras aplicaciones.Este “gateway” es ahora la única cosa en nuestro sistema que habla con proveedores externos de IA. . (Un diagrama simple es perfecto aquí: [Nuestra Aplicación] -> [Nuestro Gateway AI] -> [OpenAI, Antropic, etc.]) Esto de inmediato nos devolvió nuestro poder. 
 
 
 
 Control: Podemos intercambiar proveedores en un lugar sin que ninguna de las otras aplicaciones lo sepa. Ahorros: Construimos un simple sistema de caché directamente en la puerta de entrada. Sanidad: Todos nuestros registros, vigilancia y alertas están ahora en un solo lugar, gestionable. Paso 3: Hemos creado una “biblioteca rápida” Para detener la pesadilla de los prompts frágiles que viven en nuestro código, los extraímos todos.Hemos construido una biblioteca simple para ellos -es realmente sólo una tabla en una base de datos, con el historial rastreado en Git- que almacena cada prompt que usamos. Ahora, nuestras aplicaciones simplemente piden a la biblioteca el mensaje correcto antes de hacer una llamada. Esto finalmente separa el "qué decir" del "cómo decirlo".Nuestros gerentes de productos pueden ahora ajustar y probar los mensajes a su contenido, y no necesitan presentar un boleto de ingeniería para hacerlo. Se trata del largo juego Miren, la presión para "añadir AI" a todo no se va, pero tenemos una opción.Podemos mantener las características juntas sobre las APIs que no controlamos, construyendo un futuro de productos que son caros e imposibles de mantener. O podemos hacer el trabajo real, a veces más lento. Nuestra nueva regla es simple: juzgamos cada nueva característica no sólo por lo que puede hacer, sino por su Al abordar nuestra deuda y construir estas capas de control, hemos dejado de ser tomadores de órdenes en una fábrica de características. long-term cost of ownership. El juego no es sólo sobre A. Se trata de Dejemos de alimentar a la fábrica y empecemos a construir cosas que duren. Uso Propiedad So, what's the worst AI tech debt you've stumbled into? I want to hear your war stories in the comments.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Contact Us Today at sales@saigontechnology.com

Drop me a message at 

Read My Stories

Este audio es producido en el idioma original de la historia!

He eliminado 15 características de IA en 6 meses y casi nos rompió.

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps