This resonates a lot: you get so used to the daily friction that you start treating it as “just how it works.” The biggest leap often comes from stepping back, mapping the flow end-to-end, measuring where time actually goes, and then automating what’s repetitive. What’s one task in your business you’d be surprised to measure in real minutes/hours today?

Automation is valuable, but the real issue is context and scale. For small teams, local businesses, and narrow use cases, platforms such as n8n, Zapier, or Make can be effective for rapid proofs of concept and lightweight workflows. They are useful when the objective is speed, simplicity, and a very specific operational outcome. However, that is a very different discussion from enterprise-grade automation. Those of us who have spent decades in automation have already seen many generations of tools and approaches. When you are dealing with Kubernetes clusters, hybrid IT, cloud-native architectures, millions of concurrent users, and business-critical transactions, these low-code automation platforms are often not enough. They typically lack the scalability, performance, resilience, governance, and architectural depth required for mission-critical environments. They can look impressive in demos, but a critical core process in a major enterprise is not something serious organizations delegate to lightweight orchestration tools. At that level, the requirements are entirely different: robustness, observability, security, compliance, performance under load, and long-term maintainability. So yes, these tools have their place. They can deliver value in contained B2C scenarios or for very specific services with limited complexity. But when enterprise IT is operating at scale, with high financial and operational risk, they are often not the answer. What I see every day across clients is that much of this market noise creates unrealistic expectations. It can consume time and budget, while adding little value to the environments where automation truly matters.

I agree that automation can create value, but the conversation changes completely when we move from small-scale workflow convenience to enterprise-critical operations. For small teams, local businesses, or narrowly defined processes, tools such as n8n, Zapier, Make, or similar platforms can be useful. They are fast to deploy, relatively inexpensive, and good for proofs of concept, departmental workflows, marketing automations, notification chains, or lightweight integrations. However, that is not the same as enterprise automation. Those of us who have spent decades in automation have already seen multiple generations of “easy” tools presented as strategic answers. The reality is that once you are operating Kubernetes clusters, hybrid IT estates, cloud-native services, complex integration layers, and business-critical processes with millions of concurrent users, the requirements are fundamentally different. At that level, scalability, resilience, governance, observability, security, auditability, latency control, and performance under load are not optional. They are the baseline. That is where many low-code automation platforms start to show their limits. They are often excellent for isolated use cases, but they are not designed to be the foundation of large-scale, mission-critical enterprise systems. A serious organization will not delegate core banking flows, real-time supply chain orchestration, large-scale citizen services, or revenue-critical transaction processing to tools built primarily for convenience and speed of assembly. They are not useless. They simply belong to a different category. They can work well for a WhatsApp-based customer interaction, a lead-routing workflow, a simple website launch, or a back-office notification process. But once the system has to support enterprise-grade throughput, strict SLAs, regulatory controls, and deep operational accountability, these tools are usually insufficient on their own. What I see across clients is not a lack of innovation, but a repeated confusion between tactical automation and strategic automation. The first can be solved with lightweight tools. The second requires engineering discipline, architecture, platform thinking, and solutions designed for performance and scale from day one.

EN: If AI could save us time in one area, it would be incident triage + RCA (MTTR). In real delivery teams, the bottleneck isn’t lack of alerts—it’s the manual work of correlating logs/metrics/traces, identifying the likely root cause, and coordinating the next best action. AI can de-noise alerts, correlate signals across services, suggest probable causes, propose runbook steps, and auto-draft the post-incident report + Jira tasks—faster recovery, fewer repeat incidents, and measurable risk reduction. If AI could save time in one area, I’d pick: turning a business idea into a production-ready change (end-to-end T2M). But the win isn’t “AI alone” — it’s the stack: • Spec-Driven Development: keep specs as code, with an Agent.md that defines requirements, acceptance criteria, NFRs (security/reliability), and evidence needed. • GenAI agents: generate user-story breakdown, test cases, IaC changes, and release notes from the spec — consistently. • MCP Server (governed tool access): agents safely interact with Jira/Git/CI/CD/KBs without leaking secrets. • IDP (golden paths): standardized templates for pipelines, environments, and observability so teams don’t reinvent delivery. • DevOps/DevSecOps + SRE: automated quality/security gates, progressive delivery, SLO-based monitoring and fast rollback. Executive outcome: faster throughput with lower change risk + better MTTR — measured via DORA + SLOs. __________________________________________________________________________________________ ES: Si la IA pudiera ahorrarnos tiempo en una sola área, sería en triaje de incidencias + análisis de causa raíz (MTTR). En equipos reales, el freno no es la falta de alertas: es el trabajo manual de correlacionar logs/métricas/trazas, encontrar la causa probable y coordinar la acción correcta. La IA puede reducir ruido, correlacionar señales entre servicios, proponer causas, sugerir pasos de runbook y redactar automáticamente el post-mortem + tareas en Jira—recuperación más rápida, menos reincidencias y menor riesgo operativo.