Development

Top 10 GitHub Project Setup Tricks You MUST Use in 2025!

Have you ever seen a GitHub issue that just said “it’s broken” with zero context? Or reviewed a pull request where you had no idea what changed or why? How many hours have you wasted chasing down information that should have been provided upfront?

Here’s the reality: whether you’re maintaining an open source project, building internal tools, or managing commercial software, you face the same problem. People file vague bug reports. Contributors submit PRs without explaining their changes. Dependencies fall months behind. Security issues pile up. And you’re stuck playing detective instead of building features.

But here’s what most people don’t realize: all of this chaos is preventable. GitHub has built-in tools for issue templates, pull request templates, automated workflows, and community governance. The problem is that setting all of this up manually takes hours, and most people either don’t know these tools exist or don’t bother configuring them properly.

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.