Mohanad Abu-Nayla

About

Sat, 01 Aug 2026 00:00:00 +0000

Within my organization, I act as a technical problem router. When there’s no established answer, whether that’s new infrastructure, a new AI capability, or a complex integration, I’m brought in to assess, decide, build and deliver.

I design and run production AI systems under real-world constraints: LLM inference pipelines, OCR engines, and ML platforms on on-prem GPU Kubernetes clusters, optimized for reliability, low latency, and cost efficiency in regulated environments.

Spec-Driven Development with AI Agents: Constitutions, Checkpoints, and Handoffs

Sat, 01 Aug 2026 00:00:00 +0000

AI coding agents are strangely lopsided. Hand one a well-scoped task and it writes better code, faster, than I do. Hand it a large feature, the kind that takes days and touches a dozen files across several layers, and the failure mode changes. The context window fills up and quality quietly degrades (AKA context rot). A fresh session, missing the history, confidently invents an API that never existed. And even when the code is good, you’re left staring at a 3,000-line diff you can’t meaningfully review.

Before You Train, Audit: A TinyStories Case Study

Sat, 30 May 2026 00:00:00 +0000

If you are building a small language model from scratch, TinyStories is usually one of the first datasets you reach for. I did too. Before touching tokenization and training, I ran a quick data audit on the parquet train split. That one step surfaced something worth sharing: a large number of exact duplicate stories sitting quietly in the data. This post is a practitioner-level writeup, not an accusation. TinyStories is still a solid dataset. The point is just this: verify your data pipeline the same way you verify your model pipeline.

On-Demand Namespace Error Log Watcher in a Locked-Down Kubernetes Environment

Sat, 23 May 2026 00:00:00 +0000

During a large-scale stress test, the last thing you want is to be hunting errors across 150 pods manually.

So I built an on-demand error log watcher for a complex Kubernetes namespace under real-world constraints, without touching anything outside the namespace, and without installing a single binary on the server.

What we are building: a Kubernetes Deployment, scaled to zero by default, that runs Stern as a container inside the cluster. It watches all pods in a target namespace, filters output to errors only, and can be started or stopped with a single kubectl scale command. The entire setup RBAC, ServiceAccount, and Deployment lives within the targeted namespace it monitors and leaves no trace when removed.