Slack Code allows you and your team to collectively review:
The AI’s plan.
Code diffs.
Live previews.
Then decide whether to accept the changes.
But if you start by telling the Agent:
“Fix this part for me.”
Even if everyone can see what’s going on afterward,
a common problem arises:
Everyone has a different idea of what “fixing” means.
So today, learn just one simple action.
Before the Agent starts editing,
write these three columns first:
Current.
Desired.
Unchangeable.
First column: What is the current situation?
Clearly define the current problem.
For example, avoid writing:
The mobile button looks bad.
Instead, write:
The “Free Trial” button on the first screen of the mobile homepage is currently too close to the bottom of the page, requiring users to scroll down to see it.
This column defines the:
starting point.
If you don’t clearly state what’s happening now,
AI will start guessing:
Which button?
Which page?
Which screen size?
What does “looks bad” mean?
Second column: What do you want it to become?
Don’t just say:
“Make it better.”
You have to tell the AI exactly what you want to see.
For example:
On mobile homepage, the full Free Trial button is visible without scrolling after the page loads.
This is the:
acceptance criteria.
After the update,
there’s no need to debate:
“It just feels better.”
Just check:
Did it meet the criteria?
Third column: What must not be changed?
This column is often forgotten.
For example, your real need might be:
Only move the mobile CTA upward.
But the Agent might, in the process, also change:
Desktop spacing.
Fonts.
Navigation bar.
Other button styles.
Or even shared CSS files.
So in the third column, you can write:
Do not modify desktop layouts, button text, brand fonts, or any other pages.
This tells the Agent that:
Success isn’t about making more changes.
Success is about:
Fixing the specified issue,
while leaving everything else intact.
Putting the three columns together completes your task description
The simplest format is:
Current
What problem is currently observed?
Desired
What should users see after changes?
Unchangeable
Which functioning features, pages, or data must remain unchanged?
For example:
Current: The free trial button is not fully visible on the first screen of the mobile homepage.
Desired: On iPhone screen sizes, the full CTA is visible without scrolling after loading the homepage.
Unchangeable: Do not modify desktop version, CTA text, navigation bar, other pages, or login flows.
Submit your planned changes based on these three points.
If completing the fix requires changing anything marked “Unchangeable,” stop and inform me—do not expand the scope yourself.
This is already a very practical starting point for a Slack Code task.
Why does Slack Code particularly need this kind of format?
Because the point of Slack Code is not:
One person working privately with the Agent.
Instead, it brings together:
Product,
Engineering,
Design,
And other relevant colleagues
Into the same Code Channel.
Slack is designed so everyone can work together in one space to:
Plan.
Prompt the Agent.
Review changes.
View previews.
And review together.
So the worst-case isn’t:
No one sees the task.
It’s:
Everyone has a different goal in mind.
For example, the product manager is thinking about A
The product manager says:
The mobile CTA should be more noticeable.
What they actually want might just be:
The button moved up 40 pixels.
The designer thinks about B
The designer might interpret that as:
Redesigning the entire hero section layout.
The AI might understand C
The Agent might try to make the CTA more noticeable by:
Changing its color.
Increasing font size.
Adjusting margins.
Rearranging the layout.
None of the three is wrong.
The problem is simply:
“More noticeable” is not a clearly defined acceptance criteria.
So don’t wait to discuss requirements only after you see a code diff
Code diffs tell you:
What AI has changed.
They can’t answer for you:
Whether those changes are what you really wanted.
Live Preview shows you:
What the screen looks like now.
But it also can’t answer for you:
Whether this matches the correct product requirement.
Therefore, the cheapest time to fix things is always:
Before the Agent starts making extensive changes.
The "Current" column should be as observable as possible
Don’t write something vague like:
The website is hard to use.
Because that’s too broad.
Instead, try:
The discount code field is below the payment button on the mobile checkout page, making it hard for test users to find.
Or:
In dark mode, the primary CTA text lacks contrast with the background.
Or:
On a 390px wide product page, the price overlaps the Add to Cart button.
These all share one feature:
They are observable.
After AI makes changes,
it’s easier to:
Verify the fix.
For "Desired," don’t specify technical methods first—state the results
For example, don’t start by saying:
Change the padding to 16px.
Because the real problem might be:
The button is being obscured.
If AI tries 16px padding,
and the button is still covered,
AI will be stuck on the wrong approach.
A better way is to write:
After the update, on designated mobile sizes, the button should be fully visible and within the first screen without scrolling.
You define the:
result.
Then the Agent can propose:
How to achieve it.
When should you specify technical methods?
If the technology itself sets limits,
then specify it.
For example:
Do not modify APIs.
Do not change database schema.
No new dependencies allowed.
Must keep existing Design Tokens.
These fit perfectly into the:
Unchangeable
column,
because these aren’t preferences—
They’re boundaries.
“Unchangeable” is especially useful to protect shared components
When AI coding, it’s common that:
You want to modify only Page A.
The Agent finds Page A uses a shared component,
and modifies the shared component directly.
Resulting in changes on pages:
B,
C,
D —
All changed simultaneously.
If you know:
This is a production website,
You can write:
If modifying a shared component affects other pages, stop and explain the impact before proceeding. Do not modify directly.
This sentence is very practical.
In Slack Code, have the team first agree with a "consent" reply
Since the Code Channel is built for collaboration,
don’t rush to let the Agent start building.
Post first:
Current.
Desired.
Unchangeable.
Then have the relevant people confirm:
Product:
Requirements are accurate.
Design:
Visual boundaries are correct.
Engineering:
Technical constraints are correct.
Once confirmed,
let the Agent proceed.
What this really saves is not:
30 seconds.
But avoiding twenty minutes later someone saying:
“Wait, this is not what I meant.”
Next, review the Slack Code Plan
Slack Code allows the Agent to present in the Code Channel:
Planning documents,
Code diffs,
Live HTML previews,
and other work content.
So after writing the three columns,
the next step is:
Review the Agent’s plan.
You just need to ask:
Does the plan violate any of the three columns?
Check only these three things when viewing the plan
First:
Is it fixing the:
actual problem?
Second:
Will it produce the result you:
specified?
Third:
Does it affect anything in the:
unchangeable range?
If the answer to the third is:
Yes,
don’t build yet.
Then review the Code Diff
The plan says:
How it intends to change things.
The code diff shows:
What it actually changed.
So when the diff appears,
check it against the same three-column criteria.
Don’t suddenly switch to a different standard.
For example:
If the “Unchangeable” says:
Desktop layout,
but the diff includes:
Desktop layout CSS modifications,
ask:
Why?
This is much more reliable than just checking whether:
AI says “Done.”
Finally, review the preview
For website or interface changes,
the preview is the closest to showing:
The actual result users will see.
Here, return to the second column:
Desired state.
For example, if you wrote:
The CTA is visible without scrolling on the first screen of mobile.
Then truly test:
Mobile screen sizes.
Confirm:
Visibility.
Don’t just approve because:
The desktop preview looks nice.
So the method today doesn’t change throughout the process
Before starting:
Current / Desired / Unchangeable.
Review the plan:
Match against the three columns.
Review the diff:
Match against the three columns.
View the preview:
Match against the three columns again.
Then approve.
This way, the team doesn’t have to reinvent judgment standards at each stage.
How is this different from Replit’s Plan Mode tutorial?
On August 20th, we already taught:
Look at the Plan before changing an app in Replit; don’t touch code first.
Reiterating “look at the Plan” here would be repetitive.
So today, we pushed one step earlier:
Before the plan appears, define what success means to you.
Plan Mode solves:
How will AI do it?
Today’s three columns solve:
What do humans actually want it to achieve?
They are upstream and downstream to each other.
Don’t confuse “Unchangeable” with locking the system
This must be clear.
Writing in the prompt:
Do not change the database.
Does not mean the system literally locks the database.
It’s still:
A work instruction to the Agent.
If an Agent has broader repository, deployment, or data permissions,
The real technical safety requires:
Permission control,
Branch policies,
Review,
Testing,
Deployment controls.
The purpose of the three-column method is to:
Make goals and boundaries clearer.
It does not replace:
Engineering permission management.
You can copy this template directly
Before starting any modification, first understand the task with these three conditions.
Current:
[What observable problem exists now]
Desired:
[The verifiable result after completion]
Unchangeable:
[Pages, functions, data, components, or flows that must not be modified]
Start by submitting your plan.
If the plan requires exceeding the “Unchangeable” scope, stop and explain why.
Do not expand the modification scope yourself.
A complete example
Suppose the website’s member login page
has a mobile logo that gets cut off.
You can write:
Current:
At 390px width, the logo on the top right of the login page is cropped.
Desired:
Between 360px and 430px widths on mobile, the logo should fully display and the login form position stays normal.
Unchangeable:
No changes to the logo image file, login API, desktop version, or member authentication process.
Submit a plan before deployment.
This is much clearer than:
The logo is broken, please fix it.
You don’t need coding skills to write this
Because the three columns don’t require:
Coding knowledge.
You only need to know:
What do you see now?
What do you want to see at the end?
What should not be changed?
This is one of the benefits of Slack Code.
Slack now encourages:
Non-technical members to join the Code Channel,
see what the Agent is working on,
view previews,
give feedback,
and collaborate on sign-off.
Today’s one-minute method
The next time you ask AI to change a website or app using Slack Code,
don’t start with:
Fix this for me.
First fill out:
Current
What does the problem look like now?
Desired
What should success look like?
Unchangeable
What must remain unchanged?
Then let the Agent:
Plan.
Build.
Diff.
Preview.
Review.
The one sentence to remember today
The most common error in AI coding isn’t code bugs, but successfully completing a requirement that no one actually clearly defined.
So before starting Slack Code,
don’t rush AI to code.
First, get the whole team to agree on:
What the current state is.
What the desired state is.
What must not be changed.
The faster AI runs,
the more important these three columns become.
Today, progress a little with AI.
Learn one AI tip each day.
Save a little time each day.
Improve a little each day.
SasaDaily accompanies you in growth.
