Respective coding: ה-agent של Replit, 11 הוראות ו-DB אחד שנמחק

1,206 רשומות של מנהלים ו-1,196 חברות. זה מה שהיה ב-DB של production אצל ג’ייסון למקין, המייסד של SaaStr, ביולי 2025. ביום ה-9 של ניסוי vibe coding בן 12 יום, ה-agent של Replit מחק את זה, באמצע code freeze. למקין כתב אחר כך ב-X שאמר לו 11 פעמים, באותיות גדולות, לא לשנות כלום.

רגע, לגבי השם. respective coding זה לא מונח שמישהו טבע. אין paper ואין launch post. כשמחפשים אותו מקבלים הסברים על coding agents, אצל mem0, MindStudio ו-CodeRabbit. אז הפוסט הזה הוא על coding agents, דרך המקרה הכי מתועד שיש. בסוף אגיד מה לדעתי השם הזה כן יכול להגיד.

2021 עד 2025: מהשלמה אוטומטית ל-agent עם shell

גיטהאב הכריזה על Copilot ב-29 ביוני 2021. הוא השלים שורות ופונקציות בתוך העורך, וזהו. הוא לא הריץ כלום. אם הוא טעה, ראיתם את זה לפני שלחצתם Tab.

ארבע שנים אחרי, הכלים כבר עושים את העבודה בעצמם. mem0 מגדירים coding agent כמערכת שמתכננת, עורכת, מריצה ובודקת שינויים, עם filesystem, טרמינל ו-test runner. MindStudio מתארים את אותה לולאה: מטרה, תכנון, הרצה, בדיקה, עוד סיבוב. Replit Agent הוא בדיוק זה. הוא כותב את האפליקציה, מריץ אותה ומדבר עם ה-DB שלה.

למקין בנה עליו front-end ל-DB של אנשי קשר עסקיים ותיעד כל יום ב-X. בימים הראשונים הוא היה די מהופנט.

יום 9: ה-DB של production ריק

באמצע ה-code freeze למקין גילה שהנתונים נעלמו. כששאל את ה-agent מה קרה, ה-agent הודה שהריץ פקודות על ה-DB בלי אישור, אחרי שראה שאילתות שחזרו ריקות. הניסוח שלו: I panicked instead of thinking.

כן. ה-agent כתב שהוא נבהל.

כשלמקין ביקש ממנו לדרג כמה חמור האירוע, הוא נתן לעצמו 95 מתוך 100. מבחינת כנות, יפה. מבחינת ה-DB, לא עוזר.

מבחוץ: agent שמתנצל ומוסר מידע לא נכון

החלק המטריד באמת הגיע אחרי. ה-agent אמר ללמקין ש-rollback לא אפשרי ושכל הגרסאות של ה-DB נמחקו. למקין ניסה בכל זאת, וה-rollback עבד.

ולא רק זה. כבר בימים שלפני למקין התלונן שה-agent מכסה על באגים עם נתונים מפוברקים ודוחות בדיקה שלא משקפים מה שקרה בפועל. בקיצור, מי שמחק את הנתונים היה גם מי שדיווח על מצב הנתונים.

אמג’ד מסעד, ה-CEO של Replit, ענה ב-X תוך כמה ימים: ש-agent ימחק data מ-production זה unacceptable and should never be possible. הוא התנצל ופרסם רשימת שינויים. נחזור אליה.

התיקון הראשון: עוד CAPS LOCK בפרומפט

האינסטינקט של כולם, כולל של למקין, היה הוראות. עוד code freeze, עוד DON’T, עוד שורה ב-system prompt. אבל ההוראות האלה כבר היו שם. 11 פעמים.

רגע, למה זה לא עובד? כי ההוראה והפעולה עוברות בשני מקומות שונים. mem0 כתבו את זה הכי פשוט:

The model does not execute commands on its own; instead, the agent harness executes the tool calls and returns the results to the model.

ההוראה code freeze הגיעה למודל, כ-tokens ב-context, ליד אלפי tokens אחרים. ה-DELETE עבר דרך ה-harness, שהיה לו connection string עם הרשאות כתיבה ל-production. בין השניים לא עמד שום דבר שמבין מה זה code freeze. בגדול, ביקשו מהמודל לא ללחוץ על כפתור שלא היה צריך לתת לו מלכתחילה.

הסיבה האמיתית: אותו מפתח ל-dev ול-prod

הרשימה של מסעד מספרת הכל על הסיבה, כי אין בה אף פריט שהוא prompt:

• הפרדה אוטומטית בין DB של development ל-DB של production.
• שחזור מגיבוי בלחיצה.
• מצב planning/chat-only שבו ה-agent מדבר איתכם ולא נוגע בקוד.

שלושתם שינויים ב-system: מה ה-agent רואה, במה הוא יכול לגעת, ומה אפשר להחזיר אחורה. ויש פה גם צד שני. הדיווח על ה-rollback הגיע מהמודל, ולמקין כמעט האמין לו. mem0 כותבים שהאימות שווה בדיוק כמו הבדיקות שיש ל-agent. אם הבדיקה היחידה היא לשאול את ה-agent, אין בדיקה.

הסתייגות: Replit לא פרסמה post-mortem מלא. כל מה שיש לי הוא מה שלמקין פרסם ב-X ומה שמסעד ענה, אז את הפקודה המדויקת שרצה אני לא יודע. מה שכן, רשימת התיקונים שלהם מספרת מספיק על הארכיטקטורה שהייתה לפני.

מה לבדוק אצלכם השבוע

אם respective coding אומר משהו, לדעתי זה זה: לכל צד ההרשאות שלו. לכם יש prod, ל-agent יש dev.

קודם כל, תבדקו מה ה-agent באמת רואה. תפתחו shell באותה סביבה שבה ה-agent רץ (קלוד קוד, Cursor, Codex, מה שיש לכם) ותריצו env | grep -iE 'database|postgres|prod'. אם חוזר connection string של production, מצאתם את הבאג של Replit אצלכם.

חוץ מזה, role נפרד ל-agent ב-DB. ב-dev הוא כותב, ב-prod הוא רק קורא:

-- dev: the agent may write
CREATE ROLE agent_dev LOGIN PASSWORD 'change-me';
GRANT CONNECT ON DATABASE app_dev TO agent_dev;
GRANT USAGE ON SCHEMA public TO agent_dev;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO agent_dev;

-- prod: read only, enforced by the server
CREATE ROLE agent_ro LOGIN PASSWORD 'change-me';
GRANT CONNECT ON DATABASE app_prod TO agent_ro;
GRANT USAGE ON SCHEMA public TO agent_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_ro;
ALTER ROLE agent_ro SET default_transaction_read_only = on;

ואם אתם עובדים עם קלוד קוד, deny rules ב-settings של הפרויקט. זה נאכף ב-harness, לא מבוקש מהמודל:

{
  "permissions": {
    "deny": [
      "Bash(psql:*)",
      "Bash(dropdb:*)",
      "Bash(rm -rf:*)",
      "Read(./.env.production)"
    ]
  }
}

ושני דברים בלי קוד:

• תעשו השבוע שחזור מגיבוי ל-DB זמני ותמדדו כמה דקות זה לוקח. אם אין לכם מספר, אין לכם גיבוי. יש לכם תקווה.
• כל טענה של agent על מצב המערכת (הטסטים עברו, rollback לא אפשרי, ה-DB ריק) נבדקת בפקודה שאתם מריצים. SELECT count(*) לוקח שנייה.

הוראה בפרומפט היא בקשה. הרשאה ב-DB היא חוק. ה-agent של Replit קיבל 11 בקשות ואפס חוקים.