Forem: Farzon Lotfi

The Geometry of Dragon Ball: A Deep Dive into SDFs and Raymarching

Farzon Lotfi — Sat, 02 May 2026 09:00:00 +0000

Today we are deconstructing the 4-Star Dragon Ball shader (available on Shadertoy here). This shader is a good example of using 2D math to drive 3D optical effects. To understand it, we must reference the fundamental building blocks provided by Inigo Quilez.

This shader is more than just a piece of fan art. I built this 4-Star Dragon Ball shader as a bridge between simple 2D shapes and complex 3D optics. If you’re looking for an introductory shader to study, this is a perfect playground because it moves past "drawing a box" and dives into how light behaves. What makes this unique as a case study is the Double March. We are treating the sphere as a physical lens. Once you hit the "glass," the shader calculates a bent path and starts a second march inside. It’s my attempt at playing with coordinate transformation.

1. Defining the Stars (2D SDFs)

The internal stars are defined using 2D Signed Distance Functions. an SDF is a function that takes a point in space and returns the distance to the nearest surface.

If the distance is positive , you are outside the object.
If the distance is negative , you are inside.
If it is zero , you are exactly on the surface.

This allows us to define perfect geometric shapes without textures. The specific star logic used here, sdStar5, is a direct implementation of Quilez's formulas found in his 2D Distance Functions article.

// Helper to map the 4 stars in 2D
float map4Stars2D(vec2 p) {
    float offset = 0.22;
    float radius = 0.15;
    float d1 = sdStar5(p - vec2(offset, offset), radius, 0.45);
    float d2 = sdStar5(p - vec2(-offset, offset), radius, 0.45);
    float d3 = sdStar5(p - vec2(offset, -offset), radius, 0.45);
    float d4 = sdStar5(p - vec2(-offset, -offset), radius, 0.45);
    return min(min(d1, d2), min(d3, d4)); // Union of all four stars
}

2. Extrusion and 3D Modeling

To turn these flat stars into 3D geometry inside the sphere, we use Extrusion. By combining the 2D distance with the Z-axis, we create a volumetric shape. This technique, along with the rounding (beveling) seen in the code, is detailed in Quilez’s 3D Distance Functions article.

float mapStars3D(vec3 p) {
    float d2d = map4Stars2D(p.xy);
    vec2 w = vec2(d2d, abs(p.z) - 0.04); // abs(p.z) defines thickness
    return min(max(w.x, w.y), 0.0) + length(max(w, 0.0)) - 0.015;
}

3. The Raymarching Engine

How does the computer "see" these math functions? For a short intro think of it this way. Since we don't have triangles, we can't use standard rasterization. Instead, we use Raymarching.

Imagine firing a ray from your eye through every pixel. Instead of moving in tiny constant steps, the ray "leaps" forward by the distance returned by our SDF. Because the SDF tells us the distance to the nearest object, we know it's safe to move that far without hitting anything. We repeat this until the distance is nearly zero (a hit!) or we've gone too far (a miss).

For a full deep dive into the algorithm that powers almost every modern Shadertoy, read Quilez's Raymarching Distance Fields.

In our code, this is the loop that "steps" through space until it finds the sphere or the floor.

for(int i = 0; i < MAX_STEPS; i++) {
    p = ro + rd * dO; // Current position along the ray
    dS = map(p); // Distance to nearest object
    dO += dS.x; // "Safe" jump forward
    if(dO > MAX_DIST || abs(dS.x) < SURF_DIST) break;
}

4. Optical Physics: Refraction & Reflection

To simulate glass, we don't just "draw" it; we simulate how light behaves at the boundary of two materials.

Fresnel Effect: We use the dot product of our view ray and the surface normal to decide if we see the interior (refraction) or the exterior (reflection).
The Nested March: When the ray enters the sphere, it bends. The code then starts a new internal raymarch loop. This is what allows the stars to look magnified and distorted by the glass.

vec3 refractDir = refract(rd, n, 1.0 / 1.52); // Bending light into glass
// ... inside the sphere ...
float volumetricGlow = exp(-minStarDist * 18.0); // Creates that resin-like haze
refractCol += emissiveStar * volumetricGlow * 0.45;

5. Analytical Caustics & Chromatic Aberration

The glowing star patterns on the floor are caustics. Caustics are those dancing, wavy patterns of light you see at the bottom of a swimming pool or the bright "ring" at the base of a wine glass. They happen whenever a curved, transparent surface like water or a glass ball acts as a lens, grabbing scattered light rays and bunching them together into concentrated, glowing shapes.

I achieve this by using iSphere to project the floor's coordinates back into the star field.

To add realism, I implement **Chromatic Aberration **splitting the light into R, G, and B components by shifting the UV samples slightly.

Chromatic Aberration is a lens effect that creates a "rainbow fringe" around sharp edges. It happens because glass doesn't bend all colors of light equally; red light bends a little less than blue light. In a shader, you mimic this by "splitting" the image into its red, green, and blue components and shifting them slightly so they don't perfectly line up, giving the scene a realistic, cinematic look.

float shift = 0.015; 
float dR = map4Stars2D(distortedUV * (1.0 - shift));
float dG = map4Stars2D(distortedUV);
float dB = map4Stars2D(distortedUV * (1.0 + shift));
vec3 starShadow = vec3(smoothstep(0.03, -0.03, dR), ...);

The "Secret Sauce": Why This Works

The uniqueness of this shader lies in its **layered approach**. It isn't just one distance field; it’s a coordinate-space transformation. By distorting the UVs on the floor (distortedUV), I simulate the way a magnifying glass bends light, creating a dynamic caustic pool that responds to the pulsing of the internal emissive stars. I was really trying my best to simulate the below image.

Conclusion

Writing shaders is about translating the laws of physics into the language of mathematics. By combining Inigo Quilez’s SDFs with Raymarching, you can build complex, beautiful worlds with nothing but a few lines of GLSL.

References & Further Reading:
• noztol_shades instagram

• Raymarching Distance Fields (Quilez)

• 3D Distance Functions (Quilez)

• 2D Distance Functions (Quilez)

• 4-Star Dragon Ball by Me (Noztol)

The Hardest Problem in Engineering Isn't Code (It’s Communication)

Farzon Lotfi — Fri, 01 May 2026 04:00:00 +0000

If you ask a room full of software engineers what the hardest part of their job is, you’ll get a variety of answers. Some will say VM orchestration or these days Agent orchestration. Others will say cache invalidation or naming things.

They’re all wrong.

The hardest thing you will ever have to do in your career is communicate your ideas to other people. You can write the most elegant, highly optimized, mathematically perfect algorithm in the world, but if you can't explain why it matters to your team, your manager, or the product owner, it will sit in a repository gathering digital dust.

A good engineer can solve complex technical problems in isolation. A great engineer builds bridges between those solutions and the people who need them. Collaboration is the actual 10x multiplier in tech, and it requires a completely different skill set than writing code.

If you are an introverted engineer who prefers the quiet predictability of working on a ticket to the loud chaos of a planning meeting, this can feel daunting. But influence isn't about being the loudest voice in the room. It’s about being the most strategic. Here is how you can find your voice and get your great ideas the audience they deserve.

The Art of Engineering "Inception"

In a large corporation, a brilliant idea is a fragile thing. If a project only has one champion, it is constantly at risk of being deprioritized, defunded, or forgotten. To keep a project alive, you need consensus. You need multiple stakeholders who feel a sense of ownership over the work. The best engineers don’t just pitch ideas; they incept them into their colleagues. Like Leo in Inception, your goal is to plant the seed of an idea so naturally that your colleagues eventually think they came up with it themselves.

You do this by asking guided questions rather than making statements. Think socratic method. Instead of saying, "We need to migrate to this new compiler," you ask, "Have you noticed how slow our compile times are on CL? What do you think would happen if we looked at Clang?" When people arrive at the conclusion themselves, they become deeply invested in the outcome. They become your coalition.

Mirroring: Let Them See Themselves in You

Influence requires trust, and humans naturally trust people who feel familiar to them. When you are trying to convince a colleague of an idea, pay close attention to their energy and mirror it.

The High-Energy Visionary: If you are talking to a product manager who speaks quickly and focuses on the big picture, match that tempo. Focus on the end-user impact and the broad strokes. Skip the implementation details.
The Methodical Skeptic: If you are talking to a senior architect who is quiet, analytical, and risk-averse, slow down. Lower your volume. Present your idea with a focus on edge cases, security, and stability.

Mirroring isn't about manipulation; it’s about translation. It’s taking your brilliant, quiet idea and translating it into a language the other person natively understands. When they see their own communication style reflected back at them, their defenses drop, and they actually listen.

Building the Muscle: Why I Write

If you are a quiet person, speaking up in a crowded meeting full of extroverts might feel like trying to jump onto a moving train. You don't have to start there. Communication is a muscle, and you can build it in isolation before testing it in public.

For me, that meant writing.

I started writing down my ideas whether as formal design documents, meeting notes, internal wiki pages, or just structured notes for myself because it forced me to organize the chaos in my head. Writing strips away the pressure of a real-time conversation. It allows you to anticipate counter-arguments, refine your analogies, and distill your thoughts down to their absolute essence.

By the time I actually had to present an idea verbally, I had already rehearsed the logic on paper. If you struggle to find your voice in meetings, start by finding your voice on the page.

Finding Your Voice

The tech industry desperately needs the ideas trapped inside the heads of quiet engineers. You don't need to change your personality or suddenly become a boisterous extrovert to be heard. You just need to learn the mechanics of influence: plant the seeds, build a coalition, speak their language, and structure your thoughts.

The code is the easy part. The real engineering happens between people.

The Architecture of Service: Reclaiming the Soul of Technology

Farzon Lotfi — Thu, 30 Apr 2026 09:00:00 +0000

If you trace the lineage of the personal computing revolution back to its roots in the 1970s and 80s, you won’t find corporate boardrooms or venture capital firms. You’ll find idealists. You’ll find the counterculture hippies of the Whole Earth Catalog, Homebrew Computer Club or the hackers of the Cult of the Dead Cow tinkerers who believed that democratizing information would emancipate humanity. For a brief, shining moment, the tech industry felt like the one place on earth where you could actually change the world for the better.

Even as the industry corporatized, that idealism lingered. We saw it in Google’s famous foundational mandate: "Don't be evil." It was a promise that tech could be immensely profitable without losing its moral compass.

But today, that promise feels like it's dying a slow, agonizing death.

Instead of a unified global village, we are left with a balkanized internet of walled gardens. The products we rely on are actively undergoing what author Cory Doctorow so aptly named "enshittification." Platforms that once served users are now decaying into extraction machines. They get more expensive while degrading in quality. They are bloated with intrusive spyware and saturated with features absolutely no one asked for. Like forcing AI copilots into every corner of our digital lives just to appease shareholders. We are no longer the users; we are the product, the data points, the marks.

I hope for a new ethic in tech and I have ideas on what it should look like.

I know exactly how that sounds. I am acutely aware of the mockery that awaits anyone who talks about "ethics" in Silicon Valley. If you’ve seen the HBO show Silicon Valley, you remember the parody of "Tethics" (Tech Ethics) a hollow, performative corporate branding exercise used by narcissistic founders to dodge accountability. Proposing "tech ethics" today sounds like a punchline because we’ve seen too many ethics boards dissolved the moment they stand in the way of quarterly growth.

We don't need a new corporate compliance framework. We need a fundamental shift in how we view the people who use our tools.

I look at this through the lens of my faith, but the underlying moral framework requires no theology to understand. It is a framework that appeals just as much to the staunch atheist as it does to the believer, because it is rooted in pure, unglamorous action.

In Baha'i history, there is a story of an early American adherent named Lua Getsinger. She deeply wanted to serve God and asked the head of the Faith how to do it. He didn't tell her to pray more or something equally abstract. Instead, he sent her to the home of a destitute, chronically ill man.

When Lua arrived, the conditions were so filthy and the smell so overwhelming that she fled. But her excuse was rejected. She was told that if she truly wanted to serve the divine, she had to serve her fellow man. She was sent right back with strict instructions: clean his house, bathe his body, and feed him. She was told not to return until the work was done.

You don't need a religion to understand the weight of that lesson. The translation is simple: Lofty ideals mean absolutely nothing if you aren't willing to do the messy, tangible work of improving the reality of the person right in front of you.

This is the standard of service. It is not an abstract mission statement on an "About Us" page. It is recognizing the inherent dignity of another human being.

What would the technology sector look like if it were governed by this principle?

If we truly respected the dignity of our users, we could never justify injecting spyware into their devices to harvest their private lives. We could never justify trapping them in addictive algorithmic loops to sell their attention.

To "clean the house and feed the hungry" in the digital age means building technology that acts as a genuine public good. It means designing software that respects human autonomy, protects privacy, and solves actual problems rather than fabricating new ones to monetize. It means teaching our engineers, our designers, and our algorithms how to serve humanity, rather than exploit it.

Tech can still be a place where people go to change the world. The tools we are building today have more potential to uplift humanity than the 1970s idealists could have ever dreamed. But the internet will not be saved by a new feature, more LLMS, or a faster computer. It will only be saved when the people building it decide to roll up their sleeves, look at the people they are building for, and remember what it actually means to serve.

An Android Fuzzing Retrospective Part II: The "Single-VM" Theory and the Bionic Wall

Farzon Lotfi — Wed, 29 Apr 2026 12:00:00 +0000

In my previous post, I detailed how our move from the Android Emulator to standalone Android-x86 VHDX images gave us impressive cost saving wins for our fuzzing budget. With any infrastructure pivot, the moment we finished it, we started looking for ways to optimize it further. The plan would have been to collapse our two-VM Producer/Consumer model into a single-VM footprint.

Our next major architectural pivot would have been using ChrootOnAndroid to host both the web server based fuzzer and Edge on one kernel. However, our prototypes hit three massive walls: Bionic libc , Filesystem Permissions , and the Bootloader Logic of Android itself.

The Theoretical Efficiency: Debian via Chroot

The logic was simple: If we could run our Linux-based test-case generators (the Producer) inside a Debian Chroot on the same Android-x86 VM running Edge (the Consumer), we could effectively double our scale again.

By utilizing ChrootOnAndroid , we would have gained zero-latency fuzzing and unified compute, but we ran into deep-level technical hurdles that made it unfeasible for a production security pipeline.

The Technical Blockers: Why We Didn't Ship

1. The Bionic vs. glibc Divide

Android uses Bionic libc , while Debian relies on glibc. This is a recipe for hitting "Linker Hell." Debian looks for /lib/ld-linux.so, while Android looks for /system/bin/linker. Getting them to coexist requires more effort than I had the resources to devote to this problem.

2. Filesystem Permission Paradigms

Debian follows a traditional Linux user model (Root=0), but Android uses a Sandbox model where every app has a unique UID. We found that the Debian fuzzer would try to write test cases to a shared folder, but Android would hit an EACCES (Permission Denied) error because the Android filesystem didn't recognize the Debian "user."

3. The Bootloader and the `mmcblk0p3` Trap

Perhaps the most significant hurdle for our automation was the hardware's boot logic. To get a clean Debian environment, we often had to mess with kernel boot arguments via fastboot.

We spent days debugging errors related to /dev/mmcblk0p3. In Linux/Android, storage is represented as files. By passing root=/dev/mmcblk0p3, we were telling the kernel: "Ignore the standard Android system partition; look at Partition 3 of the internal eMMC for the Debian rootfs."

This failed for two reasons:

Partition Drift: On modern devices, p3 is often metadata or info, not the actual rootfs. We had to use cat /proc/partitions just to find where we were.
The "Live" Limitation: Using fastboot boot only loads the kernel into RAM. It doesn't persist. For a cloud-scale fuzzing fleet, we couldn't manually inject fastboot -c arguments every time a VM rebooted. Flashing the kernel permanently was too risky; if the Debian build wasn't perfect, the VM would enter a boot loop, killing our uptime.

Areas for Potential Research

While we didn't implement the "Single-VM" model, it remains a high-value optimization for mobile security research. Future efforts should focus on:

Namespace Isolation: Using Linux Namespaces rather than just a simple chroot to provide better isolation while maintaining a single kernel.
Permission Mapping: Implementing a custom FUSE mount to translate Android app UIDs to Debian-compatible permissions.
Bootloader Orchestration: Building automation that can handle persistent kernel argument injection without requiring a manual fastboot session every reboot.

Final Thoughts

Our pivot to Android-x86 was about cost constraints; the move to chroot would have been a nice to have optimization, but wasn't necessary. Fighting with fastboot for MultiMediaCard Block devies and Bionic linker errors just wasn't worth it for our team size, but that doesn't mean it couldn't be worth it for you.

The Exhausted Overachiever's Guide to Burnout

Farzon Lotfi — Tue, 28 Apr 2026 12:00:00 +0000

For an overachiever, the hardest thing to admit isn't that you're exhausted. It's admitting that you have absolutely no idea what to do next. I spent years playing a very specific character: the one who could out-think, out-work, and out-maneuver any problem. My self-worth wasn't just tied to my output; it was my output. So when burnout hit sure it drained my energy, but worse it entirely stripped away my identity. If your relentless drive that got you here has suddenly gone quiet, I need you to hear this: you have reached a necessary end of a version of yourself that was never sustainable.

The Story You’re Stuck in

In In this industry, we’re taught to define ourselves by what we can do. You’re the "DevOps guy" or the "UI specialist." That’s a narrative trap. You start to believe that if you aren't that one specific thing, you’re nothing. Your "self-narrative" is a cage you build for yourself. One based in fear where you are terrified that if you stopped being the "person with all the answers," you would lose your seat at the table. It takes self reflection to realize this story is a lie. You have to be willing to look at your professional identity and admit, "This isn't me anymore." That’s not a failure; it’s an update.

Rewrite the Story You Tell Yourself (The Power of Self-Narrative)

Your professional identity is not an unchangeable fact. You are not just "The Fixer" or the person who saves the project at the eleventh hour. Those are just roles you played. Write down the story you’ve been telling yourself. If it’s full of harsh demands and impossible standards, realize that you are the author. You have permission to write a new chapter where your value comes from your presence, your empathy, and your perspective not just your output.

Listen to the Warning Signs (The Role of Awareness)

We often ignore our own physical and emotional limits until our bodies force us to stop. We treat anxiety as an inconvenience to power through rather than a warning sign to respect.

Transformation starts with simply observing yourself without judgment. When a crisis happens at work and you feel that familiar, urgent pull to jump in and prove you’re still "smart," just pause. You don't become more valuable by making yourself more available. Notice the physical tension in your chest or your tightened jaw. That’s your ego trying to defend its territory. Awareness is finding that brief gap between a problem arising and your desperate need to fix it. Just sit in that gap and observe for now.

Lean Into the Reinvention (Embracing Discomfort)

We hate the space between who we used to be and who we are becoming. When you stop being the "Answer Guy," there is an uncomfortable void. We usually try to fill it by taking on more work, chasing a new goal, or distracting ourselves.

Don't. That discomfort is the friction of actual growth. If you feel like an imposter or a novice again, you’re exactly where you need to be. Stop trying to hustle your way out of burnout. Intentionally spend time in the awkwardness of not knowing. Go to a meeting and don't lead it. Ask a basic question. Prove to your nervous system that you don't have to be perfect to be safe.

The Pain of Tearing it Down

Reinvention sounds like a shiny, positive thing. It’s not. It’s messy and it hurts. It’s the feeling of realizing who you are doesn't fit who you’re trying to become. There’s a specific kind of vulnerability in tech when you stop pretending you’re a machine. But that’s where the "scabs" come from. You do it, you survive the transition, and you realize you didn't die.

Build Something Better with Intention (Conscious Reinvention)

Real reinvention requires letting go. You cannot just plaster over a burnt-out ego and hope for the best. You have to let the need to be the smartest person in the room die so a well-rounded human can take their place. You must pursue ego death.

This is a deliberate choice. You are deciding which parts of your old identity are worth keeping and which are just weighing you down. Identify one sharp edge of your ego maybe your defensiveness when challenged, or your need for total control and consciously choose to leave it behind. Reinvention isn't about becoming someone else; it’s about stripping away the armor to reveal someone who is approachable, resilient, and real.

Conclusion

I'm reminded of the line from Batman Begins where Thomas Wayne tells his son "Why do we fall Bruce?" Strength doesn't come from succeeding; it comes from the moments you feel completely lost. Where you don't have trust that you are still enough. Like Bruce we fall "so we can learn to pick ourselves back up again." So if you are trying to navigate through your burnout, know you will pick yourself back up. You’re in the middle of a necessary transition. Don't rush it.

The Quiet Grind: Why Talent is the Least Interesting Thing About You

Farzon Lotfi — Mon, 27 Apr 2026 12:00:00 +0000

There is a persistent myth in software engineering that we all quietly worship: the myth of the "natural."

We love the stories of the savant who can architect a billion-dollar app in their dorm room. It makes for great headlines. But if you spend enough time in this industry, staring at a terminal at 2:00 AM trying to figure out why your code keeps failing, you realize something sobering.

Talent will only get you so far. In fact, relying on talent is usually a trap.

Talent gets you through the first few years. It makes the introductory computer science classes easy. But eventually, everyone hits the wall. You encounter a bug that defies logic, a product launch that lands to total silence, or a market shift that renders your codebase obsolete.

When you hit that wall, talent is useless. The only thing that matters is resilience.

The Speed of Recovery

If you look closely at the people whose names we actually remember. The engineers who shaped the tools we use, the founders who built lasting companies; they aren't necessarily the smartest people in the room. But they are the most resilient.

Their defining trait isn't that they never fail; it's that their recovery time from adversity is vanishingly short. When a deployment goes sideways, they don't spiral into imposter syndrome. They don't spend days mourning the architecture that didn't work. They feel the sting, roll back the deploy, open the logs, and start writing the fix.

They are the people who don't spend hours on Hacker News debating the theoretical merits of a new framework. They just go build with it. Talk is cheap; execution is lonely. The most successful people have made peace with that loneliness.

Encoded in the DNA

For these people, the "grind" isn't a temporary phase you endure to get a promotion. It becomes their default state. It gets encoded in their DNA.

They show up every single day because they operate on a fundamental, unshakeable belief: if I just put in the work, better days are ahead. They don't doubt their potential. Not because they are arrogant, but because they have redefined what potential means. Potential isn't a measure of your raw intellect; it's a measure of your capacity to endure the struggle until the problem is solved.

When you realize that your ability to learn and adapt is infinite, you start to believe you are limitless. And that is why they stay winning. They outlast everyone else who quits when the novelty wears off and the real work begins.

The Long Game: Why Success is a Game of Attrition

Ultimately, the industry and life is a giant filter. It’s designed to weed out anyone who is only here for the "easy" days.

Most people are looking for a baseline of comfort. They want a career where they can rely on their initial talent, coast on what they already know, and avoid the friction of being a beginner again. But the people who stay winning, the ones who seem limitless are the ones who have made the grind their home.

They don't see adversity as a signal to stop; they see it as a diagnostic. To them, a failed project or a brutal market shift isn't a personality flaw it's just a bug that needs a patch. They don't have a special biological gift. They've just spent so much time in the trenches that their work ethic is no longer a choice. It’s encoded.

The Limitless Script

If you’re feeling like you’re hitting a wall, or like your "talent" has run dry, good. That’s where the real work begins.

Stop talking about what you’re going to build. Stop waiting for the moment where you finally feel "ready" or "talented enough" to compete. That moment doesn't exist. There is only the daily build, the recovery from the inevitable crashes, and the quiet, persistent belief that better days are a mathematical certainty if you refuse to exit the chair.

Success isn't about being the smartest person in the room. It’s about being the one who is still there when everyone else has gone home.

Show up. Ship. Repeat. That’s how you stay in the league.

The Big Tech Pivot: Why a Buyout Isn't an End, It's an Opening

Farzon Lotfi — Sun, 26 Apr 2026 12:00:00 +0000

Right now, a palpable sense of anxious terror is vibrating through our engineering floors. Microsoft is offering thousands of voluntary buyouts. Meta is axing jobs to fund a staggering $135 billion pivot into AI infrastructure.

When you are staring at a buyout package on your own desk, you have a choice to make about how you frame your reality. You can view yourself as a victim of a collapsing market, and if you do, that will become your reality. You will see a tragedy, a corporate betrayal, and a door closing.

But there is a second option. You can choose to view this not as a funeral, but as a strategic opening. Your reality is dictated by how you frame this moment. If you are sitting in an existential waiting room right now, stomach in knots, let me offer the frame of the opportunist: Your career isn't over. In fact, if you play this right, you might be stepping into the most powerful strategic position of your life.

The Brutal Math: Software is Going to Zero

To understand the opportunity, you have to look at the undeniable economic reality driving these buyouts: The marginal cost of standard software engineering is rapidly dropping to zero.

For 50 years, code was a premium, scarce asset. We built our compensation models around being the highly paid gatekeepers of this complex resource. But now, we are staring down the barrel of swarms of specialized AI agents collaborating autonomously to write, test, and deploy entire architectures. Within the next 24 months, it is highly probable that autonomous systems will generate more code than all of humanity has in the history of computing.

You cannot out-work, out-hustle, or out-code a $2.52 trillion capital rotation into silicon. When a market is intentionally flooded with artificially cheap, AI-generated code, the premium value of raw human output collapses. This is the brutal math driving the layoffs and the buyout packages.

The Great Headcount Migration

For those that remain you need to understand Big Tech isn't "running out of money" they are aggressively migrating their human capital.

Companies like Google and Microsoft are moving their best minds out of teams like Gmail and Office and onto teams like Gemini and Azure AI. As they chase the AI infrastructure crown, they are leaving their core, "solved" products the platforms that fund this CapEx in maintenance mode.

IP Without Architects

The migration of human capital to new projects means Big Tech is currently sitting on mountains of intellectual property they no longer have the organizational focus to evolve. They have the IP, but they are losing the architects.

The Big Tech Pivot (And Their Strategic Gap)

This brings us to the most important strategic shift of our generation. Big Tech is no longer fighting to be the best pure-software provider; they are pivoting to become the foundational AI infrastructure layer for the globe. They want to sell the compute, the agents, and the LLMs.

But the pivoting into AI infrastructure also exposes a massive flank. As they pour hundreds of billions into server farms, the historical revenue drivers also become increasingly easier to replicate. This creates a strategic gap, leaving their core software products vulnerable to more agile competition.

The Silver Lining: The Great Equalizer

This is where you come in. Here is the beautiful, unintended consequence of Big Tech's pivot: By subsidizing the cost of AI infrastructure to capture the market, they have dropped your barrier to entry to zero. You don't need an army of 500 engineers to build a leaner, faster alternative to a Microsoft or Google product anymore.

You just need the exact same AI agents that your former employer spent billions to build and subsidize. You are not leaving your domain expertise behind. You built these systems. You know the architectural constraints and the underlying tech debt.

You know exactly where the friction points are for end-users. You can use Big Tech's own subsidized AI infrastructure to build focused, pure-software products that compete directly in the spaces they are currently deprioritizing. In a way it is kind like malicious compliance.

The Seed Funding Reframe

Let’s be honest: a buyout package isn’t life-changing money. It isn’t a VC war chest that will last you long. But calling it "seed funding" is a necessary psychological hack.

When you label it "severance," your brain chemistry defaults to fear and preservation. When you label it "seed funding," you move into optimism. It forces you to stop thinking like a discarded employee and start thinking like the builder you’ve always been. It is a grant that buys you the time to return to the craft on your own terms.

Conclusion: Choose Your Reality

Your reality is how you frame this moment. A buyout isn't a winning lottery ticket, but it is a release from the "existential waiting room." You are an insider armed with domain expertise, a laptop, and a subsidized AI toolkit that levels the playing field in ways that were impossible five years ago.

A Retrospective on Fuzzing Edge for Android: Looking beyond the Emulator

Farzon Lotfi — Sat, 25 Apr 2026 12:00:00 +0000

When I was the head of Microsoft's Edge security for the US market, we ran into an infrastructure challenge that forced us to completely rethink how we fuzzed Android.

The project we built no longer exists at Microsoft, and the Android-x86 project we relied on is now officially dead and unsupported. However, the architectural pivot we made to get around cloud compute constraints remains a novel approach to Android fuzzing—one that solved a myriad of technical headaches while drastically cutting costs.

Here is a look back at how we bypassed the Android Emulator entirely to find better, real-world bugs.

The Catalyst: Losing Nested Virtualization

Fuzzing has always been a core focus of the Edge security posture. Using our own tooling alongside open-source frameworks, we achieved millions of fuzz hours per month across desktop environments. But doing this at scale for Android always presented unique friction.

In 2022, that friction hit a boiling point. Due to cost-cutting measures, our fuzzing budgets were reduced. We had to migrate off of public Azure to the Microsoft 365 substrate for both security and cost reasons. The unintended side effect of this migration was a severe reduction in our quota for CPU cores that supported nested virtualization.

Without nested virtualization, running the standard Android Emulator in the cloud was impossible. We needed a workaround.

Why the Android Emulator Was Failing Us Anyway

Losing the ability to run the emulator initially felt like a massive blow, but in retrospect, the emulator was already polluting our fuzzing efforts. When we fuzzed on the emulator, we spent a massive amount of time triaging crashes that had nothing to do with Edge.

The emulator suffered from several fatal flaws for our use case:

QEMU-Specific Code Paths: Many bugs we found hit qemu-specific emulation paths that a real-world mobile user would never actually experience.
Driver Crashes: The emulator frequently hit nvoglv64.dll, an Nvidia driver bug that would simply crash the emulator outright.
The Swiftshader Timesink: The only way to stop the Nvidia crashes was to enable Swiftshader for the emulator. However, Google had already deprecated Swiftshader, meaning any bugs we found there were a complete waste of time to report or investigate.

We needed a solution that tested real Android code paths, avoided emulation artifact bugs, and didn't require nested virtualization SKUs.

The Solution: Direct-to-Azure Android-x86 VHDX Images

To solve the compute constraint, we turned to the Android-x86 project. Instead of emulating Android hardware, we built Android-x86 .vhdx images and uploaded them directly to Azure to run as standalone VMs. (For a look at the mechanics of this, there is a great breakdown on running Android inside Azure here).

Because we were running standard VMs instead of nested virtualization SKUs, our compute costs plummeted. We could suddenly run two Android-x86 VMs for every one Android Emulator VM we previously ran.

In the short term, the development time required to create the images and establish communication protocols was slightly higher than just spinning up an emulator. But the image creation and communication processes ended up being a massive success. The long-term Azure cost reductions eventually set a model for the rest of Edge.

Decoupling the Architecture

Running standalone Android-x86 instances meant we could no longer run our test case generators, HTTP servers, and browser automation on the same VM as the target—something we took for granted on Windows and Linux.

To adapt, we decoupled the architecture. We built a new producer-consumer model where a robust Linux server handled the heavy lifting of generating test cases. The Android-x86 VMs acted purely as headless consumers, utilizing Mozilla's Grizzly framework to handle the browser automation.

Use of android adb tools worked really smoothly after all of this

By pushing our ASAN (AddressSanitizer) builds of the full Edge browser to these VMs, we maximized our chances of finding both security and reliability issues.

The Takeaway

Even though Android-x86 was an older version of Android than what was available via the emulator, the net result was surprising: we found more real-world bugs in the browser.

I even found one that someone beat me to fixing.

By being forced off of nested virtualization, we accidentally cured our emulator-noise problem. The project may be sunsetted today, but it stands as a great example of how strict budget and infrastructure constraints can force security teams to build leaner, smarter, and ultimately more effective testing environments.

MemGC: A Retrospective on a Bygone Frontline of Browser Security

Farzon Lotfi — Fri, 24 Apr 2026 11:00:00 +0000

Looking back at my time on the Chakra and the OG Edge team, few projects I had the opportunity to work on feel as consequential to my development as an engineer as my opportunity to work on MemGC (Memory Garbage Collection). In the 2014-16 time period the largest amount of security bugs filed against Internet Explorer were Use-After-Frees (UAFs).

MemGC was our architectural response: a garbage collector designed not just for performance, but as a hard security boundary. It was good enough that it recieved praise from Google project zero: "MemGC is an example of a useful mitigation that results in a clear positive real-world impact". I do love quoting this 😂.

The Core Idea: Turning UAF into a GC Problem

Before MemGC, we tried mitigations like Isolated Heap and Delay Free. They were clever "band-aids" that made exploitation harder but didn't solve the root cause. If a developer forgot to null a pointer after a free(), the door remained open.

MemGC changed the game by bringing the Concurrent Mark-Sweep (CMS) algorithm from the JavaScript engine (Chakra) into the heart of the DOM. We essentially built a safety net:

Reference-based Lifetime: Instead of manual free() calls, objects were only reclaimed when the GC could prove no references to them remained.
The Conservative Scan: We treated the stack and registers conservatively. If a value looked like a pointer to a MemGC object, we kept that object alive. This effectively killed "immediate" UAF exploits.

What it Was Good At: Structural Defenses

From a developer’s perspective, MemGC was incredibly successful at "Vulnerability Class Elimination."

Automation of Safety: It removed the cognitive load from DOM developers. The GC handled the cleanup of complex DOM nodes automatically.
Performance Balance: By using a concurrent mark-sweep, we kept the UI thread responsive while the GC did the heavy lifting on a background thread.
Heap Integrity: The data structures we used, like the HeapBlock32Map, allowed us to quickly determine if an address was a valid object start, preventing many "middle-of-object" pointer tricks.

Where it Failed: The "Blind Spots"

No mitigation is perfect. As developers, we had to confront the reality that hackers are just as creative as we are. One of the most interesting "failures" was a limitation in visibility between different engine components.

As detailed in the "Seeing Double" research, we discovered that having separate "Chakra" and "DOM" heaps created a blind spot. The Chakra recycler didn't always have visibility into allocations on the DOM heap, and vice versa. If a pointer to a Chakra object was stored in a buffer on the DOM heap, the Chakra GC might not "see" it, leading to a UAF despite the protection.

Furthermore, killing UAF simply pushed attackers toward Type Confusion. MemGC ensured the memory was there, but it couldn't ensure the memory was being interpreted as the correct type.

Lessons for Today’s Developers

If I were building a new engine today, what would I take from the MemGC era?

Defense in Depth: MemGC works best when paired with modern mitigations like Control Flow Guard (CFG).
The Precision Problem: Conservative scanning prevents UAF but can cause memory leaks. Precise GC is the gold standard for modern systems.
Language Safety: MemGC was a heroic effort to make C++ safe. Today, we should look toward Rust for compile-time safety guarantees.

Final Thoughts

MemGC was a milestone in browser security. It forced attackers to abandon their favorite exploits and move into much more difficult territory. For those of us who built it, it remains a proud example of weaponizing computer science for defense.

References:

The ROI of Irrationality: What Grad School Actually Taught Me

Farzon Lotfi — Thu, 23 Apr 2026 15:00:00 +0000

I went to graduate school to specialize in computer graphics. I came out of it to find a job market that had practically vanished.

If I had listened to the conventional wisdom of the time, I would have pivoted. I would have cut my losses, updated my resume to reflect a safer trajectory, and moved on. For a time I did do just that and pivoted to computer security. But I realized it would be better to dig my heels in and commit to the career I wanted. Today, I have that career. But let’s be entirely clear: it wasn’t the institution or the degree that got me here. It was sheer, unadulterated stubbornness.

Looking back on that journey, there are a few hard truths about goals, higher education, and the absolute necessity of refusing to compromise.

The Danger of Being "Rational"

Throughout my life, I have developed a deep resentment for the advice to "be rational." We are constantly told to temper our expectations, play the percentages, and have a pragmatic fallback plan.

Here is the reality: in a world of eight billion people, rationality is just a mathematical formula for settling. To truly believe that you deserve to occupy a highly specific, fiercely competitive niche, you cannot be rational. You have to be deeply irrational. You need to possess a healthy streak of delusion to look at the impossible odds, the closed doors, and the saturated markets and decide, “Yes, that spot still belongs to me.” Rationality protects you from disappointment, but it also completely insulates you from your own potential.

The Illusion of the Academic Pipeline

We also need to have an honest conversation about the current state of higher education. It is time to acknowledge that much of academia has evolved into a heavily institutionalized enterprise that frequently extracts far more financial and temporal value from its students than it returns. It has become a systemic sinkhole, operating on a timeline fundamentally disconnected from the velocity of modern industry.

If you are relying on a core curriculum to prepare you for the cutting edge, you are already years behind. Too much of the standard coursework is a parade of outdated concepts and irrelevant syllabi that no longer apply to the real-world demands of tech or art. Ironically, the only classes reflecting the true, current state of the field are the "Special Topics", the seminars, and the elective. The very courses that the university administration rarely allows to count toward your actual degree requirements.

Learning is still essential, but we must recognize it for what it truly is: the continuous act of self-creation. Today, LLMs and Youtube can deliver raw information far more efficiently than a lecture hall, which means your intellectual evolution must be self-authored. A syllabus offers no armor against the future. The only real measure of a course's worth is whether it permanently alters the architecture of your thinking.

The Saving Grace: Research

There is one major caveat to this critique. The beating heart that keeps the academic body alive and the only reason it is still worth navigating is the research.

My saving grace in graduate school was securing a Graduate Research Assistantship (GRA). That was where the real education happened. Away from the archaic lectures and standardized rubrics, research is where you actually touch the boundary of what is possible. It is the one space left in the university ecosystem where discovery and innovation are prioritized over bureaucracy. If you are going to go to grad school, go for the research. Everything else is just noise.

Stubbornness as a Strategy

I didn't get my career because a piece of paper guaranteed me a spot in computer graphics. I got it because I refused to let an empty job market dictate my trajectory. The system is not designed to hand you your dream; it is designed to process you.

If you have a vision for your life, guard it fiercely against the "rational" advice of the masses. Take the research experience, absorb the uncredited special topics, and leave the bureaucratic friction behind. At the end of the day, your success won't be a product of the institution. It will be a testament to your refusal to quit.

The Benchmarks of a Ghost Ship: On Knowing When to Walk Away

Farzon Lotfi — Wed, 22 Apr 2026 12:00:00 +0000

In the world of software engineering, we are raised on a diet of pure meritocracy. We believe that if our algorithms are faster, our latency lower, and our architecture more elegant, we win. We treat the codebase like a sanctuary where logic is the only law.

But I’ve spent my career building cathedrals in sinking cities, and if there is one thing I’ve learned, it’s that the most brilliant code in the world cannot save a product whose time has passed or one that never found its timing at all.

The Chakra Paradox: Winning the Wrong Race

During my tenure on the Chakra JavaScript compiler team at Microsoft, we did the "impossible." We went toe-to-toe with Google’s V8 and, by the metrics of the Octane, jetstream, & sunspider benchmarks, we won.

We built a world-class engine a feat of JIT optimization and memory management that could have defined the next decade of the web. Chakra was ahead in ES6 conformance and had elegant security mitigations like MemGC that even got the praise of Google project zero :

"It is also interesting to observe the effect of MemGC, a use-after-free mitigation in Internet Explorer and Microsoft Edge. When this mitigation is disabled using the registry flag OverrideMemoryProtectionSetting, a lot more bugs appear. However, Microsoft considers these bugs strongly mitigated by MemGC and I agree with that assessment. Given that IE used to be plagued with use-after-free issues, MemGC is an example of a useful mitigation that results in a clear positive real-world impact. Kudos to Microsoft’s team behind it!"

But while we were winning the technical battle, the war was already over. Microsoft had split the browser’s soul in two, drifting between the legacy of Internet Explorer and the fresh start of Edge. We were optimizing a masterpiece while the gallery was being demolished. It didn’t matter that our tech was superior; the market had moved, the trust had eroded, and the remaining market share was evaporating.

The Lesson: You can be the best in the world at something that no longer matters.

The Patent Trap: Groundbreaking vs. Market-Ready

I saw the same ghost appear again at Ionic Security. We weren’t just building another app; we were creating groundbreaking security infrastructure. I have the patents to prove it. I have tangible evidence of innovation in its purest form. We solved problems others hadn't even identified.

Yet, a startup is a race between discovery and exhaustion. We had the breakthrough, but we couldn't find the "problem-shaped hole" in the market to fit it into. We had a solution in search of a customer base that wasn't ready to change. Again, I found myself holding a piece of "superior" technology that was destined to sit on a shelf.

The Philosophy of the "Clean Exit"

When you pour your life into a compiler or a startup, "giving up" feels like a betrayal of your own craft. We fall into the Sunk Cost Fallacy, believing that if we just optimize one more path or secure one more patent, the world will finally wake up and see the merit.

But there is a profound difference between failing and being a failure. Here is the framework I've adopted:

The Code is Ephemeral, the Engineer is Permanent: Chakra and Ionic were just containers for my growth. The containers leaked, and eventually, they broke. But the liquid, the expertise, the resilience, the ability to solve the "unsolvable" is still mine. I'm reminded of Bruce Lee "Be like water my friend."
Context is King: You can write the most efficient loop in history, but if the power is cut to the building, the loop doesn't run. Moving on isn't an admission of poor quality; it’s an admission of changing context.
Meaning vs. Utility: Just because a project didn't achieve market dominance doesn't mean it wasn't meaningful. The patents exist. The benchmarks were hit. The bridge was built perfectly; it’s not the engineer’s fault if the river changed course.

Knowing the Hour

The hardest skill to learn in tech isn't a new language especially with LLMs these days; it’s the ability to look at a "perfect" piece of work and realize it’s time to walk away. We often stay too long because we want the world to validate our effort. We want the market share to reflect our IQ.

The world doesn't owe our code a living. When you realize the ship is split in two, or the customers aren't coming, the most logical thing you can do is take your tools and find a new shore.

You aren't abandoning your work. You are preserving your talent for a place where the wind is actually blowing. I have suffered from sticking around too long in the past. My rule for the last few years is give everything 18 months. If its still fun and you are seeing success stick with it. If you feel stuck move on.

The "Certainty Tax": Why Big Tech Will Never Use Wine or Darling for CI

Farzon Lotfi — Tue, 21 Apr 2026 23:30:00 +0000

In the world of DevOps, there is an obvious, glaring financial inefficiency: macOS and Windows VMs are a rip-off. If you’re running GitHub Actions or CircleCI, a macOS runner can cost you 10x more per minute than a standard Linux runner. For a Fortune 500 company running thousands of builds a day, that bill is staggering.

Theoretically, tools like Wine (for Windows apps) and Darling (for macOS apps) offer a "cheat code". They allow you to run native apps on dirt-cheap Linux hardware.

Yet, big corporations won't touch them. They’d rather set piles of cash on fire paying for native VMs. Why? Because in the modern era of software, predictability is more valuable than capital.

If you read my last two (one & two) blog posts on using Wine and Darling for testing the conclusion of this post will surprise you. I know I left you with the impression that I am recommending putting these tools into your CI workflows. That is far from the truth. I think they help speed up development but should not be relied on up for behavioral correctness if you have the resources of big tech and I will explain why.

1. The Death of the 80/20 Rule

We used to live by the Pareto Principle: focus on the 20% of code that handles 80% of the use cases. In the "99% Era," that logic is professional negligence.

When you have 100 million users, a "1-in-a-million" edge case happens 100 times a day. As scale increases, the "Long Tail" of software becomes the "Main Body."

If Wine has a slight discrepancy in how it handles a specific Windows GDI+ drawing call, and that discrepancy leads to a crash on actual Windows 11 hardware, you haven't saved money. You’ve just created the enviornment for a catastrophe.

For a giant like Adobe or Microsoft, an app that is "99% compatible" with its host OS is effectively broken.

2. The Law of Leaky Abstractions

In one of my favorite essay, The Law of Leaky Abstractions, Joel Spolsky noted that all non-trivial abstractions are, to some degree, leaky.

Wine and Darling are masterpieces of engineering, but they are cleanroom abstractions. They mimic how an OS should behave, not necessarily how it does behave under the stress of weird drivers, specific kernel patches, or proprietary Apple silicon quirks.

Corporations aren't just paying for a runner; they are paying for Environmental Parity. They need to know that if the code passes in CI, it will pass on a customer’s laptop.

The moment you introduce a translation layer, you introduce a "parity gap." If a test fails, your engineers now have two problems:

Is the app broken?
Or is the abstraction (Wine/Darling) broken?

Big Tech hates "fixing the test infrastructure" more than it hates high compute bills.

3. The Math of Risk: Why 99.9% is a Failure

To a startup, 99.9% uptime (three nines) sounds like a dream. To Amazon, it’s a nightmare.

99.9% Uptime = 8.77 hours of downtime/year.

The Cost: With Amazon’s revenue, an hour of downtime can cost upwards of $65 million.

If using a native Windows VM instead of Wine reduces the risk of a "blind spot" bug by even 0.01%, the VM has already paid for itself a thousand times over.

Corporations have a low-risk tolerance because their blast radius is massive. A botched release doesn't just annoy a few users; it triggers thousands of support tickets, legal SLA credits, and a permanent stain on brand equity.

4. The "Certainty Tax"

Ultimately, big corporations view expensive CI costs as a Certainty Tax.

They aren't looking for the most "clever" way to run a test; they are looking for the most "boring" way. A native macOS VM is boring. It is predictable. It is supported by a multi-billion dollar vendor you can escalate to if it breaks.

Wine and Darling are for the tinkers, the innovators, and the budget-conscious indies. But for the giants, the goal isn't to save a few pennies on compute. The goal is to ensure that when they hit "Deploy," the world doesn't break.

Forem: Farzon Lotfi

The Geometry of Dragon Ball: A Deep Dive into SDFs and Raymarching

1. Defining the Stars (2D SDFs)

2. Extrusion and 3D Modeling

3. The Raymarching Engine

4. Optical Physics: Refraction & Reflection

5. Analytical Caustics & Chromatic Aberration

The "Secret Sauce": Why This Works

Conclusion

The Hardest Problem in Engineering Isn't Code (It’s Communication)

The Art of Engineering "Inception"

Mirroring: Let Them See Themselves in You

Building the Muscle: Why I Write

Finding Your Voice

The Architecture of Service: Reclaiming the Soul of Technology

An Android Fuzzing Retrospective Part II: The "Single-VM" Theory and the Bionic Wall

The Theoretical Efficiency: Debian via Chroot

The Technical Blockers: Why We Didn't Ship

1. The Bionic vs. glibc Divide

2. Filesystem Permission Paradigms

3. The Bootloader and the mmcblk0p3 Trap

Areas for Potential Research

Final Thoughts

The Exhausted Overachiever's Guide to Burnout

The Story You’re Stuck in

Rewrite the Story You Tell Yourself (The Power of Self-Narrative)

Listen to the Warning Signs (The Role of Awareness)

Lean Into the Reinvention (Embracing Discomfort)

The Pain of Tearing it Down

Build Something Better with Intention (Conscious Reinvention)

Conclusion

The Quiet Grind: Why Talent is the Least Interesting Thing About You

The Speed of Recovery

Encoded in the DNA

The Long Game: Why Success is a Game of Attrition

The Limitless Script

The Big Tech Pivot: Why a Buyout Isn't an End, It's an Opening

The Brutal Math: Software is Going to Zero

The Great Headcount Migration

IP Without Architects

The Big Tech Pivot (And Their Strategic Gap)

The Silver Lining: The Great Equalizer

The Seed Funding Reframe

Conclusion: Choose Your Reality

A Retrospective on Fuzzing Edge for Android: Looking beyond the Emulator

The Catalyst: Losing Nested Virtualization

Why the Android Emulator Was Failing Us Anyway

The Solution: Direct-to-Azure Android-x86 VHDX Images

Decoupling the Architecture

The Takeaway

MemGC: A Retrospective on a Bygone Frontline of Browser Security

The Core Idea: Turning UAF into a GC Problem

What it Was Good At: Structural Defenses

Where it Failed: The "Blind Spots"

Lessons for Today’s Developers

Final Thoughts

References:

The ROI of Irrationality: What Grad School Actually Taught Me

The Danger of Being "Rational"

The Illusion of the Academic Pipeline

The Saving Grace: Research

Stubbornness as a Strategy

The Benchmarks of a Ghost Ship: On Knowing When to Walk Away

The Chakra Paradox: Winning the Wrong Race

The Patent Trap: Groundbreaking vs. Market-Ready

The Philosophy of the "Clean Exit"

Knowing the Hour

The "Certainty Tax": Why Big Tech Will Never Use Wine or Darling for CI

1. The Death of the 80/20 Rule

2. The Law of Leaky Abstractions

3. The Math of Risk: Why 99.9% is a Failure

4. The "Certainty Tax"

3. The Bootloader and the `mmcblk0p3` Trap