No construyas productos de IA como lo está haciendo todo el mundo

Artículo original ↗ Discusión en Hacker News ↗

Las APIs de LLM han facilitado lanzar “productos de IA”, pero muchos comentaristas sostienen que los envoltorios ligeros sobre ChatGPT, sin datos únicos, flujo de trabajo o conocimiento de dominio, están condenados al fracaso. Defienden partir de problemas reales de usuarios y del diseño de software tradicional, e insertar modelos estrechos y especializados solo donde la IA sea realmente necesaria, sin perder de vista el riesgo de plataforma, la latencia, el coste y la tentación de sobrediseñar toolchains personalizadas demasiado pronto. Otros responden que los prototipos rápidos, incluso derivados, siguen siendo valiosos para aprender límites, atraer usuarios e iterar hacia funciones realmente útiles potenciadas por IA.

IA como herramienta vs. IA como negocio

  • Muchos sostienen que el “verdadero secreto” es tener primero un negocio viable y luego usar IA para mejorarlo (por ejemplo, añadir resumido a un producto de correo electrónico existente).
  • Otros creen que algunos modelos solo son viables porque la IA reduce los costes, así que los negocios centrados en IA pueden tener sentido, pero son más arriesgados.
  • Varios comentarios se burlan de las “startups de IA” genéricas, comparándolas con decir “somos una startup de Python” o “startup de web3” sin un problema claro.

Riesgo de plataforma y crear una capa sobre OpenAI

  • Hay una fuerte preocupación de que los envoltorios ligeros sobre OpenAI no tengan ninguna ventaja defensible y puedan ser superados o clonados por la propia OpenAI o por competidores.
  • Algunos ven los primeros “envoltorios de API” como una fase de aprendizaje aceptable y una forma de ganar experiencia y usuarios, aunque el primer producto sea luego desplazado.
  • Se enfatiza que, si no posees tanto la API como el cliente, en la práctica estás alquilando y te pueden “desalojar”.

Toolchains, fine-tuning y elección de modelos

  • El consejo del artículo de construir modelos especializados más “código normal” gusta en general, pero algunos creen que construir compiladores/toolchains es excesivo para muchos equipos.
  • Hay desacuerdo sobre el fine-tuning: algunos lo ven como una diferenciación esencial; otros lo consideran poco práctico por la suciedad de los datos y prefieren prompting few-shot, llamadas a funciones y RAG.
  • Hay escepticismo sobre que los equipos pequeños puedan mantener modelos personalizados mientras los modelos frontier mejoran rápidamente y potencialmente vuelven obsoleto el trabajo interno.

Estrategia de producto: primero el problema vs. primero la tecnología

  • Hay un fuerte apoyo a partir de las necesidades del usuario, los flujos de trabajo y la UX, en lugar de “producto de IA” como categoría.
  • Advertencia reiterada contra construir “soluciones en busca de un problema”, comparándolo con olas anteriores de blockchain/web3.
  • Algunos argumentan que construir muchos MVP rápidos (incluso impulsados por tecnología) todavía puede ser una forma válida para que los tecnólogos descubran problemas reales.

Chatbots y experiencia de usuario

  • A muchos no les gustan los chatbots de soporte, viéndolos como filtros que bloquean el acceso a humanos capacitados.
  • Otros informan de buenas experiencias con ciertos bots (por ejemplo, reembolsos en comercio electrónico, triaje interno) y esperan que los LLM mejoren significativamente la UX de chat.
  • Existe un acuerdo general en que los bots solo son valiosos cuando realmente pueden hacer cosas (cambiar planes, emitir reembolsos), no solo recitar FAQs, aunque eso choca con preocupaciones de seguridad e inyección de prompts.

Latencia, rendimiento y compromisos de MVP

  • Hay debate sobre si ejecuciones de LLM de varios minutos son aceptables: bien para flujos en segundo plano o de traspaso, demasiado lentas para bucles interactivos ajustados.
  • Algunos ven la ingeniería pesada por adelantado (compiladores personalizados, toolchains) como una optimización prematura que retrasa el aprendizaje de los usuarios; otros la consideran necesaria para evitar envoltorios “aburridos” y commodity de ChatGPT.

Datos, privacidad y autoalojamiento

  • Se informa que algunas empresas rechazan productos basados en OpenAI, pero sí aceptan trabajar con startups que prometen mayor control o despliegue on-premise.
  • Otros sostienen que las preocupaciones de privacidad están exageradas dado el uso generalizado de grandes SaaS en la nube en el entorno empresarial, y que el alojamiento personalizado rara vez supera a OpenAI en coste salvo a una escala muy alta.

Ciclos de hype y diferenciación

  • La IA se compara con frecuencia con hype pasados como Kubernetes o blockchain; los comentaristas discrepan sobre lo transformadora que será finalmente.
  • Hay consenso en que la diferenciación debe venir de algo difícil de copiar: visión profunda del flujo de trabajo, datos, UX o integración, no solo de “usamos LLM”.