Ninguno de los seis retos se inventó en una sala de reuniones.
Cerca de 20 empresas de la comunidad de Ruta N llenaron una encuesta de diagnóstico contando qué tareas repetitivas les consumían el día. Las respuestas se agruparon por afinidad hasta que quedaron seis formas distintas de perder tiempo, y cada una se convirtió en una competencia. Por eso hay seis y no cinco ni diez.
Podía competir cualquier persona inscrita al bootcamp por los canales oficiales de la convocatoria: asistir a las cuatro noches era muy recomendable, pero no obligatorio. Quien quisiera competir elegía una competencia, construía una solución de verdad para ese problema y la entregaba con un video de tres minutos mostrándola funcionando.
Todo el desarrollo pasaba por un entorno oficial que registraba el proceso, porque cuando una IA construye, mirar solo el resultado ya no distingue a nadie. Por eso hubo entorno obligatorio, video y una verificación individual al día siguiente del cierre.
Las seis mejores soluciones se presentaron en el Demo Day, en Ruta N, ante las mismas empresas que habían descrito el problema. Los retos siguen publicados y se pueden usar para practicar.
- Cuándo
- Se lanzó el jueves 30 de julio, 9:00 p.m., al cerrar la cuarta noche del bootcamp de Claude, y cerró el lunes 3 de agosto, 11:59 a.m. — al mediodía, hora de Colombia.
- Quién lo hizo
- Convocó la Corporación Ruta N, que además puso la sede del Demo Day. Operó SMT IT S.A.S., la sociedad detrás de Smart4AI.
- Participación
- Individual. Cada persona respondía por su propia solución, y se podía competir en una o en varias competencias.
- Los datos
- Sintéticos, y los construía cada participante. Ninguna empresa entregó información real, y usar datos reales de personas o empresas estaba penalizado.
- Costo
- La Maratón no tuvo costo de inscripción y el bootcamp fue gratuito. El entorno oficial sí exigía una suscripción de pago de Claude, que cada persona le pagaba a Anthropic.
Seis problemas de empresas reales, con la misma dificultad.
Cada uno tenía sus empresas madrinas: las que vivían ese dolor y las que estuvieron en el salón el día del Demo Day. Elegir uno u otro no daba ventaja: las seis competencias compartían la misma plantilla de pruebas, la misma distribución de dificultad y un núcleo técnico idéntico.
- 01R1, Servicio al cliente
Centinela
Un asistente de atención al cliente para una pyme: entiende la pregunta, responde con los datos del negocio (catálogo, precios, políticas), recomienda el producto adecuado y escala a un humano cuando hace falta.
- 02R2, Marketing
Musa
Una solución que ayude a una pyme a producir contenido con constancia: ideas, copies y piezas para redes con voz de marca consistente, adaptadas a cada canal y a su público objetivo.
- 03R3, Comercial / Propuestas
Forja
Una solución que genere documentos comerciales: cotizaciones, propuestas, licitaciones y fichas técnicas, con plantillas consistentes, cálculos correctos y personalización por cliente.
- 04R4, Operaciones / Dirección
Faro
Una solución que consolide información dispersa (Excel, PDF, correos) y la convierta en reportes e indicadores claros, con alertas, para tomar decisiones a tiempo.
- 05R5, Finanzas operativas
Cuadre
Una solución para las finanzas operativas de una pyme: facturación, conciliación bancaria, cierres y pedidos a proveedores, con foco en exactitud, control humano y trazabilidad.
- 06R6, Ciclo comercial
Cazador
Una solución para el ciclo comercial: encontrar y priorizar leads, personalizar el primer contacto, sugerir seguimientos y mantener el CRM ordenado.
Los seis retos siguen abiertos y con su detalle completo: de qué cuello de botella salió cada uno, qué tenía que resolver la solución, qué trabajo le quitaba de encima al negocio y qué se le evaluaba a la persona.
Lo que hacía cada participante, en orden.
Siete movimientos, del primero al último. Debajo de cada uno va lo que más gente dejó por fuera ahí: no son detalles, son las razones concretas por las que buenas soluciones se quedaron sin calificar.
Elegía su competencia en la plataforma
Todo el programa vivía en la plataforma Smart Ranks, con el mismo correo de la inscripción al bootcamp. Adentro estaban las seis competencias y, dentro de cada una, la ficha del reto: el problema y la lista exacta de entregables. Las seis tenían la misma dificultad y la misma carga de trabajo.
dónde se caía la genteEntrar con un correo distinto al de la inscripción. Si no coincidía, la entrega y la verificación individual no se cruzaban y la persona quedaba fuera del ranking.
Construía su propio set de datos
La ficha describía el problema, no entregaba los datos. Cada persona inventaba los archivos con los que su solución iba a trabajar —catálogo, precios, clientes, correos, movimientos, lo que pidiera su reto— y armarlos bien era parte del reto.
dónde se caía la genteQuedarse esperando un paquete de datos que nunca existió, o montar la solución sobre dos filas de ejemplo. Eso se leía como contenido genérico y costaba diez puntos, aunque el trabajo estuviera bien hecho.
Configuraba el entorno oficial
Un computador, Claude Code instalado y la credencial personal (el token proxy) configurada según el instructivo que llegaba con la inscripción. El entorno era obligatorio porque es lo que dejaba registro de cómo se construyó, no solo de lo que se entregó.
dónde se caía la genteDejarlo para después y construir tres días en claude.ai o en Cowork. Ese trabajo no se podía recuperar: no quedaba registro, y sin registro el reto tipo Claude no se podía calificar.
Construía la solución
Siempre dentro del entorno oficial y siempre sobre sus datos inventados. No tenía que ser bonita ni enorme: tenía que funcionar de principio a fin y resolver el problema que decía la ficha. Proyectos, skills, artefactos y conectores, que es lo que se había enseñado en las cuatro noches.
dónde se caía la genteQuerer «la aplicación definitiva». Se calificaba que resolviera el problema y que una empresa pudiera adoptarla, no el tamaño.
Escribía el README y grababa el video
Un README que explicara la solución en términos ejecutivos, y un video de máximo tres minutos mostrándola funcionando, con la «prueba en vivo» que definía cada ficha: ejecutar la solución frente a cámara con un dato inventado en ese momento.
dónde se caía la genteDejar el README para el final. Entre documentación y aplicabilidad empresarial se jugaban 35 de los 100 puntos. Y grabar diapositivas en vez de la solución funcionando, que era justo lo que el video existía para demostrar.
Armaba la carpeta y la probaba desde afuera
Una sola carpeta con todo adentro —Drive, Dropbox, GitHub o lo que prefiriera— compartida en modo «cualquier persona con el enlace puede ver», y comprobada en una ventana de incógnito: la carpeta, el video y el README, uno por uno.
dónde se caía la genteCompartirla «con correos específicos». Desde la cuenta propia se veía idéntica y desde afuera no abría, y una carpeta que no abría no se calificaba: era la primera casilla del filtro de completitud.
Enviaba el formulario y presentaba la verificación
Un formulario por cada competencia, con el correo y el enlace de la carpeta, antes del cierre. Al día siguiente, la verificación individual: veinte retos en la plataforma, a libro abierto sobre su propio trabajo, dentro de una ventana de doce horas.
dónde se caía la genteCreer que el cierre era en la noche: fue al mediodía. Y no presentar la verificación, sin la cual no se podía ser finalista ni presentar en el Demo Day, por buena que fuera la solución.
Cinco cosas, y nada que no estuviera pedido.
El entregable era una carpeta; el formulario solo mandaba el enlace. Esta es la lista del numeral 4.3 de los términos, la misma que se contrastaba contra el filtro de completitud.
El set de datos lo construía cada participante. La organización nunca entregó un paquete de datos sintéticos: la ficha describía el problema y cada persona inventaba los archivos que ese problema necesitaba. Armarlos bien era parte del reto, y por eso el criterio de aplicabilidad empresarial pesaba lo que pesaba.
Ninguna empresa madrina entregó información real, y meter datos personales reales de terceros tenía penalización.
- 01README con la introducción al desarrollo del producto
Un documento que explicara la solución en términos ejecutivos. No había plantilla que rellenar: lo escribía cada persona.
- 02Video demo de máximo tres minutos
Mostrando la solución funcionando e incluyendo la «prueba en vivo» definida en la ficha del reto: una acción concreta ejecutada frente a cámara con un dato nuevo, inventado en el momento.
- 03Bitácora de proceso, que nadie tenía que armar
Se generaba sola a partir del registro del entorno oficial, así que no había que adjuntar capturas ni enlaces. Lo único que tocaba era incluir en el README una reflexión breve del proceso.
- 04Los entregables obligatorios de la ficha del reto
Instrucciones del proyecto, skill, artefacto y resultados sobre los datos inventados, según la competencia. La ficha mandaba: si algo no estaba ahí, no se estaba pidiendo.
- 05Declaración de autoría y aceptación de los términos
Se aceptaba al enviar el formulario de entrega. No era un archivo aparte.
Cómo se armaba un set de datos que aguantara la rúbrica
- Realista para el sector del reto: nombres, productos, precios y fechas verosímiles. Si era un catálogo, que pareciera un catálogo de verdad.
- Con volumen. Suficientes registros para que se notara que la solución funciona. Tres filas no demuestran nada.
- Con casos difíciles a propósito: duplicados, campos vacíos, un formato raro, un caso límite. Una solución que solo funciona con datos perfectos no le sirve a ninguna empresa, y eso es justo lo que medía el criterio de aplicabilidad empresarial.
- Cien por ciento inventado. Ni un dato real de personas o empresas: ni propios, ni del empleador, ni de clientes.
- Se podía generar con Claude. Era un uso válido y parte del ejercicio, y los archivos iban dentro de la carpeta de entrega.
Qué tenía que decir un README completo
- Qué hacía la solución y qué problema del reto resolvía.
- Quién la usa, cuándo y con qué archivos.
- Qué debe revisar una persona antes de confiar en el resultado.
- Los límites declarados: en qué casos no sirve. Reconocerlos sumaba, no restaba.
- Cómo se instala y cómo se replica, paso a paso, para que otra persona pudiera repetirlo.
- La reflexión de proceso: qué se intentó primero, qué falló y cómo se corrigió.
Cómo caben tres minutos de video
Este reparto era una sugerencia de la guía, no una regla del programa. Pero con él no se pasaba del tiempo y no se quedaba por fuera nada de lo obligatorio. No hacía falta edición, ni música, ni cámara buena: bastaba un grabador de pantalla, que se viera la pantalla y que se oyera la voz.
- 0:00 a 0:20Nombre, competencia y el problema que se resuelve, en una sola frase. Sin introducción larga.
- 0:20 a 1:00Qué es la solución y dónde vive: abrirla en pantalla. La cosa real, no una diapositiva que la describe.
- 1:00 a 2:15Ejecutarla de principio a fin con el set de datos. Que se vea entrar la información y salir el resultado.
- 2:15 a 2:45La prueba en vivo. Un dato nuevo, inventado en ese momento, y la solución respondiendo bien. Era obligatoria y la definía la ficha.
- 2:45 a 3:00En qué caso no sirve y qué debería revisar una persona antes de confiar en el resultado.
Dos notas separadas, y las reglas publicadas desde antes de empezar.
Se aplicaron igual a todas las personas y estuvieron en esta página desde antes del cierre. Una nota armaba el ranking de cada competencia; la otra definía a la persona finalista.
El ranking de cada competencia
Lo armaban los veinte retos calificables. Cada uno valía de 0 a 100 y el puntaje lo asignaba la plataforma según su dificultad real, es decir según cuánta gente lo pasaba: un reto que muchos superaban otorgaba poco, uno que casi nadie lograba otorgaba mucho, y uno que nadie pasaba otorgaba los 100. La suma de los veinte ordenaba la competencia.
La persona finalista
La definía el reto tipo Claude, calificado después del cierre con la rúbrica de 100 puntos sobre la entrega y, de manera central, sobre el registro del entorno oficial. Cada criterio se calificaba en cuatro niveles, y quien evaluaba tenía que citar el descriptor aplicado y aportar evidencia concreta. Entre quienes lideraban el ranking, esta nota decidía.
Antes de calificar: pasa o no pasa
El filtro de completitud eran seis casillas. Si faltaba una, la persona recibía una comunicación diciendo exactamente qué faltó, pero la entrega no entraba a rúbrica.
- El enlace de la carpeta abría sin pedir permisos.
- Existía un README que explicaba el producto en términos ejecutivos.
- Existía el video demo de máximo tres minutos, accesible.
- Había registro de proceso en el entorno oficial, asociado a la credencial de esa persona.
- Estaban los entregables obligatorios de la ficha del reto.
- La declaración de autoría estaba aceptada.
La rúbrica del reto tipo Claude, 100 puntos
| 30 % | Resolvía el problema realCumplía los requisitos de la ficha y el video demostraba la solución funcionando de punta a punta. |
|---|---|
| 25 % | Uso de las capacidades de ClaudeProfundidad y pertinencia: proyecto bien estructurado, skill reutilizable, artefacto funcional, conectores justificados. |
| 20 % | Aplicabilidad empresarialQue una empresa real pudiera adoptarla: quién la usa, cuándo, con qué archivos, qué revisa la persona. Con los límites declarados. |
| 15 % | Documentación y reproducibilidadREADME completo, solución replicable siguiendo los pasos, proceso trazable y coherente, video claro. |
| 10 % | Creatividad y milla extraAporte que iba más allá de lo exigido y agregaba valor real. |
Las penalizaciones
| Falta | Penalización |
|---|---|
| El video excedía los tres minutos (había tolerancia de 15 segundos) | Menos 5 puntos |
| El video no incluía la prueba en vivo definida en la ficha | Menos 10 puntos y revisión humana |
| Contenido genérico: la solución no usaba datos creados por el propio participante | Menos 10 puntos |
| Datos personales reales de terceros en la entrega | Menos 10 puntos y revisión humana |
| Indicios de que el video no correspondía a la solución entregada | Revisión humana obligatoria |
Uso de IA en la evaluación, y revisión humana
El reto tipo Claude lo calificó un sistema de IA aplicando la rúbrica publicada. Ninguna decisión final fue automatizada: toda persona ganadora pasó por ronda comparativa, revisión humana de la dirección del programa y ratificación del jurado con acta, y una de cada diez calificaciones se recalificó de forma independiente. Los empates se resolvían primero a favor de quien hubiera pasado un reto antes y, si persistían, de quien tuviera mayor calificación en el reto tipo Claude.
Los resultados no se publican
Aquí no hay puntajes ni posiciones. Las personas se identifican por su correo y el registro de la verificación quedó marcado como de uso interno del programa. Cada participante recibió su propia calificación y su retroalimentación por escrito.
Qué quedó registrado mientras la gente construía.
La Maratón corría a través de un entorno oficial que registraba el proceso de construcción. Esto es exactamente qué se guardó, para qué se usó y para qué no. Está declarado en los términos, no en letra chiquita.
| Qué se registraba | Las instrucciones enviadas, las respuestas recibidas, el modelo empleado, la marca de tiempo y el volumen de uso. Solo dentro del entorno oficial, solo durante la Maratón y solo asociado a la credencial de cada persona. Lo que cada quien hiciera en Claude por fuera de ahí no se registró, ni antes ni después. |
|---|---|
| Para qué se usó | Para evaluar el proceso de construcción con la rúbrica publicada, verificar que la solución la construyó esa persona durante la Maratón y atender reclamaciones. Lo consultaba únicamente el equipo del programa, en ejercicio de sus funciones de evaluación. |
| Para qué no se usó | No se usó con fines comerciales, no se compartió con las empresas madrinas ni con terceros, y no se empleó para entrenar modelos. |
| Cuánto se conserva | Como máximo seis meses desde que terminó el programa. Después se suprime. |
| Las credenciales de Claude | El entorno no almacenaba las credenciales de la cuenta de Claude de cada persona: se transmitían al proveedor solo para autenticar la solicitud y no quedaban registradas. |
| Quién tenía el control | El participante. El entorno se podía deshabilitar en cualquier momento cerrando la ventana donde se había habilitado. |
La obligación que tenía cada participante. Como todo se trabajaba sobre datos sintéticos, nadie debía introducir en el entorno oficial información personal real de terceros, información confidencial de su empleador, ni ningún dato que no quisiera que quedara registrado.
El tratamiento de datos personales se hizo conforme a la Ley 1581 de 2012, con SMT IT S.A.S. como responsable. Política de tratamiento de datos.
Cómo se jugó, de la primera noche al Demo Day.
Nueve hitos, del lanzamiento a la retroalimentación. Tres de ellos decidían quién seguía: el cierre de entregas, la verificación individual y el Demo Day, y están marcados sobre la línea.
- Jueves 30 de julio, 9:00 p.m.
Se lanzaron los seis retos
Al cerrar la cuarta noche del bootcamp de Claude. Desde ese momento las seis competencias quedaron abiertas en la plataforma, con su ficha adentro.
- Los cuatro días siguientes
Cada persona construyó su solución
Dentro del entorno oficial, con su credencial personal, y sobre el set de datos que ella misma inventó.
- Lunes 3 de agosto, 11:59 a.m. — al mediodía, hora de Colombia
Cerraron las entregas
A esa hora se registró el estado de todas las carpetas. Lo que se modificó después no contó para la calificación.
- Martes 4 de agosto, 6:00 a.m. – 6:00 p.m.
Verificación individual
Veinte retos por competencia en la plataforma: diez de selección múltiple, cinco de selección única y cinco de respuesta abierta. Todo en español, sin preguntas de programación y a libro abierto sobre el propio trabajo. Quien no la presentó no podía ser finalista.
- Entre la verificación y la notificación
Calificación del reto tipo Claude
La rúbrica aplicada sobre la entrega y sobre el registro del entorno, una ronda comparativa y revisión humana de la dirección del programa.
- Miércoles 5 de agosto, 6:00 p.m.
Se notificó a las personas ganadoras
Después de la ratificación del jurado, con acta.
- Jueves 6 de agosto, 8:00 a.m.
Demo Day, en Ruta N, Medellín
Las seis personas ganadoras presentaron ocho minutos, más cuatro de preguntas de su empresa madrina. Panel, premiación y networking.
- Semana del 10 de agosto
Retroalimentación escrita
A todas las personas participantes, hubieran ganado o no, junto con el certificado de participación.
- Las 48 horas siguientes a la notificación
Ventana de reclamaciones
Solo por aspectos administrativos del proceso, con respuesta en máximo 72 horas. Ya cerró.
Usar Claude era el objeto del programa. Lo que se penalizaba era entregar lo que no construiste.
Qué se valía
- Usar Claude. Era el objeto del programa: nadie penalizaba usarlo bien.
- Buscar en internet, usar documentación y las plantillas del bootcamp.
- Usar herramientas complementarias.
- Adaptar ideas públicas a la propia solución.
- Competir en varias competencias, con una solución distinta en cada una.
- Consultar su propia entrega y su propio proyecto durante la verificación. Era legítimo y esperado.
Qué no se valía
- Entregar el trabajo de otra persona.
- Usar datos reales de personas o empresas. Todo iba sobre el set sintético que construía cada participante.
- Presentar una misma solución a dos competencias distintas.
- Que el video no correspondiera a la solución entregada.
- Trabajar con una credencial que no fuera la propia.
- Participar siendo del equipo del programa, de Ruta N, del jurado o familiar de un jurado hasta segundo grado de consanguinidad.
Durante la verificación individual la plataforma registró tiempo total, tiempo por pregunta y número de cambios de pestaña, únicamente para detectar comportamientos atípicos y nunca para generar por sí sola una sanción. Los intentos con similitud anómala entre sí, o con señales atípicas en la telemetría, pasaban a revisión humana y podían dar lugar a la anulación de la verificación.
Qué se llevó cada quien
- Primer puesto de cada competencia
- Presentó su solución en el Demo Day ante las empresas madrinas de su competencia, con espacio de networking directo. Certificado de ganador o ganadora, reconocimiento público en los canales de Ruta N y Smart4AI, y visibilidad de su perfil ante las empresas asistentes.
- Segundo y tercer puesto
- Mención de honor de la Maratón de IA y reconocimiento público en los canales de Ruta N y Smart4AI.
- Todas las personas participantes
- Certificado de participación y retroalimentación escrita sobre su entrega.
La solución siguió siendo de quien la construyó. Los derechos morales y patrimoniales pertenecen a quien la desarrolló; las entidades organizadoras no adquirieron titularidad alguna.
Si una empresa madrina quería adoptarla o contratar su desarrollo, negociaba directamente con esa persona: la organización no intermedia ni percibe contraprestación por esa conexión. Ese era el objetivo del Demo Day. Al participar se autorizaba exhibir la solución con crédito a su autoría y el uso de la imagen en las piezas de comunicación del programa.
Lo que la gente sigue preguntando de este programa.
Las dudas del soporte en vivo salieron de aquí cuando la Maratón cerró. Quedan las que siguen teniendo respuesta, y las palabras del programa que no significan nada por fuera de él.
¿Quién armaba el set de datos con el que trabajaba cada solución?
Cada participante, y armarlo bien era parte del reto. No había un paquete de archivos para descargar: la ficha describía el problema y cada persona inventaba los datos que ese problema necesitaba. Tenían que ser sintéticos, es decir inventados y realistas, y nunca datos reales de personas ni de empresas. Ninguna empresa madrina entregó información real.
¿Había una plantilla para el README?
No, y no había secciones obligatorias que rellenar. Lo que se pedía era un README con la introducción al desarrollo del producto, que lo explicara en términos ejecutivos: qué hacía, qué problema del reto resolvía, quién lo usa y con qué archivos, qué debe revisar una persona antes de confiar en el resultado, los límites declarados, cómo se instala y se replica, y una reflexión breve del proceso. Esos son los puntos por los que preguntaban los criterios de documentación y aplicabilidad empresarial, que entre los dos pesaban 35 de los 100 puntos.
¿Se podía competir en más de una competencia?
Sí, en una o en varias. Pero cada competencia se resolvía por separado y se evaluaba de forma independiente: solución distinta, carpeta distinta, video distinto y un formulario de entrega por cada una. Una misma solución no se podía presentar a dos competencias. Y como las seis tenían la misma dificultad y la misma carga de trabajo, entrar a varias multiplicaba el trabajo en vez de repartirlo.
¿Por qué era obligatorio construir con Claude Code dentro del entorno oficial?
Porque cuando una IA construye, mirar solo el resultado ya no distingue a nadie: había que poder mirar el proceso. El entorno oficial era un intermediario técnico entre Claude Code y Anthropic, con una credencial personal que identificaba el trabajo de cada quien, y ahí quedaba registrado cómo se construyó. Claude en la web y Claude Cowork no permiten ese registro, así que el trabajo hecho ahí no se podía calificar.
¿Había que pagar algo para participar?
La Maratón no tenía costo de inscripción y el bootcamp fue gratuito. El entorno oficial sí requería una suscripción de pago de Claude: la versión gratuita no permite la configuración necesaria y sus límites se agotan rápido construyendo algo de ese tamaño. Ese pago iba a Anthropic, por cuenta de cada participante. No era un requisito de la organización sino una limitación del servicio, y se dijo de frente desde el principio.
¿Una inteligencia artificial calificaba los trabajos?
La calificación de los veinte retos era automática y se basaba en la dificultad real de cada uno, idéntica para todas las personas. La del reto tipo Claude la hizo un sistema de inteligencia artificial aplicando la rúbrica publicada sobre el registro del entorno oficial, la misma tecnología que se enseñó en el bootcamp. Pero ninguna decisión final fue automatizada: toda persona ganadora pasó por ronda comparativa, revisión humana de la dirección del programa y ratificación del jurado con acta, y una de cada diez calificaciones se recalificó de forma independiente. El sistema se sometió a una prueba de consistencia documentada antes de usarse.
¿La solución dejaba de ser de quien la construyó?
No. Los derechos morales y patrimoniales pertenecen a quien la desarrolló y las entidades organizadoras no adquirieron titularidad alguna. Al participar se autorizaba exhibirla con crédito a su autoría en el Demo Day, en redes y en las piezas del programa. Si una empresa madrina quería adoptarla o contratar su desarrollo, negociaba directamente con esa persona: la organización no intermedia ni percibe contraprestación por esa conexión. Ese era justamente el objetivo del Demo Day.
¿Se podía participar en equipo?
No. La Maratón era de participación individual y cada persona respondía por su propia solución.
¿Se publican los resultados o el ranking?
No. Las personas se identifican por su correo y el registro de la verificación quedó marcado como de uso interno del programa, así que no se publica ningún puntaje ni ninguna posición. Cada participante recibió su propia calificación y su retroalimentación escrita.
¿Se puede repetir el ejercicio hoy?
Sí, y para eso sigue publicado todo esto. Los seis retos están abiertos con su detalle completo, y las cuatro noches del bootcamp con las que la gente se preparó siguen grabadas y sin registro. Lo único que ya no existe es el entorno oficial con su credencial: hoy el ejercicio se hace con tu propia cuenta, inventando tú el set de datos, que era la parte difícil de verdad.
Las palabras del programa
- Ficha del reto
- El documento, dentro de cada competencia, que decía exactamente qué construir y qué entregar. Describía el problema; no entregaba los datos.
- Set de datos sintéticos
- Los archivos con los que trabajaba cada solución: catálogos, precios, clientes, correos, hojas de cálculo. Sintéticos quiere decir inventados, realistas pero falsos, y los construía cada participante.
- Reto tipo Claude
- La solución en sí. Había uno por competencia y era lo que se calificaba con la rúbrica de 100 puntos.
- Los veinte retos calificables
- Las preguntas sobre lo construido y lo aprendido, que se respondían el día de la verificación individual y armaban el ranking de cada competencia.
- Entorno oficial, o el proxy
- El intermediario técnico entre Claude Code y Anthropic, con una credencial personal por participante. Existía para que quedara registro de cómo se construyó.
- Prueba en vivo
- El momento del video en el que se ejecutaba una acción frente a cámara con un dato inventado ahí mismo. Servía para demostrar que la solución funcionaba de verdad.
La Maratón terminó. El ejercicio se puede repetir cuando quieras.
Todo lo que hacía difícil este programa sigue disponible: los seis problemas, la rúbrica con la que se midieron y las cuatro noches en las que se enseñó el método. Lo único que ya no existe es el entorno oficial con su credencial. Elige por dónde seguir.
- empieza gratisLas cuatro noches del bootcamp
Las sesiones con las que se preparó la gente que compitió, grabadas y abiertas, sin registro. Ahí está el método completo, en público.
Ver las sesionesLos seis retos, por dentro - para tu equipoSmart Ranks
La verificación de competencia en IA aplicada que se usó aquí: quién sabe usar la IA de verdad, sobre sus propias tareas y en español.
Conocer Smart Ranks - el método completoEl curso de Claude
Seis niveles, de dominar Claude a publicar y vender un producto propio, con sesiones en vivo cada 15 días durante 9 meses.
Ver el curso
Quién organizó. Convocó la Corporación Ruta N, que además puso la sede del Demo Day. Operó SMT IT S.A.S. (NIT 901.466.967-5): diseño de contenidos y retos, formación, plataforma de evaluación, calificación y logística. La totalidad del programa la aportó Smart4AI sin costo para Ruta N ni para las personas participantes. La dirección del programa y la formación estuvieron a cargo de Santiago Vélez.
Conflicto de interés. No podían participar ni recibir reconocimiento las personas empleadas o contratistas de SMT IT S.A.S. o de la Corporación Ruta N, el equipo del programa, las personas integrantes del jurado ni sus familiares hasta el segundo grado de consanguinidad.
Reclamaciones. Hubo una ventana de 48 horas después de la notificación de resultados, solo por aspectos administrativos del proceso, con respuesta en máximo 72 horas. Esa ventana ya cerró.
Esta página resume los Términos y condiciones del Bootcamp IA de Claude, Maratón de IA y Demo Day, versión 3.0 del 30 de julio de 2026. En caso de diferencia, manda el documento oficial. Tratamiento de datos personales conforme a la Ley 1581 de 2012, responsable SMT IT S.A.S. Preguntas sobre el programa y ejercicio de derechos: info@smart4ai.io. Política de tratamiento de datos.