Bassem Dghaidi: “Simple is complicated enough” — system design without overengineering theater (Rubric #Architecture)
Almost every conversation about software development now drifts fairly quickly toward models, agents, and percentages of generated code. That is what makes this 46-minute Beyond Coding conversation so refreshing: AI appears only in the final quarter. Before that, it is a calm engineering discussion about system design, vertical scaling, the cost of abstractions, and responsibility to the business—a useful counterpoint to the broader AI hype.
Patrick Akil’s guest is Bassem Dghaidi, a senior software engineer at GitHub working on GitHub Actions. He has more than 15 years of experience across domains ranging from banking and container terminals to internet-scale services. He grounds the conversation in concrete work—redesigning parts of GitHub Actions, building terminal infrastructure, and delivering systems for banks—so “scale” is not merely a whiteboard exercise here.
Dghaidi’s central thesis is that system design is not a competition to draw the largest number of fashionable boxes. A system should be designed for the next order of magnitude, not an imagined 100x future, and only after data shows the limits of the current solution. Software evolves; it is not built once. Architecture requires recurring investment rather than a single attempt to predict a system’s shape ten years ahead.
I would take four ideas from the conversation.
1️⃣ Scaling starts with measurements According to Dghaidi, some GitHub services handle millions of requests per second on only five or six containers. This is the speaker’s internal example, not an independently verified benchmark. GitHub later documented the broader rearchitecture: the old Actions core handled 23 million jobs per day, the new design targeted 10x scale, and by December 2025 it was handling 71 million jobs per day. The principle is the same: observe the real demand curve before adding distributed complexity.
2️⃣ A specific solution is more useful than a generic framework A cache, NoSQL database, or new abstraction should appear when there is a concrete bottleneck. Otherwise there is no meaningful way to choose trade-offs: a universal construction is optimized for every hypothetical problem and for no real one.
3️⃣ Architecture must be explained in units the business understands At the container terminal Dghaidi recalls, delay meant money and sometimes risk to human safety, not merely a red latency chart. His advice to engineers is to translate “the database is overloaded” into downtime cost, an unloading window, feature delivery speed, and customer risk. The most elegant Kubernetes cluster proves nothing until its measurable business effect is visible.
4️⃣ AI changes the lever, not the engineer’s job Dghaidi says agents write roughly 90% of his code. In one case, an agent created and ran three benchmarks for alternative Redis key designs in 20 minutes—work that he estimates would have taken two or three days by hand. He spends the freed attention on data-access patterns, reliability, operations, and the consequences of failure. His automatic-clutch motorcycle analogy is apt: changing gears is easier, but a person still chooses the road, speed, and acceptable risk.
There is room for disagreement as well. Dghaidi explicitly calls layoffs a dehumanizing but effective way to reallocate engineering resources. To me, that sounds too much like accounting. That makes the recording more candid, however: the participants are discussing real trade-offs rather than selling another silver bullet.
In an era when headlines compete over which model wrote more code, this conversation asks less spectacular questions: what limit have we measured, which risk are we reducing, who will operate the result, and what will change for the business? AI does not disappear from the discussion; it simply returns to its proper place—a powerful tool inside an engineering system, not a replacement for system design.
#Architecture #SystemDesign #Engineering #Software #AI #AI4SDLC