Last week, I had a bit of a “lightbulb moment” while working on a major project. Since the start of 2026, I’ve been buried in a massive redesign of one of our Go microservices. It was a necessary move to prepare for future features, but the effort required was significant.
The Freedom (and Challenge) of Go
The Go ecosystem is unique because it doesn’t force a specific project pattern or design model on you, unlike the rigid structures you might find in Spring Boot. Because of this freedom, many teams try to invent their own patterns. I want to break down my specific approach here and explain why I believe it is particularly well-suited for the era of Artificial General Intelligence (AGI).
Instead of following a traditional layered folder pattern, I shifted to a feature-focused structure. When I first started with Go after coming from a Spring Boot background, I was excited by the power it gives developers to build great software. However, I often found myself spending too much time just trying to understand how a project was organized.
Modularity as a Feature Boundary
Go prioritizes modularity, which is incredibly helpful for breaking down tens of thousands of lines of code into readable files within a package. I realized that if Go gives us this modular power, we should treat each module as a distinct feature. In my early days with Spring Boot, we focused heavily on layers. This meant new joiners(i mean new devs come to the codebase) had to spend a lot of time adapting to the architecture before they could be productive. Go’s modularity simplifies that.
At the same time, I also started realizing how naturally this approach aligns with Domain-Driven Design (DDD). Organizing services around business capabilities instead of technical layers makes the codebase feel much closer to the actual domain itself.
Of course, this is not a silver bullet for every web service. Different systems have different needs. But from my experience building saas applications especially products with rapidly evolving business requirements the feature-based approach has felt far more practical and scalable than heavily layered architectures.
The AGI Connection
Here is where it gets interesting. Over the last couple of weeks, I’ve been conducting R&D on building agentic skills for web microservices and developer tools. I noticed that the agentic skills powered by our newly redesigned, feature-based services performed exceptionally well. The AI acted like a true development partner.
I didn’t have to tell the agent exactly where the code was. While watching the agent’s “thought process” during evaluation, I noticed it was navigating the codebase feature by feature. It wasn’t burning through tokens switching between disconnected files to understand the logic. It grasped the context and completed tasks much faster.
The Takeaway
I am convinced that in the age of AGI, our folder structures need to be revolutionized. In the past, it was just the developer versus the computer. Now, we have agents working alongside us to solve real-world problems. The way we organize our code should reflect that partnership.
In my next post, I’ll talk about the importance of building a centralized agentic brain for an organization. I’ve been making great progress in my R&D on this topic, and I’ll share those insights as soon as I have a moment to breathe.