shai geva
112 posts
shai geva
@shai_ge
Writes code. Writes tests. Uses AI.
Katılım Ağustos 2014
273 Takip Edilen49 Takipçiler
זה מאוד מרשים וזה משהו שנראה יותר ויותר בעיניי: שכתובים של ספריות פופולריות בשפות low level memory safe.
שכתובים גם Zig וגם Rust (ובעיקר בRust) הולכים להחליף כל ספריה שכתובה בשפה אחרת.
Rach@rachpradhan
We replaced urllib3 inside boto3 with a Zig HTTP client. One import line. Same API. Upto 115x faster with TurboAPI. import faster_boto3 as boto3 Here's what happened..
עברית
@Bossondehigs @levelsio Mostly-monolithic codebases were always better for the vast majority of teams.
But AI makes this far clearer.
Personally, I believe AI will make the microservices architecture pretty much disappear.
English
@levelsio The interesting inversion: monolithic codebases actually win in the AI era. Less to coordinate, single deploy, agent sees everything in one context window. Microservices were designed for human teams — not for agents.
English
This is essentially my workflow of coding in production on the server with Claude Code
It's instant and extremely high velocity and I think that's where it's going
AI lets us dev extremely fast and the bottleneck now is slow deployments many of us (not me) still have I think
Sam Hogan 🇺🇸@samhogan
What if a codebase was actually stored in Postgres and agents directly modified files by reading/writing to the DB? Code velocity has increased 3-5x. This will undoubtedly continue. PR review has already become a bottleneck for high output teams. Codebase checked-out on filesystem seems like a terrible primitive when you have 10-100-1000 agents writing code. Code is now high velocity data and should be modeled at such. Bare minimum, we need write-level atomicity and better coordination across agents, better synchronization primitives for subscribing to codebase state changes and real-time time file-level code lint/fmt/review. The current ~20 year old paradigm of git checkout/branch/push/pr/review/rebase ended Jan 2026. We need an entirely new foundational system for writing code if we’re really going to keep pace with scale laws.
English
כן.
זו פעם ראשונה (אני מתכנת יותר מ-20 שנה) שהשינוי נראה ככה.
כל שאר השינויים היו די מינוריים - המהות נשארה דומה מאד, חלק מהפרטים הטכניים התיישנו (ברוב התחומים אפילו לא התיישנו מהר כ״כ. בפרונט היה מלא בלאגן, אבל שאר הדברים זזו יותר לאט) ונוצרו תחומי ידע חדשים (קלאוד, מערכות מבוזרות).
כרגע ברור שבטווח של שנים בודדות, המשרות שמבצעות את מה שהיום הוא עבודת תכנות יצטמקו משמעותית. אולי 70%, אולי 90%.
פשוט יהיה צריך פחות אנשים לבצע אותה עבודה.
ומנגד ייווצרו תחומי עשייה חדשים שצריכים הרבה יותר תוכנה מאי פעם בעבר.
השאלה היא אם תיווצר כמות גדולה של משרות מתגמלות חדשות שאותם אנשים יוכלו לעבור אליהן, או שלא.
והתשובה היא שאף אחד לא יודע.
אני מאמין לצערי שכן יהיו הרבה משרות, אבל רובן לא מאד מתגמלות.
עברית
בין אם אור צודק ובין אם לא הוא מייצג הלך מחשבה של הרבה מאוד אנשים בהיי-טק, אלה שרואים את הAI מקרוב. שנמצאים מספיק זמן בתעשייה כדי לחשוב שהפעם זה שונה. הם גם רואים סביבם לא מעט אנשים ש"יצאו מהמירוץ" אחרי שעשו אקזיט או סתם עבדו באנבידיה, ומבינים שהם לא שם.
זה מלחיץ, להיות בתעשייה שמשתנה כל כך מהר, להבין שאין לך מושג אמיתי מה יהיה עוד שנה או שנתיים. לדעת שאולי תצטרך להמציא את עצמך מחדש, שכל הניסיון והידע שצברת לאורך כל השנים לא עוזר לך כל כך בעולם החדש הזה.
לא פשוט (בלשון המעטה)
Or Azulay@orslimy
שני סוגים של אנשים בעולם כרגע. מי שהגיע לחופש כלכלי לפני AI ומי שעוד לא. הסוג השני, ואני ביניהם, צריכים לשקלל את צעדינו בהתאם. נכון שאף פעם לא היה טריוויאלי להגיע לחופש כלכלי פעם, אבל כן היה אפשר לחיות בנוחות ממשכורת של הייטק (ולהתלונן שחצי מזה הולך למדינה). עכשיו, עם קלוד, אני חושב שיווצר פער מעמדות מאוד רציני. מי שכבר צבר כמה נכסים ולא חייב לעבוד, ימשיך להשקיע ולייצר כסף מהכסף הקיים שלו. מי שעוד לא הגיע לנקודה הזו, יצטרך לקחת סיכונים הרבה יותר מבעבר (למשל - לפתוח חברת deep tech או לפרוש מהייטק ולהקים כפר גמילה מטכנולוגיה בקוסטה ריקה) או למצוא את עצמו מובטל. ולא, אני לא אוכל את הלוקש הזה שמי שיודע לעבוד עם AI ישגשג, זה רק אולי בשנתיים הקרובות, בינתיים אנחנו סתם בובות בשר שמלמדות את המודלים האלה כל מה שהם צריכים לדעת לפני שהם ידעו לזוז לבד בלעדינו. כבר היום הם מקבלים יותר ויותר אוטונומיה ומשרות מתות פה על ימין ועל שמאל בשקט. סליחה אם קמתי doomי הבוקר, אני עוד לפני הקפה, והילדים שלי, שאלוהים יודע מה הם יעשו בבגרותם, שיגעו לי את השכל הבוקר.
עברית
Types are a specific form of tests.
They reduce the entropy of the system just like any other tests.
They can have very good "economy" if done well.
Both because they "cover" most of the code base (as weak as that coverage is, it's still very useful) and because the tooling understands them.
You still need the UTs and the acceptance tests, of course.
My intuition is that AI coding will naturally drift towards "languages" that are similar to a light-weight statically typed functional language.
English
The argument can be made that statically type languages are better for AI agents than dynamically typed languages. The argument is that statically type languages are so overloaded that the AI agents can make better sense of them. By overloaded, I simply mean that you have to say everything more than once.
For example:
Dog dog = new Dog ();
I think this argument has some merit, however, developing a system using AI agents without a good solid suite of unit tests, and a good solid suite of acceptance scenarios is suicide. So I think there’s enough overloading to negate the minor benefit of a statically type language.
English
Depends on the actual constraints.
FIFO queue will give you at-least-once, but atba maximum window of t min iirc.
If that's fine for the use case, you can probably just go with that and just use enough message group ids, and you'll be fine.
If we're aiming for idempotency over longer time frames, sqs won't help either way.
You either need a faster data store to handle idempotency (e.g. redis) or change the message broker to something that gives you ghe guarantee (kafka?), though that will take a larger effort.
English
Your event-driven system processes 800K events/day through SQS.
Product wants exactly-once processing. Your current setup is at-least-once with deduplication in DynamoDB.
The DynamoDB dedup table costs $420/mo and adds 12ms per event.
Architect proposes switching to SQS FIFO queues for exactly-once delivery.
Your throughput needs: 2,200 messages/second at peak.
SQS FIFO limit: 300 messages/second per message group.
Now what?
English
@Amit_Mandelbaum השתמשת באותו מודל גם בתוך קרסר?
כלומר אני מנסה להבדיל בין המודל עצמו לאייג'נט שמפעיל אותו.
אני בקלוד קוד כבר די הרבה זמן ובדיוק חשבתי לדגום את קרסר לראות מה הסטטוס.
עברית
בגלל שנגמר לי הקרדיט ל cursor היום ״נאלצתי״ לעבור ל Claude Code (כן זה אני, לקוח פנאט של cursor כבר שנתיים+) ובחיי שאני מרגיש כזה דביל. אי אפשר להשוות בכלל כמה opus 4.5 של CC טוב יותר מזה של Cursor, שמיים וארץ.
עברית
This is theory and I haven't done it myself, but this probably depends on the use case.
I think the use case of "my real-time servers serving user requests are all served from my data center" is probably what you said.
But a use case like "I have a large bill for offline workloads. I have a setup where AWS can serve all my workloads, but I also have capacity in VPS and my own data center that pick up offline workloads if they can and thus greatly reduce cost" is something else.
It's not really related to this thread, but this is actually probably very relevant for smaller companies that are in the cost range where a few thousands of dollars a month matter to them.
A couple of beefy servers sitting in a back room can handle A LOT of background tasks if the use-case is appropriate.
English
we run 18 million EC2 instances per month. At our scale, we see very rare bugs very frequently.
Last week, we received *half* an HTTP request. Not a HTTP 206, literally half a request.
Content-Length was 2350 bytes. Body was actually 1200 bytes, and was truncated mid json doc.
English
@davidgu Very cool.
I think I would have tried a first step of provisioning enough VPSs to cover the base traffic and then use the more flexible AWS to handle anything over that.
But you guys have probably considered many variations like that and opted for single vendor simplicity.
English
@shai_ge with 6 months of our cloud spend, we could buy enough hardware to 2x overprovision for our peak load
but the sheer # of servers means supply chain and physical operations are a hard problem
we've decided to punt this for now, but eventually it's a good idea!
English
@dexhorthy Yes.
If the checks pass, mine literally just prints out this:
✅ All validations passed (lint, format, type check, tests)
English
@brankopetric00 I like to phrase it as
"It's not a scale issue, it's a skill issue".
But more seriously, the problem is the over-emphasis on big-company concerns on social etc..
The more "boring" things get lost on the noise, and many ppl (incl. smart ppl) just don't get exposed to them.
English
"Our database won't scale".
Database:
- 40GB total data
- 12 queries per second
- 0 indexes on query columns
- N+1 queries everywhere
- 200ms average query time
Solution:
- Shard across 12 databases
- Add read replicas
- Implement caching layer
- Switch to "web scale" NoSQL
Actual solution:
- Add 3 indexes
- Fix the N+1 queries
- 5ms query time
- $40/month Postgres
You don't have a scaling problem.
You have a competence problem.
English
Architects are safe, at least for a little while.
This is awful.
I was gonna go through and point out every mistake, but it’s easier to point out the alright things:
1) There are walls.
John Gregorchuk@JMGregorchuk
Architects are cooked. AI is coming for you. Prepare accordingly.
English
ראיתי כאלה וכאלה. זה קורה פחות בחודשים האחרונים לתחושתי (קלוד קוד).
אם יש הרבה טסטים ומריצים אותם הרבה פעמים, הוא גם נוטה פחות להסתבך כי ״יחידות העבודה״ קטנות יותר, אבל זה כנראה לא מעלים את הבעייה.
בכל מקרה, אני שם בהוראות ״אחרי איקס פעמים שלא הצלחת לתקן, תפסיק לנסות ותעצור״.
בד״כ הוא מקשיב.
עברית
@shai_ge @tsoofbaror הקטע שהוא לא היה עושה ריוורט לשינויים בלוגין.
הוא היה מנסה לכתוב מחדש ולתקן ואז דופק את זה יותר, מנסה לתקן שוב, דופק את זה שוב, וככה בלופ אינסופי עד שהקרדיטים שלך נגמרו.
עברית
מאחר מאד למסיבה:
התחלתי להכנס ולהבין איך לעשות Vibe Coding כמו שצריך. אני עדיין עושה את זה כמו מתכנת, ברמה של מגדיר רכיבי ארכיטקטורה ומכווין לקבצים ולמקומות ספציפיים. עכשיו נבחנת משימה גדולה של לבנות פיצ׳ר מקצה לקצה בקוד שיש בו הרבה דברים מאד לא סטנדרטיים.
הרבה מחשבות מעניינות
עברית
@shai_ge זהו, אני באמת חושב שיש דרך לכתוב קוד בצורה שהיא AI friendly, וזה משהו שגם AI עוד לא עושה כמו שצריך. משהו במבנה
עברית
@tsoofbaror כן, אכן רלוונטי בעיקר לפרויקטים חדשים.
אני כן מאמין שברגע שיהיו כלים וקונבנציות שעובדות על קוד גדול ומורכב - יהיו מלא פרויקטים שפשוט יעשו להם porting מטכנולוגיה שבה זה לא עובד לטכנולוגיה שבה זה כן עובד.
אבל נחיה ונראה.
עברית
מעולם לא כתבתי שורה בפלאטר, אז אין לי משהו חכם להגיד על זה.
מה שכן, דעתי היא שלפרוייקטים חדשים - עדיף לבחור טכנולוגיה שבה אנחנו יודעים לתת לאייג׳נט דרך לעשות פידבק לופ אפקטיבי עם טסטים טובים.
הכלים ישתנו הרבה בשנים הקרובות, המודלים יישתפרו, הקונבנציות של איך כותבים הגדרות מוצר ישתנו וכו׳ - אבל היכולת לייצר פידבק לופ טוב תישאר קריטית בכל מקרה.
עברית
טסטים.
אם היו לו טסטים שהיו מכסים את הלוגין הוא היה רואה שהוא דפק אותו והיה מתקן.
אין מה לעשות.
טסטים חייבים לכסות כמעט הכל, והם צריכים להיות טסטים טובים (מהסוג שלא נשבר על שינויי מימוש וכו׳ וכו׳).
אחד הסקילים הכי חשובים בעולם החדש זה להבין איך לעשות טסטים טובים למקרה הספציפי שאתה בונה ולהכריח את האייג׳נט לעשות את זה.
זה בעצם דומה מאד למה שתמיד היה עם מתכנתים, רק פי 100 יותר מהר ולכן מרגישים את זה הרבה יותר.
עברית
Actually, almost all coding agents have exactly this issue to some extent.
You know we all tell our coding agent "if you write code here, you need to run the linter and these tests before you can move on to the next sub-task, if they fail fix them, otherwise mark the current task as done and continue to the next task item..."
That's literally a state machine with strict rules and an LLM is making the decisions (and is often wrong!).
Of course, it makes sense for the AI agent to decide "does the code look good and fulfill the requirement", but the task workflow etc. - that's a state machine.
You can do some of it with hooks etc., but it's not a full solution.
I won't be surprised at all if pretty soon we'll be able to have the ability to define these strict workflows as a standard part of coding agents.
English
A few weeks ago, I spoke to a team that used an LLM to implement a state machine.
They were very proud of their "agentic" workflow.
It took us a few hours to delete it all and reimplement everything without using LLMs. It took fewer than 100 lines of code.
We went from "works most of the time" to "works 100% of the time."
We went from "it's not that expensive to run" to "it runs for free".
Stop using LLM for problems that don't need them.
English
האם TOON זה באמת כלי רלוונטי?
יש עליו מלאאאא פוסטים בשבועיים האחרונים שמראים כמה הוא מגניב, אבל ברגע שהסתכלתי עליו וניסיתי להבין מתי כדאי להשתמש בו, מצאתי שהתשובה היא שכמעט אף פעם.
מי שלא יצא לו להיתקל - TOON זה פורמט חדש שאפשר להשתמש בו במקום JSON כדי לשלוח מידע למודלי שפה.
הוא יותר יעיל בשימוש בטוקנים לעומת JSON, ונראה שיש לו דיוק דומה או יותר טוב.
עד פה מגניב, ויש הרבה דוגמאות שמראות איך לוקחים מידע וממירים מ-JSON ל-TOON ויוצא קטן יותר.
זה אחלה, אבל כשאנחנו מחליטים איך לשלוח מידע למודל השאלה היא לא ״האם זה יותר טוב מ-JSON״, אלא ״האם זו האופציה הכי טובה שלי״, כי הרי JSON זה לא הפורמט הנפוץ היחיד.
ומסתבר שברוב המקרים יש פורמט שהוא עדיף מ-TOON.
למשל, הרבה מהדוגמאות מראות דאטא שהוא טבלאי במהותו - ובמקרה הזה CSV עדיף במרווח קטן (למעשה, TOON על דאטא טבלאי ממש ממש דומה ל-CSV).
דאטא עם הרבה nesting - עדיף compact JSON בגדול.
נראה שיש מקרים שבהם TOON הוא לפעמים האופציה הטובה ביותר - דאטא שהוא בערך טבלאי, אבל אלה אוביקטים שהם לא שטוחים לגמרי אבל גם לא עמוקים מדי.
זה מקרה אמיתי ובעל ערך, אבל לא הייתי אומר שזה משהו מרכזי לשימוש במודלים.
הריפו של TOON, אגב, לא מייצר מצג שווא בקשר לכל זה - יש אמירות ברורות לגבי איפה הוא חזק ואיפה לא להשתמש, גם בתיאור של הכלי וגם בבנצ׳מרקים (כל המידע שאני חולק פה זה ישירות מהבנצ׳מרקים שלהם).
בלי ספק אחד המקרים היותר קיצוניים בין כמה הייפ יש על כלי לעומת כמה הוא באמת רלוונטי.
כתבתי קצת יותר פרטים בבלוג, למי שמתעניין:
shaigeva.com/posts/2025/sho…
עברית