We opened the session with the Condis technical team with a question: "how many of you have copied something from an AI chat and pasted it somewhere else this week?". Every hand went up. That gesture, copy and paste, is exactly what we came to get rid of.
It was scheduled for 90 minutes and ended up running for three hours. Which was the whole point: the moment you get practical (opening a real CLAUDE.md and reading it together, showing actual guides, running a live test), it stops being a talk about AI and everyone starts seeing their own work in it.
Chatting is not the same as coworking
In a chat, the context is whatever you paste into the window. You fix things by hand, close the tab, and the fix is gone. Next week you do it again.
Working with agents, with Claude Code and Cowork, the context is the whole repository: the files, the guides, the history and the conventions. The project's memory loads itself in every session. And the agent runs, sees the error and fixes it, instead of handing you back text you have to check by eye.
The job is no longer to write the perfect prompt. The job is to build the environment where any mediocre prompt produces a good result.
That gives you three pieces
The whole framework rests on three pieces that are worth keeping apart.
- CLAUDE.md: the project's memory. It reads itself in every session, without anyone asking. It is an index and a contract, not an encyclopedia; past around 500 lines it starts to dilute the agent's attention and it's time to trim it.
- The guides: the knowledge for each task. Written as a specification, not as prose: mandatory, forbidden, exact input and output paths, checklist.
- The tools: the agent's hands. Connectors, skills and scripts to execute, not just to draft.
A guide looks more like an API contract than a manual
The difference between a guide that works and a note that doesn't is in how it's written.
- Binary rules, not advice. Not "try to keep sentences short", but "14 words per sentence maximum; if it goes over, reject the piece".
- Substitution tables, not explanations. Our copy-correction guide has hundreds of rows like "gap is written brecha, upside is written potencial alcista". The agent doesn't interpret, it substitutes.
- Exact paths, not "somewhere around there". The file, the approximate line, the identifier. The agent doesn't search blindly: it goes straight to the spot.
And a rule we repeat a lot: a guide is not a statement of good intentions. It's where everything you've already learned by measuring gets written down.
The loop you need to internalize
It comes down to four steps, and the third is the one that makes the difference:
- You do the task with the agent, using the context it already has.
- It comes out so-so and you fix it by hand. This is where almost everyone stays.
- You write that fix into the guide. This is the real work, the only part that adds up.
- Next time it comes out right the first time. And the time after that. And the one after that.
The difference with a chat is that here the fix stays. Every correction you make by hand and don't write into a guide, you'll be making again next week.
A real case: StocksReport
So it wouldn't be a pretty demo, we showed our own project: StocksReport, a platform that generates investment reports on more than 300 listed companies, run by a single person. Marketing, sales, operations and development, all with the same model; what changes is the environment that tells it which of those roles it's playing at any given moment.
That's where two decisions that never come up in a chat start to make sense. First, a different model for each task: Opus for analysis and hard calls, Sonnet to execute well-defined guides, and Haiku to classify and summarize at volume. Second, subagents for the heavy reading, like exploring a whole repository or auditing thirty files, that hand back only the conclusion and keep the main context clean. In the end the rule is simple: a weak guide forces Opus to reason; a good guide lets Sonnet execute.
The seven mistakes we've already made
We didn't learn any of them by reading. Every one cost us work that ended up in the bin:
- Starting without version control. Git from day one: an agent touches many files at once, and without a diff you don't know what changed or how to go back.
- Leaving keys and tokens inside the project. They go outside, in environment variables: the agent reads everything inside the folder.
- Validating by eye with "looks good". Verification with a script inside the flow itself; the agent doesn't correct itself.
- Accepting permissions by clicking through. Better a reviewed permission list, shared with the team.
- Keeping the project root full of clutter. Every stray file costs it context and attention you need for something else.
- Repeating the same flow by hand every week. If you've written it in the chat three times, it's already a command.
- Not measuring the quality of what it delivers. Track which guide fails most and how many corrections each deliverable costs you: that's what tells you which guide to fix.
What works for us
The mistakes are only half the picture. The other half is the habits that stuck around, after months, because they genuinely save work.
If I had to sum them up in one line: everything you learn gets written down, and everything you ship gets verified. A short CLAUDE.md that reloads in every session, guides with explicit input and output paths, dead code marked so the agent doesn't read it, verification with a script instead of "sounds right to me", and the model chosen by the task rather than always the most expensive one. None of this is theory: it's what's left once you've spent a while measuring what breaks.
What we planted with the Condis team
The environment was highly technical and the conversation demanding. The moment we opened a real CLAUDE.md, read it together, ran a live test and showed actual guides, the session stopped being mine to carry alone. And that's when it opens up: not just development, but operations, data and the day-to-day of every department start to see themselves in it.
We planted the vision and the path to bring it into their people and their tool stack. Thanks to Josep Jarque and Sergio Murillo for the trust and the welcome; with them you feel right at home.
First step, this week: take the task you've copied and pasted from a chat the most this month. Write it a guide. Just one. And next time, don't copy it: run it.
If you're at that point, a technical team ready to move from chatting to coworking, let's talk.
