DevYouUp

ארכיטקטורת תוכנה ברמת Principal · בנויה לעידן ה-AI

אנחנו הופכים תוכנה למוכנה לפרודקשן - כולל תוכנה שנכתבה בעזרת AI.

למייסדים, ל-CTO ולמנהלי הנדסה שמעלים לפרודקשן מוצרי B2B SaaS, תשלומים או מוצרים שנבנו בעזרת AI.

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

לתיאום שיחת ייעוץ של 30 דקות ← לכל ההוכחות

הבעיה

// למה בהיקף חלקי, ולמה דווקא עכשיו

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

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

איך עובדים יחד

// מרחוק · בכל העולם · מבוסס בישראל
ליווי שוטף · 1-3 ימים בשבוע

ארכיטקט תוכנה ראשי, בהיקף חלקי

הסמכות הטכנולוגית הבכירה שלכם - בהיקף חלקי.

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

ריטיינר חודשי, בהתאם להיקף הימים

מתאים לצוותים של 2-20 מהנדסים שמוציאים גרסאות במהירות, בלי ארכיטקט בכיר ברמת Principal בצוות.

הוכחות רלוונטיות: פרצות אבטחה נעצרו לפני השקה · הוצאות הענן קוצצו ב־84% ←
היקף מוגדר · 1-2 שבועות

בדיקת מוכנות לפרודקשן

בדיקה שיטתית של המוצר לפני העלאה לפרודקשן.

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

מחיר קבוע, לפי מספר מאגרי הקוד והיקף העבודה

מתאים לפני השקה, לפני גיוס או אחרי תקרית.

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

ביקורת שימוש בכלי AI לפיתוח

איך הצוות שלכם באמת משתמש בכלי AI לכתיבת קוד - ואילו סיכונים השימוש הזה יוצר.

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

מחיר קבוע, שבוע אחד, תוצר אחד

מתאים לכל צוות שבו AI כותב חלק משמעותי מהקוד.

הוכחות רלוונטיות: מדיניות לסוכני AI נכתבה בעקבות דליפת פרטי גישה אמיתית ←
  1. 01
    מתחילים מכשל אפשרי

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

  2. 02
    מגדירים החלטה, לא ריטיינר עמום

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

  3. 03
    נשארים עם הוכחות שאפשר להשתמש בהן

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

השרטוטים

// שלוש מערכות, משורטטות כפי שאנחנו בונים אותן

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

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

מערכת 01 · הודעות וזרימת נתונים

מערכת מבוזרת מונחית אירועים

CLIENTS web · mobile API GATEWAY authn · authz · rate-limit ORDERS SVC PAYMENTS SVC ORDERS DB LEDGER DB one service · one schema OUTBOX EVENT BUS at-least-once NOTIFY WORKER BILLING WORKER DLQ dead-letter after N retries idempotent consumers retry + backoff OBSERVABILITY metrics · traces · alerts · versioned deploys · one-step rollback

אפשר להחליק על השרטוט לרוחב

  1. קצה וגבולות

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

  2. הפרדה באמצעות אירועים

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

  3. מתכננים לכפילויות ולכשלים

    at-least-once פירושו שכפילויות יקרו: הצרכנים אידמפוטנטיים, ניסיונות חוזרים עם השהיה גדלה, והודעות בעייתיות מגיעות לתור dead-letter במקום להיעלם.

  4. צופים ומחזירים לאחור

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

מערכת 02 · יצירה מבוססת אחזור

RAG ברמת פרודקשן

OFFLINE · INDEXING PIPELINE SOURCES docs · tickets · code PARSE + CHUNK EMBED embedding model VECTOR INDEX metadata · tenant tags ONLINE · QUERY PIPELINE QUERY TENANT FILTER deterministic HYBRID RETRIEVAL BM25 + vector · fused RERANK top-50 → top-5 enforced before retrieval - never by the model INJECTION GUARD content ≠ commands CONTEXT data, not instructions LLM grounded prompt ANSWER + citations GROUNDEDNESS EVALS faithfulness · context precision · hallucination rate learnings feed back into chunking & prompts

אפשר להחליק על השרטוט לרוחב

  1. אינדוקס אופליין

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

  2. אחזור היברידי, ואז דירוג מחדש

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

  3. בידוד והגנה

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

  4. עיגון והערכה

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

מערכת 03 · מחזור אספקה

ה-AI SDLC

SPEC + INVARIANTS humans own intent AI AGENTS code tests docs parallel · bounded by policy DETERMINISTIC GATES lint · types security scan secret-leak scan runs at generation speed HUMAN REVIEW judgment only where needed every finding verified TRUST NOTHING · VERIFY EVERYTHING DEPLOY canary · rollback ready TELEMETRY SLOs · error budgets production learnings feed the next spec

אפשר להחליק על השרטוט לרוחב

  1. קודם האפיון

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

  2. סוכנים מממשים

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

  3. מאמתים, לא סומכים

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

  4. משחררים ולומדים

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

הוכחות, לא סיסמאות

// תוצאות הנדסיות נבחרות, 2014-היום
אבטחה · SaaS רב-דיירי

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

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

נסגר לפני ההשקה · ביקורת מלאה של הפלטפורמה הושלמה
ענן · עלויות
-84%

קיצצנו את הוצאות AWS בלי לפגוע בארכיטקטורה

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

מעבר לפרודקשן 2026-06 · פעיל מאז
תשלומים · אמינות
100%

עצרנו שחרור של גרסה בגלל פגם שהיה גורם לכשל בכל החזר כספי

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

נבדק מול ספק תשלומים פעיל, לרבות ניסיונות חוזרים · שוחרר
הנדסה בעידן ה-AI · אבטחה

כתבנו כללי אבטחה לסוכני AI - בעקבות תקרית אמיתית, לא כתיאוריה

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

נאכף ב-CI · בתוקף מאז
הנדסה בעידן ה-AI · איכות
46

תוקנו 46 תקלות אמיתיות בסבב אחד - אחרי שכל ממצא של AI אומת ידנית

שישה סוכני סקירה פעלו על פיצ'ר הפרוס על פני שבעה מאגרי קוד. מתוך 48 ממצאים ראשוניים, כל אחד אומת בקריאת קוד ישירה; אחד נפסל כזיהוי שגוי. 46 תיקונים ב-11 PRs שנבדקו נפרסו יחד.

48 → 46 מאומתים · זיהוי שגוי אחד נפסל
תשלומים · ציות רגולטורי

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

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

סיכון הרישוי בוטל כבר בתכנון
מודרניזציה של מערכות מורשת · הובלת צוות
+60%

הובלנו מודרניזציה של מערכות המובייל הוותיקות בחברת טלקום ארצית

הובלנו צוות של שישה מפתחים במעבר מאפליקציות Java ותיקות ל-Kotlin, עם דפוסי ארכיטקטורה מודרניים - ושיפרנו את יעילות האפליקציות בשיעור של עד 60% במוצרים הפועלים ב-Android, ב-iOS ובפלטפורמות טלוויזיה חכמה.

בוצע כראש צוות · חברת טלקום ארצית
אוטומציה · הנדסת צמיחה
8×

בנינו אוטומציה שהגדילה עד פי 8 את החשיפה העסקית של לקוחות

תכננו אוטומציה ב-Python ומערכות לצמיחה עסקית עבור לקוחות הייעוץ שלנו - והגדלנו את חשיפת הפרופיל ואת המעורבות עד 800%, על בסיס אותם סטנדרטים של אמינות שמנחים את כל העבודה כאן.

בוצע במסגרת פעילות הייעוץ

ניסיון מוכח

// שלוש דרכים שבהן אנחנו מביאים תוכנה לפרודקשן כבר עשור
מיזם · מייסד וארכיטקט

Brasserio

פלטפורמת SaaS להזמנות ולתפעול מסעדות: עשרה מיקרו־שירותים ב-Python על AWS, תהליכים מונחי אירועים, תשלומים, פריסה ב-GitOps ואפליקציות לצוות מבסיס קוד אחד ב-Kotlin Multiplatform - שתוכננו, נבנו ומופעלות בידי ארכיטקט אחד.

2חנויות אפליקציות פעילות
3פלטפורמות על בסיס קוד אחד
7שפות, כולל ממשקי RTL
הובלה · ראש צוות מובייל

אפליקציות מובייל וטלוויזיה לצרכן

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

6מפתחים בצוות
+60%שיפור יעילות
5שנים כראש צוות
ייעוץ · משנת 2014

פרקטיקת DevYouUp

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

טלקום ארציפינטקהלת׳-טקEdTechAdTechסייברB2B / SaaSטכנולוגיה למסעדות

ניסיון

// ציר הזמן המלא נמצא ב-LinkedIn

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

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

ארכיטקטורהמערכות מבוזרותבקאנדפרונטאנדמוביילענןתשלומיםAI SDLCבניית צוותים וגיוס
ציר הזמן המלא ב-LinkedIn ↗

שאלות שצוותים שואלים לפני שחרור

// תשובות ממוקדות לסיכונים ממוקדים
האם קוד שנכתב בעזרת AI עדיין זקוק לבדיקת מוכנות לפרודקשן?

כן. AI יכול להאיץ את המימוש, אבל הוא לא מוכיח שגבולות ההרשאה, התשלומים, יכולת החזרה לאחור והטיפול בפרטי גישה בטוחים בפרודקשן.

איך בודקים שחרור של מערכת תשלומים לפני העלאה לפרודקשן?

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

מה עושה ארכיטקט תוכנה ראשי בהיקף חלקי?

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

מה להביא לשיחת סיכונים של 30 דקות?

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

פיצ'ר ה-AI שלנו עובד יפה בדמו. למה פרודקשן זה סיפור אחר?

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

AI כותב חלק הולך וגדל מהקוד שלנו. איך שומרים על סקירת קוד משמעותית?

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

איך מונעים מסוכני AI לכתיבת קוד להדליף סודות או למשוך תלויות מסוכנות?

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

עלויות הענן וה-AI שלנו גדלות מהר מהשימוש. מהם המנופים הארכיטקטוניים?

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

אפשר להוסיף יכולות AI למוצר רב-דיירי בלי שמידע ידלוף בין דיירים?

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

מתי שכתוב של מערכת מוצדק - ומתי הארכיטקטורה ה"משעממת" היא הנכונה?

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

הצעד הבא

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

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

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

נענה תוך יום עסקים אחד.

לתיאום שיחת ייעוץ של 30 דקות ← oraneventzur@devyouup.com לינקדאין ↗

מעדיפים תקשורת אסינכרונית? אימייל מצוין. אנחנו מגיבים תוך יום עסקים אחד, לפי שעון ישראל (GMT+3).