Triptease on Yesterday I was wrong

Picking a Language for Agents

Thu, 30 Apr 2026 09:00:00 +0000

This is the final part of a 5-part series on agentic engineering. Part 4 laid out architectural principles for choosing languages and runtimes. This post puts a handful of worked examples through those principles, just to show what the analysis looks like in practice.

This isn’t a list of “the languages I use”, and it isn’t exhaustive. It’s a deliberate move away from personal taste — what I happen to know, what’s fashionable, what the team is already comfortable with — and toward something more objective: which language properties best fit the agent and the problem domain in front of you. Different problems will pull you toward different answers, and the examples below are picked specifically to make that point.

Agentic Architecture

Wed, 29 Apr 2026 09:00:00 +0000

This is part 4 of a 5-part series on agentic engineering. Part 1 set the values-vs-mechanisms frame. Part 2 covered pairing and learning. Part 3 made the case for harness engineering. This one is about the architecture underneath the harness — the language, runtime, deployment, and version-control choices that make agents safe.

Part 5 gets concrete about specific languages.

Why architecture changes with agents

If humans are no longer the primary readers and writers of code, then architecture should no longer be optimised only for human familiarity. Instead, I want to optimise for:

Harness Engineering: Building a Factory for Code

Tue, 28 Apr 2026 09:00:00 +0000

This is part 3 of a 5-part series on agentic engineering. Part 1 made the case that we keep Agile values and change the mechanisms. Part 2 walked through what that looks like for pairing and learning. This post is about the thing that does most of the work once agents are doing the execution: the harness.

The reframe

We are no longer primarily writing code. We are building a factory for generating code safely.

From Pair Programming to Co-Steering

Mon, 27 Apr 2026 09:00:00 +0000

This is part 2 of a 5-part series on agentic engineering. Part 1 made the case that Agile values still matter; the mechanisms are what change. This post takes the most contested of those mechanisms — pair programming — and looks at what happens to it when one of the “pair” doesn’t need a keyboard.

I’ve been a fan of pair programming for a long time. At Triptease we’ve leaned on it because it improves quality, accelerates learning, spreads context, builds resilience, and quietly does a lot of work for team cohesion. Those outcomes still matter.

From Agile Engineering to Agentic Engineering

Sun, 26 Apr 2026 09:00:00 +0000

For most of my career, “doing engineering well” has meant doing Agile well. Fast feedback, sustainable pace, simple design, close customer collaboration, all the values from the Agile Manifesto that I’ve spent twenty-odd years arguing about over coffee. At Triptease those values still pay rent: they help us deliver, adapt, collaborate, and not burn out.

What’s changing is who is doing the work.

The hard part of software has never been the typing. It’s always been translating fuzzy intent into a working solution: understanding the problem, choosing the design, working out what “correct” actually means, and keeping all of that consistent as things change. That’s where the real time has always gone.