Agentic AI: איך סוכנים אוטונומיים משנים את עולם הפיתוח

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

הרקע: צוות DevOps קטן, מערכת גדולה

לפני כמה חודשים עבדנו עם צוות של חברת SaaS ישראלית — בואו נקרא להם "חברת א'" — שמתפעלת פלטפורמה עם כ-200 מיקרו-שירותים על Kubernetes. הצוות? חמישה אנשי DevOps. חמישה אנשים מול 200 שירותים, עשרות pipelines, ואינסוף alertים שצצים בכל שעה.

בלילה אחד, בשעה 3:12 לפנות בוקר, נפל שירות קריטי. ה-on-call קיבל alert, קם מהשינה, התחבר, וגילה שהבעיה היא לא בשירות עצמו אלא בשרשרת של שלושה שירותים שתלויים אחד בשני. הוא ביצע rollback, אבל ה-rollback שבר שירות אחר. עד שהוא הבין מה קורה — עברו שעתיים. שעתיים שבהן לקוחות לא יכלו להשתמש בפלטפורמה.

זה לא מקרה חריג. לפי דוח של PagerDuty מ-2024, הזמן הממוצע לפתרון תקלה (MTTR) בארגונים בינוניים עומד על 68 דקות — וזה הממוצע. במקרים מורכבים של תלויות בין שירותים, זה יכול לקפוץ לשעות.

הכניסה של הסוכן: לא רק מתריע — פועל

אחרי האירוע הזה, הצוות של חברת א' החליט לנסות גישה אחרת. במקום עוד dashboards ועוד runbooks — הם בנו סוכן Agentic AI. לא chatbot שעונה על שאלות. סוכן שמקבל alert, מנתח את השורש, בודק logs, מריץ בדיקות, מבצע פעולות תיקון, ומדווח — הכל לבד.

הסוכן הזה לא היה קסם. הוא היה תוצאה של שלושה שבועות של עבודה קשה: הגדרת כלים (tools) שהסוכן יכול להפעיל, כתיבת guardrails — מגבלות ברורות למה הסוכן מורשה ולמה לא, ואינטגרציה עם המערכות הקיימות: Prometheus, Grafana, ArgoCD, ו-Slack.

שבועיים אחרי ההטמעה, הייתה תקלה דומה. הסוכן זיהה את הבעיה תוך 90 שניות, איתר את שרשרת התלויות, ביצע rollback ממוקד רק לשירות הבעייתי, וידא שהשירותים התלויים תקינים — והכל נפתר תוך 4 דקות. בלי להעיר אף אחד. הודעה ב-Slack סיכמה את מה שקרה, עם לינק ל-log מלא של כל הפעולות שהסוכן ביצע.

ארבע דקות. בהשוואה לשעתיים. זה לא שיפור — זה שינוי קטגורי.

ההבדל בין LLM, RAG וסוכן אוטונומי

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

LLM (Large Language Model) — מודל שפה גדול כמו GPT-4 או Claude. הוא יודע לייצר טקסט, לענות על שאלות, לכתוב קוד. אבל הוא ריאקטיבי: נותנים לו prompt, הוא מחזיר תשובה. נקודה.

RAG (Retrieval-Augmented Generation) — אותו LLM, אבל עם גישה למאגר ידע חיצוני. שואלים שאלה, המערכת שולפת מסמכים רלוונטיים ומזינה אותם ל-LLM. שיפור משמעותי, אבל עדיין — ריאקטיבי. עדיין מחכה לשאלה.

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

לפי דוח של Gartner מ-2024, עד 2028 כ-33% מיישומי ה-AI הארגוניים יכללו רכיבים של Agentic AI — לעומת פחות מ-1% ב-2023. זו לא תחזית — זו מגמה שכבר במומנטום.

הארכיטקטורה: איך סוכן AI עובד מתחת למכסה המנוע

סוכן Agentic AI מורכב מכמה רכיבים קריטיים:

מנוע חשיבה (Reasoning Engine) — בדרך כלל מבוסס LLM, שמתכנן את הצעדים הנדרשים להשגת המטרה. הוא משתמש בטכניקות כמו Chain-of-Thought ו-ReAct (Reasoning + Acting) כדי לפרק בעיות מורכבות לצעדים הגיוניים.

כלים (Tools) — פונקציות קונקרטיות שהסוכן יכול להפעיל. זה יכול להיות שאילתת מסד נתונים, קריאת API, הרצת פקודת shell, או כל פעולה אחרת שהגדרנו.

זיכרון (Memory) — הסוכן שומר הקשר לאורך השיחה או המשימה. זה כולל זיכרון קצר-טווח (מה קרה במשימה הנוכחית) וזיכרון ארוך-טווח (מה למדתי ממשימות קודמות).

מנגנון בקרה (Guardrails) — הגבולות שמונעים מהסוכן לעשות דברים מסוכנים. זה אולי החלק הכי חשוב, ואני אגיד לכם למה: בלי guardrails, סוכן עם גישה ל-production יכול להרוס אתכם. עם guardrails נכונים — הוא השותף הכי אמין שיש לכם.

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

בואו נצלול לטכנולוגיה. הסוכן שבנינו עם חברת א' מבוסס על framework שנקרא LangGraph — הרחבה של LangChain שמאפשרת לבנות סוכנים כגרפים של מצבים (state graphs). הבחירה הזו לא הייתה אקראית — היא אפשרה לנו לשלוט בזרימת ההחלטות של הסוכן בצורה מדויקת.

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

from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, SystemMessage
from typing import TypedDict, Literal
import subprocess
import json

class IncidentState(TypedDict):
    alert: dict
    analysis: str
    root_cause: str
    action_plan: list
    actions_taken: list
    resolution_status: str

llm = ChatOpenAI(model="gpt-4o", temperature=0)

def analyze_alert(state: IncidentState) -> IncidentState:
    """ניתוח ראשוני של ה-alert — שליפת logs ומטריקות"""
    alert = state["alert"]
    service_name = alert["service"]
    namespace = alert.get("namespace", "default")

    # שליפת logs אחרונים מ-kubectl
    logs_cmd = f"kubectl logs -n {namespace} deployment/{service_name} --tail=100 --since=10m"
    try:
        logs = subprocess.run(logs_cmd.split(), capture_output=True, text=True, timeout=30)
        recent_logs = logs.stdout[-3000:]  # 3000 תווים אחרונים
    except Exception as e:
        recent_logs = f"Error fetching logs: {e}"

    # שליפת מטריקות מ-Prometheus
    prom_query = f'rate(http_requests_total{{service="{service_name}",status=~"5.."}}[5m])'
    # בפועל — קריאה ל-Prometheus API

    analysis_prompt = f"""
    נתקבל alert עבור שירות {service_name}:
    Alert: {json.dumps(alert, indent=2)}
    Logs אחרונים:
    {recent_logs}

    נתח את הבעיה. מה קורה? מה השורש הסביר?
    החזר ניתוח מובנה עם root cause ורשימת פעולות מומלצות.
    """

    response = llm.invoke([
        SystemMessage(content="אתה SRE מומחה. נתח תקלות בצורה מדויקת ותמציתית."),
        HumanMessage(content=analysis_prompt)
    ])

    state["analysis"] = response.content
    return state

def determine_action(state: IncidentState) -> IncidentState:
    """קביעת תוכנית פעולה על סמך הניתוח"""
    action_prompt = f"""
    על סמך הניתוח הבא:
    {state['analysis']}

    קבע תוכנית פעולה. פעולות מותרות:
    1. restart_pod — הפעלה מחדש של pod ספציפי
    2. rollback_deployment — חזרה לגרסה קודמת
    3. scale_up — הגדלת מספר replicas
    4. notify_team — הודעה לצוות בלבד (לא לבצע פעולה אוטומטית)

    פעולות אסורות:
    - מחיקת namespace
    - שינוי ConfigMap ב-production
    - כל פעולה על מסד נתונים

    החזר JSON עם רשימת פעולות מסודרת.
    """

    response = llm.invoke([
        SystemMessage(content="אתה מערכת החלטות SRE. בטיחות קודמת למהירות."),
        HumanMessage(content=action_prompt)
    ])

    state["action_plan"] = json.loads(response.content)
    return state

def execute_actions(state: IncidentState) -> IncidentState:
    """ביצוע הפעולות שאושרו ב-guardrails"""
    actions_taken = []
    ALLOWED_ACTIONS = {"restart_pod", "rollback_deployment", "scale_up", "notify_team"}

    for action in state["action_plan"]:
        action_type = action.get("type")

        if action_type not in ALLOWED_ACTIONS:
            actions_taken.append({"action": action_type, "status": "BLOCKED", "reason": "Not in allowed list"})
            continue

        if action_type == "rollback_deployment":
            service = action["service"]
            namespace = action.get("namespace", "default")
            cmd = f"kubectl rollout undo deployment/{service} -n {namespace}"
            result = subprocess.run(cmd.split(), capture_output=True, text=True, timeout=60)
            actions_taken.append({
                "action": action_type,
                "service": service,
                "status": "SUCCESS" if result.returncode == 0 else "FAILED",
                "output": result.stdout or result.stderr
            })

        elif action_type == "scale_up":
            service = action["service"]
            replicas = min(action.get("replicas", 3), 10)  # guardrail: מקסימום 10
            namespace = action.get("namespace", "default")
            cmd = f"kubectl scale deployment/{service} -n {namespace} --replicas={replicas}"
            result = subprocess.run(cmd.split(), capture_output=True, text=True, timeout=60)
            actions_taken.append({
                "action": action_type,
                "service": service,
                "replicas": replicas,
                "status": "SUCCESS" if result.returncode == 0 else "FAILED"
            })

    state["actions_taken"] = actions_taken
    return state

def verify_resolution(state: IncidentState) -> IncidentState:
    """בדיקה שהפעולות פתרו את הבעיה"""
    # בדיקת health check לשירותים שטופלו
    all_resolved = True
    for action in state["actions_taken"]:
        if action.get("service"):
            service = action["service"]
            namespace = action.get("namespace", "default")
            cmd = f"kubectl rollout status deployment/{service} -n {namespace} --timeout=120s"
            result = subprocess.run(cmd.split(), capture_output=True, text=True, timeout=130)
            if result.returncode != 0:
                all_resolved = False

    state["resolution_status"] = "RESOLVED" if all_resolved else "NEEDS_ESCALATION"
    return state

def should_escalate(state: IncidentState) -> Literal["escalate", "close"]:
    """החלטה: לסגור את ה-incident או להעביר לאדם"""
    if state["resolution_status"] == "NEEDS_ESCALATION":
        return "escalate"
    return "close"

# בניית הגרף
workflow = StateGraph(IncidentState)
workflow.add_node("analyze", analyze_alert)
workflow.add_node("plan", determine_action)
workflow.add_node("execute", execute_actions)
workflow.add_node("verify", verify_resolution)

workflow.set_entry_point("analyze")
workflow.add_edge("analyze", "plan")
workflow.add_edge("plan", "execute")
workflow.add_edge("execute", "verify")
workflow.add_conditional_edges("verify", should_escalate, {
    "escalate": END,  # מעביר לאדם עם כל ההקשר
    "close": END       # סוגר את ה-incident אוטומטית
})

agent = workflow.compile()

שימו לב לכמה דברים קריטיים בקוד הזה. ראשית, ה-guardrails: יש רשימה מפורשת של פעולות מותרות, ויש מגבלות קשיחות — הסוכן לא יכול למחוק namespace, לא יכול לגעת ב-ConfigMap, ומספר ה-replicas מוגבל ל-10. שנית, יש שלב verification — הסוכן לא סוגר incident בלי לוודא שהתיקון באמת עבד. ושלישית, יש escalation path — אם הסוכן לא מצליח לפתור, הוא מעביר לאדם עם כל ההקשר.

ההטמעה בפועל: טעויות שעשינו ולקחים שלמדנו

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

מה שלמדנו: לעולם, אבל לעולם, אל תפרסו סוכן Agentic AI ישר ל-production. התחילו ב-"shadow mode" — הסוכן רץ, מחליט, אבל לא מבצע. רק מדווח מה הוא היה עושה. אתם בודקים את ההחלטות שלו במשך שבוע-שבועיים. רק כשיש רמת ביטחון גבוהה — פותחים לו הרשאות execution.

למדנו גם שה-prompt engineering הוא 20% מהעבודה. 80% זה בניית ה-tooling הנכון, ה-guardrails, וה-observability — היכולת לראות בדיוק מה הסוכן עשה, למה, ומה היתה התוצאה. בלי observability טוב — אתם עיוורים. וסוכן AI עיוור הוא דבר מפחיד.

השוק מוצף בכלים לבניית סוכני Agentic AI. אחרי שבדקנו כמה מהם בפרויקטים אמיתיים, הנה ההשוואה שלנו:

ההמלצה שלנו? אם אתם בונים מערכת production עם דרישות reliability גבוהות — LangGraph. עקומת הלמידה תלולה, אבל השליטה שהיא נותנת לכם שווה את ההשקעה. אם אתם רוצים להתחיל מהר ולבדוק concept — CrewAI או OpenAI Agents SDK יביאו אתכם לתוצאות בימים ולא בשבועות.

מגמות מקומיות שצריך להכיר

השוק הישראלי נמצא בנקודה מעניינת. לפי סקר של Israel Tech Pulse מ-2024, כ-47% מחברות ההייטק הישראליות כבר מנסות או מתכננות להטמיע רכיבי AI אוטונומיים בתוך השנה הקרובה. אבל — וזה "אבל" גדול — רק 12% מהן עברו מ-POC ל-production.

הפער הזה הוא לא טכנולוגי. הוא ארגוני ותרבותי. חברות ישראליות מצטיינות בלרוץ מהר, לבנות POC תוך שבוע, ולהוכיח concept. אבל Agentic AI דורש משהו שהתרבות הישראלית לפעמים מתקשה איתו: סבלנות. צריך לבנות guardrails לפני שרצים. צריך shadow mode לפני production. צריך observability לפני scale.

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

Use cases שעובדים היום בארץ

מעבר ל-DevOps, אני רואה סוכנים Agentic AI בכמה תחומים בישראל שמתפוצצים מפוטנציאל:

אבטחת סייבר — חברות ישראליות כמו אלה שיושבות בבאר שבע בסייברפארק בונות סוכנים שמנתחים alerts של SIEM, מבצעים triage אוטומטי, ובמקרים ברורים — מבודדים endpoints בלי התערבות אנושית. הזמן מ-alert ל-containment ירד מעשרות דקות לשניות.

QA ובדיקות תוכנה — סוכנים שמקבלים PR חדש, מנתחים את השינויים, כותבים בדיקות, מריצים אותן, ומדווחים על תוצאות — כולל הערכה האם הבדיקות הקיימות מכסות מספיק. לפי מחקר של Google Research מ-2024, סוכני AI לבדיקות מגדילים את כיסוי הקוד ב-15-30% בממוצע.

ניהול תשתיות Embedded — וכאן זה מתחבר לעולם שלנו. סוכנים שמנטרים מערכות embedded בשטח — מ-IoT gateways ועד מערכות תעשייתיות — מזהים אנומליות, מבצעים עדכוני firmware, ומדווחים על מצב. זה לא עתיד — זה קורה עכשיו בחברות תעשייתיות ישראליות.

שלב 1: התקנת סביבה ו-Hello World של סוכן

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

# התקנת הספריות הנדרשות
pip install langgraph langchain-openai langchain-core python-dotenv

# הגדרת משתני סביבה
export OPENAI_API_KEY="your-api-key-here"

# אם עובדים עם Kubernetes — וידוא גישה
kubectl cluster-info
kubectl get namespaces

# יצירת מבנה פרויקט
mkdir agentic-sre && cd agentic-sre
mkdir -p agents tools guardrails tests

# הרצת הסוכן ב-shadow mode (לא מבצע פעולות — רק מדווח)
python agent.py --mode shadow --alert-source prometheus --output slack

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

שלב 2: ממשימה אחת למערכת Multi-Agent

אחרי שהסוכן הראשון עובד — מגיע השלב המעניין: בניית מערכת של סוכנים שעובדים ביחד. בחברת א', בנינו בסוף שלושה סוכנים: סוכן ניטור (Monitor Agent), סוכן תיקון (Remediation Agent), וסוכן למידה (Learning Agent) שמנתח incidents שנפתרו ומשפר את ה-runbooks האוטומטיים.

זה נשמע מורכב — וזה מורכב. אבל כשהסוכנים עובדים ביחד? זה כמו צוות SRE שלא ישן, לא שוכח, ומשתפר עם כל incident. ה-MTTR בחברת א' ירד מ-68 דקות ממוצע ל-7 דקות. שבעה דקות. ורוב ה-incidents נסגרים עכשיו בלי התערבות אנושית בכלל.

מה ההבדל בין Agentic AI לבין אוטומציה רגילה?

אוטומציה רגילה (כמו scripts או Ansible playbooks) עוקבת אחרי תסריט קבוע: "אם X — עשה Y". Agentic AI מקבל מטרה ומחליט בעצמו איך להשיג אותה. הוא יכול להתמודד עם מצבים שלא תוכנתו מראש, לפרק בעיות מורכבות לצעדים, ולהתאים את ההתנהגות שלו לפי תוצאות ביניים. ההבדל הוא כמו ההבדל בין GPS שמחשב מסלול מחדש כשיש פקק — לבין הוראות נסיעה מודפסות על דף.

האם Agentic AI מסוכן? מה קורה אם הסוכן טועה?

כן, סוכן AI ללא guardrails יכול להיות מסוכן מאוד — במיוחד אם יש לו גישה לסביבת production. לכן בניית guardrails היא לא אופציונלית — היא הדבר הראשון שבונים. Guardrails כוללים: רשימת פעולות מותרות, הגבלות על scope (רק namespace מסוים, רק שירותים מסוימים), human-in-the-loop לפעולות קריטיות, ו-kill switch שמאפשר לעצור את הסוכן מיידית.

כמה עולה להטמיע סוכן Agentic AI?

העלויות מתחלקות לשלוש קטגוריות: עלויות API (קריאות ל-LLM — בערך 10-50 דולר ליום לסוכן פעיל שמבוסס GPT-4o), עלויות פיתוח (שלושה עד שישה שבועות של מפתח/ת בכיר/ה לסוכן ראשון), ועלויות תפעול שוטפות (ניטור, עדכונים, fine-tuning). עבור צוות DevOps של חברה בינונית, ה-ROI מתחיל להיות חיובי אחרי חודש-חודשיים — בעיקר בזכות הירידה ב-MTTR וב-on-call fatigue.

אילו שפות תכנות צריך לדעת כדי לבנות סוכנים?

Python היא השפה הדומיננטית — כל הפריימוורקים המובילים (LangGraph, AutoGen, CrewAI) בנויים ב-Python. מעבר לפייתון, צריך הבנה טובה ב-API design, ניסיון עם כלי DevOps (kubectl, Docker, CI/CD), והבנה בסיסית של אדריכלות מערכות מבוזרות. ידע ב-prompt engineering עוזר, אבל זה 20% מהעבודה — 80% זה הנדסת תוכנה קלאסית.

האם Agentic AI יחליף מפתחים/ות?

לא. וזה לא סתם תשובה מנחמת — זו תשובה טכנית. סוכני AI מצוינים במשימות שהן repetitive, well-defined, וניתנות למדידה. הם גרועים במשימות שדורשות יצירתיות, הבנת הקשר עסקי, ושיפוט אנושי. מה שכן ישתנה — התפקיד של מפתח/ת DevOps יעבור מ"מריץ/ה פקודות" ל"מאמן/ת סוכנים". זו מיומנות חדשה, ומי שירכוש אותה ראשון/ה — ירוויח/תרוויח.

איך מתחילים ללמוד Agentic AI אם אין לי רקע ב-AI?

אתם לא צריכים תואר ב-AI או הבנה עמוקה ב-machine learning. הפריימוורקים של היום מופשטים מספיק. מה שכן צריך: יסודות חזקים ב-Python, הבנה של APIs ומערכות מבוזרות, וניסיון עם כלים כמו Docker ו-Kubernetes. תתחילו עם התיעוד של LangGraph, תבנו סוכן פשוט שעושה משימה אחת, ותתקדמו משם. ללמוד על ידי בנייה — לא על ידי קריאה.

מה הקשר בין Agentic AI ל-Embedded Systems?

הקשר הולך ומתחזק. סוכני AI יכולים לנטר מערכות embedded מרחוק, לזהות אנומליות בנתוני חיישנים, לתזמן עדכוני firmware, ולנהל צי מכשירים (fleet management) באופן אוטונומי. עם ההתפתחות של מודלים קטנים (SLMs) שיכולים לרוץ על edge — נראה סוכנים שרצים ישירות על המכשיר, מחליטים לוקאלית, ומדווחים לענן רק כשצריך. זה רלוונטי במיוחד למגזר התעשייתי והביטחוני בישראל.

הסיפור של חברת א' הוא לא סיפור על טכנולוגיה. הוא סיפור על צוות שהחליט שהוא לא מוכן להמשיך לעבוד כמו פעם. שהחליט שלקום בשלוש בלילה כדי לעשות משהו שמכונה יכולה לעשות טוב יותר — זה לא גבורה, זה בזבוז. Agentic AI הוא לא קסם ולא מהפכה שקורית בלחיצת כפתור. זה עבודה קשה, הגדרות מדוקדקות, guardrails שנכתבים עם דם יזע ודמעות, ו-shadow mode שנמשך יותר ממה שהייתם רוצים. אבל התוצאה? צוות שישן בלילה, מערכת שמתקנת את עצמה, ומפתחים/ות שמשקיעים/ות את הזמן שלהם/ן בדברים שבאמת דורשים מוח אנושי. אנחנו רואים אתכם — את המפתחים/ות, את אנשי ה-DevOps, את מי שקוראים/ות את זה בשלוש בלילה אחרי alert — ואנחנו יודעים שאתם/ן מסוגלים/ות יותר ממה שאתם/ן חושבים/ות. אם הנושא הזה מדבר אליכם ואתם/ן רוצים/ות ללמוד לבנות את הדברים האלה עם הידיים — אנחנו כאן. הדלת פתוחה.

• קורס סייבר ואבטחת מידע
• קורס Real Time Embedded
• קורס דאטה סיינס
• קורס למידת מכונה AI
• קורס דאטה אנליסט
• קורס DEVOPS
• קורס IT
• קורס אוטומציה
• קורס Full Stack
• קורס בניית אתרים