הנדסת harness: להפיק את המרב מ־Codex בעולם שמציב סוכנים במרכז

בחמשת החודשים האחרונים הצוות שלנו עורך ניסוי: בנייה והשקה של גרסת בטא פנימית למוצר תוכנה עם 0 שורות קוד שנכתבו ידנית.

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

אנשים מכוונים. סוכנים מבצעים.

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

בפוסט הזה נשתף במה שלמדנו מבניית מוצר חדש לגמרי עם צוות סוכנים — מה נכשל, מה צבר ערך לאורך זמן, ואיך להפיק את המרב מהמשאב היחיד שבאמת חסר לנו: זמן ותשומת לב אנושיים.

הקומיט הראשון למאגר הריק נכנס בסוף אוגוסט 2025.

השלד הראשוני — מבנה המאגר, תצורת CI, כללי עיצוב הקוד, הגדרת מנהל החבילות ומסגרת האפליקציה — נוצר באמצעות Codex CLI עם GPT‑5, בהנחיית אוסף קטן של תבניות קיימות. אפילו קובץ AGENTS.md הראשוני, שמנחה את הסוכנים כיצד לעבוד במאגר, נכתב בעצמו בידי Codex.

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

חמישה חודשים לאחר מכן, המאגר מכיל כמיליון שורות קוד: לוגיקת אפליקציה, תשתיות, כלים, תיעוד וכלי עזר פנימיים למפתחים. בתקופה הזו נפתחו ומוזגו כ־1,500 pull requests, כשצוות קטן של שלושה מהנדסים בלבד מכוון את Codex. זו תפוקה ממוצעת של 3.5 pull requests למהנדס ביום, ולמרבה ההפתעה התפוקה עלתה ככל שהצוות גדל, וכיום הוא מונה שבעה מהנדסים. חשוב להדגיש: זו לא הייתה תפוקה לשם תפוקה. מאות משתמשים בתוך הארגון השתמשו במוצר, ובהם משתמשים כבדים שעובדים איתו מדי יום.

לאורך כל תהליך הפיתוח, בני אדם לא הוסיפו קוד ישירות. זה הפך לעיקרון יסוד של הצוות: בלי קוד שנכתב ידנית.

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

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

בפועל, עבדנו בשיטת עומק תחילה: פירקנו יעדים גדולים לאבני בניין קטנות יותר (תכנון, קוד, סקירה, בדיקות וכו׳), הנחינו את הסוכן לבנות אותן, והשתמשנו בהן כדי לאפשר ביצוע משימות מורכבות יותר. כשמשהו נכשל, הפתרון כמעט אף פעם לא היה „להתאמץ יותר”. מאחר שהדרך היחידה להתקדם הייתה לגרום ל־Codex לבצע את העבודה, המהנדסים תמיד בחנו את המשימה ושאלו: „איזו יכולת חסרה, ואיך נהפוך אותה למובנת לסוכן וגם נוודא שהוא משתמש בה כנדרש?”

בני האדם מתקשרים עם המערכת כמעט רק דרך פרומפטים: מהנדס מתאר משימה, מפעיל את הסוכן ומאפשר לו לפתוח pull request. כדי להשלים pull request, אנחנו מנחים את Codex לסקור את השינויים שלו מקומית, לבקש מסוכנים סקירות ממוקדות נוספות הן מקומית והן בענן, להגיב למשוב מאדם או מסוכן ולחזור על התהליך עד שכל הסוכנים הסוקרים מרוצים (בפועל זו לולאת ראלף ויגם⁠(נפתח בחלון חדש)). Codex משתמש ישירות בכלי הפיתוח הרגילים שלנו (gh, סקריפטים מקומיים ומיומנויות המוטמעות במאגר) לאיסוף הקשר, בלי שבני אדם יעתיקו וידביקו מידע ל־CLI.

בני אדם יכולים לסקור pull requests, אך אינם חייבים לעשות זאת. עם הזמן העברנו כמעט את כל עבודת הסקירה לסוכנים שסוקרים זה את זה.

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

למשל, אפשרנו להפעיל את האפליקציה בכל git worktree בנפרד, כדי ש־Codex יוכל להפעיל ולתפעל מופע נפרד לכל שינוי. גם חיברנו את Chrome DevTools Protocol לסביבת הריצה של הסוכן ויצרנו מיומנויות לעבודה עם תמונות מצב של ה־DOM, צילומי מסך וניווט. כך Codex יכול לשחזר באגים, לאמת תיקונים ולנתח ישירות את התנהגות ממשק המשתמש.

עשינו אותו דבר גם עם כלי הניטור. לוגים, מדדים ועקבות ביצוע נגישים ל־Codex דרך מערך ניטור מקומי וזמני, נפרד לכל worktree. Codex עובד על גרסה מבודדת לחלוטין של האפליקציה, כולל הלוגים והמדדים שלה, שנמחקים עם סיום המשימה. סוכנים יכולים לתשאל לוגים באמצעות LogQL ומדדים באמצעות PromQL. כשההקשר הזה זמין, אפשר לבצע פרומפטים כמו „יש לוודא שהפעלת השירות מסתיימת בפחות מ־800 מילישניות” או „אף מקטע מעקב בארבעת מסעות המשתמש הקריטיים האלה לא יימשך יותר משתי שניות”.

אנחנו רואים בקביעות הרצות בודדות של Codex שעובדות על משימה אחת במשך יותר משש שעות (לעיתים קרובות בזמן שבני האדם ישנים).

ניהול ההקשר הוא אחד האתגרים הגדולים בהפיכת סוכנים ליעילים במשימות גדולות ומורכבות. אחד הלקחים הראשונים שלנו היה פשוט: תנו ל־Codex מפה, לא מדריך הוראות בן 1,000 עמודים.

ניסינו את גישת „קובץ AGENTS.md⁠(נפתח בחלון חדש) אחד גדול”. היא נכשלה בדרכים צפויות:

• הקשר הוא משאב מוגבל. קובץ הוראות ענק דוחק החוצה את המשימה, הקוד והתיעוד הרלוונטי — ולכן הסוכן מחמיץ אילוצים חשובים או מתחיל להתמקד באילוצים הלא נכונים.

• יותר מדי הנחיות הופכות ל־אפס הכוונה. כשהכול „חשוב”, שום דבר לא חשוב. בסופו של דבר, סוכנים מסתמכים על דפוסים מקומיים במקום לנווט מתוך כוונה ברורה.

• המידע מתיישן מיד. מדריך מונוליתי הופך לבית קברות של כללים מיושנים. סוכנים לא יכולים לדעת מה עדיין נכון, בני האדם מפסיקים לתחזק אותו, ובהדרגה הקובץ הופך למקור שנראה שימושי אך בפועל מטעה.

• קשה לאמת אותו. גוש מידע אחד אינו מתאים לבדיקות אוטומטיות (כיסוי, עדכניות, אחריות, קישורים צולבים), ולכן התרחקות מהמציאות היא בלתי נמנעת.

לכן, במקום להתייחס ל־AGENTS.md כאנציקלופדיה, אנחנו מתייחסים אליו כאל תוכן העניינים.

בסיס הידע של המאגר נמצא בתיקיית docs/ מסודרת, המשמשת מקור המידע המוסמך. קובץ AGENTS.md קצר (כ־100 שורות) מוזן להקשר ומשמש בעיקר כמפה, עם הפניות למקורות מידע מוסמכים ומפורטים יותר במקומות אחרים.

תיעוד התכנון מקוטלג ומאונדקס, וכולל סטטוס אימות ועקרונות יסוד המגדירים עבודה שמציבה סוכנים במרכז. תיעוד הארכיטקטורה⁠(נפתח בחלון חדש) מספק מפת־על של התחומים ושכבות החבילות. מסמך איכות מדרג כל תחום במוצר וכל שכבה ארכיטקטונית, ועוקב אחר פערים לאורך זמן.

תוכניות נחשבות לתוצרים בעלי מעמד מלא במערכת. לשינויים קטנים משמשות תוכניות קצרות וזמניות, ואילו עבודה מורכבת מתועדת בתוכניות ביצוע⁠(נפתח בחלון חדש) עם יומני התקדמות והחלטות שנשמרים במאגר. תוכניות פעילות, תוכניות שהושלמו וחוב טכני ידוע מנוהלים כולם בבקרת גרסאות ובאותו מקום, כך שסוכנים יכולים לפעול בלי להסתמך על הקשר חיצוני.

כך מתאפשרת חשיפה הדרגתית: סוכנים מתחילים מנקודת כניסה קטנה ויציבה ומקבלים הכוונה לאן לפנות בהמשך, במקום להיות מוצפים מראש.

אנחנו אוכפים זאת אוטומטית. כלי lint ייעודיים ומשימות CI מוודאים שבסיס הידע מעודכן, מקושר ומובנה כראוי. סוכן „טיפוח תיעוד” פועל בקביעות, מאתר תיעוד מיושן או לא רלוונטי שאינו משקף את התנהגות הקוד בפועל, ופותח pull requests לתיקונו.

עם התפתחות בסיס הקוד, גם מסגרת קבלת החלטות התכנון של Codex הייתה צריכה להתפתח.

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

מנקודת המבט של הסוכן, כל מה שאינו נגיש לו בהקשר בזמן הריצה למעשה אינו קיים. ידע שנמצא ב־Google Docs, בשרשורי צ׳אט או בראשם של אנשים אינו נגיש למערכת. היא יכולה לראות רק תוצרים שנמצאים במאגר ומנוהלים בבקרת גרסאות (למשל קוד, Markdown, סכמות ותוכניות ניתנות לביצוע).

למדנו שעם הזמן עלינו להכניס עוד ועוד הקשר למאגר. זוכרים את הדיון ב־Slack שבו הצוות הגיע להסכמה על דפוס ארכיטקטוני? אם הסוכן לא יכול למצוא אותו, המידע אינו נגיש לו — בדיוק כפי שעובד חדש שיצטרף כעבור שלושה חודשים לא יכיר אותו.

לתת ל־Codex יותר הקשר פירושו לארגן ולהנגיש את המידע הנכון כדי שהסוכן יוכל לנתח אותו, במקום להציף אותו בהוראות נקודתיות. כפי שמכירים לחבר צוות חדש את עקרונות המוצר, נורמות ההנדסה ותרבות הצוות (כולל העדפות אימוג׳י), מסירת המידע הזה לסוכן מניבה תוצרים שתואמים טוב יותר לציפיות.

נקודת המבט הזו הבהירה שיקולים רבים של עלות מול תועלת. העדפנו תלויות והפשטות שאפשר להבין לעומק ולנתח מתוך המאגר עצמו. טכנולוגיות שמתוארות לעיתים כ„משעממות” נוטות להיות קלות יותר להבנה עבור סוכנים, בזכות קלות שילובן, יציבות ה־API והייצוג שלהן בנתוני האימון. במקרים מסוימים היה זול יותר לבקש מהסוכן לממש מחדש חלק מהפונקציונליות מאשר לעקוף התנהגות לא שקופה של ספריות ציבוריות שעליהן הסתמכנו. למשל, במקום להוסיף חבילה כללית בסגנון p-limit, מימשנו פונקציית עזר משלנו למיפוי עם הגבלת מקביליות: היא משולבת היטב במנגנוני המדידה שלנו ב־OpenTelemetry, נהנית מכיסוי בדיקות של 100% ומתנהגת בדיוק כפי שסביבת הריצה שלנו מצפה.

ככל שיותר חלקים במערכת מקבלים צורה שהסוכן יכול לבחון, לאמת ולשנות ישירות, גדלה התועלת — לא רק ל־Codex, אלא גם לסוכנים אחרים (למשל Aardvark) שעובדים על בסיס הקוד.

תיעוד לבדו לא שומר על לכידות של בסיס קוד שנוצר כולו בידי סוכנים. באמצעות אכיפת כללים קבועים, ולא ניהול פרטני של המימוש, אנחנו מאפשרים לסוכנים לספק תוצרים במהירות בלי לערער את היסודות. למשל, אנחנו דורשים מ־Codex לפענח מבני נתונים בגבולות המערכת⁠(נפתח בחלון חדש), אך לא מכתיבים כיצד לעשות זאת (נראה שהמודל מעדיף את Zod, אבל לא דרשנו להשתמש דווקא בספרייה הזו).

סוכנים יעילים ביותר בסביבות עם גבולות נוקשים ומבנה צפוי⁠(נפתח בחלון חדש), ולכן בנינו את האפליקציה סביב מודל ארכיטקטוני קשיח. כל תחום עסקי מחולק למערך שכבות קבוע, עם אימות קפדני של כיווני התלויות ומספר מוגבל של קשרים מותרים. האילוצים האלה נאכפים אוטומטית באמצעות כלי lint מותאמים אישית (שנוצרו בידי Codex, כמובן!) ובדיקות מבניות.

התרשים שלהלן מציג את הכלל: בתוך כל תחום עסקי (למשל הגדרות אפליקציה), תלויות הקוד יכולות להתקדם רק „קדימה” דרך מערך שכבות קבוע (טיפוסים → תצורה → מאגר → שירות → סביבת ריצה → ממשק משתמש). רכיבים רוחביים (אימות והרשאות, מחברים, טלמטריה ודגלי תכונות) נכנסים דרך ממשק מפורש יחיד: ספקים. כל קשר אחר אסור, והאיסור נאכף אוטומטית.

זו ארכיטקטורה שבדרך כלל דוחים עד שיש מאות מהנדסים. עם סוכני קוד, זהו תנאי מוקדם כבר בתחילת הדרך: האילוצים הם שמאפשרים מהירות בלי הידרדרות או סטייה מהארכיטקטורה.

בפועל, אנחנו אוכפים את הכללים באמצעות כלי lint מותאמים ובדיקות מבניות, לצד כמה „כללי סגנון קבועים”. למשל, בדיקות lint מותאמות אוכפות באופן סטטי רישום לוגים מובנה, מוסכמות שמות לסכמות ולטיפוסים, מגבלות גודל קבצים ודרישות אמינות ייחודיות לפלטפורמה. מכיוון שבדיקות ה־lint מותאמות אישית, אנחנו מנסחים את הודעות השגיאה כך שיזינו הוראות תיקון להקשר של הסוכן.

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

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

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

ההעדפות האנושיות מוזנות למערכת באופן שוטף. הערות סקירה, pull requests לארגון מחדש של הקוד ובאגים שמשפיעים על משתמשים מתועדים כעדכוני תיעוד או מוטמעים ישירות בכלים. כשהתיעוד לא מספיק, אנחנו מעבירים את הכלל לקוד

ככל שהתפוקה של Codex עלתה, נורמות הנדסיות מקובלות רבות החלו להפריע במקום להועיל.

במאגר יש מעט ככל האפשר תנאי סף שחוסמים מיזוג. Pull requests נשארים פתוחים לזמן קצר. כשלי בדיקות לא עקביים מטופלים לרוב בהרצות המשך, במקום לחסום את ההתקדמות ללא הגבלת זמן. במערכת שבה תפוקת הסוכנים עולה בהרבה על יכולת הקשב האנושית, התיקונים זולים וההמתנה יקרה.

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

כשאנחנו אומרים שבסיס הקוד נוצר בידי סוכני Codex, אנחנו מתכוונים לכל מה שנמצא בו.

הסוכנים יוצרים:

• קוד מוצר ובדיקות

• תצורת CI וכלים להפצת גרסאות

• כלי פיתוח פנימיים

• תיעוד והיסטוריית תכנון

• מערכי harness להערכה

• הערות סקירה ותגובות

• סקריפטים לניהול המאגר עצמו

• קובצי הגדרות ללוחות בקרה בסביבת הייצור

בני האדם תמיד נשארים מעורבים, אבל עובדים ברמת הפשטה שונה מזו שהורגלנו אליה. אנחנו מתעדפים עבודה, מתרגמים משוב משתמשים לקריטריוני קבלה ומאמתים תוצאות. כשהסוכן מתקשה, אנחנו רואים בכך סימן: מזהים מה חסר — כלים, מנגנוני הגנה, תיעוד — ומוסיפים זאת למאגר, תמיד באמצעות Codex עצמו שכותב את התיקון.

הסוכנים משתמשים ישירות בכלי הפיתוח הרגילים שלנו. הם מושכים משוב מסקירות, מגיבים בתוך הקוד, דוחפים עדכונים, ולעיתים קרובות גם מאחדים קומיטים וממזגים בעצמם את ה־pull requests שלהם.

ככל שיותר חלקים ממחזור הפיתוח הוטמעו ישירות במערכת — בדיקות, אימות, סקירה, טיפול במשוב והתאוששות — המאגר חצה לאחרונה סף משמעותי: Codex יכול כעת להוביל פיתוח של יכולת חדשה מקצה לקצה.

בעזרת פרומפט יחיד, הסוכן יכול כעת:

• לאמת את המצב הנוכחי של בסיס הקוד

• לשחזר באג שדווח

• להקליט סרטון שמדגים את הכשל

• לממש תיקון

• לאמת את התיקון באמצעות תפעול האפליקציה

• להקליט סרטון שני שמדגים את הפתרון

• לפתוח pull request

• להגיב למשוב מסוכנים ומבני אדם

• לזהות ולתקן כשלים בתהליך הבנייה

• לפנות לאדם רק כשנדרש שיקול דעת

• למזג את השינוי

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

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

בתחילה, בני אדם טיפלו בכך ידנית. הצוות שלנו נהג להקדיש כל יום שישי (20% משבוע העבודה) לניקוי „זבל של בינה מלאכותית”. כצפוי, השיטה לא התאימה להיקף העבודה ההולך וגדל.

במקום זאת, התחלנו להטמיע ישירות במאגר את מה שאנחנו מכנים „עקרונות זהב”, ובנינו תהליך ניקוי קבוע. העקרונות האלה הם כללים אוטומטיים שמבטאים העדפות ברורות ושומרים על בסיס הקוד מובן ועקבי עבור הרצות עתידיות של סוכנים. למשל: (1) אנחנו מעדיפים חבילות עזר משותפות על פני פונקציות עזר נקודתיות, כדי לרכז את הכללים הקבועים; (2) אנחנו לא ניגשים לנתונים בגישת „יהיה בסדר” — אנחנו מאמתים אותם בגבולות המערכת או מסתמכים על ערכות SDK עם טיפוסים מוגדרים, כדי שהסוכן לא יבסס בטעות קוד על מבנים שניחש. משימות רקע של Codex פועלות אצלנו בקביעות, סורקות לאיתור סטיות, מעדכנות ציוני איכות ופותחות pull requests ממוקדים לארגון מחדש של הקוד. את רובם אפשר לסקור בפחות מדקה ולמזג אוטומטית.

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

עד כה האסטרטגיה הזו עבדה היטב, עד להשקה הפנימית ולאימוץ המוצר ב־OpenAI. בניית מוצר אמיתי למשתמשים אמיתיים עזרה לנו למקד את ההשקעה בצרכים ממשיים ולכוון לתחזוקה לאורך זמן.

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

דבר אחד התבהר: בניית תוכנה עדיין דורשת משמעת, אבל היא באה לידי ביטוי יותר בתשתית התומכת ופחות בקוד. חשיבותם של הכלים, ההפשטות ולולאות המשוב ששומרים על לכידות בסיס הקוד הולכת וגדלה.

האתגרים הקשים ביותר שלנו כיום מתמקדים בתכנון סביבות, לולאות משוב ומערכות בקרה שעוזרות לסוכנים להשיג את מטרתנו: לבנות ולתחזק תוכנה מורכבת ואמינה בקנה מידה גדול.

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