I joined Stacklok a little over 5 months ago. It has been a whirlwind. The company we have now is not the company I joined. The industry I reentered is not the industry we have now. Reflecting on that is perhaps a different blog post. Suffice to say that, like many startups, we are learning and adapting to an incredibly dynamic industry. As such, we have new exciting ideas and directions. ...
I was about to get on a plane with Claude Code mid-session on my laptop, an agent halfway through a change I didn’t want to lose. Closing the lid would suspend the session. I had a spare Intel NUC on a shelf from another project, so I (well, my 17yo daughter) put Debian on it and made it the machine where Claude Code runs. The work now lives on a box that stays on. I attach from my laptop, detach when I board, and reattach from the hotel with the session still running. This is how I set that up, and what broke along the way. ...
You know rubber duck debugging even if you have never named it: put a rubber duck on your desk, and when you are stuck, explain your code to it out loud, line by line. The duck says nothing back. That is not a limitation of the technique. It is the whole mechanism. The name comes from The Pragmatic Programmer, which tells the story of a research assistant, Greg Pugh, who carried a rubber duck around for exactly this purpose.1 The duck is not doing any work. You are, by being forced to say out loud what you think you understand, in order, to an audience that cannot interrupt. A good fraction of the bugs I have found, I found in the second sentence of explaining them to someone who had not said a word yet. ...
The line everyone quotes is “we shape our tools and thereafter our tools shape us.” Marshall McLuhan gets the credit but he didn’t write it. His friend John Culkin did, in a 1967 essay about McLuhan, and pinned it on McLuhan. But the original idea came from Winston Churchill; when rebuilding the bombed House of Commons in 1943, he told Parliament, “we shape our buildings, and afterwards our buildings shape us.” Somewhere “buildings” became “tools.” The line about how tools reshape us got reshaped. ...
Twenty years ago, a few weeks into my job at Google, I wrote a post about 20% time.1 For anyone who never ran into it: 20% time was Google’s policy of letting engineers spend a day a week, a fifth of their time, on a project of their own choosing. The argument in that post was that you couldn’t just copy it. 20% time worked because of the environment around it, not because someone wrote “20%” in a handbook. It was, as I put it then, “a result of an environment and philosophy to development more than a cause.” ...
We say “R&D” like it’s one word for one activity. It isn’t. Research and development are two different jobs with different rhythms, and a coding agent helps with each in a completely different way. This matters because most people reach for the same workflow for both. You point an agent at a problem, give it a goal, and let it run. Sometimes that works beautifully. Sometimes it produces something that looks finished and is quietly wrong. Sometimes the agent misunderstands you and the workflow starts to thrash. The difference usually isn’t the agent. It’s whether you were doing research or development, and whether you knew which one. ...
“Agent” is everywhere in AI conversations. I’d been nodding along with my own rough definition, assuming I’d sharpen it later. As an infra engineer, undefined terms are a bad habit. When a word means everything, it usually means nothing, and the ambiguity bites eventually. I watched two people use “agent” in the same meeting with clearly different meanings. Nobody flagged it. They both left thinking they’d agreed. So I asked Claude. I started with “What does agentic mean?” It sounds like some sort of concrete technology concept I needed to learn about. But it isn’t: “agentic” means “of or relating to an agent.” It sounds like a real technical term but it’s just the adjective form of the noun I couldn’t pin down. ...
I rejoined the working world about a month ago as CTO at Stacklok. That means I’m writing again: customer conversations, product decisions, technical strategy. Some of that writing wants to be longer and more considered than a social post. I needed a home for it. So: this blog. Why not just use an existing platform I’ve had a personal site for a long time. Over the years I’ve watched platforms change their terms, start charging writers, or simply disappear. Medium pivoted away from the model that made people trust it. Twitter has too many Nazis. LinkedIn is useful but is, in my opinion, a super needy, toxically positive address book. ...
A little over 10 years ago I wrote the design doc for SPIFFE, a standard for giving workloads cryptographic identities so services can authenticate to each other without passwords. I launched it at a talk at GlueCon that year. This was a unique thing as it was an “open source” project that was just a document. There was no code initially. I almost started a company around it but did Heptio instead. I handed it off to Sunil James who started a company and got it into the CNCF. Sunil and the folks at his company, Scytale, also wrote the companion reference implementation called SPIRE. ...
Well, here we are. This is the first post on the new joe.dev — a fresh Hugo setup deploying via Cloudflare Pages, with posts mirrored to ATproto via Sequoia. Nothing deep to say yet. Just kicking the tires and making sure the whole pipeline works end to end. More soon. Code highlighting Here’s some Go: package main import ( "context" "fmt" "log" "github.com/stacklok/mcp-go/pkg/server" ) func main() { srv := server.New("example", "0.1.0") srv.AddTool("greet", func(ctx context.Context, name string) (string, error) { return fmt.Sprintf("Hello, %s!", name), nil }) if err := srv.Run(context.Background()); err != nil { log.Fatal(err) } } And some Bash: ...