Half of the year 2026 has passed, and our team still manages to write most of the code by hand, do most of the ideation and system design by themselves, and review all the changes going out manually.
Again, in the year 2026, AD, mind you. In a very small team with a lot of backlog. Now depending on which side of the fence you hang your legs, that is either worth a kudos, or incredibly silly and unproductive.
It is not that we are unaware of the tools, or the productivity unlock that has taken many a 1x engineer to 10x 100x. We do use them to tinker around and work on tools for our own uses or passion projects. But we've managed to exercise restraint in our day job. Both because of news like this, but also due to our own validation of affects on brain and stress that comes with fast-lane agentic engineering. Plus, it doesn't hurt that we're working in the medical domain, even though we aren't a medical device software.
But you can only resist so much, specially when the backlog and possible opportunities look at you with longing eyes. And we've all tasted blood already. So it makes sense to set some rules of engagement so we don't falter and end up handing the control to the invisible AI agents.
We'll start with the type of work itself. Not all tasks are created equal, some are more equal than others.
Tasks that are interesting for the engineers, or are in the critical areas of the business should not be vibecoded. I created this matrix some time ago to decide where a task falls,
(And wrote about it in my newsletter here)
This however is changing, I see the creep of AI assisted building core feature rising on the horizon. As well as delegating things we want to have in the product but don't have time for, to the LLM.
So for when we let the LLM take over the wheel, I came up with the following rules that should apply,
- 1.
Specify the need. Assign a tangible benefit to a task you want to get AI to do. Does it solve a real known problem? Can you name a person who will benefits from it. Would they be willing to pay for this?
- 2.
Do your own thinking. Don't let the AI design or come up with the main suggestion of how you want something to work. Always have your own opinion, even on things you are not the expert on. Read, form opinions, then use AI as your sparring partner.
- 3.
Use your own words. Write what the task needs to achieve in your own words. If the task is small, not more than a couple of sentences are needed. But write it yourself before you hand off the work.
- 4.
Distributed responsibilities. The agent session that you use for research and sparring is not the one that writes the code. The agent (or even model) you code with is not the one which reviews the code
- 5.
You're the main reviewer. You are the first human reviewer for the code written. The AI code review comes after. Another human who reviews the code comes into the picture last.
- 6.
No releases immediately afterwards. There should be a fixed rollback window that should follow a release that was coded this way.
- 7.
You own the feature. If something breaks in production, it is your responsibility, not the agent's or AI's.
Of course, this is an initial draft recommendation that we will use and may be different for others. Over time, it may change for us even. But hopefully, this helps us (or you) go from 1x to 1.5x while maintaining quality in the process.