Development

How I Tamed Chaotic AI Coding with Simple Workflow Commands

You know what’s absolutely maddening about working with AI coding agents? They’re brilliant one moment, then completely fucking chaotic the next. They’ll write perfect code for your database layer, then completely forget about it three prompts later when you’re working on the API. They jump from task to task like rabbits on crack, losing context and making decisions that seem smart in isolation but are completely insane when you look at the bigger picture.

Here’s the thing: if you’re like most developers, you’ve probably tried to wrangle AI agents with existing tools, and you’ve probably been disappointed. Maybe you’ve used Jira or Linear to track what the AI should work on, or tried some of the newer AI-specific task management tools. The problem is that most of these tools either don’t work well with AI agents, or the ones that do provide workflows that just don’t fit how I actually think about building software.

Mirrord Magic: Write Code Locally, See It Remotely!

Imagine this scenario.

There is a frontend application that talks to a backend which uses a database.

I am working on the code of that backend application.

I neither have nor care about the code of the frontend app and I do not have the database running locally. All I want is to write the code of that backend application and see the outcome of my work, either directly or through the frontend (the one that I am not running) and I want that local code to be connected to the database (which I am also not running).

Stop Using Docker and Local Kubernetes for Dev Environments! (feat. Okteto)

You are developing something. Everybody is, no matter whether that something is a user-facing application, infrastructure, or anything else.

While developing, you are trying to set up a development environment, probably locally since that’s where your code is. You are likely trying to do all that using Docker or a local Kubernetes cluster like KinD.

If that’s what you’re doing, I’m here to tell you that you’re doing it wrong.

Remote Environments with Dev Containers and Devpod: Are They Worth It?

Today we are going to explore running remote ephemeral development environments. We are going to see (potentially) the best solution you should (probably) NOT use. If that sounds confusing, you’re not alone.

We’ll explore the Development Containers spec as well as Devpod as an implementation of that spec. Together, they provide a way to run ephemeral development environments.

There is a hidden reason for going through those. I have serious doubts about the story behind remote environments, at least in a specific form, and I want to discuss what we really want them for. But, to do that, we need to go through a few practical examples to be on the same page before I go off the beaten path and start questioning it all.

Buckle up. You’re in for a ride that starts with some important questions that turn into excitement and finish… Well… I do not yet know how it will finish.

Nix for Everyone: Unleash Devbox for Simplified Development

Nix is amazing, but also very difficult to manage. It assumes that you learned its programming language and that you are willing to ignore frastration generated by horrible documentation. I think it is one of the most useful projects out there that cannot be used by anyone but those willing to dedicate their lives to Nix.