When people ask what engineers are for now that AI writes the code, we think the question comes from a misunderstanding of what an engineer does. A lot of weight has always been put on the code.
It made sense for a while. Code took so long and was so complex that the job looked like translation. The CEO says “I want this”, and you think: fine, how do I turn that into code that does it? So it really does look as if that is all the engineer did.
But that was never the role. The role of an engineer was to have an environment and know how to solve problems in it with whatever was available. If code is what you have, you solve it with code.
Often engineers did everything they could to avoid writing it: take this library, that one, wire them together, done. No new code, and the problem is solved.
That is still the job. Here is what it looks like on a normal day, and in one example from our work on AIFindr.
An agent sets the day’s priorities
One of us works with Codex and Claude Code side by side, with a lot of things running in parallel, and starts every day with two agent sessions. One reviews all the email. The other is connected to Slack, email, Notion, practically everything, and its job is to say what the priorities are.
There is a Notion document with all of them. The agent goes through it: this one was due today, this one has already moved forward. An urgent Slack message about something that needs doing becomes a new priority and a new task.
The agent manages those priorities now.
Our attention caps how many tasks run in parallel
With the list ready, everything that can run in parallel gets launched, which is usually most of it. The first wave is easy: go and research this, look at what is happening here, find out why this is not working. That is four or five tasks, more or less.
Then come the implementations that have already been running for several days. Review what was done the day before, decide where to go next, read what results came back.
Altogether, five, six, seven tasks is what one person can sustain in this setup. More could be launched. But as they finish, each one needs attention, and someone has to get involved and see where it went. How many agents you can run depends on how much your own mind can process.
An example: the agents built the filter, we supplied the constraint
On AIFindr, people were typing their personal data into the chat, and we needed to clean the PII out of each message before it reached the main model. Our first attempt put a third-party model in front of the main one. It worked, but it was very slow: the user waited too long before seeing an answer. And the raw PII still had to leave our infrastructure, something a major Latin American bank we work with would not accept.
Optimization is always a rabbit hole, one you can go into and not come out of for a month. So we sent coding agents down it instead. They researched open-weight models that could run inside our own infrastructure, a setup complicated enough that the engineer who led this would have spent two months learning it. The agents did it in an hour or less.
They tried several models and found one that filtered the personal data out of users’ queries in 100 to 200 milliseconds. It matched the remote model on the evaluation set we had built first. From idea to a working service took practically no time.
The first version ran on a GPU. It was fast and private, and it came to about EUR 1,340 a month for that one feature.
That is where the engineer has to step in: you have this constraint, that is too expensive, look for alternatives. We gave an agent a stricter goal: keep the privacy, the quality and the speed, and make it sensible to run. It looped through hypotheses, testing each one against our evaluations and benchmarks, until it found an answer we had barely considered: no GPU at all. Before deploying, we used the previous months’ usage data, requests per second included, to load-test exactly the setup we would run. It now runs on small ARM CPU tasks for about EUR 120 a month across all our environments, 91% less. The full story is in our post on AIFindr Privacy.
The agents did the research, the setup, the load tests and even the search for a cheaper architecture. Their first working answer was too expensive to run, and the constraint that ruled it out was ours. So was the evaluation set that defined what good enough meant. The AI can do practically anything, but not everything is actually right for your problem. That judgment, and knowing how to guide the AI, is our job now.
The bottleneck moved to the ticket
When a ticket does not land in one shot, we see a bit of both: sometimes the miss is in the code, sometimes in the ticket. But getting the code right on the first try keeps getting easier. Getting all the context into the ticket does not, especially when part of it has not been figured out yet. That is why the engineer still reviews the result and decides whether it actually does what we need.
With Facility we automated the path from ticket to production. Now we are working on the step before it: taking what is in people’s heads, meetings and chats, and turning it into tickets with enough context for more PRs to land in one shot.
The problems got bigger
So what is AI? Right now it writes very good code. We would call it a tool, except it is obviously much more than that. It is one more thing we have available, and as engineers what we can do now is understand it, learn to use it well and know it well enough to solve problems with it.
We are not going to spend our time painting a button blue anymore. We are going to be working on problems closer to curing a disease. The problems have grown in complexity, and what we have to do is take a tool that powerful and, with an engineer’s mind, apply it correctly to the problem and find the solution.
The next time an optimization looks like a month-long rabbit hole, send the agents down it first. Keep the constraint for yourself.
This piece is one of a pair. The other, Engineers finally have time for the problems nobody could prioritize, is about what to invest in: skills, our own tooling and how we learn. This one is about how the work gets done.