It is Q2 of 2026 and agentic coding is so thoroughly ingrained in our daily development process that life without it has started to become unimaginable. Don’t we all sometimes wonder: How did people travel to another country before translation or navigation apps? How did people survive without emails and smartphones? Pretty soon it’s going to be: how did people write code before AI agents?

If like my team, you are using agentic coding responsibly in a serious production project, you might have noticed another change - the code repo has markedly improved.

I have previously argued that engineers using agentic coding should think like managers. But perhaps you are not interested in management. You don’t know what managers do and don’t want to learn to think like them. You are put off by all the manager-analogies and wish they’d stop. Perhaps you are the artistic type, who thinks of themselves as a software craftsperson.

So let’s change the subject and talk about something interesting, like art. Hey how about that Rubens? Do you know his process on some of his famous paintings like The Elevation of the Cross?

Developers new to agentic coding are at risk of having the wrong expectations. When they try coding agents for the first time, it feels like magic. But cracks appear when AI is used without understanding its limitations. People tend to dismiss agentic coding if it doesn’t work “perfectly”. This is unfortunate, as coding agents are in fact very impressive.
It is said that managers have been vibe coding forever. Now, if ICs are also vibe coding, are they like managers?

It’s been about two months since my team started using Gemini as part of their daily coding workflow. We observed that while AI is powerful, it requires some effort to keep it aligned with our requirements, lest it runs amok.

When we simply gave it a problem statement and let it work, the output was sometimes not what we wanted to achieve. Our simple prompts failed to specify constraints, conventions, and success criteria. Gemini was making assumptions that didn’t match our expectations.

Last year I transitioned to the role of engineering manager on a complex, legacy service with a poor reliability record. As a first-time manager I found it challenging to plan a roadmap that can balance tackling reliability issues and reducing technical debt on one hand, and building new features on the other.

Developer time is a very precious resource. As a manager, you want to spend it in a way that produces compounding benefits over time. So I came up with some guiding principles to help me prioritize work in a way that keeps the system running, with hopefully fewer hiccups over time.

“Tenbagger” is a term coined by legendary investor Peter Lynch to describe stocks that provide tenfold value on the initial investment. As software engineers we make scores of decisions every day in the face of ever-evolving requirements, whose impact on the architecture might only become visible down the line. It’s nice when a relatively low-effort code change ends up providing compounding benefits over a long time horizon.

I am currently working on a critical component in a distributed system for a food-delivery app. One of its core responsibilities is to receive information from an upstream service and pass it into downstream services. The feature requirements typically follow this pattern: customers can now provide a backup phone number, which should be shown on the delivery app. So an order passing through a chain of systems can now contain a new field, which needs to be forwarded to relevant downstream services.

Why?

There are several reasons why you’d want to squash the database migrations in your Ruby on Rails application:

1. In a long running project you may end up with hundreds of files in your db/migrate folder over time. Carrying these legacy migrations incurs maintenance overhead. For example, when upgrading the Rails version, you may need to modify those old migrations for syntax changes.

2. If your build process involves recreating the database to run the tests, it would need to run all of these old migrations. Running a lot of migrations would slow down the build time.

   [Read more]

A query plan is a sequence of steps used by a database to access data. Being able to read a query plan is key to understanding the performance of an SQL query. While tuning a query we need to know how the rows are being fetched from the tables? Are the indexes being used? What is the cost of joining to tables? A query plan provides with an answer for all of these questions.

Suppose you are tasked with writing tests for a Spring and Hibernate application. This application uses a mix of native queries, HQL or entity associations to fetch data from the database. If you choose to mock the DAO or entity layers, you leave a significant portion of the code untested. In such cases data integration tests can provide the most correct feedback. But you do you configure your application to run integration tests?

It’s not just pulling off a complex engineering feat that makes programmers love their jobs. There are small pleasures to be had even in your day to day tasks, if you look for them.

Seasoned programmers know the thrill of recognising the possibility to introduce an abstraction over duplication. A task as simple as renaming a variable can be the difference between obscurantism and lucidity. It’s the boy scout principle in action. Making your code a bit more pleasant to revisit. The joy one derives in these simple improvements is akin to Amélie’s les petits plaisirs.