A few days ago, I published Devitri, my first open source project.

The project started as an attempt to solve a very specific problem related to synchronizing Obsidian vaults (a note-taking and personal knowledge management application that I’ve been using for several years), but it ultimately led me to a completely different reflection.

For the past six months, I’ve been building software in a way that, if I’m honest, looks remarkably similar to what I imagined programming would be like when I was a kid.

When I started learning to code, around the age of twelve, I was fascinated by the idea of being able to build anything I could imagine. Reality, of course, looked very different. Every project required learning new technologies, reading documentation, making mistakes, and slowly working through countless challenges. None of that has disappeared completely, but for the first time I feel that the distance between an idea and a functional implementation is significantly smaller than I ever imagined it could be.

Devitri wasn’t the first project I built using AI agents, but it was the first one that made me stop and reflect on how much my way of working had changed. Interestingly, the conclusion had less to do with artificial intelligence itself and more to do with how I approach new problems.

Six Months of Building with Agents

Over the past several months, I’ve been refining a workflow that looks quite different from the one I used previously.

Most projects begin with a long conversation in Claude. I typically use these sessions to shape an idea, challenge assumptions, explore alternative scenarios, and eventually produce something that looks surprisingly close to a traditional product requirements document.

From there, the work is distributed across different agents and models depending on the type of problem I’m trying to solve. Some conversations focus on architecture, others on implementation, documentation, or review.

To coordinate this process, I’ve been using tools such as Multica for task orchestration, Ollama Cloud for managing specialized models, Opencode for collaborating directly with agents during implementation, and Agent Memory to preserve context and important decisions across sessions.

While the tools themselves have evolved over time, the underlying idea has remained the same: creating an environment where multiple agents can collaborate consistently around a shared project.

After several months of working this way, I’ve stopped thinking about these systems as coding assistants. They increasingly resemble a group of specialists that I collaborate with depending on the problem I’m trying to solve.

I don’t want to give the impression that agents eliminate complexity or replace experience. If anything, my experience over the past several months suggests the opposite. The more capable these tools become, the more obvious it becomes that defining the problem correctly, establishing clear constraints, and maintaining a coherent vision of the system are what truly matter. Agents accelerate execution, but judgment remains the responsibility of the person leading the project.

What Actually Changed

What’s interesting is that the most significant change wasn’t speed. It wasn’t the amount of code I can produce in an afternoon, and it certainly wasn’t the ability to work on multiple projects simultaneously.

What really changed was the way I evaluate new ideas.

For a large part of my career, I defined myself through technologies. There was a period when I was primarily a web developer. Later, I spent several years focused on mobile development. Over time, I became increasingly involved in backend systems, infrastructure, automation, and software architecture.

Looking back, many of my decisions were influenced by the stack I was most comfortable with at the time. Some ideas felt achievable because they lived within familiar territory. Others were quietly set aside because they required learning too many new things before I could even validate whether they were worth pursuing.

I don’t think there was anything wrong with that. It was simply a natural consequence of the cost associated with exploring unfamiliar technologies.

The Cost of Exploration

After six months of working this way, I realized that I ask myself one particular question far less often than I used to:

Do I know enough about this stack to build this?

Not because experience has become less important, and certainly not because all technologies are equivalent. The difference is that the cost of exploration has decreased dramatically.

Today, I can investigate unfamiliar technologies, validate approaches, build prototypes, and compare alternatives at a pace that simply wasn’t possible a few years ago. What previously required weeks of research and experimentation can now often be accomplished within hours or days.

This doesn’t eliminate the need for experience, nor does it reduce the importance of sound engineering judgment. What it changes is where the limitations tend to appear. The barrier is no longer usually the technology itself; the barrier is understanding the problem well enough to design an appropriate solution.

For years, I believed that learning a new technology meant investing enough time to become productive within its ecosystem. Today, I think productivity depends on much more than accumulated knowledge about a specific framework, language, or platform. It also depends on the ability to ask good questions, evaluate answers critically, maintain context, and coordinate tools that amplify our capabilities.

In a sense, I’m still learning new technologies. The difference is that the process now feels much more like exploration than mountain climbing.

Devitri as Evidence

Devitri became a good demonstration of this idea.

The project involved backend services, frontend development, synchronization logic, deployment pipelines, infrastructure, Docker, documentation, automation, and an Obsidian plugin.

A few years ago, I probably would have evaluated each of those areas as separate obstacles. Today, I see them as different parts of the same system. Some are certainly more familiar than others, but none feel intimidating enough to dismiss an idea before giving it a chance.

That doesn’t mean every decision was correct or that the project was built without mistakes. Like any personal project, Devitri is full of iterations, changes in direction, and decisions that will likely evolve over time.

But that’s precisely where part of the learning happened.

The ability to explore new areas no longer depends exclusively on how much prior knowledge I have about a specific technology. Increasingly, it depends on understanding the problem, maintaining a clear product vision, and coordinating the tools available to move toward a solution.

Looking Ahead

I don’t know whether this way of building software will become the dominant approach five years from now. I also don’t know whether the tools I’m currently using will still exist a few months from today.

What I do know is that my relationship with learning and technology has changed significantly.

For the first time in a long time, I feel that the primary limitation of a project is no longer the technology stack required to build it. The hardest question is no longer how to build something; it’s deciding what is worth building in the first place.

And I suspect that will remain a deeply human responsibility for quite some time.

That’s why, when I look at Devitri, I don’t just see a note synchronization tool or my first open source project.

I see evidence of a new way of building software.

And, at least for me, that’s far more interesting than the project itself.