Georgia Tech AI Hackathon: Realidad de construcción de 3 horas
Vi un clip de un hackathon del sábado en Georgia Tech esta semana y estuvo en mi cabeza durante dos días. No por la energía que había en la habitación, aunque había mucha de ella, sino por un momento específico. Una cámara captó a un equipo en los veinte minutos finales. Tres estudiantes encorvados alrededor de una sola computadora portátil. Su aplicación casi estaba funcionando. Casi. El tipo de "casi" en el que el AI había montado todo en la primera hora, y habían pasado las dos restantes intentando que no se estrellara cuando un humano real lo tocaba.
Esa expresión en sus rostros es lo más honesto que he visto filmar sobre el desarrollo asistido por AI este año.
El evento fue el hackathon Claude Builder Club, organizado en el campus de Georgia Tech y patrocinado por Anthropic. El desafío era difícil: crear una aplicación móvil o web que ayude a las personas a mantener hábitos saludables utilizando el diseño basado en AI. Tres horas. Aviso revelado al principio. Equipos de hasta tres personas. Las computadoras portátiles se cerraron al sonar el timbre, luego las presentaciones ante un panel de jueces. El equipo ganador creó una aplicación gamificada de seguimiento de comidas que sugería combinaciones nutricionales y recompensaba a los usuarios por rachas saludables.
Esa es la historia superficial. La historia subyacente, que sigo repasando, es lo que estas tres horas revelan sobre cómo funciona realmente el software de envío cuando AI escribe.
Porque esto es lo que nadie te dice cuando miras una demostración de Claude en Twitter y ves que una aplicación completa funciona en seis minutos: la demostración es la parte fácil. La parte difícil es todo entre "el prototipo se ve genial" y "un humano real puede confiarle algo importante". Un hackathon es un microcosmos perfecto de esa brecha, y los estudiantes de Georgia Tech lo vivieron frente a la cámara en tres horas.
Quédate conmigo. La razón por la que esto es importante no es el hackathon. Es lo que demuestra el hackathon sobre los próximos doce meses de cada producto creado por AI que llegue a la App Store.
Cómo se ve realmente un hackathon AI de tres horas
Permítanme preparar el escenario con los números, porque el encuadre importa.
La Facultad de Computación de Georgia Tech inscribió a 4,621 estudiantes universitarios y 16,910 estudiantes de posgrado en títulos de computación a partir del ciclo de otoño de 2024, lo que la convierte en uno de los programas de computación más grandes del país. La informática es la especialidad más popular en el campus. Cuando el Claude Builder Club de Anthropic organiza un evento allí, el nivel de talento es alto: estos no son estudiantes de introducción a la informática que se topan con su primer API. Muchos de ellos han enviado proyectos reales, contribuido al código abierto y ya han utilizado Claude Code o Anthropic SDK en su pila personal.
Ahora colóquelos en un contenedor de tres horas con un mensaje novedoso y dígales que creen una aplicación de salud que funcione con AI como autor principal. ¿Lo que sucede?
Lo que sucede es exactamente lo que sucedió en el video: un rápido andamiaje, luego un lento y frustrante avance hacia algo que no se estrella en el primer contacto con la realidad.
Los primeros treinta minutos suelen ser los más mágicos. Un equipo elige un ángulo (seguimiento de las comidas, hidratación, sueño, lo que sea) y comienza a dar indicaciones. Claude Opus 4.7 (lanzado el 16 de abril de 2026, el modelo Anthropic más capaz cuando se ejecutó este hackathon) puede crear una aplicación nativa Next.js o React completa con autenticación, enlaces de base de datos y un UI funcional en una sola conversación. Lo he hecho yo mismo para proyectos personales. Observas cómo se completa el árbol de archivos, se componen los componentes, arranca el servidor de desarrollo y sientes algo cercano al vértigo. Ya estamos al 60%. Nos quedan dos horas y media. Esto va a ser fácil.
Luego abres la aplicación y tocas el primer botón.
Ahí es donde realmente comienza el hackathon de cada equipo.
La brecha entre el andamio y el barco es donde viven los ingenieros
Cuando pienso en cómo uso AI en mi propio trabajo, esta brecha es donde va el 90% de mi tiempo, y creo que esta es la parte que la mayoría de la gente subestima cuando predicen lo que AI hará en los trabajos de software.
Aquí hay un ejemplo concreto de mi propia semana. Estaba creando una pequeña herramienta interna: un integrador de CSV que se canaliza hacia un flujo de trabajo de etiquetado. Claude Code 2.1 desarrolló todo el proyecto en aproximadamente seis minutos. Estructura de carpetas, lógica del analizador, dispositivos de prueba, una interfaz CLI limpia. La primera ejecución funcionó con los datos de prueba que le había proporcionado a Claude. La segunda ejecución, en un CSV real de un cliente, se rompió en tres lugares: un carácter de lista de materiales perdido al inicio del archivo, una columna con codificaciones mixtas y una fila de encabezado que incluía una celda de espacio en blanco fantasma debido a cómo la escribió la exportación original de Excel.
Ninguno de esos errores estaba en el mensaje. Ninguno de ellos está en ningún tutorial. Aparecen porque los datos reales son confusos, los usuarios reales hacen cosas impredecibles y la única forma de encontrar estos modos de falla es compararlos con la realidad.
Esa brecha, entre "AI creó un prototipo funcional" y "esto puede sobrevivir a usuarios reales", es exactamente la brecha que un hackathon te hace vivir en tiempo real. Los estudiantes de Georgia Tech no se quedaron atrás porque Claude era lento. Se quedaron atrás porque encontrar los diecisiete casos extremos que rompen una aplicación real de seguimiento de comidas lleva más de tres horas, sin importar qué tan rápido sea su AI.
El decano asociado de la Facultad de Computación de Georgia Tech lo dijo claramente en el video: los humanos deben permanecer "al tanto" para probar, refinar y garantizar que los resultados generados por AI sean utilizables y confiables. Esa no es una cobertura educada. Esa es la descripción del trabajo real para los ingenieros de software en 2026.
Por qué la compresión del tiempo revela lo que oculta la escala
Hay una razón por la que un hackathon de tres horas es más revelador que un proyecto corporativo AI de tres meses.
Cuando tengas tres meses y doce ingenieros, podrás ocultar la brecha. Puede tener un ingeniero solicitando Claude todo el día, dos más limpiando casos extremos, tres pruebas de escritura más y un diseñador puliendo el UX. El equipo envía una "aplicación creada por Claude", pero en realidad, Claude escribió el primer borrador y un pequeño ejército de humanos lo convirtió en algo en lo que los usuarios podían confiar. La historia que cuentas en LinkedIn es "lo construimos con AI". La historia que cuenta tu registro de git es más honesta.
Comprime el mismo flujo de trabajo en tres horas, con tres personas, y no podrás ocultar nada. O el AI te llevó a la línea o no. O encontraste los errores o tu demostración falla frente a los jueces.
Es por eso que los hackatones siguen siendo la prueba más clara de cómo AI realmente cambia el ritmo de la construcción. Las conferencias de la industria y los vídeos de demostración le muestran los momentos mágicos. Los hackatones le muestran lo que sucede entre los momentos mágicos: el tramo silencioso de treinta minutos en el que alguien está investigando un seguimiento de la pila porque AI llamó con confianza a una función que no existe en la versión del SDK que están usando.
He aprendido más sobre mi propio flujo de trabajo AI realizando compilaciones personales las 24 horas que con cualquier publicación de blog. La disciplina de "enviar algo que funcione en un cuadro de tiempo fijo" lo obliga a confrontar qué partes de su pila realmente ahorran tiempo y qué partes simplemente sienten que ahorran tiempo.
Hay un patrón sutil aquí que sigo viendo en mi propio trabajo y que vi claramente en las imágenes del hackathon. Volveré a ello después de que veamos por qué ganó el equipo ganador.
Lo que hizo bien la aplicación ganadora de seguimiento de comidas
El equipo que obtuvo el primer puesto en este hackathon Georgia Tech AI no construyó nada técnicamente impresionante. Construyeron lo correcto. Esa distinción lo es todo en una construcción de tiempo limitado.
Su aplicación combinaba el seguimiento de las comidas con la gamificación: rachas de alimentación saludable, sugerencias de combinaciones nutricionales (proteínas con carbohidratos, ese tipo de cosas) y recompensas por la constancia. Sobre el papel esto suena sencillo. A continuación, se muestra un ejemplo de libro de texto de lo que funciona actualmente en las aplicaciones de mHealth.
Las aplicaciones de dieta y nutrición tienen un problema de retención brutal. Los datos de la industria muestran que aproximadamente el 30% de los usuarios abandonan durante el primer mes. Alrededor del 70% de los usuarios abandonan una aplicación de nutrición en un plazo de dos semanas si les parece demasiado compleja o requiere mucho tiempo. El registro de comidas es uno de los comportamientos diarios más exigentes del usuario en el software de consumo, a la par del diario: pide al usuario que haga un trabajo consciente antes de ser recompensado.
Pero aquí está el dato que hace que la elección del equipo ganador haga clic: las aplicaciones de salud gamificadas muestran aproximadamente un 50% más de participación y retención que sus equivalentes no gamificadas. Las insignias de logros por sí solas aumentan el compromiso en aproximadamente un 40%. La mecánica de racha, la misma primitiva que impulsa la retención de MyFitnessPal, funciona porque secuestra la aversión a las pérdidas. No querrás romper la cadena.
El equipo ganador no inventó la gamificación para aplicaciones de nutrición. Eligieron un patrón de retención conocido y dejaron que Claude desarrollara la implementación en torno a él. Ésa es la jugada. En un contenedor de tres horas, el equipo que gana no es el que tiene la arquitectura más novedosa. Es el equipo el que reconoce qué patrón ya tiene evidencia detrás y usa AI para enviar ese patrón más rápido.
Así es exactamente como pienso ahora sobre mis propias construcciones. No intento inventar nuevas mecánicas. Leo los datos de retención, identifico qué mecánicos tienen pruebas y uso Claude para estructurarlos en una tarde. El ancho de banda creativo no consiste en inventar nuevas ruedas, sino en elegir qué rueda es importante y ajustarla para mi usuario específico.
Los cinco modos de falla del Hackathon que veo repetidamente
Si ves suficientes hackatones (o ejecutas suficientes compilaciones personales de tres horas), se repiten los mismos cinco modos de falla. El metraje de Georgia Tech muestra al menos tres de ellos. Aquí están, en el orden en que suelen morder.
Modo de error uno: aumento del alcance en los primeros treinta minutos. Un equipo recibe la indicación y comienza a hacer riffs. Pasan de "rastreador de comidas" a "rastreador de comidas más feed social más nutricionista AI más escáner de código de barras". El AI está tan dispuesto que el equipo confunde "Claude puede montar esto" con "podemos enviar esto". Dos horas más tarde, tienen seis funciones a medio construir y cero flujos de trabajo. La cura es brutal: elige un usuario, una pantalla, una interacción y envíalo. No agregue nada hasta que el núcleo funcione.
Modo de error dos: confiar en el primer AI generado por UI. La salida nativa React o React predeterminada de Claude es competente pero genérica. La primera pantalla de héroe siempre tiene los mismos degradados morados, los mismos íconos genéricos, la misma copia de CTA. Los equipos que envían algo memorable dedican al menos 20 minutos a ajustar manualmente la identidad visual, no porque el resultado del AI sea malo, sino porque el AI de todos los demás equipos está produciendo un resultado similar a partir de mensajes similares. Si ha leído mi desglose de por qué todos los sitios web generados por AI tienen el mismo aspecto, este es el mismo problema de huellas dactilares que se aplica a las aplicaciones.
Modo de error tres: manejo de errores cero. Un camino feliz y funcional es una compilación de 30 minutos. Una aplicación que funciona con errores manejados es una compilación de tres días. Los hackatones comprimen esto brutalmente. El equipo que gana suele ser el que envuelve cada llamada de API en un try/catch, muestra estados vacíos elegantes y tiene al menos un respaldo para cuando se agota el tiempo de espera de la función AI. Las demostraciones no fallan en el escenario porque el equipo tuvo suerte; no fallan porque el equipo trató el manejo de errores como una característica de primera clase, no como un paso de pulido.
Modo de fallo cuatro: juzgar el resultado del AI leyéndolo en lugar de ejecutarlo. Veo esto en mi propio trabajo y lo vi claramente en las imágenes del hackathon. Un equipo solicita Claude, escanea el resultado, ve "sí, eso se ve bien" y continúa. Luego, en el minuto 145 de 180, ejecutan el código y fallan tres cosas. La disciplina que separa a los remitentes rápidos de los lentos es ejecutar cada cambio generado por AI inmediatamente. Leer y no ejecutar es el atajo más caro en el desarrollo asistido por AI.
Modo de error cinco: olvidar que la demostración es el producto final. Un hackathon no es una revisión de código. Es un argumento de venta con software en ejecución debajo. Los equipos que crean una ruta de demostración clara de dos minutos (comienzan en la pantalla de inicio, pasan por los tres momentos impresionantes y terminan con una conclusión satisfactoria) vencen a los equipos con productos más ambiciosos que no saben cómo mostrar lo que crearon. Lo mismo se aplica al envío de cualquier producto AI. Los primeros 90 segundos del usuario son la demostración. Diseñe esos 90 segundos intencionalmente.
Si está utilizando Claude Code para construir algo en un período de tiempo limitado, vale la pena imprimir esos cinco modos de falla y fijarlos en su monitor.
La cuestión del ser humano en el circuito ya estaba resuelta: esto es lo que realmente está cambiando
El video enmarcó la discusión humana como si todavía fuera una pregunta abierta. ¿AI reemplazará a los desarrolladores o los humanos seguirán siendo esenciales? Quiero rechazar ese planteamiento porque creo que es la pregunta equivocada, y el hackathon en sí lo demostró.
Esa pregunta se resolvió en el momento en que Anthropic lanzó Claude Code 2.0 y los desarrolladores comenzaron a ejecutarlo como un bucle de agente con puntos de control humanos. La respuesta es que los humanos se mantienen informados. La pregunta interesante, la que en realidad cambia mes a mes, es dónde pertenecen los puntos de control humanos.
En 2024, el punto de control humano en el circuito estaba al nivel de línea. Le pediría al AI una función y leería cada línea antes de pegarla. En 2025, el punto de control se trasladó al nivel de archivo o módulo: Claude podría escribir un archivo completo y usted revisaría la diferencia. Para abril de 2026, con Opus 4.7, el punto de control se trasladó al nivel de características. Claude puede crear, probar y autocorregir una característica completa, y el revisor humano verifica el comportamiento de la característica, no sus líneas.
Esto es a lo que realmente apuntaba el decano asociado, y lo que el hackathon demostró en forma comprimida. Los estudiantes no escribían cada línea. Estuvieron ejecutando, probando, solicitando y volviendo a solicitar hasta que el comportamiento coincidiera con lo que querían. El papel humano ascendió un nivel de abstracción, pero no desapareció. En todo caso, se volvió más difícil, porque revisar el comportamiento requiere más habilidad que revisar la sintaxis.
Por cierto, esta es exactamente la razón por la que sigo diciendo que "la alfabetización AI" es un mal encuadre de lo que los estudiantes necesitan ahora. AI alfabetización implica habilidades de lectura. Lo que realmente necesita es juicio AI: saber cuándo confiar en la salida, cuándo volver a solicitarla, cuándo descartarla y escribirla usted mismo, y cuándo AI está seguro de que es incorrecto. Eso es un oficio, no una alfabetización. Y como todo oficio, sólo se desarrolla construyendo cosas que realmente tienen que funcionar.
Un hackathon de tres horas en una de las mejores escuelas de informática es uno de los campos de entrenamiento más limpios que puedo imaginar para el juicio de AI. No puedes fingir. Al timbre no le importa.
Lo que estoy robando del Hackathon para mis propias compilaciones
Ver este video cambió tres cosas en la forma en que ejecuto mis propias compilaciones AI este mes. No porque haya aprendido nada nuevo exactamente, sino porque el hackathon aclaró cosas que había estado haciendo de manera intuitiva.
Uno: estoy poniendo límites de tiempo más estrictos. Solía darme una semana para enviar una herramienta pequeña. Ahora me doy una tarde. No porque sea más rápido (Claude es más rápido, no lo soy), sino porque los cuadros de tiempo más cortos obligan a la disciplina a omitir funciones que no importan. La restricción de tres horas en Georgia Tech no fue cruel: fue esclarecedora. De todos modos, la mayor parte de lo que se corta bajo presión de tiempo nunca se enviaría.
Dos: estoy anticipando la ruta de demostración. Antes de escribir una línea, escribo la demostración de dos minutos que quiero ofrecer. Haga clic aquí, vea esto, toque aquello, observe cómo aumenta el contador de rachas, vea la animación de recompensa. Luego trabajo hacia atrás y construyo solo lo necesario para que esa demostración funcione. Todo lo demás es un objetivo ambicioso. Este único cambio ha duplicado aproximadamente mi tasa de finalización de proyectos paralelos.
Tres: estoy ejecutando cada cambio de AI inmediatamente. Solía leer la salida de Claude, asentir y seguir adelante. Ahora lo ejecuto. Cada vez. Si Claude agregó una función, la llamo con entrada real. Si Claude realiza un scaffolding de un componente, lo renderizo con datos reales. La fricción es pequeña. La tasa de descubrimiento de errores es enorme. La mayoría de las fallas que solía encontrar al final de una compilación, ahora las encuentro dentro de los noventa segundos posteriores a la realización del cambio.
Si ha estado usando Claude Code o cualquier herramienta de codificación agente de manera casual y desea subir de nivel, esos tres cambios por sí solos valen más que cualquier plantilla de aviso que haya compartido.
El techo no es la capacidad AI: es la confianza
Esta es la parte del hackathon a la que sigo volviendo. La aplicación de seguimiento de comidas ganadora fue inteligente. La presentación fue ajustada. A los jueces les encantó. Y es casi seguro que ninguno de esos jueces usaría esa aplicación para controlar su propia dieta.
Eso no es un golpe para el equipo: es el techo fundamental de las aplicaciones para consumidores creadas por AI en este momento. La capacidad ya no es el cuello de botella. Claude Opus 4.7 puede desarrollar una aplicación de salud completa en una hora con una mejor ergonomía predeterminada que la aplicación promedio en la App Store. El cuello de botella es la confianza. ¿Los usuarios reales entregarán sus datos de alimentación, de sueño y de salud a una aplicación cuyo creador no conocen, cuya política de privacidad no leyeron y cuyo comportamiento de retención de datos no pueden verificar?
Esa brecha de confianza es exactamente donde vive la próxima ola de ventajas competitivas. Cualquiera puede desarrollar una aplicación AI. Casi nadie puede construir una infraestructura de confianza a su alrededor: manejo claro de datos, comportamiento predecible en casos extremos, accesibilidad para usuarios que no encajan en el camino feliz, estados de error que no hacen que el usuario se sienta estúpido y una marca que indica "esto estará aquí en dieciocho meses".
Esta es también la razón por la que la conversación entre humanos es importante mucho más allá de los hackatones. En 2026, la pregunta no es ¿puede AI construirlo? La pregunta es ¿un humano lo verificó lo suficientemente bien como para que alguien con piel en el juego lo use?. Los flujos de trabajo híbridos AI, donde la automatización se combina con la supervisión humana a la altitud adecuada, son el estándar de producción actual. Los observadores de la industria han comenzado a llamar a esto "AI verificado por humanos" como un diferenciador de marca. No se equivocan. El mercado está empezando a valorar la confianza de la misma manera que solía codificar el precio de la calidad: como un foso competitivo.
Los equipos del hackathon que perdieron no fueron superados en capacidad. Fueron superados en juicio: qué características enviar, cuáles cortar, qué caja de borde manejar, en qué pulimento invertir. Ese juicio es lo que AI no reemplaza. Es lo que AI amplifica cuando el humano que lo empuña lo tiene, y lo expone brutalmente cuando el humano no lo tiene.
Lo que realmente estaban haciendo los tres estudiantes en el minuto 145
Permítanme volver a ese momento del vídeo que tengo en la cabeza.
Tres estudiantes. Una computadora portátil. Quedan veinte minutos en el reloj. Su aplicación casi estaba funcionando. Estaban depurando, solicitando Claude, volviendo a ejecutar, solicitando nuevamente. Intentando actualizar el contador de rachas sin bloquear la vista del panel.
Esa no es una historia sobre que AI reemplace a los desarrolladores. Esta es una historia sobre tres jóvenes ingenieros que aprenden el trabajo real de un desarrollador de la era AI en tiempo real. El trabajo no es escribir código. El trabajo ni siquiera solicita AI. El trabajo es el bucle: defina el comportamiento que desea, solicite AI, ejecute el resultado, encuentre la brecha entre el comportamiento y la realidad, solicite nuevamente, ejecute nuevamente, hasta que se cierre la brecha. Ese bucle es ahora toda la profesión.
Un hackathon de tres horas en Georgia Tech no expone a los estudiantes a AI. Les enseña el bucle. Eso vale más que cualquier curso sobre ingeniería rápida o cualquier tutorial sobre Anthropic SDK. El ciclo se aprende ejecutándolo bajo presión, no leyendo sobre él.
Si estuviera ejecutando un programa de informática en 2026, haría que cada estudiante hiciera al menos un hackathon en solitario de tres horas al mes. No porque los hackatones sean intrínsecamente geniales (son brutales), sino porque nada más comprime todo el ciclo de desarrollo de la era AI en una sola tarde como lo hacen.
Preguntas frecuentes
¿Cuál fue el mensaje del hackathon Georgia Tech AI?
El hackathon Claude Builder Club en Georgia Tech desafió a los estudiantes a crear una aplicación móvil o web que ayude a las personas a mantener hábitos saludables utilizando el diseño impulsado por AI, en un período de tres horas. El mensaje se reveló solo al comienzo de la competencia, y podían competir equipos de hasta tres estudiantes. La propuesta ganadora fue una aplicación gamificada de seguimiento de comidas con recompensas por racha y sugerencias de combinación nutricional.
¿Qué modelo Claude se utilizó en el hackathon Georgia Tech patrocinado por Anthropic?
Los hackathons patrocinados por Anthropic en 2026 generalmente brindan a los participantes acceso a los últimos modelos Claude, incluido Claude Opus 4.7 (lanzado el 16 de abril de 2026) para tareas de codificación complejas y Claude Sonnet 4.6 para una iteración más rápida. La mayoría de los equipos usan Claude Code o Anthropic API directamente durante la ventana de compilación. Para obtener un desglose más completo de cómo los uso en producción, consulte mi guía de flujo de trabajo Claude Code.
¿Qué tan rápido puede AI crear una aplicación que funcione en 2026?
Claude Opus 4.7 puede crear una aplicación nativa Next.js o React completa (autenticación, base de datos, UI) en aproximadamente de seis a quince minutos. El "andamio" no es lo mismo que el "producto listo para enviar". Los usuarios reales encuentran casos extremos, estados de error y formas de datos que el andamio no maneja de forma predeterminada, lo que generalmente toma la mayor parte del tiempo de compilación incluso con la asistencia de AI.
¿Por qué la gamificación funciona tan bien en las aplicaciones de salud?
La gamificación funciona porque los comportamientos de salud requieren fricción diaria (registro, seguimiento, elección) y las recompensas de una vida saludable tardan en materializarse. Las rachas, las insignias y los ciclos de recompensas comprimen el cronograma de comentarios para que los usuarios sientan el progreso en días en lugar de meses. Las aplicaciones de salud gamificadas muestran aproximadamente un 50 % más de participación y retención que sus equivalentes no gamificadas, y las insignias de logros por sí solas aumentan la participación en alrededor del 40 %.
¿Sigue siendo relevante el modelo humano en el circuito cuando AI es capaz de hacerlo?
Sí, más, no menos. A medida que la capacidad de AI ha crecido, el punto de control humano en el circuito ha pasado de la revisión a nivel de línea a la verificación de comportamiento a nivel de característica. El consenso de la industria en 2026 trata a AI verificado por humanos como el estándar de producción para cualquier sistema donde la confianza, el cumplimiento o la seguridad sean importantes. La pregunta no es si los humanos permanecen en el circuito, sino en qué parte del circuito se encuentran.
El timbre no miente
La razón por la que el video Georgia Tech permaneció en mi cabeza durante dos días no es la tecnología. Es lo que reveló el timbre.
Tres horas. Los mejores modelos de Anthropic. Algunos de los estudiantes de informática más talentosos del país. Y la brecha entre "AI puede construirlo" y "los usuarios pueden confiar en él" era aún mayor de lo que tres horas podrían cerrar. Esa brecha es todo el trabajo ahora. Esa brecha es donde cada ingeniero, cada fundador, cada constructor en solitario pasará los próximos cinco años de su carrera.
Esta noche, antes de irte a dormir, date un box de tres horas. Elige algo pequeño. Abra Claude Code. Establece un cronómetro. Vea lo que puede enviar entre andamio y confianza. Aprenderá más sobre cómo AI está cambiando el ritmo de la construcción que en cualquier conferencia de este año.
El timbre no miente. La demostración tampoco.
Trabajemos juntos
¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Cartera: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y marca): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
