Construí un segundo cerebro que escribe mis PRs por mí

Construí un segundo cerebro que escribe mis PRs por mí

El jueves pasado publiqué una funcionalidad que tocaba 14 archivos en tres servicios. La descripción del PR eran dos párrafos de contexto limpio y específico. La actualización de estado para mi equipo ya estaba redactada en Slack antes de que terminara mi café. Las notas de traspaso para el siguiente ingeniero estaban en un archivo markdown, perfectamente estructuradas, listas para compartir.

No escribí nada de eso.

Ni una sola palabra. Y antes de que asumas que estoy usando algún sistema de plantillas sofisticado o copiando de ChatGPT — no. Mi configuración de Claude Code escribió todo porque ya sabía lo que había estado construyendo, por qué había tomado ciertas decisiones arquitectónicas, qué trade-offs había considerado, y qué necesitaría entender la siguiente persona que retomara esto. Sabía todo esto porque había pasado los últimos seis meses enseñándole — no mediante prompts elaborados, sino mediante actualizaciones de 30 segundos al final de cada sesión de trabajo.

Lo llamo mi segundo cerebro. Suena dramático hasta que lo ves generar una descripción de PR mejor que cualquier cosa que yo escribiría manualmente, haciendo referencia a decisiones que tomé hace tres semanas y que ya había olvidado. La brecha entre "IA que ayuda con código" e "IA que maneja la carga cognitiva de ser ingeniero" es enorme — y la mayoría de los desarrolladores están atrapados en el lado equivocado.

Lo que nadie comenta cuando hablan maravillas de las herramientas de IA para programar es esto: escribir código es quizás el 40% de lo que los ingenieros realmente hacen. El otro 60% es comunicación. Actualizaciones de estado. Descripciones de PRs. Documentación. Notas de traspaso. Informes de incidentes. Registros de decisiones arquitectónicas. Toda esa escritura requiere contexto — contexto profundo, específico y actualizado sobre lo que estás construyendo y por qué. Y ahí es exactamente donde todas las herramientas de IA que probé antes de Claude Code se desmoronaron por completo.

Déjame mostrarte cómo lo solucioné. Pero primero, necesito explicar por qué las soluciones obvias no funcionan — porque desperdicié meses en ellas antes de encontrar lo que sí funciona.

Por qué lanzarle IA a las tareas de escritura no funciona (al principio)

Fui un adoptante temprano del uso de IA para la comunicación en ingeniería. En cuanto ChatGPT pudo mantener una conversación sobre código, empecé a pegar diffs y pedir descripciones de PRs. Los resultados eran... aceptables. Genéricos, mayormente precisos, pero sin cada pieza de contexto que hace que una descripción de PR sea realmente útil.

El problema es estructural, no es un tema de calidad de la IA. Cuando pegas un diff en cualquier chatbot, puede ver qué cambió. No puede ver por qué cambió. No sabe que refactorizaste el middleware de autenticación porque la auditoría de seguridad del mes pasado marcó una vulnerabilidad de fijación de sesión. No sabe que elegiste Redis en vez de Memcached porque el equipo ya usa Redis para la cola de trabajos. No sabe que este PR es la parte tres de una migración de cinco partes que comenzó hace dos sprints.

Entonces, ¿qué haces? Explicas el contexto. Cada vez. Escribes tres párrafos de antecedentes, pegas el diff, y entonces la IA te da una descripción de PR razonable. Felicidades — acabas de gastar cinco minutos proporcionando contexto para ahorrarte tres minutos de escritura. Ahorro neto: menos dos minutos. Más la carga cognitiva de cambiar de contexto del código a "explícale todo mi proyecto a un chatbot".

Intenté construir plantillas de prompts. "Dado que este proyecto usa Laravel 11 con Redis caching y Postgres..." — bloques de contexto pre-rellenados que pegaba antes de cada solicitud. Ayudó un poco. Pero el contexto se volvía obsoleto en días. Los proyectos evolucionan rápido. Lo que era cierto el lunes ya no lo es el jueves. Mantener esas plantillas se convirtió en una tarea más.

Después probé herramientas de IA con memoria incorporada. La función de memoria de ChatGPT, específicamente. Recordaba que prefiero TypeScript y trabajo en aplicaciones web. Increíblemente superficial. Es como contratar a un asistente que recuerda tu nombre pero olvida cada conversación de proyecto que hayas tenido.

El problema fundamental de todos estos enfoques: el contexto vive en tu cabeza, no en el sistema. Cada vez que quieres que la IA haga algo útil, tienes que extraer el contexto relevante de tu cerebro, formatearlo para la IA y verificar el resultado. Ese paso de extracción es el cuello de botella, y ninguna cantidad de ingeniería de prompts lo elimina.

Lo que sí lo elimina es darle a la IA su propia base de conocimiento persistente, local y continuamente actualizada. Un segundo cerebro que mantiene a tu lado mientras trabajas. Eso es lo que construí accidentalmente con Claude Code — y cambió toda mi relación con la comunicación en ingeniería.

Cómo funciona realmente el sistema de contexto local de Claude Code

Hace seis meses, me cambié a Claude Code principalmente como agente de programación. Es genuinamente excelente escribiendo y refactorizando código — pero eso no fue lo que me enganchó. Lo que me enganchó fue descubrir que mantiene contexto local y persistente a través de archivos markdown que viven directamente en el directorio de tu proyecto.

El mecanismo es simple. Claude Code lee y escribe archivos markdown — típicamente CLAUDE.md en la raíz de tu proyecto y archivos de contexto adicionales que tú creas. Estos archivos persisten entre sesiones. No desaparecen cuando cierras tu terminal. No se pierden en alguna nube. Se quedan en tu repositorio, versionados junto a tu código, enriqueciéndose con cada sesión de trabajo.

Así es como se ve mi archivo de contexto de proyecto después de seis meses de conocimiento acumulado:

# Project Context

## Architecture
- Laravel 11 monolith with Vue 3 SPA frontend
- PostgreSQL primary DB, Redis for caching and queues
- Deployed on AWS ECS with Terraform-managed infrastructure
- Auth: Custom JWT implementation (migrated from Sanctum in Sprint 14)

## Current Sprint (Sprint 22)
- Payment processing refactor: Stripe → multi-provider abstraction
- Migrating webhook handlers from sync to async queue processing
- Performance: targeting p99 < 200ms on checkout flow

## Recent Decisions
- Chose adapter pattern over strategy for payment providers (2024-01-15)
  - Reason: Need runtime provider switching per merchant config
- Rejected event sourcing for payment state (too complex for current scale)
- Redis cluster mode enabled for horizontal scaling prep

## Known Tech Debt
- Legacy order model still uses soft deletes (migration planned Sprint 24)
- Test coverage on payment module: 67% (target: 85% before launch)

Ese archivo no apareció por arte de magia. Lo construí con el tiempo, 30 segundos a la vez. Al final de cada sesión de trabajo, le digo a Claude Code: "Actualiza el contexto del proyecto con lo que trabajamos hoy." Revisa la sesión — los archivos que cambiamos, las decisiones que discutimos, los problemas que resolvimos — y agrega actualizaciones relevantes al archivo de contexto.

Treinta segundos. Esa es la inversión. Y el retorno se multiplica enormemente.

Porque la próxima vez que me siento y le pido a Claude Code que escriba una descripción de PR, no necesita que le explique nada. Lee el archivo de contexto, ve los objetivos del sprint actual, entiende las decisiones arquitectónicas, conoce los cambios recientes, y genera una descripción que parece escrita por alguien que lleva meses en el proyecto.

La diferencia es abismal. Compara estas dos descripciones de PR — una de una interacción fría con IA, otra de mi segundo cerebro:

IA fría (diff pegado, sin contexto):

"Este PR actualiza el módulo de procesamiento de pagos. Los cambios incluyen modificaciones a la clase PaymentService, adición de nuevas interfaces de proveedor y actualizaciones en las pruebas relacionadas."

Segundo cerebro (con contexto acumulado):

"Implementa la capa de adaptadores para la abstracción multi-proveedor de pagos (Sprint 22). Introduce la interfaz PaymentProviderAdapter con Stripe como primera implementación concreta. Los manejadores de webhooks permanecen síncronos en este PR — la migración asíncrona viene en el siguiente PR según nuestro enfoque queue-first. La configuración de proveedor a nivel de merchant lee de la tabla de settings existente con una nueva columna payment_provider (migración incluida)."

Mismo diff. Mismo modelo de IA. La única diferencia es el contexto — contexto persistente, acumulado y local que no tuve que volver a explicar.

Esto cambia completamente cómo interactúo con la IA para tareas de ingeniería. Y está a punto de volverse aún más poderoso cuando agregas skills a la ecuación.

Construyendo tu segundo cerebro — El ritual de 30 segundos que lo cambia todo

Bien, déjame guiarte exactamente por cómo configuré esto, porque la implementación es vergonzosamente simple. El valor no está en la complejidad — está en la consistencia.

Paso 1: Crea tu archivo de contexto inicial.

Al inicio de cualquier proyecto (o ahora mismo, para proyectos existentes), dedica 10 minutos a que Claude Code construya tu contexto base. Abre tu terminal en la raíz del proyecto y di:

"Mira la estructura del código, el historial reciente de git y cualquier documentación existente. Crea un archivo CLAUDE.md resumiendo la arquitectura del proyecto, el stack tecnológico, las áreas de enfoque actuales y cualquier patrón que puedas identificar."

Claude Code escaneará tu proyecto, leerá archivos clave, revisará los logs de git y generará un documento de contexto completo. Revísalo, corrige lo que haya quedado mal, y ya tienes tu base.

Paso 2: La actualización de fin de sesión (30 segundos).

Este es el hábito que hace funcionar el sistema. Al final de cada sesión de trabajo — antes de cerrar tu terminal — di:

"Actualiza el contexto del proyecto con lo que trabajamos hoy."

Eso es todo. Claude Code revisa la sesión, identifica lo que vale la pena recordar y actualiza el archivo de contexto. Las nuevas decisiones se registran. Las tareas completadas se marcan. La deuda técnica se anota. El archivo de contexto crece, pero se mantiene enfocado porque Claude Code es bueno distinguiendo entre "conocimiento importante del proyecto" y "detalles temporales de depuración".

Paso 3: Condensación periódica.

Cada pocas semanas, el archivo de contexto se alarga. Cuando eso pasa, le pido a Claude Code que lo condense: "El archivo de contexto se está haciendo grande. Consolídalo — conserva todo lo que siga siendo relevante, archiva o elimina lo que esté desactualizado."

Esto mantiene el archivo compacto y rápido de procesar. Mi archivo de contexto actual tiene unas 400 líneas para un proyecto en el que llevo trabajando seis meses. Eso es eficiente. Y cada línea es relevante.

Consejo profesional: Mantengo un archivo decisions.md separado para decisiones arquitectónicas que quiero preservar a largo plazo, incluso si ya no son activamente relevantes para el sprint actual. Esto es oro para incorporar nuevos miembros al equipo o recordar por qué elegiste un enfoque específico seis meses después.

El ritual suena trivial. Treinta segundos al final de una sesión. Pero piensa en lo que pasa después de un mes. Tienes más de 20 actualizaciones acumuladas. La IA conoce tus patrones de programación, tus preferencias arquitectónicas, la evolución de tu proyecto, los trade-offs que has considerado y rechazado. No solo sabe qué hace el código — sabe por qué lo construiste así.

Eso no es un chatbot. Es una memoria institucional que nunca olvida, nunca se va de vacaciones y nunca necesita una reunión de repaso.

Ahora viene la parte realmente emocionante — porque una vez que tienes contexto rico, puedes construir flujos de trabajo que serían imposibles sin él.

Skills: Enseñándole a tu IA a repetir tu mejor trabajo

Un skill en Claude Code es esencialmente un flujo de trabajo guardado y repetible. Piensa en él como una macro, pero inteligente — se adapta al contexto actual en lugar de repetir pasos ciegamente.

El concepto es elegantemente simple: haces una tarea una vez con Claude Code, y al final dices "Convierte esto en un skill." Claude Code examina lo que hiciste — la secuencia de pasos, las decisiones que tomaste, el formato del resultado — y lo guarda como un flujo de trabajo reutilizable. La próxima vez que necesites hacer el mismo tipo de tarea, activas el skill y se encarga de todo.

Creando tu primer skill — descripciones de PR automatizadas:

Este fue mi primer skill, y sigue siendo el que más uso. Así lo construí:

1. Guié manualmente a Claude Code para escribir una descripción de PR para un cambio real que había hecho.
2. Durante el proceso, corregí su salida: "No, no solo listes los archivos cambiados — explica el por qué detrás de cada grupo de cambios."
3. Ajusté el formato: "Usa esta estructura: Resumen, Motivación, Cambios, Notas de Testing, Elementos de Seguimiento."
4. Cuando la salida coincidió con lo que yo enviaría, dije: "Guarda esto como un skill llamado 'pr-description'. Cada vez que pida una descripción de PR, sigue exactamente este enfoque."

Ahora, después de hacer commit del código, activo el skill. Lee el diff, lo cruza con el contexto del proyecto y genera una descripción de PR en mi formato preferido. El resultado es consistentemente mejor que lo que yo escribiría manualmente — porque nunca olvida incluir notas de testing o elementos de seguimiento, y siempre tiene disponible el contexto completo del proyecto.

El skill que me salvó durante una guardia: investigación de SEV.

Este me sorprendió por lo poderoso que se volvió. Creé un skill que, dado un branch de release o una marca de tiempo de despliegue, hace lo siguiente:

1. Extrae el git log para ese período
2. Identifica todos los commits incluidos en el release
3. Los cruza con el contexto del proyecto para entender qué se suponía que hacía cada cambio
4. Genera una lista clasificada de "teorías" — posibles causas raíz del problema que activó la alerta

Durante un incidente en producción a las 2 AM el mes pasado, activé este skill en lugar de desplazarme manualmente por los logs de commits con los ojos entrecerrados. En unos 40 segundos, me dio tres teorías clasificadas por probabilidad. La segunda teoría era correcta — una condición de carrera en el manejador de webhooks que habíamos refactorizado la semana anterior. Sin el skill, esa investigación me habría tomado 20-30 minutos de revisión manual de logs y reconstrucción mental de contexto. A las 2 AM. Medio dormido.

División de PRs — el skill que no sabía que necesitaba:

Los PRs grandes son asesinos de revisiones. Todo ingeniero experimentado sabe que un PR de 500 líneas recibe mejor atención en la revisión cuando se divide en tres PRs enfocados de 150-200 líneas cada uno. Pero realmente dividir un diff grande en porciones lógicas e independientemente revisables... eso es trabajo tedioso.

Construí un skill que analiza un diff grande y sugiere cómo dividirlo. Considera:

• Agrupaciones lógicas (todos los cambios de migración de base de datos juntos, todos los cambios de endpoints API juntos)
• Orden de dependencias (qué cambios necesitan mergearse primero)
• Mi preferencia personal de tamaño de PR (me gustan 200-300 líneas máximo)

El skill no solo sugiere la división — genera los comandos de git para crear cada PR con los commits correctos. Reviso la división propuesta, ajusto si es necesario y ejecuto. Lo que antes tomaba 30 minutos de trabajo manual cuidadoso ahora toma unos 3 minutos.

Automatización de actualizaciones de estado — el que le encanta a mi jefe:

Al final del día, activo un skill que revisa mi actividad en git, los issues que he actualizado y el contexto del proyecto, luego genera una actualización de estado en el formato que usa mi equipo. Tres puntos: qué hice hoy, algún bloqueante, qué planeo hacer mañana. Mi jefe comentó específicamente que mis actualizaciones han sido "muy claras últimamente." No tiene idea de que una IA las está escribiendo.

Aquí está la idea crítica sobre los skills que la mayoría de la gente pasa por alto: los skills mejoran conforme tu contexto se enriquece. Un skill de descripción de PR ejecutándose con una semana de contexto produce un resultado decente. El mismo skill con seis meses de contexto produce un resultado que genuinamente entiende la historia y la trayectoria del proyecto. El segundo cerebro y el sistema de skills se alimentan mutuamente en un ciclo virtuoso.

La parte sobre ingeniería de prompts que está mayormente equivocada

Necesito contradecir algo que el espacio de productividad con IA entiende peligrosamente mal. Todos están obsesionados con la ingeniería de prompts. "Usa esta plantilla de prompt mágica." "Aquí está el system prompt perfecto para revisión de código." "Agrega estas 47 instrucciones para mejores resultados."

Mira, la calidad de los prompts importa. No digo que no. Pero la obsesión con los prompts distrae del verdadero cuello de botella: la calidad del contexto.

Un prompt mediocre con contexto excelente produce resultados geniales. Un prompt perfecto sin contexto produce basura genérica. Lo he probado extensamente. Mi skill de descripción de PR usa un prompt notablemente simple — básicamente "escribe una descripción de PR para este diff usando el contexto del proyecto." Sin instrucciones elaboradas, sin directivas de role-playing, sin ejemplos multi-shot. El resultado es excelente porque el contexto es excelente.

Piénsalo desde la perspectiva de incorporar a un ingeniero junior. Si contratases a alguien nuevo y preguntara: "¿Puedes explicarme la arquitectura del proyecto, los objetivos del sprint actual, las decisiones recientes y por qué elegimos estas tecnologías específicas?" — pasarías una hora poniéndolo al día. Pero después de esa inversión única, sería capaz de escribir descripciones de PR, actualizaciones de estado y documentación competentes por su cuenta. No porque le enseñaste cómo escribir — sino porque le diste el contexto para escribir bien.

Tu segundo cerebro de IA funciona de la misma manera. La inversión única es construir el contexto. Después de eso, es solo mantenimiento de 30 segundos. Los prompts son casi irrelevantes porque la parte difícil — tener conocimiento profundo, actual y específico del proyecto — ya está resuelta.

Este reencuadre cambió cómo abordo cada flujo de trabajo con IA. En lugar de gastar tiempo elaborando prompts sofisticados, invierto tiempo gestionando contexto. En lugar de buscar las instrucciones perfectas, me aseguro de que la base de conocimiento esté fresca. Los resultados son incomparablemente mejores.

Pero seré honesto en una cosa — hay una trampa en todo este enfoque que pasé por alto hasta ahora.

Lo que hice mal y lo que todavía me frustra

El archivo de contexto puede mentirte. Si actualizas tu contexto después de una sesión donde exploraste un enfoque pero finalmente lo abandonaste, podrías registrar accidentalmente ese enfoque abandonado como una decisión. He tenido a Claude Code generando descripciones de PR que hacían referencia a decisiones arquitectónicas que había considerado pero no implementado. La solución es revisar las actualizaciones de contexto antes de aceptarlas, cosa que a veces me salto cuando voy con prisa. La disciplina importa aquí.

Los skills no son "configúralo y olvídate". Mi skill de descripción de PR ha sido modificado siete veces desde que lo creé. Cada vez, noté un patrón en la salida que no me gustaba — demasiado verboso, sin notas de cobertura de tests, tono equivocado para PRs internos vs. open-source. Construir el skill inicial toma una sesión. Refinarlo para que coincida con tus estándares requiere iteración continua. No es mucho esfuerzo, pero más que cero.

Esto solo funciona si realmente lo usas de forma consistente. Me fui dos semanas de vacaciones y volví a un archivo de contexto obsoleto. La primera descripción de PR que generó después de mi regreso se basaba en objetivos de sprint desactualizados y tareas ya completadas. Me tomó unos 10 minutos actualizar el contexto y poner todo al día. No terrible, pero me recordó que el sistema requiere alimentación regular.

La adopción en equipo es más difícil que la adopción personal. He intentado que mi equipo mantenga archivos de contexto compartidos. Los resultados son mixtos. La gente que ya toma notas se adapta rápidamente. La gente que no toma notas lo ve como overhead extra, incluso cuando son solo 30 segundos. Sigo trabajando en esto — quizás necesita ser más automatizado, quizás necesita plantearse de forma diferente. Pregunta abierta.

El problema más difícil que aún no he resuelto: contexto entre múltiples proyectos. Mi segundo cerebro funciona de maravilla dentro de un solo proyecto. Pero trabajo en tres proyectos simultáneamente, y el contexto está aislado. Cuando cambio entre proyectos, cada uno tiene un contexto local excelente — pero el conocimiento entre proyectos (como bibliotecas compartidas o patrones de infraestructura) no se transfiere. Tengo ideas para resolver esto con un archivo de contexto global, pero aún no lo he construido.

Estas son limitaciones reales. Las menciono porque cada análisis de herramientas que leo en internet hace que todo suene perfecto, y eso no es útil. Este sistema tiene asperezas. La propuesta de valor central — contexto persistente que elimina las explicaciones repetidas y permite una automatización poderosa — es genuina y significativa. Pero requiere cuidado y alimentación para mantenerse valioso.

Lo que realmente cambió en mi flujo de trabajo como ingeniero

Los números ayudan. Esto es lo que registré durante cuatro meses de uso consistente:

Descripciones de PR: El tiempo promedio de escritura bajó de 8 minutos a menos de 1 minuto. La calidad — medida por el número de preguntas de clarificación de los revisores — mejoró aproximadamente un 60%. Los revisores hacen menos preguntas porque las descripciones generadas por IA incluyen el por qué detrás de los cambios, no solo el qué.

Actualizaciones de estado: De 5 minutos diarios a unos 30 segundos (activo el skill, reviso la salida, envío). En un mes, eso son aproximadamente 2 horas recuperadas. No cambia la vida por sí solo, pero elimina una tarea que yo activamente temía.

Investigación de incidentes: Mi skill de SEV se ha activado ocho veces. El tiempo promedio hasta la primera teoría bajó de 25 minutos de investigación manual a unos 90 segundos. Tres de esas ocho veces, la primera teoría era correcta. Las otras cinco veces, las teorías generadas al menos redujeron significativamente el espacio de búsqueda.

Documentación: Ahora documento decisiones arquitectónicas que antes no me habría molestado en redactar. El segundo cerebro las captura automáticamente durante las sesiones de trabajo, y un rápido "genera un ADR para la decisión de caché que tomamos hoy" produce un borrador en 15 segundos. La documentación de mi proyecto pasó de escasa a completa sin que yo realmente escribiera documentación.

Ahorro total estimado de tiempo: 4-6 horas por semana. No por momentos espectaculares individuales, sino por cientos de pequeños puntos de fricción eliminados. Muerte por mil cortes, revertida.

El ahorro no es solo de tiempo. Hay una reducción de carga cognitiva que es más difícil de cuantificar pero igualmente importante. Ya no cargo con el peso mental de "necesito recordar documentar por qué elegimos Redis" o "debería redactar los hallazgos del incidente antes de que se me olviden los detalles." El sistema captura todo conforme sucede. Mi cerebro queda libre para el trabajo que realmente requiere juicio humano — decisiones de arquitectura, revisión de código, resolución de problemas.

Eso se siente como el verdadero descubrimiento. No solo escritura más rápida, sino menos carga mental sobre la escritura que debería estar haciendo pero no hago.

El cambio que viene y que la mayoría de los ingenieros se van a perder

Aquí va mi predicción, y estoy dispuesto a equivocarme sobre los plazos pero no sobre la dirección: en menos de dos años, los ingenieros que mantengan sistemas de contexto potenciados por IA tendrán una ventaja de productividad medible sobre los que no. No porque sean mejores ingenieros, sino porque habrán eliminado toda una categoría de carga cognitiva.

Los ingenieros que desestiman esto como "solo hype de IA" son los mismos que desestimaron el control de versiones, CI/CD y la contenedorización. Cada una de esas tecnologías eliminó una categoría de trabajo que los ingenieros solían hacer manualmente. La gestión de contexto es la siguiente.

La parte interesante no es la automatización en sí — es lo que te libera para hacer. Cuando no estás gastando energía mental en descripciones de PRs, actualizaciones de estado y documentación, esa energía va a algún lado. En mi caso, fue a revisiones de código más profundas, discusiones de arquitectura más reflexivas y — irónicamente — mejor escritura cuando escribir realmente importaba (como este artículo).

Mi desafío para ti es específico: elige un proyecto en el que estés trabajando activamente. Dedica 10 minutos hoy a crear un archivo de contexto. Luego comprométete con la actualización de 30 segundos al final de la sesión durante dos semanas. No construyas skills todavía. No optimices nada. Solo acumula contexto.

Después de dos semanas, pídele a Claude Code que escriba una descripción de PR para tu próximo cambio. Compárala con lo que habrías escrito manualmente.

Esa comparación te va a decir todo lo que necesitas saber sobre si vale la pena invertir en este enfoque. Y apuesto — basándome en lo que me pasó a mí y a cada ingeniero al que se lo he mostrado — que no vas a querer volver atrás.

La pregunta no es si la IA manejará la comunicación en ingeniería. Es si tú construirás el sistema de contexto que la haga realmente buena, o si seguirás pegando diffs en chatbots preguntándote por qué el resultado se siente vacío.

Tu segundo cerebro está esperando a ser construido. Solo necesita 30 segundos al día.

🤝 Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• 🔗 Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
• 🌐 Portfolio: mejba.me
• 🏢 Ramlit Limited (soluciones empresariales): ramlit.com
• 🎨 ColorPark (diseño y branding): colorpark.io
• 🛡 xCyberSecurity (servicios de seguridad): xcybersecurity.io