How Feature Slicing and AI-Augmented Engineering Reinforce Each Other

In a field where developments follow each other at a rapid pace, it’s not uncommon for two seemingly independent trends to unexpectedly strengthen one another. This is the case with the concept of feature slicing and the rise of AI-augmented engineering. AI tools like GitHub Copilot benefit from the advantages of feature slicing while also compensating for some of its drawbacks. I’ve experimented with this in my current project — with surprisingly strong results.

Feature Slicing

Software development ultimately revolves around the functional requirements of an application. So why not align the architecture accordingly? Instead of spreading functionality across application layers, feature slicing focuses on co-location: all code related to a functional requirement is grouped together — ideally in the same folder, or even the same file. Like any architectural concept, this comes with both benefits and drawbacks.

Code Co-location

One of the biggest advantages of feature slicing is that all code related to a feature is located in a single place. This makes it much easier for developers to find and modify the right code when changes are needed. There’s no longer a need to search across multiple projects or folders. Feature isolation also helps minimize the potential side effects of changes.

AI tools enjoy nearly the same benefits. An AI agent has less code to sift through when making changes. It also doesn’t need to modify unrelated code when implementing new features. As a result, the risk of an agent unintentionally breaking another feature is reduced. You can even drop an entire feature file into the AI chat window for processing.

Unfortunately, co-location also brings some challenges for developers. Feature slicing sometimes clashes with the DRY (Don’t Repeat Yourself) principle. A lot of boilerplate code may be needed to make a feature fully independent. It’s also generally discouraged to share functional logic between features, which can lead to duplicated code. This can be partially mitigated by placing domain logic outside of individual features.

However, AI can make code duplication virtually effortless. If you’re not writing the repeated code yourself, is it really still bad practice? Ultimately, it’s up to you to strike the right balance.

Feature Design Documents as Prompts

If you value documentation, you’ll probably already document each feature in a feature design document. You can create your own standard template for this, which typically includes:

• Feature name and description

• Context of the feature

• Design

• Error handling

• Test plan

• Authorization

A thorough design document makes implementing a feature much easier — most of the thinking is already done. Once documented, it also serves as a ready-to-use AI prompt. The better the design document, the better an AI agent can execute it — and you’re left with excellent documentation as a bonus.

Optimizing Prompt Context

In a feature slice architecture, you can fully tailor each feature to meet its specific needs. In practice, however, it helps to define conventions for how different feature types are structured. This provides clarity for developers and improves code quality.

Once you’ve documented these conventions, you also have a context file you can give to an AI agent. While AI tools are getting better at understanding your environment, providing that context explicitly still produces better results.

In my current project, I created a prompt context file for this purpose. This file describes what a standard API endpoint feature should look like. With that guidance in place, collaboration with AI has become more consistent and efficient.

The context includes, among other things:

• Project structure with folders and naming conventions

• Database setup

• Description of a feature file

• Example feature implementation

• Description of a standard test class

• Example test

If you notice the AI agent frequently making mistakes — like choosing the wrong mocking library — you can include those clarifications in the context file. How specific you need to be depends heavily on the AI model you’re working with.

Results

In my project, I used the method described in this article to implement a series of basic CRUD features for a new database entity. Due to their relatively low complexity, these types of features are excellent candidates for AI implementation.

It started with copying and pasting the context file and the feature design into Copilot’s chat window. After some iteration on the context, I was able to use Copilot’s edit mode to generate the entire feature implementation. This was even before the Copilot Agent mode was available in preview — which will make this approach even more effective in the future.

After experimenting, I reviewed and tested the code. Only minor adjustments were needed. In fact, one of the changes I made turned out to be incorrect — Copilot had interpreted the feature design document more accurately than I had.

As a result, I spent roughly 30–50% less time on these features than if I had implemented them manually. That means less time on repetitive, simple programming tasks — and more time for solving the interesting problems.