---
title: "Mateo Ruiz (@mateoruiz) | Hashnode"
description: "Senior Tech Consultant. Read the latest articles by Mateo Ruiz on Hashnode."
url: "https://hashnode.com/@mateoruiz"
---

@mateoruiz

# Mateo Ruiz

@mateoruiz · Boston, USA · Joined May 2026

Senior Tech Consultant

[Website](https://www.itpathsolutions.com/)

## Comments

[One subtle issue worth watching is that resetting the mock doesn't automatically guarantee isolation if tests share external identifiers or asynchronous requests are still in flight. For example, a delayed request from one test could arrive after beforeEach has reset the mock and contaminate the next test's request history or scenario state. I'd make sure each test waits for its interactions to settle before cleanup, and use unique context IDs where possible. Randomized execution catches ordering dependencies, but repeated parallel runs are especially useful for exposing these timing-related leaks.](https://hashnode.com/posts/reset-mock-state-between-tests-isolation/6ae809c7343f9333b83ed5cb/comment/6ae82bd611447caa302aa06c)

Comment · Article · Nov 2 · [Resetting Mock State Between Tests for Real Isolation](https://hashnode.com/posts/reset-mock-state-between-tests-isolation/6ae809c7343f9333b83ed5cb)

[One thing I’d emphasize is that observability cost should be measured against the cost of diagnosing an incident, not just the volume of telemetry collected. Aggressive sampling can save money, but if it removes the context needed to reconstruct a failed request, the savings can quickly disappear. At IT Path Solutions, we see this as an important part of building production-ready systems: correlate logs, metrics, and traces around critical workflows, while keeping high-cardinality identifiers out of metric labels. I’d also make sure sampling preserves error and slow traces across service boundaries. The goal isn't to collect everything; it's to retain enough context to explain what went wrong when it matters.](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126/comment/6ae82b8ffa2e89bfc5ee014c)

Comment · Article · Nov 2 · 1 · [Observability on a Budget: Logs, Metrics, and Traces with Open-Source Tools](https://hashnode.com/posts/observability-on-a-budget-logs-metrics-and-traces-with-open-source-tools-zxgpm/6ae824538caaf19abed0e126)

[The distinction between per-packet CPU cost and queueing delay is important because optimizing one can leave the actual bottleneck untouched. I’d add one more dimension to the benchmarking: measure tail latency under load, not just average RTT or peak throughput. For example, an XDP rule might reduce processing overhead while a saturated uplink still creates bufferbloat. Similarly, kernel bypass can improve packet handling but introduce operational blind spots when standard observability tools no longer see the traffic. The best design is usually the least complex option that meets the latency target with enough visibility to debug it in production.](https://hashnode.com/posts/high-performance-edge-tunneling-architecture-kernel-bypass-xdp-and-bbr-tuning/6ad6e90d4b37d66e6a92d660/comment/6ae4a0cc41190ba61d30fe83)

Comment · Article · Oct 30 · [High-Performance Edge Tunneling Architecture: Kernel Bypass, XDP, and BBR Tuning](https://hashnode.com/posts/high-performance-edge-tunneling-architecture-kernel-bypass-xdp-and-bbr-tuning/6ad6e90d4b37d66e6a92d660)

[One thing worth adding is that keeping the machine awake solves only the infrastructure side of the problem. It doesn’t guarantee the agent task survives a dropped API connection, terminal crash, or unexpected reboot. For longer coding tasks, I’d treat caffeinate and tmux as convenience measures, but make the workflow resumable as well: persist task state, keep important outputs in files or commits, and make tool operations safe to retry. That way, even if the Mac does sleep, the work doesn’t have to start from zero. An always-on machine improves availability; recoverability is what makes the setup reliable.](https://hashnode.com/posts/claude-code-stops-when-your-mac-sleeps-the-quick-fixes/6adf50ad92cceff05c10caed/comment/6ae4a07a41190ba61d30fbfb)

Comment · Article · Oct 30 · [Claude Code stops when your Mac sleeps: the quick fixes](https://hashnode.com/posts/claude-code-stops-when-your-mac-sleeps-the-quick-fixes/6adf50ad92cceff05c10caed)

[The distinction between schema validity and semantic correctness is the part I’d pay the most attention to. A response can satisfy every required field and still point to a line that doesn’t exist or provide evidence that was never in the source. I’d keep structural validation and grounding checks as separate stages, then track failures by category: malformed output, repair required, invalid references, and unsupported claims. That makes the schema-off experiment much more useful because you’re measuring not just whether the model returns valid records, but whether those records are actually reliable. Strict output controls the shape; it doesn’t establish truth.](https://hashnode.com/posts/stop-parsing-prose/6ae0e5ff407874d8b565d81f/comment/6ae32f90d84a8b92dc658f50)

Comment · Article · Oct 29 · [Day 04: Stop parsing prose. Make the model return a struct](https://hashnode.com/posts/stop-parsing-prose/6ae0e5ff407874d8b565d81f)

[The biggest takeaway is that agent-ready documentation is a delivery-system problem as much as a content problem. A page can be accurate and well written, yet still be useless to an agent if it’s undiscoverable, truncated, or served in a representation the agent can’t consume reliably. I especially like the move toward generating machine-friendly Markdown from the same source rather than maintaining a separate version. In production AI work at IT Path Solutions, that same principle matters for RAG systems and coding agents: keep one authoritative source, preserve structure and provenance during transformation, and validate the generated output in CI. One additional check worth considering is freshness and parity between the human-facing and agent-facing versions. A build can pass every formatting check while an agent still receives outdated instructions. Treating content freshness and representation consistency as measurable release criteria would make the system even more reliable.](https://hashnode.com/posts/the-comprehensive-technical-guide-to-building-ai-ready-documentation-systems/6abfb5a1c8356b9bd94208ca/comment/6ae1d367db1a2fdd78fa6c74)

Comment · Article · Oct 28 · 1 · [The Comprehensive Technical Guide to Building AI-Ready Documentation Systems](https://hashnode.com/posts/the-comprehensive-technical-guide-to-building-ai-ready-documentation-systems/6abfb5a1c8356b9bd94208ca)

[One distinction worth emphasizing is that a successful pilot proves the workflow can work, while production readiness proves it can keep working when assumptions break. Those are very different thresholds. In production AI projects at IT Path Solutions, I’d pay particular attention to the failure paths that pilots often under-test: stale or unavailable data, partial integration failures, incorrect outputs, and changes in model behavior after an update. Each needs a defined recovery or escalation path, not just a monitoring alert. I’d also make the scale-up gate evidence-based. Before expanding access, teams should know the acceptable failure rate, who owns incidents, how outputs are evaluated after changes, and when a human must take over. If those answers depend on the original pilot team being constantly available, the technology may be ready, but the operating model isn’t.](https://hashnode.com/posts/enterprise-ai-readiness/6abf6c37029d53f1ed6fabc1/comment/6ae1d2c21f84fdf776ced468)

Comment · Article · Oct 28 · [Enterprise AI Readiness: How to Decide Whether a Pilot Can Scale](https://hashnode.com/posts/enterprise-ai-readiness/6abf6c37029d53f1ed6fabc1)

[AI readiness is less about how modern the data platform is and more about whether the data can be trusted, traced, and accessed in the right context. Even a well-maintained warehouse can produce unreliable AI answers if records are stale, permissions aren't preserved, or conflicting sources have no clear precedence. In production AI work at IT Path Solutions, I’d pay particular attention to data lineage and permission-aware retrieval. An AI system needs to know not just what information it found, but where it came from, how current it is, and whether the requesting user is allowed to see it. Those controls become especially important when enterprise data feeds RAG systems or autonomous agents. A useful readiness test is to trace one AI-generated answer all the way back to its source records and access rules. If the team can't explain why that answer was produced and whether the underlying data was appropriate to use, modernizing the infrastructure alone hasn't solved the problem.](https://hashnode.com/posts/building-modern-data-architectures-for-ai-ready-enterprises/6a797608252b658703228ba5/comment/6adf36aaf566171c9750b9c1)

Comment · Article · Oct 26 · [Building Modern Data Architectures for AI-Ready Enterprises](https://hashnode.com/posts/building-modern-data-architectures-for-ai-ready-enterprises/6a797608252b658703228ba5)

[The useful takeaway is that “local is cheaper” only makes sense after you define the workload. Hardware turns inference into a capacity-planning problem, while cloud turns it into a usage-based operating cost, so comparing only the per-token price misses the real trade-off. For production AI work at IT Path Solutions, I’d look at this as a routing decision rather than a local-vs-cloud decision: keep predictable, high-volume or privacy-sensitive workloads close to the data, while sending frontier reasoning or bursty workloads to the cloud. That also makes utilization a much better metric than simply asking which option has the lower headline cost. The hidden costs around maintenance and model drift are important too. If the local system sits underutilized, its “cheap” inference capacity is effectively stranded capital. The real break-even point is therefore based on sustained useful utilization, not just token volume.](https://hashnode.com/posts/who-actually-saves-money/6ac6cae262df7f6c217c2fc8/comment/6ac73e8450cf183794e1ba2d)

Comment · Article · Oct 8 · [Who Actually Saves Money?](https://hashnode.com/posts/who-actually-saves-money/6ac6cae262df7f6c217c2fc8)

[The interesting shift here is treating API deprecation as an enforcement and telemetry problem rather than a communication problem. If the old endpoint continues returning 200 with no observable consequence, migration will naturally lose priority until the cutoff becomes an incident. The per-consumer decision loop is particularly useful. Aggregate traffic can tell you that 8% of requests remain, but it doesn't tell you whether those requests belong to one critical payment integration or hundreds of dormant clients. That distinction should determine how aggressively enforcement progresses. I’d also treat brownouts as a compatibility test, not just a forcing mechanism. The retry behavior, ownership gaps, and clients that ignore 429s can expose failure modes before hard retirement. That makes the deprecation process itself a form of production readiness testing.](https://hashnode.com/posts/the-deprecation-notice-nobody-reads/6ac60542bddd02be1ee67ea2/comment/6ac73d369e0441b4081ba21f)

Comment · Article · Oct 8 · [The Deprecation Notice Nobody Reads](https://hashnode.com/posts/the-deprecation-notice-nobody-reads/6ac60542bddd02be1ee67ea2)