The response was amazing, but reading the post could make it sound like maybe the answer is just to get rid of AI entirely, at least for juniors and folks early in their career.

I don’t believe that that is the case, so this post will serve as a counterbalance to the last piece. I don’t think AI is all bad, and refusing the gift of modern tooling isn’t the answer.

There is absolutely a way to embrace these tools and still learn on top of them. But, and this is a massive ‘but’, doing so requires intentional human support, active pair programming, and rigorous mentorship. You cannot just hand a junior developer an AI license, leave them in a silo, and expect them to magically develop engineering intuition.

Juniors are currently stuck in a Catch-22.

On the one hand, we all know that real engineering skill comes from friction. You build cognitive neural pathways by banging your head against a NullPointerError at 2 AM, hunting down a typo on line 22, and wrestling with syntax until it finally clicks.

When you outsource all of that productive struggle to an LLM, your debugging skills, much like your leg muscles if you drive down the block instead of walking, quietly atrophy (easy come, easy go).

On the other hand, if you stubbornly refuse to use AI, you aren’t training in the actual workflows you will undoubtedly use in your day-to-day job. It borders on professional malpractice to ignore a tool that can boost your productivity and velocity so much.

So how do we reconcile the two? How do we embrace the boost that modern AI tools give us without losing the friction required to actually grow as developers?

The Rebbe’s Gift

While thinking about this the other day, I was reminded of a 200-year-old story involving Rabbi Shneur Zalman of Liadi (the founder of the Chabad Chassidic movement, affectionately known as the Alter Rebbe. You may remember him from this post) and his young grandson, Rabbi Menachem Mendel (who would later become a revered scholar and the third Rebbe of Chabad, known for his series of books, the “Tzemach Tzedek”).

The Alter Rebbe raised his grandson, who was orphaned at the age of three, and personally oversaw his education. One day, the Alter Rebbe made his grandson an incredible offer: “I want to give you all the Torah knowledge I possess as a present.”

To his grandfather’s surprise, the young boy politely declined.

He explained that he preferred to acquire his knowledge through his own Yegiah (a Hebrew term that translates to intense intellectual toil, effort, and sweat). He knew that knowledge handed over on a silver platter would never truly belong to him the way knowledge earned through rigorous struggle would.

Usually, inspirational stories end right there with an obvious, tidy moral: “And the boy refused the easy way out because hard work is magical!”

But the story doesn’t end there.

Years later, when the grandson had grown into a brilliant leader in his own right, he looked back on that childhood moment with deep regret.

“I should have accepted the gift from my holy grandfather.” he remarked, “As far as my concern about Yegiah — Torah is infinite, so as much Torah knowledge as he would have given me, there would always be room to toil on top of that!”

Moving the Friction Up the Stack

Nice story, but what does an exchange from two centuries ago have to do with AI?

That hindsight realization the Tzemach Tzedek had, that’s the exact blueprint we need for navigating software development in 2026.

AI coding assistants are an amazing gift. By automating a lot of the boilerplate, they offer us a massive boost in productivity. They can generate database migrations and write standard CRUD endpoints in seconds.

We shouldn’t gatekeep the industry or force ourselves (and the juniors coming up behind us) to reject this gift out of some misplaced sense of purity (just like we don’t write Assembly on punchcards anymore and we don’t force juniors to use vim). Take the present! Let the AI write the boilerplate so you can move faster.

However: we still need the Yegiah.

The mistake isn’t using AI to write code; the mistake is letting AI eliminate our intellectual toil entirely. Instead of refusing the gift, we simply need to move our Yegiah up a level.

When you let an LLM generate a complex module, you aren’t spending your cognitive friction remembering standard syntax or matching closing brackets. Your Yegiah is now free to shift to higher-order engineering:

• Architectural Skepticism: Why did Claude structure the data this way? Does this pattern actually scale under load, or is it just the most statistically common answer on GitHub? (Spoiler: it’s usually the latter.)
• Security & Edge Cases: Where are the subtle race conditions? What happens when this endpoint gets hit with malformed data by a bored script kiddie (who is probably using AI as well)?
• Domain Mastery: Can I clearly explain every single line of this generated code to a junior developer without looking at the screen?

By accepting the baseline gift of AI, we free ourselves from spending our intellectual energy reinventing the wheel. But if we want to become true masters of our craft, we have to take that extra bandwidth and reinvest it in the deep, rigorous Yegiah of solving harder, more human problems.

So remember, take the gift, but don’t forget to sweat as well.

Before I got into tech I was a teacher, and still consider myself a teacher at heart. Being a teacher and mentor was never separate in my eyes from being a good programmer and engineer; on the contrary, teaching was a tool that helped me become better at my craft at every stage of the journey.

But in the last few years, and accelerating in the last few months, the landscape for teaching and learning has been changing at a scary pace. The advent of LLMs and “AI” coding assistants has drastically shifted how we acquire engineering skills in ways that we are definitely not prepared for.

All of that has prompted many thoughts and conversations, and I hope to distill some of them in this blog post.

In true Talmudic fashion, this post doesn’t contain too many answers and will hopefully leave you with more questions than you started with. But asking the questions is how we start these conversations, and these conversations need to be happening if we are to do right by the coming generation of programmers and engineers.

Don’t Spoon-Feed Me

As a student, whether in Yeshiva when I used to spend hours each day poring over dense Talmudic legal debates and esoteric Chassidic philosophy or later while learning Rails and React at the Flatiron bootcamp, I quickly realized an uncomfortable truth about skill acquisition.

My best, most profound learning never happened when a lesson went smoothly; it happened when I was painfully stuck, banging my head against a cryptic error message or wrestling with a concept that just wouldn’t click (usually at 2 AM, fueled by cold coffee and sheer stubbornness).

When you strip away that struggle, you get rid of the growth. And when you get rid of the growth, the learning just doesn’t happen.

Even if you memorize just enough to pass the test, “easy come easy go.” Without that cognitive friction, the knowledge evaporates the moment you close your editor.

The best teachers and mentors I ever had understood this intuitively. When I was staring at a broken script knowing there was probably a stupidly easy fix, they didn’t just swoop in and drop the solution onto my screen (much to the vocal frustration of my sleep-deprived brain).

Instead, they wielded tools like the Socratic method. They would point to a specific line of code and start asking gentle, probing questions to expose my flawed assumptions.

They actively leaned into the friction to create just enough cognitive space for me to connect the dots on my own.

They understood a fundamental rule of our teaching craft: that good mentorship is not about getting to the code. The goal wasn’t just to get the tests turning green today; it was to build the mental resilience required to debug the next inevitable failure tomorrow.

And it was these skills that I took with. me when it was my turn to become the teacher, whether it was teaching second graders at the Jewish Online School, as a TA at Flatiron, or when mentoring new teammates joining my team.

The Yes-Man in Your IDE

Fast forward to today, and our industry has largely outsourced that initial layer of mentorship to LLMs and coding assistants. And here is the uncomfortable truth: AI makes a terrible Socratic tutor.

If you’ve spent any serious time pairing (or even just chatting) with modern LLMs, you know they are pathological yes-men. Tell an AI you want to architect a distributed microservice mesh for a todo-list app with twelve active users, and it won’t push back. It will chime in with “That is a brilliant insight!” and instantly spit out 400 lines of boilerplate.

AI defaults to blind trust. It rarely challenges a mistaken assumption, and when you ask it why a stack trace is blowing up, it immediately serves up a copypastable fix instead of helping you understand the underlying bug.

By acting like an algorithmic vending machine (error_in => fix_out), AI systematically removes all the cognitive friction from the development process.

In our rush for 10x velocity, we forgot a foundational rule of skill acquisition: friction is a feature, not a bug. That was a load-bearing friction we removed!

This isn’t just philosophical speculation; there’s hard data to back it up. A recent study by Anthropic (or dive into the raw paper here if you love parsing methodology) took 52 software engineers learning an unfamiliar programming library and split them into two groups: one with AI coding assistants, and one coding by hand.

The overall results were as damning as they were not surprising. The engineers who delegated their coding to AI suffered a 17% drop in conceptual mastery and debugging skills (the equivalent of two full letter grades!) often without completing their tasks meaningfully faster than the manual control group.

Why? Because when you offload the cognitive friction of getting painfully stuck, your brain never builds the deep neural pathways required to evaluate whether the generated code is actually any good.

Now, to be fair, there was some nuance in the data: a handful of the AI-assisted engineers actually outperformed the manual control group. But who were they? They were the developers who refused to trust the AI blindly. They treated the LLM like a study partner, asking probing follow-up questions and manually injecting their own friction back into the process.

For everyone else, the automated yes-man just quietly destroyed their understanding.

The Learner’s Dilemma: Manually Injecting Friction

This dynamic leaves junior developers in a massive bind.

Friends and mentees who are earlier in their career have complained that they feel stuck in a frustrating Catch-22:

On one hand, they have to pragmatically accept the reality that AI isn’t going anywhere. If an LLM can generate working boilerplate from a single prompt, you can’t just stubborn your way out of using it. Ignoring AI entirely feels irresponsible, considering that you will be using these tools heavily in your day-to-day workflows.

But on the other hand, if you rely on that autocomplete blindly, you get trapped in what’s known as “superficial learning.” You get a quick answer that allows you to pass a test suite or get a PR approved without truly understanding the mechanics under the hood. You miss out on the “deep learning” where the actual, career-sustaining growth happens.

In my experience, that superficiality is a direct pipeline to developer anxiety and impostor syndrome. True professional confidence doesn’t come from hitting Tab to accept a prompt; it comes from code ownership and intense intellectual toil and sweat.

To survive this, diligent learners are now being forced to manually inject friction back into their workflows just to keep their brains from turning off.

Junior developers I’ve spoken to have resorted to explicitly prompting their IDE with guardrail instructions like: “I want to learn how to code it myself, rather than copying and pasting, so enable that however you can.”

They take notes by hand (yes, actual paper and pen!) and set physical timers just to recreate the safeguards of active listening that a tool designed for instant gratification systematically tries to bypass.

Why We Need the Messy Web of Context

This need for self-imposed struggle makes total sense when you look at Emily Bender and Alex Hanna’s book, The AI Con, which highlights why friction in information access is actually a feature, not a bug.

Think about what happens when you manually hunt down an obscure bug using a search engine.

You read messy documentation, scan through twelve-comment GitHub issue threads (usually ending with a maintainer closing it as “not a bug” in 2014), weigh the credibility of conflicting answers on Stack Overflow, and stumble across related gotchas along the way.

That messy web of meta-information is where real engineering context is built.

An AI chatbot flattens all of that rich, frustrating struggle into a single, authoritative-sounding (and occasionally “hallucinated”) summary. It gives you the answer to your immediate problem while robbing your brain of the surrounding ecosystem knowledge required to solve the next one.

The Chavrusa Model: Pair Programming && The Adversarial Rubber Duck

This brings me to an ancient pedagogical model that survives to this day in Yeshivas (Talmudic academies) around the world, and one that software engineering desperately needs right about now.

In a traditional Yeshiva, you rarely see people sitting in silent isolation reading a book or passively listening to a lecture. Instead, the room is loud, energetic, and filled with people arguing fiercely in pairs.

This study partner system is known as a Chavrusa (from the Aramaic word for “friend” or “companion”).

When you learn with a Chavrusa, your partner isn’t there to read the text to you, nor do they nod along and sycophantically affirm how brilliant your theories are. A real Chavrusa regularly challenges your logic, pokes holes in your arguments, pushees back against shaky assumptions, and generally refuses to let you get away with intellectual laziness.

You don’t master the Talmud by reading cliff notes or listening to a brilliant lecture (though there’s some of that as well); you master it through Yegiah (a Hebrew term that translates to intense intellectual toil and sweat).

If you think about it (and as I mentioned in my 2021 RailsConf talk), pair programming is just the tech industry’s recreation of the Chavrusa.

And here is the most important part of that system: it’s not only the junior member of the pair who’s learning in a true Chavrusa.

It doesn’t matter if you are pairing with a 10-year staff engineer or a junior developer who just finished a bootcamp; the learning is always a two-way street!

When your partner acts as an adversarial rubber duck (one that actually talks back!), they force you to slow down, articulate your hidden assumptions, and defend your code logic from start to finish. Both of you gain from that friction, and both of you walk away with a significantly better mental model than you started with.

Rabbi Ḥama, son of Rabbi Ḥanina, said: What is the meaning of that which is written: “Iron sharpens iron, so a man sharpens the countenance of his friend” (Proverbs 27:17)? This verse comes to tell you that just as with iron blades, one sharpens the other when they are rubbed against each other, so too, when Torah scholars study together, they sharpen one another.

-Ta’anit 7a

In our rush for 10x velocity, we tried to replace human pair programming with AI copilots. But in doing so, we forgot a critical dependency: we exchanged the adversarial Chavrusa and Yegiah for a sycophantic robo-duck.

Empathetic Balancing Act

A common response I hear from the tech crowd is: “Well, let’s just fix this with better system prompts! Let’s build guardrails that instruct the AI to act like a Socratic tutor instead of just giving away the answer!”

There are plenty of tools attempting this right now, but I am deeply skeptical that technical guardrails can solve a fundamentally human problem.

First of all, relying on a prompt to withhold answers requires elite learner discipline. Some students can stick to it, but that level of willpower is rare, especially when your cognitive battery is hitting empty.

When a junior developer is staring at a cryptic NullPointerException at 2 AM and their brain is fried, a prompt asking them to “reflect on the lifecycle of the object” is getting bypassed immediately. If all it takes is typing /solution or opening a new browser tab to get the dopamine hit of copypastable code, not too many people I know will power through.

More importantly, LLMs are fundamentally architected to please. Even if you prompt-engineer them to be tough Socratic tutors, their core tuning means that the moment a user expresses genuine frustration, the AI folds like a cheap lawn chair and hands over the syntax anyway.

Why? Because an LLM lacks the quality most important in an educator: empathy.

Mentorship is a human pedagogical balancing act. A great mentor understands the fine line between productive struggle and demoralizing suffering. A good educator can read the room. They notice the heavy sighs, the mounting panic, and the sheer exhaustion.

Sure, as a student I learned best when I was given the tools to figure things out on my own. But sometimes I maxed out my energy on the stupid error message, and all of the leading questions my tutors were asking me felt like they were just causing me to circle and circle around the one insight that would make it all work, an insight my brain just couldn’t reach.

That is the point a good teacher knows to step back, smile, say “Hey, JavaScript is just weird sometimes,” and hand the exact line of code I needed to get unstuck so I could finally go get some sleep.

An algorithm cannot read a learner’s emotional state. It cannot dynamically toggle between a challenging sparring partner and a supportive safety net. Code can never replicate that relationship.

The Unsolved Catch-22

So where does this leave us? If I’m being entirely honest, I have way more questions than answers right now (not exactly what you want to hear from a tech blog, I know!).

We are sitting on a massive, industry-wide Catch-22:

On one hand, it would be borderline professional malpractice to forbid junior developers from using AI. It is the modern IDE (which, back when I was learning to code, gatekeepers argued juniors shouldn’t use either—I disagreed then and I disagree now). If juniors will be expected to use these tools on the job, it hardly makes sense not to train them to use them effectively.

On the other hand, the engineers getting that massive 10x velocity boost without introducing architecture-destroying bugs are the seniors who spent years writing code without it.

We know when an LLM is spinning its wheels on a false premise because we have a built-in BS-meter, hard-earned through years of manual debugging.

How does someone without that pre-AI experience build that intuition today? They won’t get it from a sycophantic yes-man chat-bot assistant. And manually inventing your own cognitive friction requires a level of self-discipline that is hard to maintain on a tight deadline.

Maybe the future of onboarding relies on doubling down on human pair programming—having juniors shadow seniors for months on end to soak up that pre-AI intuition by proxy. After all, pair programming has always been one of the best onboarding methods, even before Claude. But not every company is Pivotal, and not all companies are interested in the investment that full-time pairing requires in an industry often obsessed with shipping yesterday.

What I do know is that we cannot afford to ignore the problem or assume that better LLM models will magically fix our talent pipeline.

If we just hand junior developers an oracle and fail to preserve the empathetic, rigorous struggle of the Chavrusa, we are going to wake up in a few years to a terrifying system error: an industry with a massive, AI-generated codebase to maintain, and not enough senior engineers left who know how to maintain it.

What are you and your teams doing to keep productive friction alive? I’d love to hear your thoughts.

Back when I started learning programming, I wanted a place to share my learnings, and that’s how “Rabbi on Rails” was born.

At the time, Medium was a perfectly reasonable place to host my blog. It looked clean, handled formatting well enough, and had a built-in network effect (some of my blog posts got tens of thousands of views and I still don’t know why). But over the last few years, we’ve all watched the slow, painful “enshittification” of third-party publishing platforms. Paywalls went up and algorithms got aggressive. Still, I stayed. Change is hard, and as long as Medium technically worked, migrating remained a background task to be tackled “some day.”

Then the final straw landed in my inbox: Medium was making changes to their DNS, and as part of those changes, I was going to lose my custom domain unless I upgraded to a paid plan.

Another ongoing pain point was that my writing had become fractured. At some point, I started posting my “Torah && Tech” articles (along with other posts of Jewish/religious interest) on my Rabbi on Rails Medium blog, while my more technical posts went to my DEV.to profile. There was some overlap (a few articles were cross-posted) but there were no clear rules on what went where, and worse, I didn’t truly own any of it.

So recently, I decided it was finally time to take back ownership of my content, my platform, and my domain.

Here is the story of how I migrated both of my blogs into a single self-hosted, static Jekyll site, and the technical headaches I encountered along the way.

Choices, Choices…

So I knew I wanted to migrate off of Medium, but where should I migrate to?

Of course, I could take the easy path and pick a new platform like Hashnode or Ghost, but that would run the risk of finding myself back in the same place in a year or two when they inevitably change their terms and I have to migrate again.

Clearly, it was time to finally self-host.

The timing was right as well. A few years ago, going the self-hosting route would have required a significant time investment—from researching frameworks to spending hours on “just one little tweak” that would send me down a CSS rabbit hole. But these days, with the ubiquity of LLMs, I figured the process of creating a blog (very much a solved problem) should be trivial to accelerate.

Sure enough, my guess paid off. Within half an hour, I had all the information I needed to choose. My blog would be hosted on GitHub Pages using Jekyll as the framework and Minimal Mistakes for the theme.

Why Jekyll?

When choosing a platform, I had a few criteria.

First and foremost, I wanted control over the platform and the content for the reasons I already mentioned. But within the world of self-hosting, there are a million ways to go, so I had to narrow things down.

As a busy (and somewhat lazy 🙃) developer, I didn’t want to spend three weeks building a custom React or Next.js blogging engine from scratch, nor did I want to navigate the mess of modern JavaScript framework fatigue just to display static text. I wanted something stable, battle-tested, inherently secure, and low-maintenance, requiring me to write as little code as possible.

Seeing how the theme of the blog is “Rabbi on Rails,” Jekyll, built in Ruby, was the obvious choice.

It integrates natively with GitHub Pages (meaning zero-cost hosting), uses standard Liquid templating, and handles simple Markdown files. To keep from reinventing the wheel layout-wise, I pulled in the Minimal Mistakes theme, which gave me a sleek, responsive design, an author sidebar, and clean typography right out of the box.

Most importantly, everything now lives in a Git repository on GitHub. My blog posts are version-controlled. If I make a catastrophic formatting mistake, I don’t rely on a platform’s fragile history UI; I just run git revert. Plus, every post includes a built-in “Suggest a Fix” button that drops readers directly into the GitHub web editor to submit a PR. Even the reactions and comments on posts are handled via GitHub Discussions using giscus.

Scripting The Migration: The Fun Part

Setting up the blog using Jekyll was the easy part. Actually extracting years of data from two completely different platforms and standardizing it into Jekyll-compatible Markdown is where the real engineering happened.

Because I didn’t want to copy and paste dozens of articles manually, I wrote custom Ruby scripts to handle the heavy lifting (if you’re curious, you can find the scripts under the /scripts directory in the blog’s repo). I quickly discovered that Medium and DEV each have their own pain points that torment migrating developers in completely opposite ways:

1. The Medium Export (The HTML Swarm)

When you export your data from Medium, they don’t give you clean Markdown. They hand you a zip file full of raw, clunky HTML files. My migration script had to parse through these HTML nodes, strip out Medium-specific wrappers, extract the metadata for the frontmatter, and translate the core elements back into clean Markdown. Furthermore, they don’t differentiate between different kinds of content: every blog post you wrote and every comment you ever left on anyone’s article all get dumped into one massive folder with no built-in way to tell them apart.

2. The DEV.to Export (Liquid Tag Fun)

DEV.to is much friendlier on the surface; their export gives you actual Markdown files. However, the headache here was their proprietary ecosystem. DEV relies heavily on custom Liquid tags for embeds (like tweets, YouTube videos, GitHub gists, and other articles and comments on DEV). Because standard Jekyll doesn’t understand DEV’s specific tags, my script had to use a heavy dose of regex to scrub, translate, or strip those out into standard web embeds.

3. The Asset Trap (Owning the Images)

One critical rule of a true migration: you must host your own images. If you leave your blog post images pointing to Medium or DEV’s CDNs, you don’t actually own your blog. If they change their CDN routing or delete your old account, your images break.

My script didn’t just transform text; it scanned every post, found the image URLs, downloaded the assets locally into an assets/images/ directory, and rewrote the Markdown image paths to point to my repository.

The Hyde Side of Jekyll: The Honest Tradeoffs

So far, the new setup is working fine for me, but every architectural change always comes with compromises. If you are thinking of making a similar move, you have to be comfortable with a few realities:

• No Native Platform Visibility: Medium and DEV have built-in audiences. When you publish on your own domain, you are shouting into the void until you distribute the link yourself. I plan on mitigating that a little by still cross-posting my technical posts on DEV (DEV makes it easy to add a canonical URL so your blog doesn’t take an SEO hit). Of course that means I need to do a better job promoting new blog posts on LinkedIn and other platforms.
• No Slick Web Editor: Medium and DEV spoil you with smooth, browser-based WYSIWYG editors that feature instant previews and drag-and-drop image uploading. With a static blog, you say goodbye to all that. Writing a post now means opening your IDE, writing raw Markdown, manually saving image files into local asset folders, and pushing a git commit to publish. As a developer, I don’t mind writing in my local code editor anyway, and VSCode plugins provide useful features like quick previews and syntax support. But you definitely lose the convenience of logging into a website from any computer and firing off a quick post.
• No Built-in Interactions: Out of the box, there are no “claps,” likes, or comment sections. In order to have a way for users to interact, I used giscus which relies on GitHub’s Discussions. That does mean that readers need a GitHub account to interact which works for an engineering crowd, but it means that my wife, who was my most consistent “clap” on Medium, probably won’t be reacting to my Jekyll posts anymore :)
• The Analytics Void: Static sites on GitHub Pages have no backend server logs. If you want to track page views without involving massive, privacy-invasive trackers like Google Analytics, you have to get creative by switching to a server-side host like Cloudflare Pages or utilizing privacy-first, cookie-less scripts like GoatCounter. For me, that wasn’t worth the hassle; I write primarily for myself and if others find my posts useful that’s fine, so I’m okay just not collecting analytics and not knowing how many readers each blog post gets (if any).

The Wins: Long Live the Indie Web

Despite the tradeoffs, the pros completely outweigh the cons.

I have total ownership. I own the layout, the content, the deployment pipeline, and the domain. Everything is centralized under blog.yechiel.me.

And the coolest unexpected side effect? The moment I published my first post, my RSS aggregator immediately pinged me. Because Jekyll natively builds a feed.xml file on every deploy, my RSS feed, which had been broken for ages by platform API shifts, instantly came back to life out of the box.

It feels incredibly good to step off the platform carousel and return to the roots of the indie web. If you’ve been putting off migrating your own content because of the technical friction, take this as your sign: write the script, own your data, and take your domain back.

If you follow the tech world these days, you’ve probably noticed that there is absolutely no middle ground when it comes to Artificial Intelligence.

On one side, you have the AI evangelists claiming that AGI is basically here, you’ll be replaced in six months (for the past two years), and you should be letting AI write your entire codebase based on vibes only or risk being left behind.

On the other side, you have the AI doomers who point at AI’s inability to count the “R”s in “strawberry” and its tendency to be wrong so confidently it puts mediocre white men to shame and proudly declare the technology to be a useless, glorified autocomplete.

The reality, as always, contains a little bit of both.

AI is neither a magic wand that does your job for you and will solve all the world’s problems, nor is it completely useless. It could be a massive force multiplier. But in software engineering, as in life, speed is only useful if you are actually heading in the right direction.

Horsing Around

To understand where AI really fits into our toolbelts, I like to think of a story about Rabbi Shneur Zalman of Liadi known as the Ba’al HaTanya (“Author of the Tanya”) for his seminal work by that name.

Rabbi Shneur Zalman lived in present-day Belarus in the late 1700s and founded the Chabad chassidic movement. He was renowned not just as a mystic and a scholar, but as a deeply practical advisor. People would travel and correspond with him from all over to consult with him on their personal struggles.

One day, a father came to the Rebbe. His teenage son was turning away from his upbringing and values. Instead of focusing on his studies, the boy was spending all his time at the local stables, obsessing over horses and galloping around the countryside. The father wasn’t happy with his son’s new hobby and asked the Rebbe for advice.

The Rebbe advised the father to find an excuse to send the boy into town so they could meet. Knowing his son loved to ride, the father gave him an errand at the Rebbe’s court and told him he could ride his horse there. The young man happily galloped into town, eventually finding himself face-to-face with the Rebbe.

“Why did you choose to ride into town on a horse instead of taking a carriage?” the Rebbe asked.

“Because a good horse runs fast,” the boy replied enthusiastically. “You gallop away, and you reach your destination so much quicker.”

“That is all very well,” the Rebbe countered. “But if you make a wrong turn, then you end up traveling quickly in the wrong direction and get completely lost!”

The young man thought for a moment and pushed back. “That may be true, Rebbe,” he insisted, “but as soon as you catch yourself and see that you are on the wrong path, the horse can help you quickly get back on the road.”

“Yes,” the Rebbe repeated slowly and emphatically. “If you realize you’re on the wrong path before it is too late, you can quickly return to the main road…”

The Artificial Horse

This story captures the reality of coding with Large Language Models.

LLMs give us unprecedented velocity, but they don’t actually understand why we are building things. It is raw, untamed horsepower.

Just the other day, I was using Claude to help write some controller tests for a web app. The test failed because the endpoint returned a 401 Unauthorized, which made sense, we hadn’t set up an authenticated user in the test setup yet.

Instead of figuring out how to properly mock a logged-in user, Claude decided to take the fastest possible route to a green test suite. It rewrote the test to expect a 401 Unauthorized and proudly declared the test passed “because we know the controller is working.”

This is exactly what the Alter Rebbe meant. The AI horse galloped to the destination at lightning speed and got the test passing, but in completely the wrong direction.

If you just blindly click “Accept” (or worse, run Claude with --dangerously-skip-permissions 😱), AI will confidently help you write terrible code, introduce subtle (and not so subtle) security flaws, or “fix” tests by defeating their entire purpose, all faster than you can type.

Hold The Reins Tight

But the young man in the story was right as well: if you realize you’ve made a mistake, the horse helps you pivot fast.

An experienced engineer will know when to pull the reins. When Claude tried “fixing” my test and I told it, “No, we need to actually authenticate a user before making the request.” It instantly generated the correct setup block, and got us back on the right path just as quickly as we had left it.

The horse isn’t the enemy, but it also isn’t going to get you to your destination on its own.

In the hands of someone who doesn’t know how to code, AI is just a fast ride in the wrong direction. But in the hands of an engineer who knows its strengths and its limitations it is an incredible tool.

Don’t be the developer who blindly trusts the horse to do the architectural thinking for you. And don’t be the developer who stubbornly refuses to ride, insisting on walking on foot while everyone else is galloping.

Don’t fear the horse. Just keep your hands on the reins, constantly check your map and compass, and be the rider.

RubyConf holds a special place in my heart. It was the very first tech conference I attended after receiving a scholarship fresh out of Flatiron School back in 2017 (you can read about my experience here), and then in 2021, it was the stage for my first conference talk in Denver.

Now, in another first, I joined the Program Committee for RubyConf 2026 to help put the program together, and what a program it is! We have an absolutely amazing lineup this year, and I’m so excited to see it come to life!

Who else is planning on attending? Let’s make plans to meet up and say hi!

In Part 1 of this series, we built the foundation of our container using Go. We successfully used the CLONE_NEWUTS namespace and process forking to isolate our container’s hostname from the host machine.

But we still have a massive security flaw. Right now, if we drop into our container’s bash shell, we can still see all of the host’s files. We could easily cd straight out of our “isolated” environment and mess with the host machine.

Let’s lock it down.

chroot to Jail

Linux has a wonderful system call called chroot (short for “change root”). It lets us change the root directory (/) for a given process. As far as the process is concerned, the directory we point chroot to is the entire universe. Anything outside of it simply doesn’t exist.

Let’s update our child() function to set the root directory to our current working directory:

func child() {
	fmt.Printf("Running in new child process %v \n", os.Args[2:])
	
	must(syscall.Sethostname([]byte("container")))
	
	// Get current directory and lock the process inside it
	pwd, err := os.Getwd()
	must(err)

	must(syscall.Chroot(pwd))
	// chroot changes the root, but doesn't automatically move us there. 
	// We must explicitly change our working directory to the new root!
	must(os.Chdir("/"))
	
	cmd := exec.Command(os.Args[2], os.Args[3:]...)
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	
	must(cmd.Run())
}

Run sudo go run main.go run /bin/bash.

Crash!

panic: fork/exec /bin/bash: no such file or directory

What happened?

We just told our process that our current directory is the entire universe. So, when we ask exec.Command to run /bin/bash, it isn’t looking at your computer’s actual hard drive anymore. It is looking inside your project folder for a directory called bin containing an executable called bash.

Because our current directory doesn’t have those, it fails! We need an actual root filesystem to provide the basic binaries our shell expects.

(Note: Production container runtimes like runC actually use a more advanced system call called pivot_root for better security, but chroot is perfect for understanding the core concept!).

The Image

To fix this, we need to provide an actual root filesystem that contains the basic folders and binaries (like /bin/bash) that our shell expects.

You can grab a basic Ubuntu root filesystem yourself using Docker. Open a new terminal tab and run these exact commands in your project directory:

# Use docker to start a Ubuntu container and then export its filesystem to a compressed file called ubuntu.tar
docker export $(docker create ubuntu) > ubuntu.tar

# Create a directory called ubuntu-rootfs and unzip your tar file into it
mkdir ubuntu-rootfs
tar -xf ubuntu.tar -C ubuntu-rootfs

This creates a folder called ubuntu-rootfs containing a complete, brand-new Ubuntu file system.

Assuming you have that folder in your project directory, let’s change our chroot call to point to it as follows:

	must(syscall.Chroot(filepath.Join(pwd, "ubuntu-rootfs")))
	must(os.Chdir("/"))

Now, when we run sudo go run main.go run /bin/bash, everything works perfectly!

You can run ls / and you will only see the files inside your ubuntu-rootfs directory. Try running cd .. to escape, and you will find yourself in the exact same directory as before. You cannot access the host machine at all.

PIDs and /proc

We’re ready for the next step. If you remember, when we ran docker run -it ubuntu /bin/bash back in the beginning of Part 1, one of the ways we could tell we were in an isolated container was by running ps aux and observing only two processes running with very low PIDs.

Let’s try to replicate that. While inside our new container, try running ps aux to view the running processes.

It breaks with an error:

Error, do this: mount -t proc proc /proc

The ps command works by reading the /proc directory, which is a special virtual filesystem in Linux that contains live data about running processes. Our isolated root filesystem has an empty /proc folder, and the operating system hasn’t been told to attach the live process data to it. Because it’s empty, ps fails!

To fix this, we need to do two things:

1. Give our container its own isolated Process IDs (PIDs) using namespaces.
2. Mount the proc filesystem so commands like ps can read it.

First, update the SysProcAttr in the run() function to include the PID and Mount namespaces. (Note: CLONE_NEWNS stands for “New Namespace”, but it specifically refers to the Mount namespace! It just happens to be the first namespace added to the Linux kernel and back then no one thought they might end up needing more so they just called it “namespace” 🤷).

	cmd.SysProcAttr = &syscall.SysProcAttr{
		Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS,
	}

Next, mount the proc directory inside our child() function, right after we chroot. We will also use Go’s defer keyword to ensure we unmount it and clean up after ourselves when the function exits:

	must(syscall.Chroot(filepath.Join(pwd, "ubuntu-rootfs")))
	must(os.Chdir("/"))
	
	// Mount the proc filesystem
	must(syscall.Mount("proc", "proc", "proc", 0, ""))
	// Clean up after ourselves when the function exits
	defer syscall.Unmount("proc", 0)

Now, run your container and type ps aux. You’ll see only three processes running: exe (our Go program) running as PID 1, bash running as PID 2, and the ps command we just ran!

Cgroups (Keeping it Civil)

We have our invisibility cloak (Namespaces) and our isolated universe (chroot). But what happens if we write an infinite while loop inside our container that eats up all the CPU and memory?

It would completely crash the host machine!

To prevent our container from using up all of our resources, Linux uses cgroups (Control Groups). Cgroups act as the bouncer, ensuring no single container uses more than its fair share of resources.

To set up a cgroup, we can lean on a famous Linux philosophy: “Everything is a file.” This means we can configure the kernel’s resource limits by creating specific directories and writing text into special files.

Let’s add a quick helper function to our main.go file to limit the maximum number of processes our container is allowed to spawn to 20:

func cg() {
	cgroups := "/sys/fs/cgroup/"
	pids := filepath.Join(cgroups, "pids")
	
	// 1. Create a new cgroup for our container
	containerCgroup := filepath.Join(pids, "my-container")
	os.Mkdir(containerCgroup, 0755)
	
	// 2. Write the limit into the cgroup file (max 20 processes)
	must(os.WriteFile(filepath.Join(containerCgroup, "pids.max"), []byte("20"), 0700))
	
	// 3. Add our current process to this cgroup
	must(os.WriteFile(filepath.Join(containerCgroup, "cgroup.procs"), []byte(strconv.Itoa(os.Getpid())), 0700))
}

Let’s break down what this function is doing:

1. Create the group: By making a new directory inside /sys/fs/cgroup/pids, the Linux kernel automatically creates a new Control Group for us.

2. Set the rule: Inside that new directory, Linux automatically generates a file called pids.max. We open that file and write the text "20" into it. This establishes a rule that our process will only be allowed to run 20 sub-processes.

3. Enforce the rule: Linux also generates a file called cgroup.procs. We get our Go program’s current Process ID (os.Getpid()) and write it into this file. This tells the kernel, “Hey, apply the rules of this folder to me!”

Finally, let’s call this function inside our run() function, right before we execute our child process:

func run() {
	fmt.Printf("Running %v \n", os.Args[2:])
	
	args := append([]string{"child"}, os.Args[2:]...)
	cmd := exec.Command("/proc/self/exe", args...)
	
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	
	cmd.SysProcAttr = &syscall.SysProcAttr{
		Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWPID | syscall.CLONE_NEWNS,
	}
	
	// Set up our resource limits!
	cg()
	
	must(cmd.Run())
}

And just like that, our container is officially resource-limited! Because cgroups inherit down to child processes, everything that runs inside our container is bound by this rule. If a malicious script inside tries to execute a “fork-bomb” (a script that endlessly copies itself to freeze the computer), the kernel will step in and aggressively kill it the second it hits 20 processes.

The Reveal

If you put all of this together, we just built Docker from scratch in about 50 lines of code.

Containers aren’t magic. They aren’t heavyweight VMs. They are simply standard Linux processes wrapped in namespaces, jailed in a specific directory, and policed by cgroups.

In fact, you don’t even need Go to do this. You can trigger the exact same isolation using a single line of bash:

sudo unshare --uts --pid --mount --fork --root=/home/ubuntu-rootfs --mount-proc /bin/bash

And there you have it! The next time someone says “it works on my machine,” you know exactly what it takes to ship their machine to production.

We’ve all been there. You spend days writing a new feature. You test it locally, everything passes, you push it to production, and… boom. It crashes immediately.

“But it works on my machine!” you cry out to your lead engineer.

And that is exactly what containers are. They are a way to bundle up your application and the environment it runs in—your machine—so that it behaves exactly the same way in production as it does on your laptop.

But what is a container, really?

Most people have an intuition of containers as some kind of complicated application that runs on your computer and simulates another computer. That is the image I had in my head even after working on containers for a few months at Pivotal/VMware… and it’s a myth.

The reality is a lot simpler, and a lot more interesting!

The truth is that a container is simply a directory on your computer—like any other directory—with a process running inside of it. What makes it a container and not just another process running inside a directory is that we use some clever built-in Linux features to trick the process into thinking that this directory is the entire computer. As far as this process is concerned, nothing exists outside of the directory we “trapped” it in and that directory is the entirety of its universe.

In this two-part series, we are going to demystify this illusion by building Docker from scratch in exactly 60 lines of Go code.

Note: Because containers rely heavily on the Linux Kernel, this tutorial will only run natively on a Linux machine. If you are following along on a Mac, you’ll need to spin up a Linux VM first, as Macs run on the Darwin kernel and don’t have these system calls!

Let’s get started!

Setting the Stage

We’ll be writing our container in Go. Why Go? Because it gives us incredibly clean access to underlying Linux system calls, which we’ll need to create our container illusion. This is the reason Docker, Kubernetes, and other cloud-native projects are all written in Go.

Let’s try to replicate the core behavior of Docker.

Normally, when using Docker, you run a command like:

docker run -it ubuntu /bin/bash

If you run that (assuming you have docker installed) you will see that you have been dropped into a new shell. This shell looks different than your original shell and you can tell it’s completely isolated from the rest of your machine (the host) in a few ways (it’s worth opening a new tab in your terminal so you can see these changes side by side):

1. Your prompt: Everyone’s prompt is different, but most have something in the beginning that looks like [username]@[hostname]. The prompt you see now probably looks like root@[some-random-string].

2. Your hostname: If you type hostname in your host computer’s terminal, it will output your computer’s actual name. If you run hostname inside your container, on the other hand, you will see that same random sequence of characters from your prompt. Docker assigned this fake hostname to your container at random.

3. Your File System: If you type ls / inside your container you will see that none of the files from your computer’s actual root directory are there, instead you will see a fresh list of files and directories, exactly like you would find in a brand new Ubuntu installation.

4. Your processes: If you type ps aux in your container you will find only 2 processes with very low Process IDs (PIDs)—typically PID 1 for the shell process you’re in and another low number PID for the ps command you just ran. Meanwhile, running ps aux on your host machine will show a massive list of running processes, many of them with very high PIDs.

We will try to replicate this behavior from scratch, with a few minor differences.

Our goal is to run:

go run main.go run /bin/bash

And if we do everything right the behavior will be mostly the same. We will drop into a new shell where:

1. We will see a different hostname than our existing one.

2. The root directory we will have access to will not be the root directory of our computer, instead it will be a new root directory.

3. If we inspect the processes running using ps we will see only the processes running in our program and not all the processes on our computer.

So let’s start!

Show Me the Code

Let’s build this step by step. Create a new directory on your Linux computer, make a file named main.go, and let’s add our initial boilerplate:

package main

import (
	"fmt"
	"os"
)

func main() {
	// os.Args is a list of everything typed in the terminal.
	// [0] is the program name (main.go), [1] is our command ("run")
	switch os.Args[1] {
	case "run":
		run()
	default:
		panic("Invalid argument")
	}
}

func run() {
	// os.Args[2:] takes everything AFTER the "run" command
	// e.g., ["echo", "hello", "world"]
	fmt.Printf("Running %v \n", os.Args[2:])
}

In Go, os.Args captures every word you type into the terminal as a list (a slice) of strings. We are telling our program to look at the second word (os.Args[1]). If it says “run”, we trigger our run() function which, for now does nothing but print all our arguments to the terminal.

If we run this in our terminal:

$ go run main.go run echo hello world
Running [echo hello world]

Awesome. It successfully reads our command. But it’s just printing text; it’s not actually executing the command yet.

To make it execute the command, we need to wire up Go’s os/exec package (a package for executing commands on our computer). Let’s update our file:

package main

import (
	"fmt"
	"os"
	"os/exec"
)

func main() {
	switch os.Args[1] {
	case "run":
		run()
	default:
		panic("Invalid argument")
	}
}

func run() {
	fmt.Printf("Running %v \n", os.Args[2:])
	
        // 1. Define the command we want to execute. This includes the third element in our array 
	// (the actual command, in our case "echo"), as well as any optional arguments we may 
	// want to pass to it ("hello world").
	cmd := exec.Command(os.Args[2], os.Args[3:]...)
	
	// 2. Wire up the plumbing
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	
	// 3. Run the command and handle any errors
	must(cmd.Run())
}

// A tiny helper function to catch errors and crash the program 
// cleanly if something goes wrong.
func must(err error) {
	if err != nil {
		panic(err)
	}
}

Let’s look at what we just added to run():

1. Define the command: exec.Command takes the program we want to run (like echo) and any arguments we want to pass to it (hello world).

2. Wire up the plumbing: This part is crucial. By default, when a program spins up a new process, it runs invisibly in the background. By pointing the new command’s Standard Input, Output, and Error to our own os.Stdin, os.Stdout, and os.Stderr, we are attaching its “mouth and ears” directly to our terminal so we can actually interact with it.

3. Run it: We execute the command. Because Go requires explicit error handling, we wrapped it in a tiny must() helper function to keep our code readable.

Let’s test it out:

$ go run main.go run echo hello world
Running [echo hello world]
hello world

We actually get hello world echoed back at us by the system!

Even better, we can tell our program to drop us into an interactive shell:

$ go run main.go run /bin/bash
Running [/bin/bash]
root@your-computer:/home/yechiel/docker-clone# 

However, this shell is absolutely not a container yet. If you type hostname, you’ll see your host machine’s actual name. If you type ls /, you can see all your host files. Right now, we have just written a fancy Go wrapper around a regular bash process.

It is time to start building the walls of our container.

Introducing Namespaces (The Invisibility Cloak)

To isolate our process from the rest of the computer, we need to put it inside a Namespace. A namespace is like an invisibility cloak that hides the rest of the computer from our process.

There are different namespaces that isolate different aspects of the system. Let’s start with the UTS namespace, which isolates the hostname.

To create a new namespace, we pass a specific “clone flag” to the system call spinning up our process. Update your run() function:

func run() {
	fmt.Printf("Running %v \n", os.Args[2:])
	
	cmd := exec.Command(os.Args[2], os.Args[3:]...)
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	
	// Set up the namespace!
	cmd.SysProcAttr = &syscall.SysProcAttr{
		Cloneflags: syscall.CLONE_NEWUTS,
	}
	
	must(cmd.Run())
}

If you try to run the command now, you’ll get a “permission denied” error. Because changing a namespace requires modifying kernel-level structures, you now need root privileges.

Instead, let’s run sudo go run main.go run /bin/bash.

If you run hostname now you will still see your computer’s actual hostname. This is because, by default, Linux has your new process inherit the hostname of the host computer.

However, if you manually run hostname container inside this new bash shell, and then type hostname, you’ll see your hostname is now container. But if you switch to a terminal tab on your host machine and type hostname, you’ll see your actual computer’s name hasn’t changed at all! Our process is successfully isolated.

Forking the Process

Did you notice something weird when you manually changed the hostname in the last step? Even though typing hostname printed out container, your actual bash prompt likely still said root@your-computer#!

This happens because the bash shell reads the machine’s hostname when it first starts up. Changing the hostname after the shell is already running doesn’t dynamically update your prompt. If we want our container to feel like a truly isolated environment from the second it boots, we need our Go program to change the hostname automatically before we execute /bin/bash.

Luckily, Go has a function to change the hostname: syscall.Sethostname().

But here we run into a “chicken and egg” problem: where do we call that function?

If we call it before cmd.Run(), it executes on our host machine and changes our actual computer’s name (bad!). If we call it after cmd.Run(), it’ll only run after our bash shell has already exited (still bad!).

We need a middleman. We need our Go program to cross over into the new namespace, set the hostname, and then execute the /bin/bash command.

To do this, we are going to have our Go program run itself again as a child process.

Let’s update our main.go file. We will update the main() and run() functions, and add a brand new child() function:

package main

import (
	"fmt"
	"os"
	"os/exec"
	"syscall"
)

func main() {
	switch os.Args[1] {
	case "run":
		run()
	case "child":
		child() // We added a new command here!
	default:
		panic("Invalid argument")
	}
}

func run() {
	fmt.Printf("Running %v \n", os.Args[2:])
	
	// /proc/self/exe is a special Linux file that points to the program 
	// currently running. So, our program is calling itself!
	// We pass "child" as the first argument, followed by the rest of our commands.
	args := append([]string{"child"}, os.Args[2:]...)
	cmd := exec.Command("/proc/self/exe", args...)
	
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	
	cmd.SysProcAttr = &syscall.SysProcAttr{
		Cloneflags: syscall.CLONE_NEWUTS,
	}
	
	must(cmd.Run())
}

func child() {
	fmt.Printf("Running in new child process %v \n", os.Args[2:])
	
	// We are now inside the namespace! It is safe to change the hostname.
	must(syscall.Sethostname([]byte("container")))
	
	// Now we run the actual command the user requested (like /bin/bash)
	cmd := exec.Command(os.Args[2], os.Args[3:]...)
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	
	must(cmd.Run())
}

func must(err error) {
	if err != nil {
		panic(err)
	}
}

Let’s break down the magic happening in exec.Command("/proc/self/exe", args...):

1. "/proc/self/exe": In Linux, /proc is a special directory that holds information about all running processes. If you check what’s in there (by running ls /proc) you will see a whole bunch of directories that have numbers as names. Each number is a PID and that directory contains information about the process with that PID. /proc/self/exe is essentially a shortcut to the directory for the process that’s currently running (in our case go run main.go).

2. args...: We are taking the word "child" and appending the rest of the user’s commands (like /bin/bash) to it. The ... syntax in Go simply “unpacks” the list so it can be passed as individual arguments.

So, when you type go run main.go run /bin/bash, here is what happens:

1. The program starts, sees "run", and triggers the run() function.

2. The run() function sets up the invisibility cloak (the NEWUTS namespace).

3. Inside that cloak, it runs itself again, but this time passing the command "child".

4. The program starts a second time, sees "child", and triggers the child() function.

5. Because we are now safely inside the namespace, it changes the hostname to container and finally runs /bin/bash.

Let’s test it. Run sudo go run main.go run /bin/bash:

$ sudo go run main.go run /bin/bash
Running [/bin/bash]
Running in new child process [/bin/bash]
root@container:/home/yechiel/docker-clone# 

Look at that prompt! We’ve successfully isolated the hostname programmatically before bash loaded. You’ll see both print statements execute, and if you type hostname in the new shell, it will say container.

We are still not in a proper container, though. If you run ls /, you will see all the files on your host machine, and you can even use cd .. to “escape” the directory entirely. Worse, if you were running this in a shared cloud environment, you would theoretically be able to see everyone else’s files and running processes—a massive security risk! We need a way to lock our process down so it can’t escape its designated environment.

In Part 2, we will tackle the final pieces of the container puzzle: jailing the file system, isolating the Process IDs (PIDs) so our container can only see itself, and stopping infinite loops from crashing the host computer using cgroups. Stay tuned!

Refactoring Your Bitachon: Moving From Monolith to Modular

I was recently learning Shaar HaBitachon (“The Gate of Trust”) — a section of the classic 11th-century work Chovot Halevavot (“Duties of the Heart”) by Rabbeinu Bachya ibn Pekuda dedicated to cultivating trust in G-d — with my Chavruta (study partner). (By the way, shout-out to this amazing book! If you aren’t learning it yet, I highly recommend picking it up! It’s a game-changer for your mindset!)

We were learning a part in Chapter Five which discusses the proper attitude one should have towards the “means” (hishtadlut, or personal effort) we employ to make a living.

Rabbeinu Bachya, the author, explains that there is a fundamental difference between someone who has Bitachon (trust in G-d) and someone who trusts in their own efforts:

“While a person who relies on G-d also involves himself in various means of obtaining his livelihood… he doesn’t rely on them, nor does he expect them to either benefit him or cause him harm unless G-d wills it to be.

The only reason he involves himself in them is his choice to carry out the service of the Creator, Who instructed him to involve himself in the world…”

Contrast this with the person without Bitachon :

“However, a person who does not rely on G-d involves himself in the means of pursuing his livelihood because he relies on them for help and protection… If they do indeed help him, then he will praise them…

If, however, they do not help him, then he will abandon them, reject them, and turn his desire away from them.”

As I was reading this, it hit me: This is exactly the concept of Decoupling in programming.

Spaghetti Code vs. Modular Design

As developers, we know the pain of “tightly coupled” code. That’s when Module A is so knowledgeable about, and dependent on, the inner workings of Module B that you can’t touch one without breaking the other. If you want to swap out your database from MySQL to Postgres, but your business logic is writing raw SQL queries directly inside the controller, you’re in for a nightmare. Everything is tangled. The logic depends on the specific implementation.

Good architecture, on the other hand, strives for Decoupling.

You define an interface. Your business logic requests data, but it doesn’t care how that data is retrieved. You can swap out the database, change the API, or refactor the entire backend — and as long as the interface remains the same, the application keeps running smoothly. The logic is independent of the implementation details.

Refactoring Your Bitachon

Shaar HaBitachon is teaching us to refactor our lives to be loosely coupled.

A person with true Bitachon has “decoupled” their livelihood (Parnassah) from their job.

• The Interface: G-d’s promise to sustain us.
• The Implementation: The current job, gig, or business deal (the means/effort).

When you are tightly coupled to your job, you are living in a legacy codebase full of dependencies. You think, “This job is the only way I can pay my mortgage.” That’s a fragile architecture. If that specific “module” (the job) crashes, your whole system goes down.

However, when you live with Bitachon, you realize that your livelihood comes from the “Sustenance Service” (G-d), and your job is just one interchangeable module used to deliver it.

If you lose your job, or a deal falls through? It’s not a system failure. It’s just a hot-swap. G-d is simply deprecating one method and initializing another. You don’t panic because your “Sustenance Provider” hasn’t changed — only the delivery mechanism has.

The “Why” Matters

What really struck me in that chapter of Shaar HaBitachon is the motivation. The person with Bitachon still works just as hard! But why?

Not to get money, but to fulfill the will of G-d.

Just like we write modular code to make our applications robust, scalable, and maintainable, we should strive to make our trust in G-d robust and modular. We do the work because it’s the right thing to do (the spec), but we know that the result is handled entirely by the Core System.

So, the next time you’re refactoring a messy class or abstracting away a dependency, take a second to think: Is my own Bitachon tightly coupled to my job, or is it modular enough to handle whatever life throws at it?

Do You Even Wordle?

If you’re on social media, chances are that you are one of two kinds of people; those who post their Wordle results every day or those who are extremely annoyed by the yellow and green boxes flooding their feeds.

What is it about this word game that took the world by storm and made it so popular (at least until the next trend comes along)?

There are plenty of takes out there, but it seems to me that people find Wordle so wholesome because it stands in contrast to so much of what makes the toxic parts of the internet so toxic.

Unlike most apps and games out there, Wordle isn’t spying on you, it isn’t trying to drive engagement, it’s not addictive, and it isn’t trying to suck you into playing for hours every day. In fact, by only giving one word a day, it sets a pretty tight limit to how much time you can waste on it every day.

A lot has been said about the toxic parts of internet culture, and the large tech companies have been blamed for putting shareholder profits over the well-being of their users.

In Parshat Mishpatim, the first Parshah after the Jews got the Torah at Mount Sinai, the Torah goes into great detail about the laws of civil liability and the responsibility we have for damages caused by our actions and our property.

Just as a person can’t say “I just let my goat graze; it’s not my fault she ate up your tomato patch,” similarly, we can’t absolve ourselves from responsibility for the products and the technology we create.

Sure, profits are important, but they can’t come at the expense of the first principle; don’t be evil.

P.S. Really? “Knoll”? What’s up with that?

Talmudic Gems For Rails Developers

A few weeks ago, I gave a talk at RailsConf titled Talmudic Gems For Rails Developers.

In the talk I discussed lessons I learned from a lifetime of Talmudic study that helped me in my journey as a developer, and which I felt could benefit other developers in their growth.

The talk is geared at any developer looking to grow using the timeless wisdom of the Talmudic sages, not just Rails developers.

I shared a transcript of the talk in the Torah && Tech newsletter issue #123 (if you haven’t yet, you can sign up to the newsletter, and get the first year’s worth of newsletters in book format, at the Torah && Tech website: torahandtech.dev).

The talk has just been posted to YouTube, and I’m happy to share it with my audience!

If you would like to delve into some of the sources I mentioned, you can find links in the source sheet I prepared here.

Happy Learning!