Over the last two months, I have built and deployed roughly twenty distinct projects.

The range has been wide:

  • KiCad 9 Plugins & Tooling: A 1-click manufacturing release package exporter, an organic freehand trace routing tool with curve smoothing, an enterprise SQLite component database library, and a machine-readable requirements gate.
  • Parametric 3D Design (Blender MCP): Procedural aerodynamic blower nozzles, modular lamp studios with cable routing, stereographic projection candle lamps, and non-photorealistic Wind Waker cel shaders for PCBs.
  • Mobile Applications: Offline educational Flutter apps for children (Hinduism4Kids, Maths Kids, Akshar), and Chessloom, a native Android computer-vision scanner running on-device Stockfish via C++ NDK.
  • Desktop & CLI Utilities: A zero-dependency 1MB C# WPF frontend for jpegoptim, Reddit-to-Joplin metadata exporters, and automated CI/CD hardware pipelines.

Whenever I demo or write about these projects, fellow engineers and makers inevitably ask:

“Where is the GitHub link? Are you going to open-source the repo?”

My answer usually catches them off guard: No, I am probably not going to open-source the repos.

It is not because I want to protect the intellectual property. It is not because I am planning to paywall them or build a SaaS around them. I have zero interest in hoarding code.

The reality is much simpler: I believe the deep technical blog post is the new source code.

The Hidden Cost of the Traditional Repository

Consider what an open-source GitHub repository actually represents in the traditional software paradigm:

  1. Language & Framework Lock-in: If I write a Windows desktop utility in C# WPF, a macOS developer or a Linux sysadmin cannot directly use it. If I build a mobile app in Flutter, a team with a native Kotlin or Swift codebase has to manually translate the logic line by line.
  2. Environment & Dependency Rot: Every repo comes burdened with external baggage—package managers, virtual environments, pinned SDK versions, C++ CMake toolchains, and platform-specific quirks. Six months from now, a minor OS update or deprecated dependency will break the build.
  3. Friction to Customize: When you clone someone else’s repository to solve your specific problem, you spend the first hour understanding their directory structure, fighting their build system, and figuring out where to splice in your changes without breaking their abstraction layers.

A static git repository is a frozen implementation detail. It represents one specific author’s compilation target on one specific day.

The Architectural Blueprint as Executable Logic

When I document a project on this blog, I deliberately skip superficial high-level overviews. Instead, I document the engineering core:

  • The Problem Constraints: Why existing solutions fail, the edge cases encountered, and the hardware or platform limitations.
  • The Mathematical Formulations: The exact equations—whether it is Chaikin’s corner-cutting algorithm, Ramer-Douglas-Peucker polyline simplification, Monotone Cubic Hermite splines (PCHIP), or 2D projective homography matrices.
  • The Data Structures & State Flow: How the models communicate, how state machines handle asynchronous lifecycle transitions, and how edge cases (like Material 3 theme tinting or zero-dependency fallback sequences) are resolved.
  • The CLI & UI Boundaries: The exact argument mappings, data tables, and input/output contracts.

This kind of documentation is not merely a summary of work done. It is a rigorous, unambiguous architectural specification.

Point, Prompt, and Adapt

Here is how software consumption actually works in 2026:

If you want the tool I built, you do not need my repository.

You copy the URL of the technical blog post, paste it into your LLM of choice (Claude, ChatGPT, Gemini, or a local model), and give it your context:

“Read this architectural breakdown. Implement this as a lightweight command-line tool in Go.”

“Take this KiCad plugin design, but rewrite the export path structure to match my company’s internal server layout.”

“Port this column-arithmetic state machine from Flutter into a React component for our web dashboard.”

Within thirty seconds, you have clean, idiomatic, working code tailored precisely to your language, your operating system, your libraries, and your workflow.

You avoid the dependency debt of cloning my repo. You do not inherit my build scripts or my architectural biases. You get the pure logic, synthesized on demand for your exact runtime.

The Definition of Software is Changing

In the pre-AI era, the source code was the primary asset, and documentation was an afterthought that engineers rarely had the time to write.

Today, that relationship is completely inverted:

  • Source code is ephemeral. It is a transient artifact that can be generated, discarded, refactored, and ported in seconds.
  • Architecture, constraints, and domain understanding are durable. The hard part of engineering has never been typing syntax; it has always been deciding what to compute, why to compute it that way, and how to handle the physical and logical constraints of the problem.

The deep technical blog post captures the durable engineering thinking. The LLM handles the ephemeral syntax.

Don’t clone my repo. Feed the blueprint to your model, and build the version that fits your world.