monday.com AI engineering

AI agents don’t click like humans. They call APIs. A lot. At monday.com, API traffic grew to 2.5 billion requests a week. So we rebuilt the API edge. The result? 🚀 2.5× the traffic 📉 92% less CPU ⚡ 11× lower p99 edge latency Michał Budziak shares the engineering behind the numbers and what it takes to build for agents at scale. Link in comments 👇

Yesterday, I had the pleasure of speaking at LangChain Interrupt ’26 London about how we at monday.com AI engineering are using evals to make our AI agents smarter. I've shared the monday.com vision shift to Doing the Work for our customers and how the real difference for them is not another AI feature. it's Reliability, Trust and Confidence in AI results. That's why we built a hybrid evaluation architecture connecting what happens before release with what we learn from real production usage. Two pipelines. Two questions. Offline EVALS runs pre-production against datasets with expected outcomes and is the gate for release, answering the question: Can we ship? Online evals analyze real production traces and uncover failures we couldn't anticipate. Real users bring new scenarios, unexpected behaviors, and data we've never tested. It answers the question: Is it working for real users? Focusing on three key signals: • Task Completion - Did the agent achieve the user's goal? • Trajectory Health - Did it use the right tools and execute efficiently? • User Frustration - Did the user struggle, repeat requests, or correct the agent? A high completion rate can hide slow responses or wrong tool selection. A healthy trajectory can still miss the goal. The lesson: don't rely on a single metric, but don't measure everything either. Focus on what is significant for you! We also break down the conversations by domain, family and use case. It helps us to understand our strengths and opportunities and helps us prioritize our work. Online & Offline evals must come together. Measuring quality, Latency and Cost. One cannot replace the other. When online evals uncover recurring failures, we can turn them into offline regression tests, verify fixes before release, and measure whether production actually improves. Closing the Loop: Production → Detect failures → Offline tests → Fix → Verify in production. I've also shared how we as builders are getting trust in the metrics and scores. LLM judges aren't the ground truth. We build confidence through human reviews, comparisons between different judges, repeated scoring for consistency, and real user feedback. The real value of evals isn't knowing your agent's score. It's knowing what to improve next, why it matters, and whether your changes actually made an impact. Thanks to Harrison Chase and the entire LangChain team for having me at Interrupt London and to everyone who joined the session!

Last week at The AI Conference, I shared how monday.com went from AI-assisted to AI-native in 12 months, and what that change looks like in our engineering teams. The talk focused on how we’re bringing AI agents into everyday engineering work, from picking up tickets to writing and testing code. I shared what we’ve learned along the way and what it takes for people and agents to work together as a team. It was great to hear how other companies are using AI and talk openly about what’s working, what’s still hard, and how teams are adapting. I also got to spend time with our sales and marketing colleagues from San Francisco and New York. It always amazes me how warm, smart, and fun monday.com people are, all around the world! So happy we got to meet, learn from each other, and have a good time together. Thank you for making me feel so welcome! monday.com AI engineering Megan Pierce Debra Gostrer Justin Burkett Dean Raab Kasey Daniels Chris Oberheide

אחת התקלות הכי מסוכנות באייג׳נטים היא לא כשהם נכשלים, אלא כשהם נכשלים ונראים כאילו הצליחו. באחד ה-evals שלנו ביקשנו מאייג׳נט לדווח על סטטוס הפרויקטים. הוא השתמש בכלים הנכונים, החזיר תשובה מסודרת ומשכנעת, ולא הייתה שום שגיאה בדרך. רק שבפועל הוא עבר רק על חלק מהפרויקטים. אם היינו מסתכלים רק על התשובה הסופית, כנראה שהיינו מסמנים הצלחה. וזו אחת התובנות המרכזיות שלמדנו כשבנינו את תשתית ה-Evals שלנו ב monday.com AI engineering: לא מספיק לבדוק את התשובה. צריך לבדוק אם האייג׳נט באמת השלים את המשימה. 1. צריך לבדוק את כל ה-trajectory לא רק מה האייג׳נט כתב בסוף, אלא באילו טולים הוא השתמש, איזה מידע הוא אסף, והאם הוא אסף את כל המידע שהיה צריך. לפעמים תשובה טובה מסתירה execution לא טוב. 2. הסביבה היא חלק מהבדיקות אפשר לבנות judges מצוינים ודאטהסט מעולה, אבל אם האייג׳נט רץ מול מוקים שלא באמת מייצגים אינטגרציות, דאטהבייסים, פיצ'ר פלאג, הרשאות ושירותים אמיתיים - אנחנו בודקים גרסה מאוד נקייה של העולם. זו הסיבה שבחרנו להריץ את ה-Offline Evals מול סביבת הסטייג'ינג והשירותים האמיתיים שלנו, בלי דיפלוי נפרד לכל הרצה או סביבה ייעודית. המטרה היא לבדוק את ההתנהגות של האייג׳נט בסביבה שקרובה ככל האפשר לזו שבה הוא באמת יצטרך לעבוד בה. 3. הבדיקות הכי טובות מתחילות בפרודקשן Offline Evals נותנים לנו ביטחון לפני ריליס או כשאנחנו בוחנים מודל חדש. Online Evals מגלים את המקרים שלא חשבנו עליהם בפרודקשן. וכשמוצאים כישלון מעניין בפרודקשן, הוא יכול להפוך לקייס חדש בדאטהסט של האופליין. מבחינתי אחד המדדים הכי מעניינים למערכת Evals הוא לא רק כמה בדיקות יש בה או מה הציון. אלא כמה מהר אפשר להפוך חוויית משתמש גרועה בפרודקשן לבדיקה קבועה שלא תאפשר לאותה בעיה לחזור. שינוי בפרומפט, במודל או בטול יכול לשנות התנהגות בדיוק כמו שינוי בקוד. ולכן גם תהליך הריליס צריך לתת לנו רמת ביטחון דומה. דיברתי על כל זה לאחרונה בוובינר עם Eyal Bukchin מMetalBear, כולל דמו של איך אנחנו מריצים evals מקומית, דרך אייג׳נט וב-CI, ואיך mirrord מאפשר לנו לחבר את הריצה לשירותים האמיתיים בסטייג'ינג. Arsh Sharma גם הפך את זה לבלוג פוסט ממש מעניין. אשים בתגובות את הלינק לוובינר המלא ולפוסט אשמח לשמוע פידבק, רעיונות או שאלות

Designers opening PRs directly into the product. Our Design Foundation team created a workflow that lets designers start from the live monday.com product, move into a local environment, work with Claude or Cursor, iterate directly on the experience, and eventually open a PR. The interesting part is not that this makes designers faster. It changes the workflow itself. Less handoff between design and engineering. Less time rebuilding context. More ownership from idea to implementation. This is what AI-native product development starts to look like. Great work by the team 👏

I thought AI model updates would have diminishing returns. I was wrong. Before we release a new model, we run an extensive set of evals and tests to ensure everything works as expected and that the user experience improves. To be honest, the last couple of model updates from Anthropic were disappointing. The models were slower, cost more to run, and had marginal improvements. But I have to say that, in my professional opinion, Opus 5.5 is freaking awesome! It made our product faster, any app created with it looks 10x better, and we can offer it to customers at a lower price 🤯 Just to make sure, we released it in an AB test, and our CSAT immediately jumped by 10% In the video, one of my tests showcases how good Opus 5.5 is with motion animations Keep it up, Anthropic!

2,000+ agents in production is only part of the story. The real challenge is building an engineering organization that can actually trust them. Over the past year at monday.com, we’ve been moving from AI as a tool that helps engineers — to agents that operate as real teammates, take ownership, and execute meaningful work. Doing that inside a 10+ year-old system, with hundreds of microservices and hundreds of builders, brings a whole new set of engineering challenges around quality, control, observability, and trust. Tomer Brook shared some of what we’ve learned along the way with Geektime גיקטיים. 🇮🇱 The article is in Hebrew — highly recommended for our Hebrew-speaking community. A great look into how agentic engineering is becoming real production infrastructure, not just a demo. Great work, Tomer Brook and the team 🚀

אם AI עושה היום את העבודה של הג׳וניורים — מאיפה יגיעו הסניורים של 2030? ככל ש־AI ו־Agents לוקחים על עצמם יותר מהעבודה שפעם הייתה נקודת הכניסה של מפתחים צעירים, עולה שאלה הרבה יותר גדולה מ־productivity: איך מפתחים את דור המפתחים הבא? בפרק החדש של AI אנג׳נירינג,Maya Asher ו־Dor Yehuda מצטרפים ל־Netanel Abergel ו־Ido Karlan לשיחה על איך תפקיד המפתח משתנה בעולם שבו כתיבת קוד כבר לא נמצאת רק אצל המפתח. הם מדברים על מה צריך לחפש היום בג׳וניורים, אילו יכולות הופכות לקריטיות, ואיך נראה מסלול ההתפתחות ממפתח מתחיל לסניור בעידן ה־Agents. אם אתם מגייסים מפתחים, מנהלים צוותי הנדסה או פשוט מנסים להבין לאן המקצוע הזה הולך — זה פרק שכדאי לשמוע. 🎧 הפרק המלא — לינק בתגובה הראשונה 👇

כמה מהתפקיד של מפתח נשאר באמת אותו דבר בעידן שבו AI כבר יודע לכתוב חלק גדול מהקוד? בפרק החדש של AI אנג׳נירינג Maya Asher ו-Dor Yehuda מדברים על אחת השאלות שהכי מעסיקות ארגוני R&D היום: איך נראה מפתח מצוין ב-2026 — ואיך בכלל מגייסים אותו? כי כשה-AI הופך לחלק מהיום־יום, הערך עובר מיכולת לכתוב עוד קוד ליכולת להבין מערכת, לקבל החלטות טובות, להפעיל judgment, לעבוד נכון עם AI ולהוביל בעיות מקצה לקצה. דיברנו על השינוי שאנחנו כבר רואים: איך נראה תהליך גיוס בעידן ה-AI, מהי AI Fluency, למה ניסיון בשפה או framework מסוים הופך לפחות משמעותי — ואילו יכולות דווקא הופכות לחשובות הרבה יותר. 🎧 פרק שמעניין לא רק מפתחים, אלא גם Engineering Leaders וכל מי שחושב על איך ייראו צוותי הפיתוח של השנים הקרובות. לינק לפרק בתגובה הראשונה 👇