Thoughts of an Engineer: May 30, 2026
Today is my birthday, and as I get older, I find myself spending less time thinking about what I’ve accomplished and more time thinking about what I want to build next. Every year there seems to be a problem, idea, or pattern that captures my attention and refuses to let go. This year that idea is something I’ve started calling Harness Engineering.
Over the past year, I’ve been doing a lot of vibe coding. Like many engineers, I’ve been amazed at how quickly AI-assisted development has changed what is possible for a single person. Projects that would have taken weeks can now be prototyped in days. Features that once required hours of research can be scaffolded in minutes. The ability to move from idea to implementation has improved dramatically, and I genuinely believe we’re only at the beginning of that shift.
What surprised me, however, is that the bottleneck didn’t disappear. It simply moved.
When people talk about AI development, most conversations focus on code generation. Can the model write code? Can it fix bugs? Can it build an application? Those are interesting questions, but they are becoming less important to me. The actual act of producing code is no longer where I spend most of my time. Instead, I spend a surprising amount of energy managing context.
By context, I mean everything surrounding the code itself. I have to remember which repository contains the project, which branch I’m working from, which environment is deployed, where the credentials live, how the AI tooling is configured, and what decisions I made the last time I touched the project. None of these tasks are individually difficult, but together they create enough friction that they slow me down more than the coding itself.
I started noticing this because I tend to jump between projects frequently. One day I might be working on a CRM. The next day I might be experimenting with family tree software. Later in the evening I may be building security tooling, testing infrastructure ideas, or exploring a random concept that seemed interesting over lunch. The actual coding is often the easiest part. The harder part is rebuilding the mental model required to continue where I left off.
This is where the idea of harness engineering started to form. To me, harness engineering is not about building smarter AI models. It is not about creating another agent framework. It is about building the systems that connect projects, tools, infrastructure, repositories, credentials, and execution environments together in a way that minimizes friction. The harness is the layer that understands where work should happen and how work should happen.
The more I thought about it, the more I realized that engineers often serve as the harness themselves. We are the integration point between systems that do not naturally communicate. We know which repository belongs to which deployment. We know which credentials belong to which service. We know which machine runs which workload. We know where documentation lives and which dashboards matter. A large portion of our work consists of carrying context between systems that have no awareness of each other.
What if software could help with that?
That question led me back to my home lab. Over the years I’ve experimented with various platforms, cloud providers, virtualization technologies, and orchestration systems. While there are many technically sophisticated options available, I keep coming back to Unraid. It is not because Unraid is the most advanced platform in existence. It is because I know it well enough that I can focus on solving problems rather than managing infrastructure.
For this particular idea, familiarity matters more than theoretical capability. I already know how to manage virtual machines on Unraid. I already know how to manage containers, networking, storage, and backups. More importantly, I know I will actually use it. One lesson I’ve learned repeatedly throughout my career is that the best technology is often the technology that gets adopted. An elegant solution that sits unused is less valuable than a practical solution that becomes part of a daily workflow.
Part of this thinking comes from revisiting an older project that I considered a failure. Some time ago I experimented with ephemeral development environments. The concept was straightforward: create environments on demand, execute work, and destroy everything when the task was complete. Technically it worked exactly as intended. The problem was that I rarely used it.
At first I assumed the project had failed because the implementation was lacking. Looking back, I think the real issue was that I misunderstood the problem. I was optimizing for infrastructure efficiency when I should have been optimizing for human efficiency. While ephemeral environments are incredibly useful for some workloads, there are many situations where persistence is valuable. Sometimes I want an environment that remembers where I left off. Sometimes I want repositories already cloned, tools already configured, and context already available.
Today I think the answer is not choosing between persistent and ephemeral systems. I think the answer is supporting both. Some projects benefit from long-lived environments that continuously accumulate context. Other tasks benefit from disposable environments that can be created and destroyed as needed. The harness should understand the difference and make those decisions automatically.
One idea I’m actively exploring is using Slack as the primary interface. That may sound unusual at first, but the more I think about it, the more natural it feels. I already spend a significant amount of my day inside Slack. Most teams do. Channels already represent projects, discussions, and areas of responsibility. Historical context already exists there. Conversations already happen there. Rather than treating Slack as a communication platform, I can imagine treating it as a command surface.
Imagine a world where each project has dedicated channels representing different execution contexts. One channel could represent persistent development environments while another could represent ephemeral workspaces. Instead of manually connecting to systems, opening terminals, and navigating repositories, I simply interact with the channel. The harness determines where the work should execute, which environment should be used, and which resources should be made available.
I am still evaluating whether Hermes fits into this vision or whether it becomes something adjacent to it. Hermes already solves parts of the orchestration problem, and there may be opportunities to build on that foundation rather than starting from scratch. At this stage, I am less concerned with specific implementation details and more concerned with validating the workflow itself.
The vision I keep returning to is one where projects have dedicated workers that understand their environment. Not generic AI assistants that know a little about everything, but project-specific workers that know the repositories, deployment targets, documentation, and operational history associated with a particular project. Instead of rebuilding context every time I switch tasks, I reconnect with an environment that already possesses the context I need.
What excites me most about this idea is that it feels like the next logical step beyond vibe coding. The first wave of AI tooling focused on accelerating implementation. The next wave may focus on reducing the friction surrounding implementation. Generating code is becoming easier every month. Managing context remains difficult. If we can reduce the cost of context switching, we can unlock another layer of productivity that has very little to do with coding itself.
I don’t know exactly where this project will lead. It may become a collection of scripts running in my home lab. It may evolve into a larger platform. It may end up teaching me lessons that lead somewhere entirely different. Regardless of the outcome, I think the underlying problem is worth exploring.
AI has dramatically reduced the effort required to build software. The challenge I’m interested in now is reducing the effort required to move between software. If I can create a system that makes context as portable as code, I think it will fundamentally change how I work. That’s a problem worth spending my birthday thinking about, and hopefully one worth building over the year ahead.