June 21st, 2026

Apologies for missing last week, I've been working on a project, as well as being in the middle of a leave of absence from work to focus on some family/personal stuff so I kind of missed writing the blog.

Articles of the week

This week I picked up these articles:

Learned/Notes

AI demands more engineering discipline. Not less.

I had read maybe 1-2 articles from Charity Majors and it hadn't clicked for me that she was deep in the SRE/DevOps world. I really liked this blog and plan on keeping up with what she writes from now on!

Charity's main argument is one I never heard put this way: The economics of writing code have completely flipped. Code used to be expensive to produce. Now it's effectively free and instant. That changes everything. She compares it to infrastructure: we've had tools like Kubernetes and Terraform for a while that let us destroy and recreate infra from a spec. Her point is that code should be heading in the same direction — if you can define your architecture and behavior clearly enough, you should be able to regenerate the code from scratch.

The question she leaves towards the end is the one that stuck with me the most: if you destroyed your codebase today, does your spec contain enough information to regenerate it and get the same behavior? When I thought about my own project(s), the honest answer was no. For the most recent project I'm working on: I've been defining the API, the database schema, the service logic — but my tests came after, not before. Front-end I'm testing by hand, thinking of what automated tests to add. I'm guilty of following the bad practices from our industry D:

The three things she says you actually need are tests that capture behavior, observability that tells you what your system is doing, and architecture definitions detailed enough to hand to AI and get the same code back. I have a lot to think about regarding this, but I definitely agree this is where we're heading and how it should be.

Loop Engineering: Designing Systems That Prompt

I saw 'loop engineering' pop up in my feeds a few times this week, which is usually a sign I should read it. Before reading, I guessed it was about agents looping through a task nonstop — it kind of is? But the full picture is more interesting.

The article traces how we got here: LLMs → reasoning models → agent engineering (where MCPs and tools gave models the ability to access literally anything we want them to access) → loop engineering. The idea behind loop engineering, which apparently comes from Addy Osmani (he has a blog on this I want to read), is that instead of you being the operator who kicks off systems in the morning, you design workflows that run themselves — triggered by cron jobs, schedules, events.

The example that clicked for me was something I could apply at work: imagine automating ticket creation — scanning epics, checking the backlog for missing stories, generating a report for review, then moving forward once approved. I'd still be in the loop for sign-off, but the agent handles the grunt work. The key is that each step needs to be something that genuinely doesn't require me — that's harder than it sounds.

I'm still cautious about the "let it run forever" version of this. My brain goes to: what happens when something breaks or I need to change it? If I can't understand what it built, I'm stuck. But for well-scoped, repeatable workflows? I think it's real and I want to start experimenting.

Nine Questions I Now Ask in Interviews That I Wish I'd Asked Five Years Ago

I already have a short mental list of questions I ask companies — why are you hiring, what's the culture around learning, things like that. But Louise's questions are sharper. They're designed to surface red flags.

A few that I'm adding to my list immediately:

  • "Can you walk me through the last time someone on this team got promoted?" — If they can give you a concrete example, they have a real process. If they say something like "we do reviews twice a year," that's a yellow flag (big corpos where IMO politics are very important and that I want to get away from). If they say they don't know, run.
  • "What's something the team is genuinely bad at?" — You'll know immediately if you're getting an honest answer or a rehearsed one.
  • "What does success AND failure look like in 6 months?" — I think the best way to ask this one is to ask about success, and then follow up with a question about failure. A team that can't describe failure clearly probably hasn't thought hard about expectations.
  • "Who would I be working with most closely, and can I talk to them?" — Hesitation here is a signal. If they make it weird to talk to potential teammates before you join, imagine what it's like once you're inside.

Louise frames some of these as "trapdoors" and others as "diagnostic," and I think that's the right way to think about them. You're not just gathering info — you're watching how they handle the questions. That alone tells you a lot.

Why is Meta destroying its engineering org?

Meta has been producing a lot of headlines lately — layoffs, weird policy changes, people gaming metrics, constant re-orgs. I wanted to understand if any of this has a coherent reason behind it or if it's just chaos.

Gergely does a great job going through the culture's history. Meta's original culture was "move fast and break things" — I think it truly drove how fast they grew and the massive engineering that company has produced. By the time they had a billion users, they had built a culture of fast experimentation that let them stay competitive and build a lot of the things they're still known for.

What's happening now is a combination of things: AI pressure from the top, the Scale AI acquisition bringing in Alexandr Wang (29 years old and already a billionaire — insane), pushing engineers into data labeling workflows they didn't sign up for, tracking keystrokes and AI usage, and all the fallout from a high-profile account hack that made the CISO (who had been there 13 years) leave.

The interviewing.io data point was wild to me — they saw huge spikes in engineers from Meta trying to leave starting in May 2026. That's a real signal, not just gossip.

My take: the people who built something together don't have to be the same people who build what comes next. If Meta is genuinely pivoting toward something new, some of this friction might be necessary even if it's painful for the people caught in the middle. But forcing people into workflows they didn't agree to and tracking how they use their computers? That's just ew. They're already reversing some of the decisions, which I think is good and the way to go for them.