Una reflexión personal sobre los costos ocultos de usar IA en desarrollo, desde la suscripción que no aprovechas hasta los miles de dólares que se queman en requerimientos que nunca llegan a producción.
Hace unos meses empecé a usar Claude de forma intensiva en un proyecto personal. Arranqué con el plan de 20 dólares al mes y, como era de esperar, en pocas semanas me quedé corto. Los límites llegaban rápido y cortaban el flujo de trabajo. Así que subí al plan Max de 100 dólares.
El pico inicial: cuando todo parece justificarse
Cuando inicias un proyecto desde cero, hay una cantidad enorme de trabajo "mecánico": configuración, scaffolding, código base, estructura de carpetas, primeras integraciones, boilerplate de autenticación, modelos, migraciones. Es ese tipo de trabajo donde la IA realmente brilla, porque puedes ir tirándole tareas concretas una atrás de la otra sin pausa.
En esa fase, los créditos del nuevo plan se aprovechaban al máximo. La productividad subió, el avance se sentía real, y la decisión de pagar más parecía obvia.
Pero después llegó la segunda fase. Y ahí empecé a ver el problema.
El cuello de botella soy yo
A medida que el proyecto avanzó, el bloqueo dejó de estar en la velocidad de la IA y empezó a estar en mí. Yo soy quien define los requerimientos. Yo soy quien piensa qué función agregar, cómo debería comportarse, qué casos contemplar. Y eso lleva tiempo. Tiempo de leer, de pensar, de probar, de cambiar de idea.
Resultado: paso días en los que no estoy usando ni el 50% de los créditos que pago. Estoy pagando por capacidad que no consumo.
Esto me hizo acordar a un concepto bastante conocido en programación reactiva: el backpressure en streams. El backpressure aparece cuando el productor envía datos más rápido de lo que el consumidor puede procesarlos. En mi caso, la IA es el productor (puede generar código casi instantáneamente) y yo soy el consumidor (necesito tiempo para definir el próximo paso).
La trampa del gimnasio
Hay un punto en todo proyecto donde la cantidad de requerimientos empieza a bajar. La arquitectura ya está, las funcionalidades core ya existen, ahora son detalles, refinamientos, casos borde. En ese momento, mantener una suscripción de alto tier deja de ser rentable.
Es la misma lógica que la membresía del gimnasio: pagás por un mes entero pero vas dos o tres veces. No es que el gimnasio sea malo, es que tu uso real no justifica el precio.
Podemos imaginar este mismo proceso en empresas. En una empresa, entre que el Product Manager baja el requerimiento, el dev lo entiende, lo discute, lo implementa y lo revisa, pasan horas y a veces días donde los créditos de IA simplemente están ahí, esperando.
El nuevo costo del proyecto cancelado
Algo que en desarrollo pasa: Inicias una funcionalidad, avanzas un poco, y a mitad de camino cambia el requerimiento o directamente se cancela el proyecto. Antes, el costo de eso era principalmente tiempo. El dev cobraba su sueldo igual, pero podías cambiar el rumbo sin un golpe económico directo.
Hoy es distinto.
Imagina este escenario: a un desarrollador se le asigna un nuevo requerimiento y, gracias a la IA, en lugar de tardar tres meses lo tira en dos semanas. Pero en esas dos semanas quemó 3.000 o 4.000 dólares en créditos. Y resulta que al mes el producto cambia de dirección y ese código se descarta. Antes perdías tiempo de desarrollo. Hoy pierdes tiempo más dinero en créditos que ya no se recuperan.
Lo peor es que la velocidad invita a saltarse el análisis. Si producís rápido, te tomas menos tiempo para pensar si realmente vale la pena producir eso. Y como todo se siente instantáneo, nadie frena para preguntarse si el requerimiento estaba bien planteado desde el inicio.
La velocidad esconde errores que después se pagan
El último punto, y quizás el más incómodo: la IA genera código rápido, pero también genera más errores. No porque la IA sea mala, sino porque los requerimientos que le pasamos rara vez están al 100% pulidos.
Cuando desarrollabas algo manualmente, había un proceso natural de analizar nuevamente el problema mientras codeabas. Te sentabas a escribir una función y a mitad de camino te dabas cuenta de que faltaba algo, que un caso borde no estaba contemplado, que había una mejor forma de modelar el problema. Ese proceso es valioso. Es donde aparecen los hallazgos que no estaban en el documento de requerimientos.
Con la IA, ese espacio de analizar varias veces el mismo problema, se comprime o desaparece. Definís un requerimiento, lo tira y sale código funcional, los tests pasan. ¿Y por qué pasan los tests? Porque cubren exactamente lo que dijiste que tenían que cubrir. Los casos borde que ni vos pensaste, tampoco aparecen en los tests.
A mí me pasó en este proyecto. Cuando me senté a revisar todo lo que había generado al 100% con IA, encontré cosas que funcionaban "bien" pero que tenían problemas de seguridad, casos no contemplados, lógica frágil en partes que parecían triviales. Y trazar todo eso cuando son muchas funcionalidades a la vez es muy difícil.
Y acá viene la parte cara: terminas usando la misma IA, gastando más créditos, para revisar y arreglar el código que esa misma IA generó. Diez mil líneas que después necesitan dos mil llamadas más a la IA para auditar, corregir y validar.
Mi perspectiva
Si lo pongo todo junto, en mi experiencia personal vi al menos cuatro formas claras de perder dinero con IA en desarrollo:
- Backpressure humano: pagas capacidad que no puedes consumir porque vos sos el cuello de botella.
- La trampa del gimnasio: la suscripción de alto tier deja de ser rentable cuando los requerimientos bajan, pero seguís pagándola.
- Cancelaciones más caras: los proyectos que se descartan a mitad de camino ahora se llevan miles de dólares de créditos consumidos, no solo tiempo.
- Velocidad sin análisis: generas más código, con más errores, y terminas gastando más créditos revisando y arreglando lo que la IA misma produjo.
Hoy en día, muchas empresas están ajustando sus modelos de negocio para poder ser más óptimas en este proceso de uso de IA, más aún con la subida de costos que se está presentando.
Me encantaría leer la experiencia de otros.
Top comments (0)