Ingeniero de IA y arquitecto de software
Hola, soy Luke.
Llevo más de dos décadas desarrollando software, con Magento como parte de mi trabajo desde 2010. He sido desarrollador, líder técnico y arquitecto, asumiendo la responsabilidad tanto del diseño de un sistema como del trabajo necesario para llevarlo a producción.
Trabajo con productos nuevos y sistemas consolidados: convirtiendo una idea en algo que un equipo pueda construir o entrando en una base de código con años de personalizaciones para descubrir cómo mejorarla mientras el negocio sigue funcionando.
Sigo trabajando directamente con el código. Lo escribo y reviso, investigo problemas de rendimiento y resuelvo detalles de implementación con otros ingenieros. Moverme entre esos detalles y la arquitectura general es una parte importante de lo que aporto a un proyecto.
Magento y Adobe Commerce, desde 2010
El comercio ha sido una parte importante de mi carrera. A través de Act Digital, lideré la arquitectura de la plataforma B2B Adobe Commerce de Saint-Gobain Brasil. En Visualr, entré como primer especialista en Magento y trabajé como arquitecto participando directamente en la implementación de una plataforma B2B compleja. Ese trabajo incluyó reglas de precios, grandes catálogos, integraciones, rendimiento y las decisiones técnicas detrás de las entregas.
En Infobase, fui líder técnico en proyectos de Magento y Adobe Commerce para marcas como Panini, Yara y BASF, entre otras. Uno fue el comercio electrónico de Dufry, el minorista global de duty-free, entonces una de las mayores tiendas Adobe Commerce del mundo.
También he liderado desarrolladores, revisado decisiones técnicas y trabajado con equipos de negocio para convertir requisitos complicados en una implementación práctica.
Mi experiencia va desde Magento 1 hasta Magento 2 y Adobe Commerce. Módulos personalizados, inyección de dependencias, contratos de servicio, plugins, observers, APIs GraphQL y REST, indexadores y consumidores de RabbitMQ forman parte de esa trayectoria. También el checkout, los pagos, los envíos y las integraciones con ERP, donde un cambio en una parte del sistema puede tener consecuencias en otra.
Antes de añadir una personalización, analizo dónde corresponde, qué acopla y cómo se comportará durante una actualización. Eso afecta al esfuerzo que requerirá la siguiente funcionalidad.
Trabajando con código complejo
Cuando entro en una base de código desconocida, empiezo siguiendo una operación real. ¿Dónde está la regla de negocio? ¿Qué componente es responsable de los datos? ¿Qué más cambia cuando se ejecuta este código? Eso suele decirme más que la estructura de carpetas.
Ahí aplico SOLID, diseño orientado al dominio y Clean Architecture: decidiendo dónde corresponden las responsabilidades, definiendo contextos delimitados y evitando que las reglas de negocio se enreden con frameworks o proveedores externos.
Si los detalles del proveedor de pagos se extienden por un módulo de pedidos, un contrato de integración claro puede establecer un límite útil. Si un servicio aplica reglas de negocio y da formato a una página, esas responsabilidades necesitan separarse. Ninguno de esos cambios exige reconstruir la aplicación.
Mi enfoque de Clean Code y refactorización consiste en entender el comportamiento existente, protegerlo con pruebas útiles y hacer mejoras concretas. A veces requiere un adaptador o una estrategia. Otras veces significa eliminar una abstracción que no aporta nada.
Python, TypeScript y aplicaciones de IA
Python y TypeScript son centrales en el trabajo de backend y aplicaciones de IA en el que me enfoco hoy. Uso Python para flujos de IA, tratamiento de datos e integraciones de servicios, y TypeScript para servicios, APIs y flujos de producto. En ambos presto atención a los contratos, la validación en tiempo de ejecución, el trabajo asíncrono y el manejo de errores.
Con IA, empiezo decidiendo de qué debe ser responsable el modelo. ¿Qué partes necesitan comprensión o generación de lenguaje? ¿Cuáles deben seguir siendo lógica normal de la aplicación? ¿Qué puede sugerir el modelo y qué puede modificar?
Con RAG, eso implica trabajar los documentos, la división en fragmentos, las actualizaciones, los permisos de acceso y la calidad de la recuperación. Con agentes, implica definir herramientas, estado y límites de ejecución, incluido qué ocurre cuando una herramienta falla o una acción necesita confirmación.
La elección del modelo forma parte de ese trabajo. También las salidas estructuradas, el contexto, la latencia y el coste. Quiero ejemplos que podamos evaluar, trazas que podamos investigar y una forma de comparar el comportamiento cuando cambian el modelo, el prompt o la recuperación. Producir JSON válido es útil; no nos dice si el resultado es correcto.
Llevando software a producción
Mi trabajo también abarca CI/CD, despliegue y soporte en producción. He trabajado con Docker, Linux, Nginx e infraestructura de AWS, además de pruebas automatizadas, revisiones de código y pipelines de entrega.
Quiero que el camino de un cambio de código a una versión sea comprensible: qué se está construyendo, qué comprobaciones importan, cómo se gestionan la configuración y los secretos y cómo sabremos si la versión funciona bien. Los cambios de base de datos, la compatibilidad y la recuperación requieren atención antes del despliegue, no durante el incidente.
El trabajo no termina con la entrega. Con el software funcionando, quiero logs, métricas y trazas, en herramientas como New Relic, Grafana y CloudWatch, que muestren su comportamiento real: qué solicitudes son lentas, dónde se consume el tiempo entre la aplicación, la base de datos y los servicios externos y qué errores aumentan. Así los cuellos de botella dejan de ser suposiciones. La producción aporta información a la plataforma: qué optimizar, simplificar y corregir antes de que se convierta en un incidente.
Al planificar el crecimiento, analizo la carga de trabajo y los probables puntos de presión: acceso a la base de datos, caché, procesamiento en segundo plano y dependencias externas. Eso orienta qué necesita escalar de forma independiente y qué puede seguir junto. También ayuda a evitar complejidad operativa antes de que resuelva un problema real.
Los microservicios forman parte de esa decisión; no son el punto de partida. Dividir un sistema puede dar a los equipos despliegues independientes y permitir que una parte muy utilizada escale sola, pero también trae llamadas de red, fallos parciales, consistencia de datos y más cosas que observar. Prefiero módulos claros dentro de una aplicación hasta que exista un motivo real para separarlos. Cuando un servicio se justifica, su contrato, su responsabilidad y su observabilidad deben definirse desde el principio.
El proceso debe ajustarse al proyecto. Un sitio personal de publicaciones y una plataforma empresarial de comercio no necesitan la misma estructura de entrega.
Lo que estoy construyendo
Mis propios proyectos me dan un lugar para reunir esas decisiones. Lukre es un producto de finanzas conversacionales construido alrededor de WhatsApp.
También estoy experimentando con desarrollo asistido por agentes, grafos de ejecución, Gas City y Beads: cómo reciben los agentes el contexto adecuado, cómo se siguen las dependencias y cómo se verifica su trabajo antes de incorporarlo a la base de código.
Lejos del teclado
Al principio de los cuarenta, y disfrutándolos más de lo esperado. La experiencia compensa, la paciencia es mayor, la mirada para lo importante es más aguda y las ganas de vivir, de alguna manera, aumentaron en vez de disminuir. Las canas venían en el paquete. Un intercambio justo.
El nerd nunca se desconectó. Series, películas y libros ocupan buena parte de mi tiempo libre, con El Señor de los Anillos cerca del primer puesto y Star Wars justo al lado, de la vieja escuela. La historia es el otro pozo sin fondo. Dame un buen libro sobre cómo ocurrió algo de verdad y la noche se acaba.
El vino y la buena comida son una pasión seria. Una buena botella, una comida bien hecha y buena compañía hacen una noche casi perfecta, y viajar lo pone todo en la misma mesa: lugares nuevos, su cocina, sus vinos y su historia. También es el mejor recolector de basura que conozco para un cerebro que pasa la mayor parte del día dentro de sistemas.
Hoy vivo en São Francisco de Paula, en la Serra Gaúcha, al sur de Brasil: bosques de araucarias, inviernos de verdad, una niebla que convierte una mañana soleada en un misterio en unos diez minutos y bodegas al alcance de un fin de semana.
Fuera de los detalles técnicos, escribo sobre la vida como programador: concentración, inseguridad, salud mental y las cosas extrañas que nos hacen gracia después de pasar suficiente tiempo con software. Disfruto del trabajo, especialmente cuando puedo construir algo útil con personas que se preocupan por hacerlo bien y todavía pueden reírse por el camino.
Construyendo sistemas inteligentes. Sin dejar de ser humano.
