Have you ever reached lunchtime or the end of your workday, started a task for an agent before stepping away, and then spent your break wondering what it was doing, whether it had found a solution or finished the task?
Unfortunately, this is something I have found myself doing more often than I would like. After noticing it for several months, I started asking friends and colleagues how they were integrating agents into their personal and professional lives.
In this post, I want to share a few of the things I have learned and noticed while working with agents on a day-to-day basis.
AI removes a natural filter on ideas
Before AI agents made software implementation much faster, ideas required significant effort to realize. The high implementation cost forced prioritization. We had to sit down and think about why we wanted to do something, often starting from the assumption that it was better not to do it unless it was genuinely needed.
These high implementation costs created stronger incentives to prioritize and search for simpler alternatives. This encouraged people to simplify problems and decompose them into smaller sub-problems that could be tackled independently.
For example, with AI, you might now be able to refactor your entire API surface in a matter of hours. However, you would still have to fit that change into the existing system, figure out backward and forward compatibility, and deal with the fact that integration remains the bottleneck. The scope of the change would also become massive, along with the surface area for potential bugs.
Before, you might have decomposed that refactor into multiple steps because of the complexity involved. Or perhaps you would have postponed the refactor entirely because it was not actually necessary.
Delegation is not ownership transfer
When I build software with AI, I do not simply delegate a task, let the agent do the work, and then magically have the result appear in production. I usually delegate the implementation, but the responsibility, the consequences, and the high-level judgments are still mine to carry.
This distinction is crucial when working with AI. The cost of producing changes becomes very low because AI can write most of the code, but the cost of integration remains. Integrating a change does not simply mean writing it into the codebase. It means understanding the code, reconciling it with your mental model, deciding whether the change should exist at all, explaining it to other people, taking ownership of its long-term consequences, putting it through a review process, deploying it, considering backward and forward compatibility, and assessing the impact it may have on other systems.
My point is that writing code is only one part of our job as software engineers. Many other responsibilities come with working in an organization, with people who have expectations, systems that may outlive us, and entire companies relying on our code to power their businesses. We should not conflate vibe coding with AI-assisted software engineering.
Ownership is deeply connected to this. I believe ownership is extremely important, even more so now that AI can build so much while we remain ultimately responsible for what it produces.
Being responsible for what AI produces means that we need to check its work and carefully think through the implications of the changes it makes. This brings us back to the cost of integration.
The perception of activity is skewed
Another thing I found myself questioning was whether I was actually becoming more productive or simply surrounding myself with more evidence that something was happening.
All of my agents were running and producing changes across the board. My brain, still shaped by my previous way of working, reacted as if to say, “A lot of things are changing, tests are passing, so we are making progress. We are being really productive.” I could finally do the job of five versions of Riccardo from only a year earlier.
The problem emerged at the integration stage. The activity was real. The problems were being worked on, but the visible signs of activity exaggerated how complete, integrated, and valuable the work actually was. Often, it was simply a large amount of code solving a problem that might have been better addressed by not writing code at all and changing something else instead.
This ties back to what I said earlier: friction can force us to spend more time evaluating other options because we know how expensive an implementation will be. In the process of searching for alternatives, we may realize that our original idea was suboptimal. In this sense, friction itself becomes an important step toward finding a better solution.
Agents parallelize execution but not attention
When I first started using these AI tools, I had a single clone of my repository and tackled one task at a time. I babysat the model, checked its output while it was working, and tried to steer it toward the correct solution as quickly as possible.
Over time, however, things changed dramatically. As the models became better, I started letting them work more independently.
This put me in a position where I had to decide how to spend my own time. One part of me would say, “No, do not start something else. Focus on the task you are already doing and perhaps work on something less complex.” Another part would say, “Start something else. The agent will take care of it.” This is how I began parallelizing more of my work.
I started creating multiple clones of the same repository and even kicking off work across several repositories. Initially, this felt like a very smart idea: I was solving more problems and felt much more productive. In a literal sense, that was true.
However, I eventually realized something: I could parallelize execution, but not my attention.
I could only properly focus on one thing at a time. Even though I was able to coordinate multiple streams of work, I could not give each individual task as much attention as I would have if I had worked on them sequentially. This became a problem because I was less attentive to the details of the implementations the models were producing.
For me, parallelization was already a problem before AI, and AI only made it worse. Early in my career, I had a tendency to start new work as soon as one of my pull requests was ready for review. But I often ended up getting lost in all of the work I had started, and sometimes I became stressed for no real benefit.
One research paper reported that two experiments showed that people need to stop thinking about one task in order to fully transition their attention and perform well on another. The results also suggested that people find it difficult to shift their attention away from an unfinished task, causing their performance on the next task to suffer. (Source)
In my case, each running agent became another unfinished task that remained partially active in my mind. This caused me to constantly switch between tasks and lose track of what I was doing.
Striving to keep the agents running
Using AI agents in my day-to-day work has definitely increased the number of problems I can solve, especially because I can solve the problem conceptually and then ask the agent to implement the solution. Execution therefore takes much less of my time. Agents are also extremely helpful when thinking through edge cases or debugging bugs that are difficult to reproduce.
However, this agentic coding craze has also created a new impulse in me: the desire to keep my agents running at all times.
These agents usually continue working after receiving a prompt until the prompt has been satisfied or they become blocked.
While this sounds great in practice, it creates a major problem. In the past, if I was working and then had to go to lunch, I had no choice but to stop working, enjoy lunch, and return to my desk afterward. Now, I always have the thought that I could start an agent and let it work while I eat. Then, while I am eating, part of my mind remains occupied with what the agent might be doing.
This is a problem because work begins to creep into leisure time.
Since I now work from home at Supabase, I notice this even more. I usually eat lunch alone, and my computer is in the living room. I often let agents run while I am eating, but if I see that one has finished, I interrupt my lunch, return to the computer, and try to keep it active. I really dislike this because it prevents me from fully enjoying my free time and makes it difficult to take a proper break.
This became even worse with the introduction of remote-control capabilities for Codex and Claude Code, which let me control my instance remotely from my phone. Although I think this is an incredibly useful feature, it creates even more opportunities to keep my agents running.
I then asked myself: why does an idle agent start to feel uncomfortable?
I think each of us may have a different answer, but for me, it is because I ask myself, “If this tool can reliably do useful work while I am eating, why would I leave it idle?” This is a second-order effect of having cheap and asynchronous execution at your fingertips.
More work is still more work
Parallel work sounds appealing, but every additional task must still be serialized through attention and integration.
The amount of work created a few problems for me. I ended up with many open PRs: some were waiting for review, some were still drafts, and some I had even forgotten existed.
The problem with these PRs was that their cost increased over time. As I lost the context required to evaluate them, the work they contained became more expensive to review and integrate.
This raises a natural question about the word “productivity.” If the work is generated and then abandoned, was it productive output or just production?
The paradox
While writing this article, I came to realize that there is a strange paradox surrounding agents.
The paradox is that the better agents become at working without me, the harder it becomes for me to stop thinking about their work.
One might expect that if agents become better at working independently, we would have less reason to think about them. Instead, the opposite seems to happen.
The reason for this paradox is difficult to explain, and I think there are several deeper causes. Responsibility still remains human. The results and progress of the agents become personally interesting. Agents can still perform unwanted actions. And we constantly feel the desire to steer them with new ideas and insights that emerge while they are working.
At this stage, I do not think we should optimize for agent autonomy without also designing clear boundaries, feedback loops, verification, and accountability mechanisms.
At the same time, ownership should remain tied to the person responsible for the work, along with all the consequences that responsibility entails.