Voy a abrir una tienda online con un generador de IA: ¿en qué partes no podré apañármelas solo?

En un proyecto parecido pensé que me ahorraba 120 horas haciendo que la IA escribiera la interfaz. Luego tuve que pagar 110.000 RUB a un experto externo para depurar los códigos de error del proveedor de pagos. Ahorras en diseño, pero la infraestructura siempre exige presupuesto.

Los modelos de IA suelen generar código que funciona en entornos de prueba. En producción, si 50 personas meten el mismo producto al carrito a la vez, se produce una condición de carrera (race condition) y el stock se queda en negativo. Si le dejas la arquitectura de bloqueo de inventario a la IA, no darás abasto con las cancelaciones de pedidos.

En vez de escribir código desde cero monta una plataforma de e-commerce probada y contrastada. Usa la IA solo para traducir descripciones de producto diseñar banners y redactar textos de categoría. No hace falta reinventar la rueda.

¿Quién le va a dar mantenimiento mañana al código que escribió la IA? Cuando salga un fallo en la base del código le volverás a preguntar a la herramienta y te propondrá una arquitectura totalmente distinta. Después de un tiempo el código se vuelve un espagueti y ningún programador querrá meterle mano.

el diseño es la parte fácil amigo, el verdadero dolor de cabeza es la api de las agencias de transporte y las devoluciones luego o sea si al cliente le cobran de la tarjeta y el producto no llega e immpugna el cargo en el banco te vas a comer un buen marrón yo tmb opino q deberías contratar a alguien pa la parte de atrás.

¿Cuántas referencias de stock vas a llevar en la web y cómo tienes pensado gestionar la facturación? Si vas a recibir 5 pedidos al día lo puedes llevar a mano, pero si entran 50 al día, ¿podrás controlar cómo guarda los registros (logs) el código de la IA por detrás?

El año pasado hicimos la web con esa misma ilusión para nuestra tienda de recambios en San Petersburgo. Todo parecía perfecto hasta el primer intento de fraude. Entraron bots a probar tarjetas el sistema no los bloqueó y el banco nos congeló el TPV al instante. Ese día entendimos lo seria que es la cosa.

Hace dos años viví exactamente lo mismo. El calendario de pagos debe vincularse a las fases del proyecto no a fechas fijas.

Las soluciones que funcionan a pequeña escala se rompen al crecer aprendí esto tarde. Comprobado por experiencia.

Yo también pienso lo mismo. Un informe semanal por escrito funciona mucho mejor que preguntar por fechas.

Ánimo.

os expliico cómo se hace en la práctica. las decisiones apresuradas son las que hay que corregir seis meses después.

Os explico cómo se hace en la práctica. Antes de decidir mirad qué datos tenéis en la mano.

Lo dejo como nota por si sirve.

Hace dos años viví exactamente lo mismo. Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

Ánimo.

os cuento lo que me pasó a mí, a ver si os sirve de ayuda. los primeros tres meses todo va bien, los problemas aparecen en el cuarto.

también me gustaría sbaer si alguien lo hace de otra manera.

Estoy en la misma situación, por eso pregunto. La respuesta varía mucho según el sector, no hay una regla general.

Ha sido una buena idea abrir este hilo. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

Por supuesto, cambia si tu situación es diferente.

Os cuento lo que me pasó a mí, a ver si os sirve de ayuda. Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

Corrijanme si me equivoco.

lo escribo para que no cometan el mismo error. intentar hacerlo solo es la vía más cara.

si obtieenes tres respuestas distintas sobre un tema la pregunta está mal formulada luego bueno también me gustaría saber si alguien lo hace de otra manera.

Buen trabajo.