In the Author Spotlight series, TDS Editors chat with members of our community about their career path in data science and AI, their writing, and their sources of inspiration. Today, we’re thrilled to share our conversation with Mike Huls.
Mike is a tech lead who works at the intersection of data engineering, AI, and architecture, helping organizations turn complex data landscapes into reliable, usable systems. With a strong full-stack background, he designs end-to-end solutions that balance technical depth with business value. Alongside client work, he builds and shares practical tools and insights on data platforms, AI systems, and scalable architectures.
Do you see yourself as a full-stack developer? How does your experience across the whole stack (from frontend to database) change how you view the data scientist role?
I do, but not in the sense of personally building every layer. For me, full-stack means understanding how architectural decisions at one layer shape system behavior, risk and cost over time. That perspective is essential when designing systems that need to survive change.
This perspective also influences how I view the data scientist role. Models created in notebooks are only the beginning. Real value emerges when those models are embedded in production systems with proper data pipelines, APIs, governance, and user-facing interfaces. Data science becomes impactful when it is treated as a core part of a larger system, not as an isolated activity.
You cover a wide range of topics. How do you decide what to focus on next, and how do you know when a new topic is worth exploring?
I tend to follow recurring friction. When I see multiple teams struggle with the same problems, whether technical or organizational, I take that as a signal that the issue is structural rather than individual, and worth addressing at the architectural or process level.
I also deliberately experiment with new technologies, not for novelty, but to understand their trade-offs. A topic becomes worth writing about when it either solves a real problem I am currently facing or reveals risks that are not yet widely understood. Finally, I write about topics I personally find interesting and worth exploring, because sustained interest is what allows me to go deep.
You’ve written about LangGraph, MCP, and self-hosted agents. What is the biggest misconception you think people have about AI agents today?
Agents are genuinely powerful and open up new possibilities. The misconception is that they are simple. It is easy today to assemble cloud infrastructure, connect an agent framework, and produce something that appears to work. That accessibility is valuable, but it masks a lot of complexity.
Once agents move beyond demos, the real challenges surface. State management, permissions, cost control, observability, and failure handling are often underestimated. Without clear boundaries and ownership, agents become unpredictable, expensive, and risky to operate. They are not just prompts with tools; they are long-lived software systems and need to be engineered and operated accordingly.
In your article on Layered Architecture, you mention that adding features can often feel like “open-heart surgery.” For a beginner or a small data team looking to avoid this, what is your key advice on setting up an architecture?
“The only constant is change” is a cliché for a good reason so optimize for change rather than for initial delivery speed. Even a minimal form of layered thinking helps: separating domain logic, application flow, and infrastructure concerns.
The goal is not architectural perfection on day one or perfect categorization. It is about creating clear boundaries that allow the system to evolve without constant rewrites. Small upfront discipline pays off significantly as systems grow.
You’ve benchmarked PostgreSQL insert strategies and noted that “faster is not always better.” In a production ML pipeline, what is a scenario where you would deliberately choose a slower, safer insertion method?
When correctness, traceability, and recoverability matter more than raw throughput. In many pipelines, reducing runtime by a few seconds offers little benefit compared to the risk introduced by weaker guarantees.
For example, pipelines that feed regulatory reporting, financial decision-making, or long-lived training datasets benefit from transactional safety and explicit validation. Silent data corruption is far more costly than accepting modest performance trade-offs, especially when data becomes a long-term asset others will build on..
In your Personal, Agentic Assistants article, you built a 100% private, self-hosted platform. Why was avoiding “token costs” and “privacy leaks” more important to you than using a more powerful, cloud-based LLM?
In my daily work I’ve experienced that trusting a system is fundamental to system adoption. Token costs, opaque data flows, and external dependencies subtly influence how systems are used and perceived.
I also made a conscious choice not to route my personal or sensitive data through external cloud providers since there are limited guarantees on how data is handled over time. By keeping the system self-hosted, I could design an assistant that is predictable, auditable, and aligned with European privacy expectations. Users have full control over what the assistant has access to and this lowers the barrier for using the assistant.
Finally, not every use case requires the largest or most expensive model. By decoupling the system from a single provider, users can choose the model that best fits their requirements, balancing capability, cost, and risk.
How do you see the day-to-day work of a data professional changing in 2026?
Despite common stereotypes, data and software engineering are highly social professions. I strongly believe that the most significant part of the work happens before writing code: aligning with stakeholders, understanding the problem space, and designing solutions that fit existing systems and teams.
This upfront work becomes even more important as agent-assisted development accelerates implementation. Without clear goals, context, and constraints, agents amplify confusion rather than productivity.
In 2026, data professionals will spend more time shaping systems, defining boundaries, validating assumptions, and ensuring responsible behavior in production environments.
Looking ahead at the rest of 2026, what big topics will define the year for data professionals, in your opinion? Why?
Generative AI and agent-based systems will continue to grow, but the bigger shift is their maturation into first-class production systems rather than experiments.
That transition depends on trustworthy, high-quality, accessible data and robust engineering practices. As a result, full-stack thinking and system-level design will become increasingly important for organizations that want to apply AI responsibly and at scale.
To learn more about Mike’s work and stay up-to-date with his latest articles, you can follow him on TDS or LinkedIn.