En la serie Author Spotlight, los editores de TDS conversan con miembros de nuestra comunidad sobre su trayectoria profesional en ciencia de datos e inteligencia artificial, sus escritos y sus fuentes de inspiración. Hoy estamos encantados de compartir nuestra conversación con Mike Huls.
Mike es un líder tecnológico que trabaja en la intersección de la ingeniería de datos, la inteligencia artificial y la arquitectura, ayudando a las organizaciones a convertir paisajes de datos complejos en sistemas confiables y utilizables. Con una sólida experiencia en full-stack, diseña soluciones integrales que equilibran la profundidad técnica con el valor comercial. Además del trabajo con clientes, crea y comparte herramientas prácticas y conocimientos sobre plataformas de datos, sistemas de inteligencia artificial y arquitecturas escalables.
¿Te ves como un desarrollador full-stack? ¿Cómo cambia su experiencia en toda la pila (desde el frontend hasta la base de datos) su forma de ver el rol del científico de datos?
Lo hago, pero no en el sentido de construir personalmente cada capa. Para mí, full-stack significa comprender cómo las decisiones arquitectónicas en una capa dan forma al comportamiento, el riesgo y el costo del sistema a lo largo del tiempo. Esa perspectiva es esencial al diseñar sistemas que necesitan sobrevivir al cambio.
Esta perspectiva también influye en cómo veo el papel del científico de datos. Los modelos creados en cuadernos son sólo el comienzo. El valor real surge cuando esos modelos están integrados en sistemas de producción con canalizaciones de datos, API, gobernanza e interfaces de usuario adecuadas. La ciencia de datos adquiere impacto cuando se la trata como una parte central de un sistema más grande, no como una actividad aislada.
Cubre una amplia gama de temas. ¿Cómo decides en qué centrarte a continuación y cómo sabes cuándo vale la pena explorar un tema nuevo?
Tiendo a seguir fricciones recurrentes. Cuando veo que varios equipos luchan con los mismos problemas, ya sean técnicos u organizativos, lo tomo como una señal de que el problema es estructural más que individual y que vale la pena abordarlo a nivel arquitectónico o de proceso.
También experimento deliberadamente con nuevas tecnologías, no por ser novedosas, sino para comprender sus ventajas y desventajas. Vale la pena escribir sobre un tema cuando resuelve un problema real al que me enfrento actualmente o revela riesgos que aún no se comprenden ampliamente. Finalmente, escribo sobre temas que personalmente encuentro interesantes y que vale la pena explorar, porque el interés sostenido es lo que me permite profundizar.
Ha escrito sobre LangGraph, MCP y agentes autohospedados. ¿Cuál es el mayor error que cree que tiene la gente hoy en día sobre los agentes de IA?
Los agentes son realmente poderosos y abren nuevas posibilidades. La idea errónea es que son simples. Hoy en día es fácil montar una infraestructura de nube, conectar un marco de agente y producir algo que parezca funcionar. Esa accesibilidad es valiosa, pero oculta mucha complejidad.
Una vez que los agentes van más allá de las demostraciones, surgen los verdaderos desafíos. A menudo se subestiman la gestión del estado, los permisos, el control de costos, la observabilidad y el manejo de fallas. Sin límites y propiedad claros, los agentes se vuelven impredecibles, costosos y riesgosos de operar. No son sólo indicaciones con herramientas; son sistemas de software de larga duración y deben diseñarse y operarse en consecuencia.
En su artículo sobre Arquitectura en capas, menciona que agregar funciones a menudo puede parecer una “cirugía a corazón abierto”. Para un principiante o un equipo de datos pequeño que busca evitar esto, ¿cuál es su consejo clave sobre la configuración de una arquitectura?
“La única constante es el cambio” es un cliché por una buena razón, así que optimice para el cambio en lugar de para la velocidad de entrega inicial. Incluso una forma mínima de pensamiento en capas ayuda: separar la lógica del dominio, el flujo de aplicaciones y las preocupaciones de infraestructura.
El objetivo no es la perfección arquitectónica desde el primer día ni una categorización perfecta. Se trata de crear límites claros que permitan que el sistema evolucione sin reescrituras constantes. Una pequeña disciplina inicial rinde frutos significativamente a medida que los sistemas crecen.
Ha evaluado las estrategias de inserción de PostgreSQL y ha observado que “más rápido no siempre es mejor”. En una canalización de ML de producción, ¿cuál es un escenario en el que elegiría deliberadamente un método de inserción más lento y seguro?
Cuando la corrección, la trazabilidad y la recuperabilidad importan más que el rendimiento bruto. En muchas canalizaciones, reducir el tiempo de ejecución en unos pocos segundos ofrece pocos beneficios en comparación con el riesgo que introducen garantías más débiles.
Por ejemplo, los canales que alimentan los informes regulatorios, la toma de decisiones financieras o los conjuntos de datos de capacitación de larga duración se benefician de la seguridad transaccional y la validación explícita. La corrupción silenciosa de los datos es mucho más costosa que aceptar modestas compensaciones en el desempeño, especialmente cuando los datos se convierten en un activo a largo plazo que otros aprovecharán.
En su artículo Asistentes personales y agentes, creó una plataforma autohospedada y 100% privada. ¿Por qué era más importante para usted evitar los “costos simbólicos” y las “fugas de privacidad” que utilizar un LLM más potente basado en la nube?
En mi trabajo diario he experimentado que confiar en un sistema es fundamental para su adopción. Los costos simbólicos, los flujos de datos opacos y las dependencias externas influyen sutilmente en cómo se utilizan y perciben los sistemas.
También tomé la decisión consciente de no enviar mis datos personales o confidenciales a través de proveedores de nube externos, ya que existen garantías limitadas sobre cómo se manejan los datos a lo largo del tiempo. Al mantener el sistema autohospedado, podría diseñar un asistente que sea predecible, auditable y alineado con las expectativas de privacidad europeas. Los usuarios tienen control total sobre a qué tiene acceso el asistente y esto reduce la barrera para usar el asistente.
Por último, no todos los casos de uso requieren el modelo más grande o más caro. Al desacoplar el sistema de un único proveedor, los usuarios pueden elegir el modelo que mejor se adapte a sus necesidades, equilibrando capacidad, costo y riesgo.
¿Cómo cree que cambiará el trabajo diario de un profesional de datos en 2026?
A pesar de los estereotipos comunes, la ingeniería de datos y software son profesiones altamente sociales. Creo firmemente que la parte más importante del trabajo ocurre antes de escribir el código: alinearse con las partes interesadas, comprender el espacio del problema y diseñar soluciones que se ajusten a los sistemas y equipos existentes.
Este trabajo inicial se vuelve aún más importante a medida que el desarrollo asistido por agentes acelera la implementación. Sin objetivos, contexto y limitaciones claros, los agentes amplifican la confusión en lugar de la productividad.
En 2026, los profesionales de datos dedicarán más tiempo a dar forma a los sistemas, definir límites, validar suposiciones y garantizar un comportamiento responsable en entornos de producción.
De cara al resto de 2026, ¿qué grandes temas definirán el año para los profesionales de datos, en su opinión? ¿Por qué?
La IA generativa y los sistemas basados en agentes seguirán creciendo, pero el cambio más importante es su maduración hasta convertirse en sistemas de producción de primera clase en lugar de experimentos.
Esa transición depende de datos accesibles, confiables y de alta calidad y de prácticas de ingeniería sólidas. Como resultado, el pensamiento completo y el diseño a nivel de sistema serán cada vez más importantes para las organizaciones que quieran aplicar la IA de manera responsable y a escala.
Para obtener más información sobre el trabajo de Mike y mantenerse actualizado con sus últimos artículos, puede seguirlo en TDS o LinkedIn.