When I started using artificial intelligence in software development, a pattern quickly emerged in my workflow. I spent my time repeating our programming standards at the start of every new session just to ensure it produced a satisfactory solution.

Talking with colleagues, I realized I wasn't alone. They were experiencing the exact same frustrations! I even heard one of them say: "I spend more time fixing what the AI suggests than actually coding myself. It never does exactly what I want!"

This sentiment is widely shared across the community. For anyone just starting to explore AI and its capabilities, it is crucial to understand a fundamental aspect of current models: AI doesn't learn.

Whether you are a developer, product manager, or designer, this reality remains true and will change the way you collaborate with it. Let's look at how AI works conceptually and how we can help it adhere to our working practices.

How AI Truly Works

The Illusion of Understanding and the Trap of the Average

To understand the source of our frustrations, we must first dispel a persistent illusion: AI does not "understand" what it is doing. Tools like ChatGPT or Claude are fundamentally extremely sophisticated statistical engines. Their job is to predict the most likely next word based on what you have just typed. It is computation, not thought.

This probabilistic nature leads to a second major problem: amnesia. Imagine a brilliant colleague who has read all the documentation in the world, but completely loses their memory every time they walk through your office door. During your discussion, they are incredible. They adapt to your feedback, course-correct, and give the impression of learning. But as soon as you close the window and open a new conversation, they start from scratch. They have forgotten everything about your preferences, your project's architecture, or the mistakes they fixed the day before. Their only memory is the history of the current conversation.

Since it starts with a blank slate every time, the AI adopts a default behavior: it aims for the middle. This is the 50th percentile problem. Without specific context about how you work, it will generate the most statistically probable response based on its training data. Asking it to generate code? It will use the most common patterns found on the internet, not necessarily the ones your team spent months standardizing. It will never be truly bad, but it will never be excellent either.

In short, the AI retains the immediate context of your current discussion well, but it systematically forgets everything else. And even this short-term memory has its limits: if your conversation drags on or you feed it too many files at once, it hits the limit of its "context window". To keep functioning, it will start compressing the history or "forgetting" certain information you provided. The quality of its responses will then degrade.

Without your intervention to structure this memory, it will remain forever stuck in this generic average, or eventually lose its way.

The Illusion of Continuity: What AI Remembers and What It Forgets

This is where we need to make a fundamental distinction that many of us confuse at first: the difference between intra-session and inter-session memory.

In the heat of the moment, the illusion is perfect. The AI reads the contents of the files you provide, follows your prompt's instructions, and grasps the immediate context of your question. If you correct it on a specific point, it adjusts for the rest of the discussion. This is known as intra-session memory. It retains absolutely everything that happens in the current conversation. But it's temporary. It disappears as soon as the session ends.

The problem arises when you close the tab. That's when inter-session memory should take over to retain information from one discussion to the next.

In recent months, tools like ChatGPT, Gemini, and Claude have started integrating inter-session memory features. These are designed to retain certain information from previous conversations. What information gets saved in this memory? That is at the tool's discretion. You never really know what the AI has retained, what it has forgotten, or how it interprets it. The files, however, remain available on your computer.

Despite this, with each new session, the AI tends to start from scratch, back at its famous generic 50th percentile. Unless, of course, you take control and explicitly build this memory yourself.

But if left to its own devices, what happens when we use AI without taking this amnesia into account?

The Trap of Blind Delegation and "Vibe Coding"

When we ignore the limits of AI memory, we mistakenly assume it keeps the full complexity of our project in mind. We easily fall into a trap increasingly known as "vibe coding." The concept is simple: we vaguely describe what we want, the AI churns out code, we accept it without really trying to understand it, and we move on.

We've all seen stories online of people with no technical background producing entire applications this way. The problem is that the result can lack crucial development elements, such as security. Furthermore, as soon as the project needs maintenance, everything falls apart. If the AI can't fix a bug, what happens? The AI may know security rules, but if we don't explicitly guide it to our specific context, it won't apply them by default.

Vibe coding isn't inherently bad. For building a proof of concept, quickly testing an idea, or visualizing a prototype, it's a valuable shortcut. But trying to turn it into a final product without the necessary expertise to validate the code is a recipe for disaster.

This is where we risk diluting our own expertise. You know the story of the designer who charges $5,000 for a logo sketched on a napkin in five minutes? To the outraged client, he replies that he is actually charging for the twenty years of experience that allowed him to do it so quickly.

With AI, we risk reversing this logic. If the machine generates all your code and you no longer understand the thought process behind it, the expertise remains locked inside the tool. Your codebase becomes a black box that no one on the team truly understands anymore. Ultimately, the AI's output is only as good as the person using it. Without the expertise to guide and correct it, we settle for mediocre work and gradually lose our ability to do better.

How do you know if you've crossed the line into blind delegation? There are telltale signs. The first is when you find yourself unable to explain the code you just integrated to a colleague. Another classic symptom is finding yourself asking for the exact same thing in every new session. The AI has forgotten, you start over from scratch, and the time supposedly saved is lost to repetition.

Worse still, accepting the first result without reviewing it turns this false sense of speed into massive technical debt. If an entire feature is generated this way and the context isn't documented, the slightest future maintenance will turn into a full-blown archaeological dig for the rest of the team.

Fortunately, these traps are not inevitable. They can be avoided simply by changing how we interact with the tool on a daily basis.

Iterative Feedback: Small Steps, Big Impact

In my experience, it's very tempting to ask the AI to produce a lot of code or content all at once. I spent weeks tirelessly fixing the exact same mistakes before realizing the problem wasn't the tool. The problem was that I wasn't documenting anything. The broader the task you give it, the more generic and disconnected from your actual needs the result will be.

At its core, this is the exact same philosophy as traditional product development. When building software, we no longer code in isolation for six months before showing it to customers. We work in small iterations: we deliver a feature, observe how users react, and adapt.

Working with AI requires the exact same dynamic. Instead of asking for a complete feature, proceed iteratively:

1. Ask for a small, clear task
2. Verify what was produced
3. Correct it if necessary
4. Document what works
5. Move on to the next task

This rhythm has a twofold advantage: it keeps your own understanding of the code up to date and drastically limits quality drift. Each feedback cycle becomes an opportunity to realign the AI before it strays too far from your vision.

This is where what I call "active correction" comes into play. I set a simple rule for myself: if I fix the same thing more than once, it's a signal that I need to add it to my configuration files.

Every time you correct the AI, ask yourself if you can ensure it never makes that mistake again. If the answer is yes, it's time to act. You aren't just fixing a one-off problem; you are preventing all future occurrences. This is exactly what bridges the gap between a simple tweak and building a lasting memory.

Let's take a concrete example. You ask the AI to create a utility function in TypeScript. It produces code that works, but it's riddled with any types, lacking any strong typing. You manually fix the types. Instead of stopping there, you ask yourself how to prevent this from happening again. You then add a rule to your AI configuration file instructing it to always use explicit types in TypeScript and never use any. In the next session, the code will be strongly typed right from the start. You have just turned a fleeting correction into a permanent improvement.

Giving one-off feedback to the machine is good. But for these corrections to survive beyond the current session, they absolutely must be anchored somewhere.

Building AI's Memory

The AI's automatic memory remains temperamental. Since we control neither what it decides to retain nor how it will use it, the only real solution for software development is to build it a custom artificial memory. The principle is to write your conventions, decisions, and preferences into files that the tool will read automatically. For the machine, these files become its absolute source of truth.

In practice, this starts with a simple configuration file at the root of your project. Depending on the tool you use, this could be a CLAUDE.md, a .cursorrules, or an equivalent. This text file is versioned in your repository, and the AI reads it at the beginning of every conversation. You put your team conventions, architectural decisions, and coding rules in it. This is the simplest and most powerful lever at your disposal. With each new session, the AI starts with your context rather than its own.

You can then go further. Beyond the project, it is possible to configure global preferences (language, tone, generic naming conventions) that will apply to all your sessions. Some tools even allow the AI to take its own notes along the way to capture things you might have forgotten to document.

For more advanced users, this customization turns into true automation. With the concept of "skills," you break down your knowledge into specialized modules. If the AI needs to write tests, for example, it automatically loads your dedicated module for testing conventions. If it generates a component, it consults your front-end architecture module. Instead of having a giant catch-all file, you build a library of knowledge that the tool draws from at the right moment.

Custom agents push this logic even further. Instead of using a single generalist AI juggling an immense context, you create specialists. You can have a test-writing agent calibrated to your patterns and another dedicated to code review with your strict quality criteria. Each has its own targeted context and its own memory. It's the difference between using a Swiss Army knife and calling on a team of craftsmen.

But no matter the level of complexity, the basic principle remains the same: there is no magic. These are just text files, versioned and human-readable, that the AI consults before getting to work.

Let's take a concrete technical example. Often, the AI generates tests by creating objects manually every time. You end up with dozens of lines of duplicated configuration where each test rebuilds a user or an order with all its fields, even those that are irrelevant to the case being tested.

To fix this, simply add these few lines of markdown directly to your CLAUDE.md or .cursorrules file:

### Tests

- Use fixture functions to create test objects

- Each fixture provides default values and accepts a `Partial<T>` for overrides

- Only specify the fields relevant to the test case

function createUser(props: Partial<User> = {}): User {

return {

id: "user-1",

name: "Alice",

email: "alice@example.com",

role: "developer",

...props,

};

}

// In the test: only the relevant field is specified

const admin = createUser({ role: "admin" });

The result is immediate. The generated tests will use these functions right from the start. You will have less duplication, more readable tests, and clear intent. Moreover, to dive deeper into writing behavior-driven tests with AI, I invite you to check out our dedicated article on the subject.

This concept applies just as well outside of code. If the AI writes user stories with acceptance criteria that are far too vague, like "the user should be able to...", simply add a clear rule to your configuration:

### Story Writing

- Always use the Given/When/Then format for acceptance criteria

- Include at least one happy path and one error case

- Reference the relevant persona

From the very next session, your stories will become directly actionable. The format will remain consistent from one discussion to the next, without you needing to remind it every time.

The Memory Workflow

The process is simple and cumulative:

Manual correction → Update config file → Verification → ✓ (or return to step 1)

Every added rule makes the AI a little more adapted to your context. It's a simple, cumulative process. You make a manual correction, update the configuration file, verify that it works, and the loop is closed. Over the weeks, your assistant no longer starts from the generic 50th percentile. It starts with your choices and preferences. The only difference between a mundane assistant and one perfectly calibrated for your project is this configuration file and the discipline you put into keeping it up to date.

It's important to keep in mind, however, that these files are not a silver bullet. They require maintenance. A file that isn't reviewed regularly will accumulate contradictory or outdated instructions. You also have to beware of a false sense of control. The AI can easily ignore or misinterpret certain rules, especially if they are ambiguous. Finally, watch out for overload. If your file is 500 lines long, the machine will have as much trouble prioritizing the information as a human faced with indigestible documentation.

These limitations shouldn't discourage you from documenting; quite the opposite. They prove that it must be done rigorously.

Technical memory is only part of the equation. Once this memory is in place, who ensures it is used correctly?

Human Responsibility and Team Best Practices

There is a growing trend of using one AI to review what another AI has produced. It's a bit like a snake eating its own tail. In reality, it can be very useful, provided you don't stop there.

AI review is excellent for catching obvious errors like style issues, naming inconsistencies, or surface-level bugs. It relieves the human reviewer of irritating little details, freeing up their time to focus on what really matters: business logic, architectural choices, edge cases, and automated tests. Using a different model from the one that generated the code can even reduce bias, as each model has its own strengths and blind spots.

The trap is stopping there. Even with full access to your tools, your documentation, or the project history, the AI has no judgment. It has the information, but doesn't always understand when it's relevant. It will never question an architectural choice that technically "works" but is completely unsuited to your context. If no human validates it afterward, you end up in a dangerous closed loop. One AI generates an endpoint without input validation, another approves it because neither knows your business validation rules.

"AI review is a filter, never a verdict. The human must remain the final link in the chain."

This rigor must extend to the entire team. AI configuration files shouldn't be the business of one person working in isolation. Ask yourselves these questions: Who writes the rules? Who maintains them? How do you prevent each team member from having their own conventions in their personal configuration file, creating inconsistencies in the generated code?

The answer is the same as for any other shared artifact. Treat these configuration files exactly like source code. They must be committed to the repository, reviewed as a team, and maintained collectively. When someone adds a rule, the team validates it. When a convention changes, the file is updated. And above all, the golden rule must be clear to everyone: a human absolutely validates all AI output before it goes into production.

Anyone who accepts an AI output without validating it takes exactly the same risk as a developer who merges code without reading it. The excuse of speed doesn't hold up.

Ultimately, you remain solely responsible for what the AI produces in your name. In the event of a security flaw, a critical bug, or an ill-advised decision, the tool will bear no legal or moral responsibility. You are the one answerable for the code. This is the best reason to invest in this daily rigor: guide the machine with solid configuration files, review everything it generates, and above all, maintain your own understanding of what it produces.

Conclusion

AI doesn't improve on its own. But with a minimal, cumulative investment, just a few lines in a configuration file, updated alongside your corrections, each session becomes better than the last.

It's not about resisting AI or adopting it blindly. It's about intelligent collaboration. I have learned, through months of daily use, that this collaboration starts with understanding how the tool works: it retains nothing, it doesn't think, it predicts. It is up to you to provide the context that transforms its generic predictions into results tailored to your reality.

In your very next session with AI, ask yourself this question: what did I just fix, and how do I make sure I never have to fix it again? Write down the answer to that question. That is the beginning of your AI's memory.