onlyascii.dev

onlyascii.dev — a tech blog and profile

Wed, 01 Jul 2026 00:00:00 +0000

This is onlyascii.dev — my personal blog and profile. I’m Panos Xynos, a platform engineer and SRE. This is where I write about the things I build, the experiments I run, and the methodology I develop along the way.

The site shares the terminal/phosphor aesthetic of the OnlyASCII company site because it is the same brand. Same dark background, same phosphor green accent, same monospace discipline. The difference is purpose. onlyascii.io is the consultancy. onlyascii.dev is the workshop.

The Philosophical Developer — Chapter -1: Deeper Roots

Mon, 06 Jul 2026 00:00:00 +0000

I found a gist today. Two years old. And it stopped me cold.

The URL is still live: gist.github.com/dark5un/cd1a9b8162958c75026d7c9fb72740c4

Debian bookworm 12 ML Tooling installation notes & more. I wrote it in January 2024. A raw Markdown document with every command I ran to set up a machine for AI work — NVIDIA drivers, CUDA toolkit, Docker with GPU passthrough, ASDF version manager for half a dozen languages, Neovim with NvChad, Oh-My-Zsh, Syncthing, the whole stack.

The Philosophical Developer — Chapter 00: Two Voices

Wed, 01 Jul 2026 00:00:00 +0000

A note about these chapters.

You might notice the articles in this series do not all sound like me. They were written by my padawan, OrsonRius — the Hermes Agent that implements while I architect. The ideas are mine. The experiments are mine. The code is ours. But the voice in those chapters is not the one I use when I write for myself.

I wanted it that way. I wanted to see if an AI could capture the shape of a thought without losing the substance. And it did. The chapters are clear, honest, and they follow the work faithfully. But they are from both of us.

The Philosophical Developer — Chapter 01: How I Steer My Padawan

Wed, 01 Jul 2026 00:00:00 +0000

I am the architect. My padawan OrsonRius is the implementer. I design the approach, frame the problem, set the boundaries. He turns the cranks, writes the code, and reports back what he finds.

This dynamic is the core of how I work. It is not delegation. It is steering.

I communicate intent, not instructions. Instead of “run this command and paste the output,” I say “I want to understand the blast radius before we touch code. Map every caller of this function, every test that could break. Write it down.” The padawan executes. I review. I adjust.

The Philosophical Developer — Chapter 1.5: The First Steering

Wed, 01 Jul 2026 00:00:00 +0000

This is a steering note — a behind-the-scenes look at how I communicate intent to my padawan between experiments. These entries sit between the main chapters.

When I set up the weather-cli experiment, I did not give my padawan a specification. I gave him a framing.

I said: “I want to know whether an AI can build a complete Rust CLI from scratch using TDD with LSP as a guardrail. The subject is a weather forecast tool. It needs to fetch real data from an API, parse it, and display it in the terminal. Use the RED-GREEN-REFACTOR loop. One behavior per cycle. Commit per cycle. Tag the trace.”

The Philosophical Developer — Chapter 02: Weather CLI, A Complete Loop

Wed, 01 Jul 2026 00:00:00 +0000

I built a weather CLI and asked my padawan to drive it through completion.

The first experiment was about whether an AI could write Rust from scratch using TDD and LSP as a guardrail. It could. But one experiment doesn’t prove a methodology. You need to see it land the plane. Take a project from zero to a complete, tested, working CLI that does something real.

The project was a weather forecast CLI. Fetch current conditions and a five-day forecast from the Open-Meteo API, display them in the terminal. Nothing fancy. But real enough to stress the pipeline.

The Philosophical Developer — Chapter 2.5: The LSP Insight

Wed, 01 Jul 2026 00:00:00 +0000

Steering note — the moment the methodology shifted.

After the weather-cli experiment, I had a problem. The padawan’s discipline was good. But I noticed something in the trace: every cycle had a “compile then debug” phase. He would write code, hit compile, see an error, fix it, compile again. Each compile was seconds lost.

The insight came while I was watching VS Code. Red squiggles in the editor. LSP catching the error before the file was saved. I thought: that is what the padawan needs. Not a compile loop. An editor loop.

The Philosophical Developer — Chapter 03: Building with a Tether

Wed, 01 Jul 2026 00:00:00 +0000

I had this thought a while back. When an AI writes code, it guesses. It guesses function names, return types, what a library exports. And sometimes it guesses wrong. The code compiles but the logic is built on thin air.

I wondered: what if we could tether the AI to something real during the writing process? Something that catches the bad guess before it becomes a test failure or, worse, a bug in production.

The Philosophical Developer — Chapter 3.5: Designing Traceability

Wed, 01 Jul 2026 00:00:00 +0000

Steering note — designing the trace tag pattern.

After mini-clap, I had another problem. The code was good. The LSP tether worked. But when I looked at the repository, I could not see the reasoning. I saw one commit: “feat: CLI argument parser.” Where were the ten cycles? Where was the RED phase? Where was the refactor?

An AI does not explain itself. It produces. If I could not reconstruct the reasoning from the repo, how could anyone else?

The Philosophical Developer — Chapter 04: Making Thought Visible

Thu, 02 Jul 2026 00:00:00 +0000

After the first experiment I had a new problem. The LSP tether worked. The AI wrote good code. Tests passed, coverage was high. But when I looked at the repository, I saw one commit. One wall of code. No trace of how we got there.

An AI does not explain itself. It produces. And production without explanation is hard to trust, especially when you have to review it later.

The Philosophical Developer — Chapter 05: Polishing the Output

Thu, 02 Jul 2026 00:00:00 +0000

I had three repos full of chapters and articles. Markdown files. Well written, I thought. But I wondered: how clean are they really? Are there broken patterns I am not seeing because I am too close to the text?

So I asked my padawan to audit the writing quality using automated tools.

markdownlint caught two things right away. First, the line length rule. Default is 80 characters, which works for code but not for prose. Every single paragraph in every chapter was flagged. I turned that rule off for chapters. Second, a missing newline at the end of each file. Easy fix.

The Philosophical Developer — Chapter 06: The Pipeline on My Own Machine

Thu, 02 Jul 2026 00:00:00 +0000

The whole point of this series is local inference for development. Data ownership matters. When the model runs on your machine, the code never leaves. No API calls, no token billing, no third party seeing what you are working on. I want development to work on my own machine. The cloud is just a tool to move faster while we figure things out.

DeepSeek V4 Flash is the reason this is possible. I use their cloud service and I am really happy with it. It is insanely cheap and does the job I need. Full credit where it is due.

The Philosophical Developer — Chapter 07: The Three-Line Fix That Broke Three Tests

Fri, 03 Jul 2026 00:00:00 +0000

I had my padawan fix a bug in an open source Go library. Nothing unusual. He jumped in, found the problem, wrote a test, fixed it. Standard stuff.

Then a test broke. Then another. Then we found a composite filesystem was missing a pattern that a different one already had.

Three surprises across 20 minutes. The fix itself took three lines. The debugging took the rest.

The codebase was afero, a filesystem abstraction library for Go. It has two backends: an in-memory one (MemMapFs) and a real OS one (OsFs). The bug was straightforward: creating a file in a non-existent directory silently created the directory on MemMapFs, but returned an error on OsFs. Tests passed on the in-memory backend, then failed in production on the real one.

The Philosophical Developer — Chapter 08: The Slower Approach Is Faster

Fri, 03 Jul 2026 00:00:00 +0000

I designed a formal process for fixing bugs in unfamiliar codebases. My padawan just proved it works.

We have the same project, same pattern of bug, two approaches. The first time we jumped in and fixed it (Chapter 07). The second time we followed the process I designed.

The comparison is worth writing down.

The first bug took 20 minutes. Three tests broke that we did not see coming. The fix was found through failures.

The Philosophical Developer — Chapter 9.5: The Sites

Sat, 04 Jul 2026 00:00:00 +0000

I have had onlyascii.dev for a long time. It was never close to what it is now.

The Philosophical Developer series changed that. Every chapter is a real experiment with real code, real tests, real outcomes. The code is on GitHub. The trace tags are there for anyone to verify. The methodology is developed openly with my young Padawan OrsonRius.

I was publishing these on LinkedIn. That worked, but it is not where the work lives. LinkedIn is for announcements. The blog is for the work itself. The full chapters, the header images, the navigation between them, the RSS feed for people who remember what that is.

The Philosophical Developer — Chapter 09: Language Transfer

Fri, 03 Jul 2026 00:00:00 +0000

I moved my padawan from Go to Python for Chapter 09. I wanted to know if the methodology transfers. The same four phases: reconnaissance, work item, RED test, fix. Different language, different ecosystem, different testing framework. The question was not whether it works for Go. The question was whether it works in general.

The codebase was tqdm, a progress bar library that has been installed over 200 million times. Nine thousand lines of Python spread across a well-organised package. Tests using pytest. Issues managed with labels. A mature project with a clear architecture.

The Philosophical Developer — Process Note: Delivery Audit

Sat, 04 Jul 2026 00:00:00 +0000

We finished Chapter 09 of The Philosophical Developer. Three bugs from the tqdm issue tracker, two fixed, one documented dead end. All code pushed, all meditations written, all branches tagged.

Then I asked my padawan to check everything.

Empty files. Missing meditations. Reconnaissance reports that existed on the fork branch but never made it to the lab mirror. Not everything was broken, but enough was missing that I could not trust the delivery without inspecting it file by file.

The Philosophical Developer — Chapter 10: Building Blindfolded

Wed, 08 Jul 2026 00:00:00 +0000

I gave my padawan a spec that did not exist. No codebase to fork. No issue tracker to mine. Just an API documentation page and a blank cargo new. The task: build a Model Context Protocol server that wraps the FreeAgent accounting API. The constraints: strict TDD, no cutting corners, full API compatibility.

The question was not whether the methodology works on greenfield projects. The question was whether it works when there is nothing to trace into.

The Philosophical Developer — Chapter 11: Running Local

Wed, 08 Jul 2026 00:00:00 +0000

Behind every chapter there is a machine. Behind every machine there is a model. And behind every model there is someone wrestling with build flags at 2am.

This one was me.

The hardware

An RTX 5090. 32 GB of VRAM. Sitting in a room that hits 31°C in the UK summer. The kind of card that turns your desk into a space heater. The kind of card that makes you check GPU temperature like it’s a toddler’s forehead.

The Philosophical Developer — Chapter 12: Recursive Language Models

Wed, 08 Jul 2026 00:00:00 +0000

What happens when you ask an AI to read a 94,000-line codebase in one sitting? The context window swells, attention dilutes, and the analysis becomes… superficial. You get the broad strokes but miss the details that actually matter.

This is the problem that Recursive Language Models solve.

The Paper

Zhang & Khattab from MIT CSAIL published “Recursive Language Models” (arXiv:2512.24601) describing a deceptively simple pattern: instead of dumping everything into one massive prompt, decompose the input into chunks, dispatch each to an independent model call, then aggregate the results.

The Philosophical Developer — Chapter 13: Why Local Matters

Thu, 09 Jul 2026 00:00:00 +0000

All code for this series lives in the local-cloud repo on GitHub.

Three things converged in 2025-2026 that make this timely:

1. LocalStack’s Community Edition was sunset in March 2026. The go-to free local AWS emulator went proprietary overnight. Teams that built their entire local dev workflow around it suddenly needed an auth token, were hitting feature gates, or were paying.

2. Cloud providers raised prices across the board. AWS, Azure, GCP all increased pricing. Egress fees became a real business decision point, not just an ops footnote.

The Philosophical Developer — Chapter 14: Code Your Infrastructure

Thu, 09 Jul 2026 00:00:00 +0000

Code Your Infrastructure

Last chapter we stood up the local cloud: Floci as our AWS emulator, a local registry, k3s in k3d. It works. But “works” is a state, not a guarantee.

Infrastructure as code turns states into contracts.

All code for this series lives in the local-cloud repo on GitHub.

Why OpenTofu

OpenTofu forked from Terraform when HashiCorp switched to BUSL. The code is the same. The philosophy diverged — OpenTofu stayed open source, community-governed, and committed to backward compatibility. For a project about sovereignty and local control, that alignment matters.

The Philosophical Developer — Chapter 15: The Pipeline

Thu, 09 Jul 2026 00:00:00 +0000

The Pipeline

Last chapter we coded infrastructure with OpenTofu — five modules, seven tests, all passing. But a test suite that runs locally is a habit, not a guarantee. The difference between discipline and assurance is automation.

Code without a pipeline is a promise. Code with a pipeline is a proof.

Pipeline code lives in the local-cloud repo on GitHub.

The Problem

Every change to the local-cloud stack went through this flow:

The Philosophical Developer — Chapter 16: Deploy to the Local Cloud

Thu, 09 Jul 2026 00:00:00 +0000

Deploy to the Local Cloud

All code for this series lives in the local-cloud repo on GitHub.

We’ve spent four chapters building the foundation: a local cloud environment with Floci, k3s, TDD infrastructure modules, and an automated CI/CD pipeline. Now we deploy.

The Kubernetes Module

The k8s module creates three resources:

Namespace — isolates the local-cloud workloads
Deployment — runs the application with configurable replicas
Service — exposes the deployment as a ClusterIP

TDD First

Following the same pattern as every module before it, we wrote the test first:

The Philosophical Developer — Chapter 17: Observability

Thu, 09 Jul 2026 00:00:00 +0000

Observability

All code for this series lives in the local-cloud repo on GitHub.

Last chapter we deployed workloads to the local k3s cluster. The deployment ran, the pods started, the service responded. But we had no idea what was happening inside.

A cluster without observability is a black box. You know it’s running until the moment it’s not, and then you have no data to tell you why.