Kaizen Teams

Dropdown

Table of Contents

Time to read

·

12

Published on

·

June 3, 2025

Last updated on

·

April 10, 2026

Valentina Ibinete, Marketing Lead at Kaizen Softworks

Valentina Ibinete

Travel magnet collector

Marketing Lead

How to Give Windsurf the Right Context for Smarter AI Coding

Published on

·

April 10, 2026

Last updated on

·

April 10, 2026

Time to read

·

12

Valentina Ibinete, Marketing Lead at Kaizen Softworks

Valentina Ibinete

Marketing Lead

Windsurf is an AI coding assistant that generates code based on the context you provide. If you don’t give it enough context, it behaves like a new teammate with no prior knowledge. This matters because better context directly improves code accuracy, consistency, and usefulness. This guide is for developers who want more reliable results from AI-assisted coding.

Key Takeaways

  • Windsurf does not retain full context by default, so you must provide it explicitly.
  • Rules, Memories, @mentions, and Impersonation are the 4 core ways to guide its behavior.
  • Clear and structured context produces better code than long, vague instructions.

What is Windsurf in AI coding?

Windsurf is an AI-powered coding assistant that generates and modifies code based on user prompts and contextual inputs. It relies on the information you provide in each interaction to produce results.

This behavior is aligned with how large language models (LLMs) work: they generate outputs based only on the input context they receive, not long-term memory (OpenAI Prompt Engineering Guide).

Bottom line: Windsurf performs best when you explicitly define what it should know before generating code.

Why does Windsurf need context to generate better code?

Windsurf needs context because it cannot reliably infer your project structure, goals, or constraints on its own.

Without context:

  • It may generate incorrect or irrelevant code
  • It can modify unintended files
  • It may ignore project-specific conventions

Research on generative AI systems shows that models perform better when given explicit instructions and relevant examples (Google Cloud Prompt Design Guide).

With proper context:

  • Code aligns with your architecture
  • Outputs are more predictable
  • You reduce rework and corrections

Conclusion: Context acts as the “memory layer” that makes AI outputs usable in real projects.

How to use Rules in Windsurf?

Rules are predefined instructions that control how Windsurf behaves across conversations or projects. They act as guardrails that reduce randomness and enforce consistency.

Providing structured instructions is a core prompt engineering technique, where clear constraints help guide model outputs toward desired formats and behaviors (OpenAI Prompt Engineering Guide).

Types of Rules

Type Scope Example
Global Rules All projects “Write code in English, respond in Spanish.”
Project Rules Single project “Always read the README before answering.”

How to use Rules effectively (step-by-step)

  1. Define behavior clearly
    Example: “Use TypeScript for all code.”
  2. Set language and formatting preferences
    Example: “All comments must be in English.”
  3. Add project-specific instructions
    Example: “Follow the structure defined in README.md.”
  4. Keep rules minimal
    Too many rules reduce clarity and can confuse the model.

Pro tip (based on practice): In our tests, 3–5 highly specific rules outperform long rule lists, because the model prioritizes clearer signals.

Bottom line: Use fewer, clearer rules to guide consistent outputs.

What are Windsurf Memories and When Should You Use Them?

Memories are stored pieces of context that Windsurf uses to remember important project information over time.

They function similarly to persistent notes about your project.

How Memories work

  • Windsurf can auto-generate memories based on conversations
  • You can also manually create memories
  • They are project-specific (not global)
  • You can edit them anytime

Example of a Memory

“This app is a SaaS dashboard for managing subscriptions.”

When to use Memories

Use Memories when:

  • You are working on long-term projects
  • You want to avoid repeating the same explanations
  • Your project has stable requirements
  • You need consistent context across sessions

Avoid overusing Memories when:

  • You want exploratory or creative outputs
  • Your project changes frequently

Important limitation: Memories can become outdated if your project evolves, so you must review and update them regularly.

Conclusion: Memories reduce repetition but require maintenance to stay accurate.

How to Use @mentions in Windsurf to Provide Context?

@mentions allow you to reference specific files, code, or documentation directly in your prompt.

This reflects a key prompt engineering principle: providing grounded context (real data or documents) reduces hallucinations and improves accuracy (OpenAI Prompt Engineering Guide).

Examples of @mentions

  • @README → Loads project overview
  • @server.js → References backend logic
  • @/components/Button.tsx → Targets a specific UI file

How to use @mentions (step-by-step)

  1. Reference the exact file or resource
  2. Give a clear instruction
    Example: “Read @README and summarize the architecture.”
  3. Limit scope
    Prevents Windsurf from modifying unrelated files

Why this works:
You eliminate guesswork by forcing the model to use real project data instead of assumptions.

Bottom line: @mentions are the fastest way to inject precise, relevant context.

What is "Impersonation" in Windsurf and How Does it Work?

Impersonation is a technique where Windsurf adopts a specific role or persona to guide its outputs.

This is similar to role-based prompting, a widely used technique where assigning a role improves output relevance and tone (OpenAI Prompt Engineering Guide).

This is useful for tasks that require a particular perspective, such as design, QA, or architecture.

Example of impersonation

“Impersonate a senior UX designer focused on usability.”

Advanced use: Persona files

You can create reusable profiles (e.g., @luna.md) that define:

  • Tone
  • Priorities
  • Constraints

Then use: “Impersonate @luna”

Use cases for Impersonation

  • UX/UI design perspectives
  • Code review roles
  • Architecture decision-making
  • Testing and QA validation

Why it works

Impersonation narrows the model’s decision space by:

  • Defining priorities (e.g., usability vs performance)
  • Applying consistent criteria across outputs

Real-world workflow tip: In practice, teams use impersonation to:

  • Generate quick prototypes (HTML/CSS)
  • Validate ideas before implementation
  • Run AI-powered code reviews after development

Conclusion: Impersonation adds focus and expertise to AI outputs.

Rules vs Memories vs @mentions vs Impersonation

Feature Purpose Scope Best Use Case
Rules Define behavior Global / Project Consistency
Memories Store context Project Long-term projects
@mentions Inject data Instant Precision
Impersonation Change perspective Task-based Specialized outputs

How to give Windsurf the best context (Checklist)

Use this checklist before prompting:

  • ✅ Define clear rules
  • ✅ Add key memories
  • ✅ Reference files with @mentions
  • ✅ Use impersonation for complex tasks
  • ✅ Keep instructions short and specific

Common mistakes when using Windsurf

  • ❌ Giving too many rules at once
  • ❌ Not updating memories after changes
  • ❌ Writing vague prompts
  • ❌ Not referencing actual files
  • ❌ Expecting Windsurf to “just know” your project

Fix: Always provide explicit, structured context.

Final Summary

To get better results from Windsurf, you need to control its context.
Use rules for consistency, memories for persistence, @mentions for precision, and impersonation for focus.

The clearer your context, the better your code.

Windsurf is an AI coding assistant that generates code based on the context you provide. If you don’t give it enough context, it behaves like a new teammate with no prior knowledge. This matters because better context directly improves code accuracy, consistency, and usefulness. This guide is for developers who want more reliable results from AI-assisted coding.

Key Takeaways

  • Windsurf does not retain full context by default, so you must provide it explicitly.
  • Rules, Memories, @mentions, and Impersonation are the 4 core ways to guide its behavior.
  • Clear and structured context produces better code than long, vague instructions.

What is Windsurf in AI coding?

Windsurf is an AI-powered coding assistant that generates and modifies code based on user prompts and contextual inputs. It relies on the information you provide in each interaction to produce results.

This behavior is aligned with how large language models (LLMs) work: they generate outputs based only on the input context they receive, not long-term memory (OpenAI Prompt Engineering Guide).

Bottom line: Windsurf performs best when you explicitly define what it should know before generating code.

Why does Windsurf need context to generate better code?

Windsurf needs context because it cannot reliably infer your project structure, goals, or constraints on its own.

Without context:

  • It may generate incorrect or irrelevant code
  • It can modify unintended files
  • It may ignore project-specific conventions

Research on generative AI systems shows that models perform better when given explicit instructions and relevant examples (Google Cloud Prompt Design Guide).

With proper context:

  • Code aligns with your architecture
  • Outputs are more predictable
  • You reduce rework and corrections

Conclusion: Context acts as the “memory layer” that makes AI outputs usable in real projects.

How to use Rules in Windsurf?

Rules are predefined instructions that control how Windsurf behaves across conversations or projects. They act as guardrails that reduce randomness and enforce consistency.

Providing structured instructions is a core prompt engineering technique, where clear constraints help guide model outputs toward desired formats and behaviors (OpenAI Prompt Engineering Guide).

Types of Rules

Type Scope Example
Global Rules All projects “Write code in English, respond in Spanish.”
Project Rules Single project “Always read the README before answering.”

How to use Rules effectively (step-by-step)

  1. Define behavior clearly
    Example: “Use TypeScript for all code.”
  2. Set language and formatting preferences
    Example: “All comments must be in English.”
  3. Add project-specific instructions
    Example: “Follow the structure defined in README.md.”
  4. Keep rules minimal
    Too many rules reduce clarity and can confuse the model.

Pro tip (based on practice): In our tests, 3–5 highly specific rules outperform long rule lists, because the model prioritizes clearer signals.

Bottom line: Use fewer, clearer rules to guide consistent outputs.

What are Windsurf Memories and When Should You Use Them?

Memories are stored pieces of context that Windsurf uses to remember important project information over time.

They function similarly to persistent notes about your project.

How Memories work

  • Windsurf can auto-generate memories based on conversations
  • You can also manually create memories
  • They are project-specific (not global)
  • You can edit them anytime

Example of a Memory

“This app is a SaaS dashboard for managing subscriptions.”

When to use Memories

Use Memories when:

  • You are working on long-term projects
  • You want to avoid repeating the same explanations
  • Your project has stable requirements
  • You need consistent context across sessions

Avoid overusing Memories when:

  • You want exploratory or creative outputs
  • Your project changes frequently

Important limitation: Memories can become outdated if your project evolves, so you must review and update them regularly.

Conclusion: Memories reduce repetition but require maintenance to stay accurate.

How to Use @mentions in Windsurf to Provide Context?

@mentions allow you to reference specific files, code, or documentation directly in your prompt.

This reflects a key prompt engineering principle: providing grounded context (real data or documents) reduces hallucinations and improves accuracy (OpenAI Prompt Engineering Guide).

Examples of @mentions

  • @README → Loads project overview
  • @server.js → References backend logic
  • @/components/Button.tsx → Targets a specific UI file

How to use @mentions (step-by-step)

  1. Reference the exact file or resource
  2. Give a clear instruction
    Example: “Read @README and summarize the architecture.”
  3. Limit scope
    Prevents Windsurf from modifying unrelated files

Why this works:
You eliminate guesswork by forcing the model to use real project data instead of assumptions.

Bottom line: @mentions are the fastest way to inject precise, relevant context.

What is "Impersonation" in Windsurf and How Does it Work?

Impersonation is a technique where Windsurf adopts a specific role or persona to guide its outputs.

This is similar to role-based prompting, a widely used technique where assigning a role improves output relevance and tone (OpenAI Prompt Engineering Guide).

This is useful for tasks that require a particular perspective, such as design, QA, or architecture.

Example of impersonation

“Impersonate a senior UX designer focused on usability.”

Advanced use: Persona files

You can create reusable profiles (e.g., @luna.md) that define:

  • Tone
  • Priorities
  • Constraints

Then use: “Impersonate @luna”

Use cases for Impersonation

  • UX/UI design perspectives
  • Code review roles
  • Architecture decision-making
  • Testing and QA validation

Why it works

Impersonation narrows the model’s decision space by:

  • Defining priorities (e.g., usability vs performance)
  • Applying consistent criteria across outputs

Real-world workflow tip: In practice, teams use impersonation to:

  • Generate quick prototypes (HTML/CSS)
  • Validate ideas before implementation
  • Run AI-powered code reviews after development

Conclusion: Impersonation adds focus and expertise to AI outputs.

Rules vs Memories vs @mentions vs Impersonation

Feature Purpose Scope Best Use Case
Rules Define behavior Global / Project Consistency
Memories Store context Project Long-term projects
@mentions Inject data Instant Precision
Impersonation Change perspective Task-based Specialized outputs

How to give Windsurf the best context (Checklist)

Use this checklist before prompting:

  • ✅ Define clear rules
  • ✅ Add key memories
  • ✅ Reference files with @mentions
  • ✅ Use impersonation for complex tasks
  • ✅ Keep instructions short and specific

Common mistakes when using Windsurf

  • ❌ Giving too many rules at once
  • ❌ Not updating memories after changes
  • ❌ Writing vague prompts
  • ❌ Not referencing actual files
  • ❌ Expecting Windsurf to “just know” your project

Fix: Always provide explicit, structured context.

Final Summary

To get better results from Windsurf, you need to control its context.
Use rules for consistency, memories for persistence, @mentions for precision, and impersonation for focus.

The clearer your context, the better your code.

Related Articles

·

May 15, 2026

Can AI Safely Apply Changes Across Microservices?

Learn how AI can apply changes across microservices when service ownership, message contracts, DTOs, and architectural context are clearly defined.

12 read time

Read more

Applying changes across microservices is difficult because business logic is distributed across multiple services, each with its own data, contracts, and responsibilities.

In our experiment at Kaizen Softworks, we tested whether an AI system could safely apply coordinated changes across a microservices architecture using only minimal input.

Short answer: Yes, but only when the AI has enough architectural context.

Why are coordinated changes in microservices so hard?

In distributed systems, a single business change rarely affects just one service.

It often requires:

  • Updating multiple microservices
  • Modifying message contracts
  • Keeping DTOs (Data Transfer Objects) consistent
  • Respecting domain boundaries defined by Domain-Driven Design (DDD)

Key entities in this system:

  • Microservice: An independently deployable service responsible for a specific domain
  • Aggregate (DDD): A cluster of domain objects treated as a single unit
  • DTO (Data Transfer Object): A structured format used to transfer data between services
  • Message/Event: A communication mechanism between services

The complexity is not in the code, it’s in the relationships between components.

The experiment: Can AI reason across services with minimal input?

We designed a controlled experiment to test whether an AI model could apply system-wide changes with limited information.

Input given to the AI:

  • Message definitions (events between services)
  • DTOs (data contracts)

Tasks the AI had to perform:

  1. Identify affected aggregates
  2. Determine service ownership
  3. Apply coordinated changes across services
  4. Maintain consistency in messages and DTOs

In other words, the AI had to behave like a software architect, not just a code generator.

What was the biggest obstacle?

The biggest challenge was not technical, it was contextual.

Before and after diagram showing how ambiguous microservice names prevent AI from understanding service ownership, while aggregate-to-service mapping helps AI apply safe coordinated changes.

Problem: unclear service naming

Instead of descriptive names like:

  • order-service
  • billing-service

Our services were named:

  • john
  • sally
  • roger

This removed any semantic clues about responsibility.

Result: The AI could not infer which service owned which domain logic.

The missing piece: aggregate ownership mapping

To solve this, we introduced a simple but powerful structure:

Aggregate → Service mapping

  • Order → john
  • Shipment → sally
  • Invoice → roger

This created a clear relationship between domain concepts and system components.

Once ownership was explicit, the architecture became understandable.

How we used AI to generate architectural context

Instead of building this mapping manually, we used AI to analyze the codebase and extract:

  • Where each aggregate was defined
  • Which microservice implemented it
  • The relationship between domain and infrastructure

The result was a machine-readable architecture map.

In practice, we used AI to generate the context that AI itself needed.

Results: Can AI safely apply distributed changes?

With the architecture map in place, the AI was able to:

  • Trace message flows across services
  • Identify affected aggregates
  • Locate the correct microservices
  • Apply coordinated updates
  • Maintain consistency between DTOs and messages

While not perfect, the system worked reliably as a proof of concept.

What is the real limitation of AI in microservices?

The main limitation of AI is not code generation, it’s architectural understanding.

Without knowing:

  • Which components exist
  • How they relate
  • Who owns what

AI cannot safely modify a distributed system.

AI performance depends more on context quality than model capability.

When can AI safely modify microservices?

AI works well when:

  • Aggregate ownership is clearly defined
  • Message contracts are explicit
  • Architecture is structured and consistent

AI struggles when:

  • Naming is ambiguous
  • Relationships are implicit
  • Context is incomplete

Simple rule: If the architecture is clear, AI can reason. If not, it guesses.

Final thoughts

This experiment revealed something important:

AI doesn’t fail because it can’t write code.
It fails because it can’t see the system.

As teams move toward AI-assisted development, the focus will likely shift from:

Writing better code to Designing better systems for machines to understand

At Kaizen Softworks, we see this as a foundational shift.

Because when AI can understand architecture, it doesn’t just generate code, it helps evolve systems.

·

Mar 13, 2026

How We Make Decisions Without Managers

We don’t have traditional managers. This is how we make decisions and keep things moving.

12 read time

Read more

There's a myth that in flat organizations, everyone decides on everything.

That's not how it works. At least not at Kaizen.

When people hear "no managers," they often picture one of two extremes: either total chaos where nobody is accountable, or endless meetings where 80 people vote on which coffee to buy. The reality is neither.

Not everyone decides on everything. Not everyone votes. What we do have is a clear set of decision-making methods that we choose based on context.

It depends on who's affected and how deep the impact goes

Before choosing how to decide, we ask ourselves a few questions:

  • Who is affected? A decision that only impacts one team doesn't need the whole company involved. A decision that affects everyone's daily work does.
  • How deep is the impact? Changing the office furniture is wide but shallow. Changing the salary model is deep and lasting.
  • Is it reversible? If we can easily undo it, we can move fast and just inform. If it's hard to reverse, we slow down and include more people.
  • How urgent is it? And here we're careful to distinguish real urgency from anxiety, the pressure to decide quickly because someone already has "the answer" in mind.

These dimensions help us pick the right method. Not every decision deserves the same process.

Our decision-making toolkit

Over the years, we've landed on a few methods that we use depending on the situation:

1. Role-based decisions

Some decisions belong to a specific role. If someone owns a responsibility, say, office logistics or hiring for a team,  they decide within that domain. No committee needed. The key is that roles are transparent: everyone knows who owns what, and the scope of each role's authority is clear.

2. Advice Process

When a decision doesn't clearly belong to one role, or when it crosses boundaries, we use the advice process. Here's how it works:

  1. Someone takes the initiative. They identify the problem and own the process.
  2. They gather input from people who are affected and people with expertise.
  3. They seek advice, real conversations, not rubber-stamping.
  4. They make the decision and communicate it, including what advice they incorporated and what they didn't (and why).

The decision-maker is not a committee. It's one person (or a small group) who takes responsibility. But they don't decide in isolation, they bring in the perspectives that matter.

We sometimes call this "Team Advice" when a working group forms around an issue that doesn't naturally fall into anyone's area, and "Area Advice" when a team opens up a topic that exceeds their own scope.

3. Consent (not consensus)

Consent is not "everyone agrees." Consent means "no one has a strong enough objection to block this." We do use a poll, but not to count votes — we use a 1-to-5 scale to measure the level of agreement and surface objections, not to let the majority rule.

We use it in two flavors:

  • High-participation consent: For decisions with deep, company-wide impact. This is our most expensive and slowest method, which is exactly why we reserve it for high-impact decisions that affect many people. The Board sets the boundaries, for example, when we moved offices, they defined the monthly budget. Then a working group produced proposals, collected feedback, evolved them, and the whole company expressed their position for the final decision. Silence is not approval; we explicitly ask people to weigh in, even if it's just "I have no objection."
  • Lightweight consent: For decisions that are broad but not deep. Participation is optional, anyone who's interested can jump in. We share the proposal, open a window for objections, and if nobody opposes, we move forward. This gives us speed without sacrificing transparency. If nobody engages, that's a signal too, maybe the proposal doesn't add enough value, or we're using the wrong channel.

4. Inform, don't fake-consult

Not everything needs participation. When a decision has already been made through a legitimate process, the right move is to inform, not to fake-consult. One of the fastest ways to kill self-management is to ask for feedback and then ignore it. If you're not going to change course based on input, don't ask for it, just be transparent about the decision and the reasons behind it.

What we explicitly avoid

  • Decision by Voting. In a company context, majority rule creates losers. And losers become detractors, often generating more resistance than an autocratic decision would have. Instead of voting, we prefer to evolve a proposal through feedback until it's "good enough for now," and then introduce a review point to adjust later. If voting happens at all, it's the cherry on top, not the main course.
  • The "surprise" approach. Working behind closed doors and then unveiling a finished decision is a recipe for frustration. Adults don't need surprises. Adults need to feel like they're part of the process. The complaints that follow a surprise aren't about the decision itself, they're about not being included.

Why we work this way

We didn't adopt these methods because they're trendy. We adopted them because they solve real problems:

  • Better decisions. When you include affected people, you get information you wouldn't have had otherwise. Ideas emerge that no single person would have come up with alone.
  • Less resistance. A person who feels heard is far less likely to resist a decision, even one they wouldn't have made themselves.
  • Faster execution. It sounds counterintuitive, but participative decisions often execute faster because people already understand and support them. The time you "save" by deciding alone, you spend later managing pushback.
  • Distributed authority. When people can make decisions within their domain without escalating everything to a founder, the organization scales. The bottleneck disappears.
  • Resilience. If a shared decision fails, the group adjusts together. If a top-down decision fails, the blame falls on one person and the chances of proactive correction drop.

The real principle behind all of this

Transparency is the foundation. Every method we use, from role-based decisions to high-participation consent, works because information flows openly. People know what's being decided, who's deciding it, and how they can participate.

Horizontal doesn't mean structureless. It means fewer hierarchical levels, clearer roles, and intentional decision-making processes that match the weight of each decision.

Not everyone decides on everything. But everyone knows how things get decided.