Sí, usamos inteligencia artificial todos los días. La usamos para escribir código repetitivo, para explorar alternativas antes de decidir, para escribir pruebas y para revisar lo que escribimos. Nos hace más rápidos y no tenemos ningún interés en ocultarlo.
También creemos que eso no cambia lo que estás contratando. Cuando alguien nos dice «eso lo hago yo más barato con una IA», casi siempre tiene razón sobre la primera versión y casi nunca sobre la segunda. La diferencia entre un software que arranca y uno que sigue funcionando en dos años no está en quién escribió las líneas: está en quién decidió cómo se estructuran, cómo se protegen y cómo se sostienen.
Somos un equipo con más de 40 años de experiencia sumada en web, móvil y escritorio. Esta página explica, sin adornos, qué parte del trabajo delegamos a una máquina y qué parte no, para que puedas decidir con información en vez de con una promesa.
Con IA
Para qué sí usamos IA
En todo lo que es mecánico, verificable y de bajo riesgo. Si una máquina lo hace bien y nosotros lo revisamos, no hay razón para cobrarte las horas de escribirlo a mano.
- Código repetitivo: formularios, validaciones, adaptadores entre sistemas, migraciones de datos.
- Primeras versiones de pruebas automatizadas, que después ajustamos a los casos reales del negocio.
- Explorar dos o tres formas de resolver algo antes de comprometernos con una.
- Documentación técnica y comentarios, que alguien del equipo revisa antes de que queden.
- Una segunda lectura del código que ya escribimos, buscando lo que se nos pudo pasar.
Sin criterio
Dónde deja de alcanzar
Estos no son casos raros de laboratorio. Son los cuatro o cinco problemas que encontramos una y otra vez cuando nos llega un software para rescatar.
Escribe la consulta a la base de datos.
No se da cuenta de que consulta dentro de un bucle y que eso, con 500 usuarios y un catálogo real, convierte una pantalla de medio segundo en una de treinta.
Escribe el inicio de sesión y los permisos.
No verifica que el identificador en la URL pertenezca a quien lo pide. Es el fallo más común y más caro que existe: un cliente viendo los datos de otro.
Genera el proyecto y lo deja corriendo en tu máquina.
No configura respaldos, ni forma de volver atrás, ni monitoreo, ni certificados, ni qué pasa cuando el servidor se reinicia solo un domingo.
Resuelve el error que le señalas.
No sabe qué se rompió en otra parte al arreglarlo, porque no tiene el modelo completo del sistema en la cabeza. Alguien tiene que tenerlo.
Responde a cualquier hora, en segundos.
No firma un contrato, no asume la responsabilidad de una caída ni te devuelve la llamada cuando tu operación está detenida. Eso lo hace un equipo que responde por su trabajo.
Antes de publicar
Lo que revisamos antes de que algo salga a producción
Ninguna de estas revisiones la hace un modelo por su cuenta, porque ninguna depende de escribir código: dependen de conocer tu negocio y de haber visto fallar cosas antes.
- Que las consultas a la base de datos estén indexadas y no se multipliquen dentro de bucles.
- Que cada endpoint verifique no solo que hay sesión, sino que esa sesión tiene derecho a ese dato en concreto.
- Que los datos sensibles estén cifrados y que nada confidencial quede en registros ni en el navegador.
- Que exista respaldo automático, que se haya probado restaurarlo, y que haya forma de volver a la versión anterior en minutos.
- Que haya monitoreo y alertas: que nos enteremos nosotros antes que tú.
- Que el despliegue no interrumpa el servicio y que las migraciones de datos se puedan revertir.
- Que el sistema aguante el volumen real que va a tener, no el de la demo.
El costo real
Qué pasa cuando no hay criterio detrás
Una parte creciente de nuestro trabajo de mantenimiento es exactamente esto: software generado rápido, que funcionó bien durante unas semanas y empezó a fallar cuando llegó el uso real. Casi siempre se repite el mismo patrón.
El sistema va bien con veinte registros y se arrastra con veinte mil, porque nadie pensó en índices. Los permisos comprueban que hay usuario pero no cuál, así que cualquiera con la URL correcta ve lo que no debería. No hay respaldos, o los hay y nunca se probó restaurarlos, que es lo mismo. No hay registro de errores, así que cuando algo falla nadie sabe qué pasó. Y el código creció sin estructura, de modo que cada arreglo rompe otra cosa.
Rescatar eso cuesta más que haberlo hecho bien. No porque haya que empezar de cero —muchas veces no hace falta— sino porque hay que entender un sistema que nadie diseñó, corregirlo sin detener la operación y hacerlo con el negocio ya dependiendo de él. Ese es el precio real de la primera versión barata, y se paga tarde.
Si ya estás en esa situación, lo que necesitas es un diagnóstico y plan de estabilización, no empezar de cero.
Cuándo no
Cuándo te vamos a decir que no nos necesitas
Si lo que quieres es validar una idea con diez usuarios, probar si a alguien le interesa, o montar algo interno que usarán tres personas y que si se cae no pasa nada: hazlo con IA, o con una herramienta sin código. Te lo vamos a decir en la primera conversación y no te vamos a cobrar por escucharla.
Nuestro trabajo empieza a tener sentido cuando el software sostiene algo que importa: dinero que se cobra, datos de clientes que hay que proteger, una operación que se detiene si el sistema se detiene. Ahí la pregunta deja de ser cuánto cuesta construirlo y pasa a ser cuánto cuesta que falle.
Preguntas frecuentes
Lo que nos preguntan sobre IA y desarrollo
Las dos cosas, y siempre con una persona responsable. Usamos IA para las partes mecánicas y repetitivas, y un desarrollador del equipo diseña la estructura, revisa todo lo generado y responde por el resultado. Nunca entregamos código que nadie del equipo haya leído y entendido.
Parte del trabajo sí cuesta menos, y eso se refleja en que hacemos más en el mismo tiempo. Pero escribir código nunca fue la parte cara. Lo caro es decidir la arquitectura, proteger los datos, desplegar sin romper nada y sostenerlo cuando falla. Esa parte no la acelera una IA, y es la que evita que tengas que rehacerlo todo dentro de un año.
Depende de qué sostiene el software. Para una prueba rápida o algo interno de bajo riesgo, probablemente no. Para algo de lo que dependen tus cobros, tus clientes o tu operación diaria, sí: la IA genera código, pero no responde por él. Alguien tiene que garantizar que aguante, que sea seguro y que se pueda arreglar cuando falle.
Los que vemos con más frecuencia: consultas sin índices que colapsan cuando crecen los datos, controles de acceso que verifican que hay sesión pero no de quién, ausencia total de respaldos y monitoreo, dependencias desactualizadas con vulnerabilidades conocidas, y falta de estructura, de modo que cada corrección rompe algo en otro lugar.
Sí, es una parte creciente de lo que hacemos. Empezamos con un diagnóstico del código, la base de datos y la infraestructura, y te decimos con claridad qué está pasando y qué prioridad tiene cada cosa. Muchas veces no hace falta empezar de cero: se estabiliza, se corrige y se adapta lo que ya existe.
No. Usamos IA sobre código, no sobre los datos de tu operación. La información de tus clientes no se envía a servicios de terceros para generar ni para depurar, y cuando necesitamos probar con datos reales trabajamos con copias anonimizadas.
Porque puedes verlo. Trabajamos por entregas: revisas versiones funcionales durante el proyecto, no solo al final. Te explicamos las decisiones técnicas en lenguaje claro y te entregamos el código y la documentación. Y hablas siempre con quien lo construyó, no con un intermediario.