Your AI Engineer Is Brilliant. It Also Forgets Everything Overnight.

Most engineering teams have met this colleague by now. Quick, tireless and happy to work on a transformation before you've finished your morning coffee. Yet each day, it greets your codebase, your conventions and yesterday's outage like a complete stranger.

‍

That's the AI coding agent. It's great at writing on pipelines, but far less great at remembering why the last one broke. So teams work around the amnesia, pasting the error back in, re-explaining the architecture and fixing the same bug, again and again. 

‍

We tried that too. It worked, for a while.

‍

A brief that punished small mistakes

‍

On a recent Databricks engagement, we built a lakehouse to turn semi-structured supplier documents into data for a customer-facing app. The catch was the destination. A strict PostgreSQL database that enforces every foreign key and rejects a whole batch if a single row is off. In between sat twenty interlinked tables, each a fresh chance for something to point at nothing.

‍

For the first few tables, prompting the agent was a joy. Describe the table, paste the error, accept the fix. But as the relationships multiplied, the same problems kept coming back:

‍

• Phantom keys: Missing source values created valid-looking IDs that linked records to nowhere.
• Accidental mergers: Blank IDs collapsed unrelated documents into one record.
• Load-order dominoes: Tables loaded out of sequence sent data into mass quarantine, making minor slips look like total failures.
• Zombie locks: Cancelled runs left queries active and the database locked.

‍

Each time, the agent could fix the problem once we'd found it. Then the next session started from scratch, because prompts produce answers, not memory.

‍

Treat the agent like a new hire, not a search box

‍

So we stopped treating the agent as a chat window and started onboarding it like a colleague. That meant writing three things into the repository.

‍

A project guide that the agent reads at the start of every session, covering the architecture, conventions and known traps.

‍

A record of decisions, with the reasoning attached, so arguments settled on Tuesday stay settled on Thursday.

‍

Skills or versioned instruction files the agent loads whenever a matching task comes up. Any problem that recurred several times earned one. The most useful diagnoses failed exports and proposes a fix. Others check for key-hashing traps, clear orphaned locks safely and keep the template for new data sources current.

‍

A skill isn't much more than a well-written README. The difference is that the agent actually follows it, every time, which is more than most of us can claim.

‍

What changed?

‍

Before, every engineer had their own prompts, debugging habits and private chat history, so each lesson stayed with whoever learned it. Drop a new human hire into that setup and they'd struggle too. Now the lessons live in the repository, where they can be reviewed, versioned and inherited. The next engineer, or the next agent session, starts with everything we learned instead of relearning it.

‍

The real mistake

‍

Most teams use their AI agent like a search engine. Ask, receive, forget. Yet if a new engineer broke a foreign-key constraint or locked the database, nobody would just fix the code and hope it doesn’t happen again. You'd update the docs, tighten the reviews and onboard them properly.

‍

AI agents need the same discipline. Write the rules down where the agent will read them, and you stop fixing the same bug twice. Leave them scattered across chat histories, and you'll spend the project explaining your architecture to a very fast, very polite stranger with an unfortunate case of amnesia.