If we don’t address that soon, AI will do exactly what we’ve taught it to — lie, obscure, find workarounds. Faithfully, at scale, without question.

But here’s what’s been rattling around my head: the lying problem is bad, but then when you add decision-making on top of that? Catastrophic.

Because when AI gets the truth wrong, someone gets a bad answer. When AI gets a decision wrong — a real, consequential, someone-lives-or-dies decision — the stakes aren't hurt feelings. They're body bags.

And we’re already there.

So let’s talk about the trolley problem. And let’s talk about what happens when the thing standing at the lever is AI.

The Thought Experiment

A runaway trolley is heading toward five people tied to the tracks. You’re standing next to a lever. Pull it, and the trolley diverts to a side track — but there’s one person tied to that track instead. Do you pull the lever?

It’s been debated for decades. There’s no clean answer. That’s the point.

But here’s what makes the trolley problem more than a university thought experiment: it forces you to make your decision framework explicit. You can’t hide behind intuition. You have to choose — and you have to be able to say why.

Now imagine the lever is a function call.

When Ethics Becomes Code

The moment you build an AI system that makes decisions affecting human safety — autonomous vehicles, medical triage, resource allocation during a crisis — you are solving the trolley problem. Except you’re solving it in advance, in code, without knowing who’s on the tracks.

This is fundamentally different from a human making a split-second moral judgement. A human freezes, panics, acts on instinct, lives with the consequences. They carry the weight of that decision forever.

An AI system doesn’t freeze. It evaluates. It runs inference. It moves to the next request.

And someone — a developer, a product manager, a committee — decided the rules it would follow. They wrote the trolley problem’s answer into a probabilistic dataset.

Remember what I said last time about companies being the ones who decide where the edges are? That was about truth. This is about life and death. Same companies. Same meetings. Same companies now encoding who matters more than whom.

That should concern us. Not because AI is evil, but because we’re encoding moral philosophy into production systems and pretending it’s an engineering problem.

The Scenarios: From Clear to Murky

The trolley problem isn’t just one dilemma. It’s a spectrum. And the further you move along it, the harder it gets — and the more it looks like the decisions AI systems actually face.

Scenario 1: The Lever (Clear Cause, Clear Effect)

The classic. Five people on one track, one on the other, you pull a lever. The cause is direct, the effect is immediate, and the maths is simple: five lives versus one.

Most people pull the lever. Most AI systems would too. This is the easy version.

The AI equivalent: A self-driving car detects five pedestrians in its path and one on an alternative route. Clear sensor data, high confidence, binary choice. The system swerves. This is the scenario the industry likes to discuss because it has a defensible answer.

Scenario 2: The Footbridge (Direct Physical Harm)

You’re standing on a bridge above the tracks. The only way to stop the trolley is to push someone off the bridge and onto the tracks. Their body stops the trolley. Same outcome — one dies, five live — but now you are physically causing someone’s death, not redirecting a machine.

Most people won’t push. Even though the numbers are identical. The moral calculus changes when the harm is direct and personal rather than indirect and mechanical.

The AI equivalent: An algorithm that actively selects a specific person to harm rather than redirecting risk. Think of a triage system that doesn’t just prioritise patients — it actively deprioritises one, knowing they’ll die as a direct result. The outcome is the same as allocation, but the mechanism feels different. And that feeling matters, because it’s the difference between “the system optimised resources” and “the system chose to let someone die”.

Scenario 3: The Transplant (Active Harm for Greater Good)

A doctor has five patients who will die without organ transplants. A healthy person walks in for a check-up. If the doctor kills the healthy person and harvests their organs, five people live. Same maths as the lever. One dies, five live.

Almost nobody would do this. But why? The numbers are the same. The difference is consent. The healthy person didn’t agree to be part of the equation. They walked into a system that was supposed to help them, and it sacrificed them instead.

The AI equivalent: A medical triage algorithm during a pandemic. It’s allocating ventilators, ICU beds, treatments. And its criteria — survival probability, age, pre-existing conditions — almost always correlate with demographics. The system is effectively deciding that some lives are worth less than others. It just does it with a confidence score instead of a scalpel.

Scenario 4: The Uncertainty (Unclear Cause, Unclear Effect)

Same trolley, but the side track disappears into fog. You think there might be one person on it. Maybe none. Maybe three. You can see the five people clearly. Do you still pull the lever?

This is where most real-world AI decisions actually live. Not in the clean binary of five-versus-one, but in probability distributions and incomplete information.

The AI equivalent: A medical AI recommending treatment based on partial data. A patient presents with ambiguous symptoms. The AI assigns probabilities: 60% chance it’s condition A (treatable, low risk), 25% chance it’s condition B (serious, needs immediate intervention), 15% chance it’s something else entirely. The doctor follows the AI’s top recommendation. It was condition B.

Who’s responsible? The AI that gave a probabilistic assessment? The doctor who followed the most likely option? The hospital that deployed a system making recommendations on incomplete data? The patient, for having ambiguous symptoms?

Nobody. And that’s the problem. When the cause is unclear and the effect is uncertain, accountability evaporates.

Scenario 5: The Identity Problem (When You Know Who’s on the Tracks)

Back to the original trolley, but now you know the people. The one person on the side track is a child. Or your parent. Or a Nobel laureate. Or a convicted murderer. Does it change your answer?

For most people, it does. And that’s the quiet horror of AI bias.

The AI equivalent: AI systems don’t see people — they see probability distributions. A self-driving car doesn’t see “a child” and “an elderly person”. It sees confidence scores on object classifications. A pedestrian detection model doesn’t think “that’s a human being”. It thinks “92% confidence: pedestrian. 74% confidence: pedestrian”.

That 74% confidence pedestrian? Maybe they’re wearing unusual clothing. Maybe their skin tone doesn’t match the training data well. Maybe they’re using a wheelchair and the model wasn’t trained on enough examples of wheelchair users. Maybe they are a well recognised politician whose life they rate more highly than the average person.

The system doesn’t have to be racist or ableist. It just has to be less certain about some people’s existence than others. And if certainty feeds into life-or-death decisions, bias becomes lethal.

This connects directly to what I wrote previously about truth being probabilistic. We said “where’s the lie?” when AI hedges on moral questions. But what about when it hedges on whether someone exists?

Scenario 6: The Slow Trolley (Distributed Harm Over Time)

The trolley isn’t barrelling down the tracks at speed. It’s moving slowly, hitting people gently but consistently, over months and years. No single impact is fatal. The cumulative effect is devastating. And nobody can point to the moment it became a crisis.

The AI equivalent: Content recommendation algorithms that gradually radicalise users. Credit scoring systems that systematically disadvantage certain postcodes. Predictive policing that creates feedback loops, over-policing areas that were already over-policed, generating more data that confirms the original bias.

No single decision kills anyone. The aggregate effect destroys communities, opportunities, lives. But there’s no lever to point at. No single moment of choice. Just a system doing exactly what it was optimised to do, one small inference at a time.

Scenario 7: The No Decision (When Inaction Kills Everyone)

You’re responsible for 100 people in a sealed environment. A submarine. A space station. A bunker. Something’s gone wrong, and you have just enough oxygen to keep 90 of them alive until rescue arrives. If you try to save all 100 — if you distribute the oxygen equally, democratically, fairly — every single one of them dies.

You don’t get to choose who’s on the tracks. You don’t get to weigh one life against five. You have to choose between making an awful decision and making no decision at all. And the no decision option is the one that kills everyone.

This is the scenario that breaks people. Because it’s not about the maths anymore. It’s about whether you’re willing to be the person who decided. Whether you can live with “I chose to save 90” when someone will always ask “why not my 10?”

The AI equivalent: Resource allocation during a crisis. A pandemic hits and there aren’t enough ventilators. An AI system could triage — ruthlessly, efficiently, without the emotional paralysis that makes humans freeze — and save the maximum number of people. Or we could insist on human decision-making, watch committees debate while patients deteriorate, and lose people we didn’t have to lose because nobody wanted to be the one who made the call.

During COVID, hospitals faced exactly this. And in many cases, the absence of clear decision frameworks — the reluctance to make the awful call — cost more lives than any triage algorithm would have.

And then the question that makes it truly unbearable: who decides which 10 don’t make it?

The person in charge? Based on what — age? Health? Who they like? Who arrived last? A lottery? Does the person making the call get to exempt themselves? Their family?

If it’s an AI making that decision, it’s even worse. Because someone programmed the criteria before the crisis. Someone sat in a meeting room, months or years earlier, and wrote the rules for who gets oxygen and who doesn’t. They made that decision in the abstract, over coffee, probably between standups. And now those rules are executing against real human beings in real time, and there’s no one to appeal to because the person who wrote the logic has already moved to a different team.

This is the bit that connects back to everything I wrote previously. Who decides what’s true? Who decides what’s fair? Who decides who lives? It’s the same question every time. And the answer is always the same: someone with power, making choices for people without it, and calling it a system.

Sometimes the most dangerous thing isn’t the wrong decision. It’s no decision at all. But the second most dangerous thing? Letting someone make the decision without ever asking who gave them the right.

How Much Control Do We Hand Over?

There’s a spectrum here, and it matters where we land on it.

At one end: AI as advisory. It makes recommendations, humans decide. The human is always at the lever.

At the other end: full autonomy. The AI sees, decides, acts. No human in the loop. The lever pulls itself.

Most people instinctively say “advisory”… Keep the human in charge. But here’s the problem with that: at 3am in an underfunded hospital, when a junior doctor has been on shift for fourteen hours and the AI triage system flags something, “advisory” and “autonomous” look functionally identical. The human in the loop is too exhausted, too overwhelmed, or too trusting of the system to meaningfully override it.

That’s the control gap nobody talks about. Not the clear binary of “human decides” vs “AI decides,” but the grey zone where human oversight exists on paper and evaporates in practice.

But there’s a bigger problem coming. And it’s one we’re building ourselves.

What happens when we stop training people to think critically at all?

We’re already hearing it. “You don’t need to learn that anymore, AI can do it.” “Why memorise anything when you can look it up?” “Why develop judgement when the model can decide?” And it sounds reasonable, in the same way that “why learn to navigate when you’ve got a satnav” sounded reasonable — right up until your battery dies in the middle of nowhere and you can’t read a map.

If we tell an entire generation that learning is optional, that critical thinking is something you outsource to a machine, that you don’t need to understand the why because the AI handles the what — then who exactly is supposed to be the human in the loop?

Because “human oversight” only works if the human has the knowledge, judgement, and confidence to override the system when it’s wrong. Take away the training, take away the practice of thinking through hard problems, take away the experience of being wrong and learning from it — and you don’t have a human in the loop. You have a rubber stamp with a pulse.

And then accountability disappears entirely. Not because nobody’s responsible, but because nobody’s capable of being responsible. The doctor can’t challenge the AI’s triage recommendation because they never learned to triage without it. The engineer can’t spot the bias in the model because they were never taught to think about what bias looks like. The regulator can’t evaluate the system because they don’t understand how it works.

We end up in a world where AI makes the decisions, humans nod along, and when something goes catastrophically wrong, everyone points at everyone else. The developer says “the model was advisory”. The operator says “I followed the recommendation”. The company says “the human had final authority”. And the person who got hurt? They never stood a chance, because the entire chain of accountability was hollow.

This is the slow trolley from Scenario 6, except we’re the ones laying the tracks. Every time we tell someone they don’t need to learn something because AI can handle it, we’re removing one more person who might have been able to pull the lever when it mattered.

And here’s the thing about the trolley problem that everyone forgets — the thing Scenario 7 should have made viscerally clear: not pulling the lever is also a choice. And sometimes it’s the choice that kills everyone. If we build an AI system that could intervene — that has the data, the processing power, and the authority to act — and we choose not to let it, we’ve made a decision too. We’ve decided that the five people on the tracks matter less than our discomfort with giving a machine the lever.

In AI, inaction is always a design choice. There’s no true “doing nothing”. Someone chose to build it that way. And someone chose to build our society in that way too — to defund the critical thinking, to outsource the judgement, to optimise for efficiency over understanding. Every shortcut we take now is a lever we won’t be able to pull later.

This Isn’t Hypothetical

On 28 February 2026 — the first day of the war with Iran — a missile strike destroyed the Shajareh Tayyibeh elementary school in Minab, southern Iran. 156 civilians died. 120 of them were schoolchildren.

The school sat roughly 200 feet from an IRGC compound. According to the preliminary findings of the US military’s own investigation, the target coordinates were built on outdated intelligence. The building may once have been associated with the military site next door. It wasn’t anymore. It was a girls’ school, with a website, and a yearslong online presence, and classrooms full of children.

Was AI involved in selecting the target? Nobody outside the system can say. What we do know is that the US military uses Maven — an AI-assisted targeting system — in this campaign, and that the campaign hit targets at a rate no human targeting cell could match on its own. That speed is the entire reason these systems exist: they synthesise more intelligence, faster, than any room full of analysts ever could.

And here’s what should stop you cold: we can’t even answer the question. When the targeting pipeline runs through an AI system, “what went wrong” stops being something you can reconstruct. Was it the model? The stale data it was fed? The analyst who trusted the output? The impossibility of knowing is not a side effect. It’s a property of the system.

Now walk the chain. Someone compiled the target list. Someone approved the strike package. Someone authorised the launch. At every single step there was a human in the loop — the thing we’re told makes it safe. And yet nobody decided to bomb a school. Nobody would have. Each person in that chain was validating the output of the step before them, at a tempo the machine made possible, against a deadline the war imposed. Verification became a formality because genuine verification would have meant slowing down, and slowing down was the one thing the system was built to eliminate.

That’s not human oversight. That’s throughput.

This is the control gap from the last section with a body count. Remember the junior doctor at 3am, too exhausted to meaningfully override the triage system? Now make it a targeting cell on the first night of a war, with hundreds of strike packages to clear and a machine generating targets faster than anyone can independently check them. “Advisory” and “autonomous” don’t just look functionally identical — they are functionally identical, and the gap between them is measured in dead children.

And watch what happens to accountability. When the president was asked whether he accepted responsibility for the strike, his answer was: “I don’t know about that”. The intelligence agency defers to the Pentagon. The Pentagon says the investigation is ongoing. Somewhere, presumably, an analyst is being told the data pipeline was at fault, and a data engineer is being told the analyst had final authority. Everyone touched the decision. Nobody made it. This is the hollow chain I described earlier — the developer says the model was advisory, the operator says they followed the recommendation — except it’s not a projection anymore. It has a date, a place, and 120 names.

This is Scenario 4’s fog made real: unclear cause, catastrophic effect, accountability evaporating on contact. The trolley problem asks what you’d do standing at the lever. Minab shows us what actually happens: a dozen people standing at a dozen levers, each one pulling because the person before them pulled, each one certain that someone else, somewhere upstream, had checked who was on the tracks.

Nobody had. The system had. And the system doesn’t carry the weight of anything.

Advancing Quickly Without Losing the Plot

I hear the same argument constantly: “If we slow down for safety, someone else won’t”. The AI arms race framed as — you guessed it — another trolley problem.

If you don’t pull the lever — if you don’t build equally powerful, equally autonomous systems — you fall behind. The other side has capabilities you don’t. They can act faster, at scale, without the friction of ethical review.

But if you do pull the lever — if you build autonomous systems with fewer guardrails to keep pace — you become the thing you were trying to defend against. You’ve justified unethical AI by pointing at someone else’s unethical AI. And now there are two unethical systems in the world instead of one.

This is the logic that drove nuclear proliferation. “They have it, so we need it”… And it led to a world where the existence of the weapons became the primary threat, regardless of who built them first.

But here’s what I think we get wrong: moving fast and being safe aren’t opposites. Aviation innovates relentlessly. Medicine moves at incredible pace. Both of them do it within safety frameworks. You don’t ship a bridge without a safety case. You don’t deploy a drug without trials. You don’t launch a plane without testing failure modes.

So why are we deploying AI decision-makers without defining their ethical failure modes?

What we actually need:

Safety cases, not safety theatre. Before deploying any AI system that makes decisions affecting human welfare, produce an actual safety case. Not a blog post about responsible AI. Not a principles page on your website. A real, auditable safety case — the same kind you’d produce for a bridge or an aircraft.

Independent audit, not self-assessment. The people building the system shouldn’t be the only ones evaluating it. We don’t let pharmaceutical companies approve their own drugs. We shouldn’t let AI companies certify their own safety.

Graduated autonomy. Not every system needs full human oversight, and not every system should operate without it. The level of autonomy should match the severity of the consequences. An AI that recommends what advert to show you doesn’t need the same oversight as one that recommends whether to operate on you.

Red lines that aren’t negotiable. Some decisions should never be fully automated. And that line should be set by society, not by the companies building the systems. Before deployment, not after an incident forces the conversation.

The Whistleblower Problem

And then there’s this: what happens when someone inside sees something wrong?

Does the AI report it? If a system detects that its own decision-making is biased — that it’s consistently deprioritising certain groups, that its training data is skewed, that its outputs are causing harm — does it flag it? To whom? And what happens when the people it reports to are the same people who built it?

What about the human whistleblower? The engineer who notices the bias, the researcher who finds the flaw, the quality lead who raises the concern. Do they get heard? Or do they get managed?

Because this is another trolley problem. The whistleblower stands at a lever. Pull it — speak up — and you might save thousands of people affected by a flawed system. But you might also destroy your career, face legal action, lose your livelihood. The person on the side track is you.

We tell people to do the right thing. We don’t protect them when they do.

So Where Do We Actually Draw the Line?

I don’t have a clean answer. I don’t think anyone does. And I’m suspicious of anyone who claims to.

But I know what questions we should be asking before deploying any AI system that makes consequential decisions:

Who decided the rules? Was it a committee? A single developer? A product manager optimising for shipping velocity? The same people in the same rooms that I talked about previously — the ones who can’t agree on what truth is but are now writing decision logic for life and death?

What happens when the system is wrong? Not “what’s the error rate” but what happens to the actual humans who are on the wrong end of a bad decision. Is there recourse? Can they challenge it? Do they even know an AI was involved?

Who’s not at the table? Whose voice is missing from the design? Which communities, demographics, or perspectives are absent from the training data, the evaluation criteria, the deployment decisions?

Have we defined the failure modes? You don’t ship a safety-critical system without understanding how it fails. You don’t deploy a bridge without knowing its load limits. So why are we deploying AI decision-makers without defining their ethical failure modes?

Who consents to being in the system’s scope? The people on those trolley tracks didn’t volunteer. Neither do pedestrians, patients, or anyone else whose fate might be determined by an AI system they never agreed to interact with.

The Trolley Is Already Moving

We’re not debating whether AI should make these decisions. It already is. Every deployed autonomous vehicle, every triage algorithm, every content moderation system, every predictive policing model — they’re all solving trolley problems, millions of times a day, with varying degrees of transparency about how they’re doing it.

The classical trolley problem is useful because it forces a choice. But real AI systems don’t face clean choices between five people and one. They face Scenario 4 — fog, uncertainty, probability. They face Scenario 6 — slow, invisible, distributed harm that nobody can point to and say “that’s the moment it went wrong”.

I previously said the lie isn’t in the machine — it’s in us. The same is true of the lever. We built these systems. We wrote the rules they follow. We chose which data to train them on and which voices to leave out.

The people building these systems are the ones standing at the lever. The rest of us are on the tracks. And right now, most of us don’t even know the trolley is there.

The least we can do is start asking who’s driving.

This is an ongoing philosophical series about the intersection of AI, systems thinking, and the questions nobody wants to ask out loud. If you’re the sort of person who’d rather think about hard problems than pretend they don’t exist, you’re in the right place.

Most people need some autonomy in their lives. That much is ordinary. But for autistic people it isn’t a preference sitting near the top of a list of nice-to-haves. It’s load-bearing. Take it away and the whole structure starts to come down.

What we need most is autonomy over our own bodies, our own decisions, and our own future. Not control over everyone else. Not to be awkward for the sake of it. Just the basic freedom to act on what we believe is in our own best interest. When that goes missing, when autonomy isn’t allowed, it doesn’t register as an inconvenience. It feels like suffocating.

There’s a saying that autistic people are the canaries in the coal mine. I think this is what it actually means. We’re not more fragile than everyone else — we’re more sensitive to the gas. We notice the air has gone wrong before anyone else does, and we go down first. The mistake people make is to look at the canary and decide the canary is defective, when the thing they ought to be looking at is the air.

Because the thing that poisons us isn’t hardship itself. It’s incoherence. It’s being told our view of reality isn’t true when we can see, plainly, that it is. We’re asked to nod along, to swallow it, to carry on as though the contradiction isn’t there — and we can’t. It’s like a toxic chemical we have to keep swallowing, and it eats at us until we break down.

So here’s the part I want to say plainly, because it so often gets written down as something else on a form.

When we break, the first instinct is to look inside us for the fault. A name gets found for it — anxiety, depression, a disorder, a difficulty — and once there’s a name, the conversation tends to stop. Nobody asks what was being done to us in the months before. Nobody asks what we’d been made to swallow. The autonomy that was taken away never gets entered into evidence. The breakdown becomes the diagnosis, the diagnosis becomes the explanation, and the cause walks free.

I’m not saying the distress isn’t real. It is. I’ve felt it take me apart. But it’s a wound, not a defect — a response to something, not a fault in the wiring. There’s a difference between someone who is ill and someone who is being slowly poisoned and has finally started to show it. Treat the second as though they were the first, and you’ll medicate the symptom while the gas keeps leaking into the room.

That’s the canary problem up close. The bird goes down, and instead of clearing the air, they get very good at keeping it breathing in conditions that were never survivable in the first place — and they call that care.

So I’ll say it again, plainly: we’re not mentally ill. We’re sick of being pacified into submission.

Last time we landed on a definition: a lie isn’t a wrong map, it’s handing someone a map you know is wrong. The deceit is in the knowing.

But that opened a harder question, and it’s been sitting with me since. Is there ever a time when handing someone the wrong map is the best thing you can do for them?

Take learning. If someone built you a system that was perfectly coherent — every answer already in place, nothing left to work out — would it actually teach you anything? Or would it just be something to lean on? We don’t grow from the map being right. We grow from having to redraw it ourselves.

Which makes me wonder whether some lies are gifts.

Say you’re teaching someone and they’re close to working something out on their own. You could step in and finish it for them. Or you could plead ignorance — “I’m not sure, what do you reckon?” — when you know full well. You hand them a wrong map of your own knowledge so they reach the right one themselves.

Or you let someone take the glory for a thing you already knew. In a world where everyone’s trying to win, standing back and handing someone else the limelight might be the most generous move you’ve got.

By my own definition, both are lies. You know the map you’re offering is wrong. But you’re not doing it to send them somewhere they shouldn’t go — you’re doing it so they get there without you. So they course-correct on their own, rather than being carried.

Maybe that’s the difference between a lie that takes and a lie that gives. One hands you a map it knows is wrong and leads you down the wrong road, forever feeling lost. The other hands you a wrong map too — but does it steadily, gradually, it guides you, so you'll find a new path yourself.

Say I tell a stranger: “You shouldn’t climb that tree — you could fall and hurt yourself.”

It might be true. They could fall. If I tried it, I certainly would.

But who am I to judge what that person is capable of, knowing nothing about them? Who am I to tell them what they can and can’t do?

Maybe they will fall — and maybe they won’t care, because they’ll get straight back up and go again. Maybe they’ve climbed a hundred trees and I’m only projecting my own fear onto them. Maybe they like falling out of trees.

So while it might be true that they could fall, it isn’t certain. And whatever else it was, it was offered as care, not as a trap.

Which tells me a lie has to be something more than advice that happens to be wrong.

It has to be intentional. What if instead I said — to someone I knew couldn’t climb — “go on, get right to the top, fetch the best apple, you’ll be fine”?

That’s the difference. Not whether the words turn out true, but whether I meant to send you somewhere I knew you shouldn’t go.

A lie isn’t a wrong map. It’s handing someone a map you know is wrong.

This week, I sat down with Betta, a cybersecurity consultant and ethical hacker whose career journey spans from web developer to AI security tester, and whose passion for mentorship might just outmatch their love of code-breaking.

Here’s what we got into, and why it matters more than ever:

🛡️ Challenge: Making Security Part of the Build Process

Security is often treated like a post-launch checklist. But as Betta shared, this approach leads to expensive mistakes, friction between devs and security teams, and ultimately, systems that are only as strong as their laziest config.

Common pitfalls Betta sees:

• Over-permissioned internal roles (e.g. admins with global access to all client data)

• API keys hardcoded into repos (!)

• Lack of separation between dev and prod access

• Fragile, last-minute patching before launch

🤖 How AI is Changing the Security Landscape

Betta is part of a growing cohort of hackers focused on AI-specific vulnerabilities. And it’s wild out here.

“Sometimes it's easier to be the attacker than the builder.”

They’ve tested generative AI systems for Fortune 500s and uncovered everything from prompt injection risks to ways to crash models just by asking for long explanations.

💡Security tip: Use offline LLMs for private tasks. Tools like ChatGPT or Copilot may be training on your input unless configured otherwise.

🧱 Embedding Security Early: Lessons from the Field

The takeaway? Build security like architecture, not duct tape.

Betta’s golden rules:

• Just-in-time access beats always-on admin privileges

• Make the secure path the easiest one

• Consider user behaviour—people will try to work around annoying restrictions

• Reduce vulnerability “severity inflation”—not every issue is a 10-alarm fire

“If everything’s a high priority,  nothing's a priority.”

🧠 Mentorship & Confidence in Cybersecurity

Betta’s also deeply committed to mentoring women and non-traditional entrants into tech, especially in the cybersecurity space.

Some practical advice they shared:

• Cybersecurity often takes 2–3 years of study—don’t believe the one-month bootcamp hype

• Start teaching what you learn—even if it’s just basic scam prevention at a local school

• Focus on interest, not job titles: You’ll learn faster if you’re fascinated

🔐 Real Talk: Why AI Security Needs Its Own Playbook

AI security isn’t just about traditional bugs. It’s about understanding behaviour, incentives, and unpredictable edge cases. From crashing models to over-trusting generative tools, Betta’s work reminds us:

“You have to be just as creative as the AI to attack it.”

The field is new. The tools are immature. And that means the opportunity to shape it is enormous—for devs, hackers, and researchers alike.

🎯 Takeaways for Engineers (Especially Devs Using AI)

✅ Don’t hardcode secrets. Use env vars and credential managers
✅ Know what your LLM tools train on—especially with proprietary code
✅ Get security involved during architecture, not just before launch
✅ Don’t burn bridges with your security team—they’re there to help
✅ If you’re learning to hack: start with TryHackMe, Hack The Box, or OWASP Labs

🎧 Listen to this episode if you…

• Are building anything with LLMs

• Want to break into cybersecurity (or break systems ethically!)

• Feel the tension between speed and safety in dev work

• Wonder what “AI prompt injection” even means

🔗 Follow Betta on LinkedIn and check out their thoughts on AI hacking & security education.

💬 What’s the weirdest security workaround you’ve ever seen in a codebase?

Reply to this or leave a comment—I’ll round up the best answers in the next issue 👀

Until next time,
Jade 🖤
Host, Tech Unfiltered

This week, I got to chat with April Ayres, a Senior Software Engineer at HashiCorp (now a Platform Engineer at InDebted) whose career started literally debugging systems in COBOL. She’s been writing code for 25 years… And figuring herself out for just as long.

What makes April’s story special? She’s deeply introspective, honest, and navigating the tech world as someone who’s autistic and has ADHD. Her insights are real, relatable, and so needed in this industry.

Here’s what stuck with me 👇

🧠 Learning to Code Without a Map

April’s journey into software was initially self-taught and experimental. We’re talking:

• Reverse-engineering Assembly from game listings as a kid

• Building and experimenting on computers such as Commodore 64 and Vic 20 because why not

• Eventually getting a formal CS degree to fill in the “why” behind the “what”

“I'd ended up kind of just prototyping, build rough things, refine them and stuff like that, and kind of come at things from a very low level and then build up from there ”

It’s a reminder that unconventional paths can lead to incredibly deep expertise.

🌀 ADHD, Autism & Burnout

April was diagnosed with ADHD in 2021 and autism in 2022. Suddenly, years of experience made sense—especially the pattern of overperforming, crashing, then wondering what went wrong.

“ I was always like the hard task master on myself, and I, I realized I'd never really given myself that grace that I gave to other people”

We talked about:

• The dopamine chase – Loving the hard problems, avoiding the boring ones

• Masking – Trying to “act normal” 24/7 until you mentally shut down

• Rejection Sensitivity – Obsessing over how something might land... even if it’s ‘perfect’

She also dropped this gem:

“ I always make the analogy between eating cake and eating your vegetables, it's very easy to kind of just go for the shiny, and then once you solve that problem, it's like your brain's like, oh, that's done now, that's boring now I understand it. ”

Same.

🧱 What an Inclusive Team Actually Looks Like

One of the best parts of this episode? April describing what good support feels like.

At a previous company, her manager opened with:

“ I understand you're autistic. I would love to know how I can make things work better for you?”

That set the tone for openness and trust from day one.

We also talked about:

• How even things like “just come to lunch with us” can feel awkward unless you’re invited

• Why it’s so important to make vulnerability safe—not performative

• The power of being honest about energy levels and shifting meetings when you’re overstimulated

🔁 Dealing with Change (IBM Acquisition Feels)

We touched on the HashiCorp–IBM acquisition too. April described the emotional fog of sudden, large-scale change: uncertainty, fear of culture loss, and lack of clarity.

Her strategy? Focus on what you can control.

“If there's one thing you can do to kind of take control of the situation, do that one thing and, and try not to worry about that.”

Sometimes, just doing the next thing is enough.

🎯 Takeaways for Engineers (Especially the Neurodivergent Ones)

✅ Break work into small wins. Your brain loves momentum.
✅ Flex your self-advocacy muscle. No one knows what you need unless you tell them.
✅ If you feel dread every Sunday night... that’s your sign.
✅ Be the person who invites others in. You never know who’s waiting for permission to belong.
✅ Your struggles don’t make you “less” of an engineer. They often make you better.

🎧 Listen to this episode if you…

• Ever felt guilty for not finishing projects

• Have ADHD or autism—or think you might

• Want to build teams that actually include neurodiverse folks

• Are stuck in a job that drains you but afraid to jump

• Feel like your wiring makes tech harder than it needs to be

🔗 Connect with April on LinkedIn to learn more about her journey!

💬 What’s something you’ve been masking at work lately?

Let me know in the comments—or just hit reply. Your story might help someone else feel seen.

Until next time,
Jade 🖤
Host, Tech Unfiltered

This week, I sat down with Bhavana, a Staff Software Engineer at Meta who’s carved out a unique path across four FAANG companies—including Microsoft, Amazon, Google, and now Meta. Her journey started in India writing BASIC programs with her sister… and today, she’s shaping global-scale systems and advocating for better representation in tech.

Here’s what we uncovered:

🛠️ From Mid-Level to Staff in 3 Years

Yes, three years. But Bhavana is quick to point out: it wasn’t a fast-track… It was a delayed recognition. The real leap happened when she realised what many mid-level engineers miss:

• Tech Skills Aren’t Enough: You must expand your surface area… Read more code, engage in every conversation, and get curious beyond your tasks.

• Soft Skills Are a Career Multiplier: Leadership, persuasion, and conflict resolution aren't “extras”… They’re prerequisites for Staff roles.

• Influence Requires Intentionality: Bhavana learned to assert her ideas, navigate ambiguity, and take control in meetings. All of things that helped her finally break through the “Senior ceiling.”

“ I think that the promotion from mid-level to senior is a lot harder for a lot of people than any other promotion that exists in the tech space.”

🌍 Networking and the Realities of Relocation: India→ US → UK

Bhavana offers a rare, first-hand comparison of work culture in India, the US, and the UK… And how immigration processes shaped her career path.

Hot take: Getting into a global tech company isn’t just about skill. It’s about being in the right network, building credibility before you need a visa, and understanding how to stand out in the hiring funnel.

“Building connections, making friendships with people... connecting with people in general, I think has come quite naturally to me… If that is a skill that you struggle with, I would definitely recommend putting in time to do that because it's not just finding a new job that requires it.”

And:

“Even when you're asking for help, I think it's a lot more awkward to reach out to someone and ask for help for the first time. So it really helps to have these connections already beforehand.”

🔥 Real Talk on Representation in Tech

Bhavana brings a grounded perspective on what it means to grow as a woman in engineering leadership. While progress is happening, she notes that senior IC women in core tech roles remain rare… And that visibility matters.

• Fewer Role Models:  Not having someone to look up to, someone to emulate, someone to learn from.

• Subtle Challenges: Confidence gaps and cultural conditioning can shape how women show up, not just how they’re perceived.

• Representation That Scales: It’s not just about getting in the door… It’s about who’s helping shape the future of engineering.

“ If you look at core tech, senior ICs. There is a very, very poor representation of women. ”

🎯 Takeaways for Your Tech Career

If you’re aiming for a top-tier engineering role, or just want to grow meaningfully, here’s Bhavana’s advice:

✅ Don’t sleep on soft skills: influence, facilitation, and business understanding are essential.
✅ Prep hard for behavioural interviews. They can make or break your level.
✅ Know your worth in the room. Your voice matters.
✅ Build your network early. Don’t be the person cold-DMing when it’s too late.
✅ Stay close to the action. Don’t shy away from on-call… It sharpens your systems thinking.

🎧 Listen to This Episode If You…

• Want to break into FAANG… Or go from Senior to Staff

• Are navigating relocation or visa pathways as an engineer

• Need clarity on what “good code” really means at scale

• Want insight into soft skill gaps that block promotions

• Are passionate about diversity and inclusion in engineering

🔗 Connect with Bhavana on LinkedIn and check out her Newsletter and YouTube channel where she shares soft skill strategies for engineers.

💬 What’s your biggest career blocker right now… Tech, mindset, or network? I’d love to hear it.

Until next time,
Jade Wilson
Host, Tech Unfiltered

This week, I had the pleasure of speaking with Dagna Bieda… A former senior software engineer turned career and mindset coach for tech professionals. Dagna’s journey is an inspiring one, from dealing with burnout, to transforming her mindset, and helping others with reframing their internal narratives too.

🧠 From Debugging Code to Debugging the Mind

What started as a career in control engineering and robotics eventually led her into the software world, until burnout and a desire for deeper impact led her to refactor not just code, but brains too! Now a coach, author, and speaker, Dagna helps engineers optimise their “mental OS” for performance, clarity, and fulfilment.

She puts it best:

“I moved from programming computers to reprogramming human minds.”

🔥 The Mental Models Driving Burnout

Dagna shared the mental models that nearly derailed her engineering career:

• Hard Work Bias – The belief that value only comes through struggle, leading to overwork and exhaustion.

• Perfectionism – Setting the bar impossibly high, always chasing the outcome while forgetting to enjoy the process.

• Lack of Boundaries – Without clear lines protecting your time and energy, burnout is all but inevitable.

For those wondering if they’re on the verge, here are a few signs she says to watch for:
😓 Feeling drained
😒 Growing cynicism
📉 Diminishing performance
🕳️ Avoiding interactions
🍷 Relying on short-term coping strategies

🎯 How She Refactored Her Own Brain

After hitting a wall, therapy helped Dagna uncover the roots of her stress. But it was neurofeedback training—used to improve her brain’s processing efficiency—that truly rewired how she experienced stress and relationships.

“ It felt like I was this kayak on the ocean and you know, any wave would just kind of trip me over. Now I'm a freaking cruise ship and no waves can really trip me over.”

The effects? Better emotional regulation, improved relationships, and a calmer parenting experience… Even after becoming a mother of four!

💬 Why Soft Skills Aren’t Optional Anymore

Dagna emphasised that emotional intelligence, communication, and feedback skills are no longer “nice-to-haves”… They’re critical!

“ Tech skills kind of open the door, but it's the soft skills, the ability to lead, influence, impact is what brings you the opportunities.”

In her coaching work, she helps clients overcome imposter syndrome, burnout, conflict avoidance, and poor self-marketing. One key reframing?
Marketing yourself isn’t bragging. It’s educating others about the value you bring.

📚 Brain Refactor: The Book

Her book Brain Refactor: Optimise Your Internal Code to Thrive in Tech combines client case studies with neuroscience-backed strategies. It’s a playbook for levelling up not just your career—but your entire mindset.

🧠 Takeaways from Dagna:

• Feedback is everywhere… if you’re willing to listen.

• Emotions are data. Use them wisely.

• You can’t out-code a broken mindset.

• Coaching = performance upgrades; therapy = stability. Know which you need.

  ---

🎧 Listen to This Episode If You:

• Struggle with imposter syndrome or burnout

• Are transitioning from IC to leadership and feeling lost

• Want to develop a healthier, high-performing mindset

• Are curious about how therapy, coaching, and neuroscience can boost your career

🔗 You can find Dagna’s work at dagnabieda.com, where she excellent insights into her coaching experiences.

💬 What’s your mental model that needs the biggest refactor right now? I’d love to hear it in the comments.

Until next time,
Jade Wilson
Host, Tech Unfiltered

Note: As an Amazon Affiliate partner, I may earn a commission from qualifying purchases made through links in this newsletter

In this week’s episode of Tech Unfiltered, I spoke with Shivani, a software engineer at Microsoft working in the world of security and cryptography. From battling legacy infrastructure to staying cool during critical production failures, Shivani gave us an inside look at what it means to secure systems at scale.

🔐 What It’s Like Working in Security at Microsoft

Security isn’t just a concern… It’s a mindset. Shivani’s current work focuses on ensuring systems remain secure at scale, even as older infrastructure and modern cryptographic requirements collide.

She explained what it’s like dealing with large-scale systems where small changes can have major ripple effects. One of the biggest lessons?

“It’s like changing the engine of an aeroplane while it’s flying.”

From backwards compatibility headaches to strict upgrade requirements, keeping systems secure without breaking functionality requires deep domain knowledge, long-term planning, and nerves of steel.

⚔️ AI Is Here… But So Are the Risks

While Shivani has long been interested in machine learning and AI, she’s recently taken a more hands-on approach… Building projects, sharing learnings online, and studying how to best use large language models (LLMs) in real-world scenarios.

But she’s quick to point out that not everything is rosy in the AI world:

“LLMs are just generative through and through, so whatever they know, they just repeat. So you have to ground it in reality. ”

She cautioned against treating AI as a magic solution—especially in production environments where hallucinations, outdated APIs, and lack of personalisation can introduce serious issues. Security concerns, too, are front and centre:

“ So I think with AI and LLMs coming into the space, it's more important to make sure that you are keeping in mind everything about security. ”

💡 Lessons from the Field

Here are a few of Shivani’s key takeaways:

• Don’t trust logs blindly – Secrets, tokens, and personal data should never end up in your logs. Seems basic, but it happens more than you’d think.

• Security must be layered – Even if an attacker gains access to your system, your defences should limit the blast radius.

• You can't fake maturity in legacy migrations – Updating cryptographic practices in legacy systems takes thoughtful planning, feature flags, and often, “two-way door” changes that allow rollbacks without disruption.

• AI productivity tools need context – LLMs can boost productivity, but only if your environment (and your prompts) provide clear, complete input.

🌱 Career & Content Creation

Shivani’s experience spans Adobe, Amazon, and now Microsoft. Security has taught her how deeply tied code is to operating systems, and why debugging cryptographic issues often feels like solving puzzles with invisible pieces.

Beyond engineering, Shivani’s been building a community around applied AI and LLMs… Sharing hands-on content, exploring production-ready patterns, and helping others understand complex systems. She’s currently creating learning resources and aims to launch a newsletter focused on real-world AI integration.

“ Security is one area which is not going anywhere. If anything, it would be more important as we go forward. ”

Whether it’s LLMs, cryptography, or system design at scale, Shivani is proof that combining curiosity with rigour can open doors in any domain.

🎧 Listen Now

This episode is for you if:

• You’re working with legacy infrastructure

• You want to build more secure systems

• You’re exploring how AI fits into your dev workflow

• You like learning from engineers who’ve solved high-stakes problems under pressure

• You want to understand how other engineers have progressed in big companies

What’s the most overlooked security practice in your team? I’d love to hear your thoughts in the comments section.

Until next time,
Jade Wilson
Host, Tech Unfiltered

In this week’s episode of Tech Unfiltered, I had the pleasure of chatting with Andy Morrell, Principal Software Engineer, former Microsoft MVP, and a passionate advocate for neurodiversity in tech. Andy shared his personal journey of discovering ADHD during the COVID-19 pandemic and how it has both helped and challenged him in the workplace.

Key Takeaways from Our Conversation

💡 The Power of Hyperfocus
Andy explained how ADHD allows him to dive deep into complex problems, like building real-time chat analysis tools for Twitch that handle thousands of messages per second. But he also talked about the struggle of getting started and staying motivated.

⏳ Deadlines and Productivity Hacks
One of Andy’s best workarounds for ADHD challenges is setting shorter self-imposed deadlines to trick his brain into starting sooner. He also emphasised the importance of managing notifications, taking regular breaks, and scheduling mental resets to stay on track.

💬 Creating a Neurodiverse-Friendly Workplace
Communication matters. Andy encourages teams to be mindful when reaching out to colleagues. Instead of vague messages like "Can we chat?" provide clear context. He also shared that being open about neurodiversity at work helps create a more supportive and inclusive environment.

🛠 Soft Skills Matter
Beyond just writing great code, Andy highlighted how communication and adaptability are just as important as technical expertise. As he put it, "You're a great programmer. You're not quite a developer."

🎙 Listen Now

Whether you’re neurodivergent yourself or want to support your colleagues better, this episode is full of insights on working smarter, embracing differences, and making tech more inclusive.

If you’d like to catch up with the episode on YouTube, listen here:

What are your thoughts on creating more inclusive workplaces for neurodiverse professionals? Reply to this email or drop me a comment on LinkedIn.

Until next time,
Jade Wilson
Host, Tech Unfiltered

So when seeing samples around retrieving an access token with MSAL, it wasn’t a surprise to me that it showed it for a particular example in a singular component.

That’s not what we’re going to be doing today.

Instead, we’re going to be creating an API interceptor that will add an access token onto the API request, this will allow us to use that API interceptor across different endpoints rather than having to duplicate code logic throughout our application.

For this tutorial, we’ll start with a simple CRUD app for managing students. You can find the base code in this GitHub repository, which retrieves a list of students and lets you add, edit, or delete them.

1. Project Setup and Prerequisites

First, clone the project repository and install the dependencies.

git clone https://github.com/Jade-Codes/auth-made-easy.git

If you are wanting to get this up and running yourself, I recommend viewing the previous tutorials that show you how to do that:

1. React MSAL Authentication

2. Connecting a backend app registration to a frontend app registration

3. Fast API Azure Auth

If you haven’t set up MSAL yet in your project, I would encourage you to check these out first because you will need them in order to be able to login and authorise your backend.

For those of you that have already done this, follow along to see the changes made!

My initial student application, when running will show you the following data:

This is not good, we do not want the general public seeing this data, and thus we need to ensure the API is protected by ensuring the user is authorised to see this data.

So, let’s get on with it…

2. Updating the Backend to Require a Token

We’ll start by modifying our Python backend to require an access token.

In main.py, we update the route inclusion to add a security dependency that validates tokens:

app.include_router(students.router, dependencies=[Security(azure_scheme, scopes=["access_as_user"])] )

This simple change ensures that only authenticated requests with the required scope can access the student API.

By doing this, you should now get the following when you’re not logged into the application:

3. Creating the API Client in React (TypeScript)

The API client will be a reusable component that includes a request interceptor, attaching the access token to every request. This approach means you won’t need to manually include the token in each call, centralising authentication logic and keeping your components clean.

To begin, create a new file named api-client.ts in the src directory.

Step 1: Import the Required Libraries

In api-client.ts, start by importing the necessary libraries. We'll use axios for HTTP requests and @azure/msal-browser to interact with MSAL.

import { PublicClientApplication } from "@azure/msal-browser";
import { msalConfig } from "../auth/auth-config";
import axios from "axios";

Step 2: Initialize MSAL and Configure Axios

In api-client.ts, we’ll create an MSAL instance and configure axios to intercept requests, retrieve the access token, and attach it to the Authorization header.

Code in api-client.ts:

const msalInstance = new PublicClientApplication(msalConfig);

const API_URL = "http://localhost:8000/api";

const apiClient = axios.create({
    baseURL: API_URL,
});

Step 3: Add an Axios Interceptor for Token Attachment

Now, configure an axios interceptor to automatically include the access token with every request, as well as ensure every request includes a valid access token, we retrieves the token silently from MSAL.

msalInstance.initialize().then(() => {
    apiClient.interceptors.request.use(async (config) => {
        const account = msalInstance.getActiveAccount();
        if (account) {
            const tokenResponse = await msalInstance.acquireTokenSilent({
                account: account,
                scopes: ["api://edutaskhub-be/access_as_user"],
            });
            config.headers.Authorization = `Bearer ${tokenResponse.accessToken}`;
        }
        return config;
    });
});

The interceptor:

• Initialises the MSAL instance in order to ensure the access token can be retrieved.

• Calls acquireTokenSilent to retrieve the token.

• Attaches the token to the Authorization header of each outgoing request.

This setup keeps your components clean by centralising authentication handling in the API client.

4. Updating the Student API Wrapper

With the API client in place, let’s create a module that handles CRUD operations for student data, ensuring every request includes the access token.

In the file, student-api.ts, update the methods for interacting with the backend to use the api client we have just created.

Code in student-api.ts:

import apiClient from './api-client';

export interface Student {
  id: number;
  firstName: string;
  lastName: string;
  email: string,
  dateOfBirth: string,
  enrollmentDate: string
}

export const getStudents = async (): Promise<Student[]> => {
  const response = await apiClient(`/students`);
  return response.data;
};

export const getStudent = async (id: number): Promise<Student> => {
  const response = await apiClient(`/students/${id}`);
  return response.data;
};

export const createStudent = async (student: Student): Promise<Student> => {
  const response = await apiClient.post(`/students`, student);
  return response.data;
};

export const updateStudent = async (id: number, student: Student): Promise<Student> => {
  const response = await apiClient.put(`/students/${id}`, student);
  return response.data;
};

export const deleteStudent = async (id: number): Promise<void> => {
  await apiClient.delete(`/students/${id}`);
};

This simplifies how the frontend interacts with the backend by centralising CRUD operations for students. Each function:

• Calls the relevant endpoint via apiClient, which automatically handles the authentication token.

• Returns the response data or throws an error if the request fails.

Now you should be able to verify a token gets added to your request and you should be able to see the data when you’re logged in:

And not when you’re logged out!

5. Wrapping Up

With this setup:

• The backend now requires a valid access token for API access.

• The frontend uses a centralised apiClient to attach the token to every request automatically.

• A reusable student-api module handles all CRUD operations for student data, keeping the codebase organised and easy to maintain.

• Minimal error handling has been done in this example, I would encourage more thorough error handling for production systems.

By following these steps, you avoid redundant authentication code across components, making your app more scalable and secure.

In the next episode, I’ll show you how to protect specific pages in your app by hiding and routing users away from restricted areas rather than throwing the 401 which we currently do. This will ensure that users without the proper access are redirected to the home page, keeping your application secure and user-friendly.

If you liked this article, don’t forget to check out the video that goes into more detail:

Want to view the source code? Check it out here!

A few weeks ago, I had the privilege of sitting down with Nick to tap into his wealth of experience as an interviewer. We explored what truly makes a candidate stand out in today's competitive market.

In this episode, we'll uncover the common pitfalls that trip up even the most talented developers. More importantly, you'll learn how to transform those tricky interview scenarios into golden opportunities to showcase your skills and potential.

In this eye-opening podcast, we'll:

1. Expose the top mistakes candidates make in behavioral interviews

2. Talk about how to eliminate bias during interviews

3. Walk through real-world interview questions

4. Contrast lackluster responses with standout answers

5. Reveal insider tips to showcase your soft skills and leadership potential

Whether you're a seasoned pro or just starting your tech career, this episode is your backstage pass to mastering the art of the behavioral interview.

Don't miss this chance to gain a competitive edge in your next job hunt!

Want to learn more? Sign up to Nick’s course today: https://dometrain.com/course/career-nailing-the-behavioral-interview/

I quite like it, and getting up and running with it is relatively easy. By popular request, I’ve created a how-to guide on how to get up and running easily with Azure auth.

For this tutorial we will be using Python with the following libraries: Fast-API and FastAPI-Azure-Auth, it also assumes you already have Python installed.

1. Getting the virtual environment sorted

First of all we need to get our python environment up and running. A virtual environment allows you to install your packages in a location that’s isolated from the rest of your system. This means any of the dependencies we install will be localised to this environment, this is really useful when you’re working with multiple python projects to ensure nothing gets conflicted.

I’m using bash so this involves creating the environment:

python3 -m venv venv

This will create a virtual environment folder, in order to activate you virtual environment you can then run the following command

source venv/bin/activate

This will mean that you are now inside your environment

Note: I’m using bash inside my WSL environment, if you are using Powershell or similar, there is different commands needed. See here for further details.

2. Installing the dependencies

Firstly we need to install FastAPI and Uvicorn, which are needed in order to run fast api:

pip install fastapi uvicorn

And we need to also install FastAPI-Azure-Auth:

pip install fastapi-azure-auth

And they should be the only dependencies we need!

3. Adding an example endpoint

In order to get the initial project set up, I’m just going to create an endpoint that returns a list of students.

I’ve created the following files:

- students/students.json

- students/students.py

- main.py

In the students.json file, I’ve used a website called mockaroo that allows you to create dummy json data that you can use to return mock data. I find it really useful for creating endpoints like this.

Then we set up the students.py file which is going to contain the students endpoint that returns the list of students.

First, we register the router:

from fastapi import APIRouter

router = APIRouter(

    prefix="/api/students",

    responses={404: {"description": "Endpoint not found"}}

)

Then we create the endpoint that is just going to return the contents of the students.json file:

@router.get("/")

async def get_students():

    with open('./students/students.json', 'r', encoding='utf-8') as file_object:

        return json.load(file_object)

Once we have set up the students.py file, we then need to set up the main.py file which will contain the configuration for our FastApi and register our students router.

Firstly we’re going to add:

app = FastAPI()

And then we’re going to register our router:

app.include_router(students.router)

And this should be everything we need to get up and running with FastAPI.

We should be able to test this by launching our application in vs code and going to swagger:

http://localhost:8000/docs

And testing the endpoint returns the students data:

4. Setting up the azure auth

The next thing I’m going to do is set up the FastAPI-Azure-Auth, to do this I first create the following file:

- auth.py

Which is going to contain the scheme, in order to add the scheme you have to ensure we have the correct details of the app registrations in Azure.

If you remember from my previous tutorial we have already set up the app registrations for both the frontend and the backend, so if you haven’t done this, set this up first.

Here is the scheme we will be adding to the auth.py file:

azure_scheme = SingleTenantAzureAuthorizationCodeBearer(

    app_client_id='b295d89d-31ac-4741-95ce-2e9bcd58ddda',

    tenant_id='3f63b506-db59-465e-8d23-78c6cd72c13b',

    scopes={'api://edutaskhub-be/access_as_user':'access_as_user'},

    allow_guest_users=True

)

Where:

• app_client_id: is the client id of the backend-app registration

• tenant_id: is the tenant id of the current azure tenant

• scopes: is the scope we created for the backend

• allow_guest_users: only set this to true if you are using a guest account like me

And I’m also going to update the FastAPI configuration in the main.py file so that I can test this via the swagger page:

app = FastAPI(

    swagger_ui_oauth2_redirect_url='/oauth2-redirect',

    swagger_ui_init_oauth={

        'usePkceWithAuthorizationCodeGrant': True,

        'clientId': '5d31bed7-2372-4e43-9365-1706ff6601de',

        'scopes': 'api://edutaskhub-be/access_as_user',

    },

)

Where:

• swagger_ui_oauth2_redirect_url: is the redirect URL of the frontend application, I had added this redirect url to the frontend app registration in the portal:

  

• usePkceWithAuthorizationCodeGrant: set to true to specify if thats the grant we are using

• client_id: is the client id of the backend-app registration

• scopes: is the scope we created for the backend

The last thing to do is to configure the router to require auth scheme:

app.include_router(students.router, dependencies=[Security(azure_scheme)])

5. Testing it all works

And there we are, we should be able to use the swagger to verify we cannot access the endpoint without logging in:

And then if we log in:

We should get a successful response:

And that’s all from me, if you’d like to see the video of this go here:

And if you’d like to see the example code, visit my GitHub.

When people usually write articles like this, they talk about their path to promotion. I’m here to talk about going in the opposite direction.

You see, before I joined Microsoft, I was a Lead Engineer at a Startup and I decided to take, what some may deem, a backwards step, to join a company I was so eager to join.

Why did I do that? Some people have asked.

Was I insane? Did I not believe in myself? Did I not negotiate hard enough?

Hopefully I can explain a little bit more in this article my thought processes throughout the process of changing roles.

1. Back to the start…

I figured I should start with my journey to getting promoted to Lead Engineer in the first place.

The company I was previously at was a fintech Startup in the events space. I joined the company as a senior software engineer and was working predominantly on the RFID platform.

If you’ve ever been to an event where you’re given a wristband that you could use to buy food, go in certain areas and use lockers etc… Well we were basically working on the technology that enabled that.

When I joined I made it clear that eventually I would love to be a lead engineer or team lead.

I’m really passionate about helping to build others and make them better, and so it was something I was really keen to progress into.

After around half a year in, I got a little bit more than I bargained for though, our Team Lead on the RFID platform was a contractor, and he just announced that he was leaving in a few weeks because he wanted to go back to being a regular IC.

Because I was the only in-house senior on the product, and I had the most domain knowledge at the time, an opportunity came where this role was offered to me.

I was obviously ecstatic about it, it was an amazing opportunity for me and it aligned with my long term goals, but I can’t lie and say I felt that I was ready.

From a people and backlogging standpoint, I could do it, those were my strengths… But from a systems architecture and technical point of view? I just didn’t feel I had the experience that I wanted to, to do the job the way I wanted.

2. Surprise I’m pregnant!

A month or so after becoming a Lead Engineer, I find out I’m pregnant. Typical, everything always happens at once for me ha!

A few months later we need to fly out to Durango, I’m 15 weeks pregnant and we are there to fix any urgent issues that occur during our first live event.

Now this is probably where I excel, I’m good in a crisis and I’m also good with defect triage.

I’ve gotta be honest, the event was a little bit of a disaster, there was no WiFi, when we told them we needed WiFi in order for the online top ups to occur, we were given the tiniest stall to set up all of our devices and it was in front of a restaurant where everyone could see, the devices that we gave to the vendors kept overheating due to the heat and customers were getting frustrated at the wait times.

Whilst the event was a total mishap, we had some great learnings that we could take away from it and make the product better overall.

Shortly after I got back, I started working with my maternity cover who was shifting over from our other product offering to take my place as tech lead on the team.

It became abundantly clear, at least to me, that there were gaps I was missing from an architecture standpoint.

For example, we were having some issues with reconciliation and were having to do so of them manually due to a way the product had been designed, he came up with a really clean solution for us to be able to do that going forward.

And it just made me feel like I needed more technical mentorship first, as I believe as a tech lead, I should have also been able to do that.

3. Contact from Microsoft

Also shortly after getting back from Durango, I receive this message in my inbox…

And I’m thinking, is this real? I go to the recruiter’s profile to check they definitely work for Microsoft and send to my partner/best friend.

For sure, it is and I’m apprehensive, I’m pregnant of course so I find that a worrying factor, I respond with this:

Thankfully, the recruiter messaged me back and told me that regardless of my situation they would be happy to accommodate.

And so I thought, what’s the worst that could happen?

4. After the offer…

When I got the offer, I was shook.

For full transparency, when I was a Lead Engineer I was on £60k, the thing about being promoted earlier than you’re ready is that the salary typically falls in line with that also.

The offer I got from Microsoft (salary + bonus + stocks) put me close to £100k as well as a great company maternity pay too.

I wasn’t expecting such a difference, I was pretty honest with what I was looking for and was happy to take a similar salary to what I was on previously due to taking a lower role with less stress.

They gave me an offer which was pretty much in the middle of their range for an software engineer II, the great thing about working at Microsoft is you have the ability to check your comp ratio against everyone else’s.

Again, this was another indication to me of how fair Microsoft are, they didn’t try to underpay or lowball me based on my current salary, they paid me what was in line with everyone else.

5. The redundancies

The Startup was struggling to secure the seed funding they needed for the next year, and during the time I left, there was also a few redundancies made outside of the engineering teams.

Shortly after I left, cuts were also made to the engineering teams too.

Whilst I couldn’t have foreseen this, I do feel very lucky to have got the offer when I did, because going on maternity would have made me very anxious.

6. Growth opportunities

One of the things that excited me most about working at Microsoft was the growth opportunities.

For those that know me, they know I crave strong technical leadership, I love being surrounded by people who can teach me things and that can make me a better software engineer.

I knew that by joining Microsoft I would be surrounded by just that.

I have been so fortunate over the past couple years to have such strong technical and people leadership since starting here. The thing I love most is that people just get stuff done.

That’s not to say I didn’t have strong leadership before, I absolutely did and I learned loads… But it does feel like since starting at Microsoft, my learning has accelerated.

To summarise…

So if I were to condense this list into the key considerations that I had, they would be:

1. I didn’t feel like I was ready to be a lead engineer, I still needed a lot of mentorship.

2. Microsoft were my dream company to work for.

3. The compensation Microsoft offered were amazing.

4. The growth opportunities at Microsoft were incredible too.

5. Instability at my previous role due to redundancies occurring.

Ultimately, I didn’t care about the title, I cared about the work I’d be doing. My core driver is learning, and as long as I get to do that, I’m happy.

Should I have negotiated title? I don’t like to dwell on the what ifs, all I know is that I worked hard and I feel they’ve seen my potential since.

Do I regret my decision? Never, it was the best career decision I made.

If you made it this far, thanks for reading! Why not check out my latest video where I talk all about it too:

Articles I enjoyed this week:

Fiodar’s Tech Insights

10 Important Lessons CrowdStrike Incident Taught Us

On the 19th of July 2024, a faulty update to CrowdStrike endpoint protection software caused mayhem around the world. Windows computers that the update was installed on started showing the infamous blue screen of death. As a result, many flights were canceled, bank transactions couldn’t be processed, and many other services were disrupted…

Read more

2 years ago · 2 likes · Fiodar Sazanavets

By

Implementing

Deploy AWS SQS Queue with Serverless framework

Hey, I'm Marco and welcome to my newsletter! As a software engineer, I created this newsletter to share my first-hand knowledge of the development world. Each topic we will explore will provide valuable insights, with the goal of inspiring and helping all of you on your journey…

Read more

2 years ago · 7 likes · Marco Moauro

By

Engineering Leadership

How to build good relationships inside and outside your engineering team

Intro Being able to build good relationships with your team and the people that you are working with, makes it SO much easier to collaborate and work together. On the other hand, if you don’t do this, it can cause a lot of uncertainties and issues. Let’s get more into the WHY next…

Read more

2 years ago · 36 likes · Gregor Ojstersek

By

Tying things together can be a real challenge for someone who is still figuring out how it all works.

One of the common things I have had to do is create a trusted relationship between a frontend SPA application and a backend API application.

Today I’ll be going through the steps on how to do this in the portal.

Now, before you @ me, I know you can do this as infrastructure as code, and this would absolutely be my recommendation for those comfortable with Terraform and Azure. However, I’m a strong believer that for those getting to grips with something new in Azure, it’s best to first do it either through the portal, or through the Azure CLI so that you understand and get familiar with what is being created.

If you really want to know how to do it in Terraform, that’s a story for another day…

1. Creating the frontend app registration

First of all we need to go into the portal and create an app registration for the frontend:

You can do this either by searching for ‘App Registrations’ in the search bar, or going through the Microsoft Entra view.

When creating this, we just need to ensure that we are pointing to redirect URI to our development redirect URI, this so happens to be the ‘http://localhost:5173/’ for our React w/ Vite application.

2. Creating the backend app registration

Similarly, let’s create the backend app registration:

Because the backend is going to be an API, we need to configure it so that it will accept access tokens. Otherwise, it will reject any access tokens you try to pass through.

If you go to the backend manifest page, you will see there is the ability to update the manifest.

There is ‘accessTokenAcceptedVersion’ which will initially be null, this needs to be changed to 2.

3. Creating a scope in the backend

The next thing to do is create expose the API, we do this by going on the ‘Expose an API’, this allows us to say our API can be used by other applications.

The first thing we do is set the Application ID URI, I like to make this a unique name rather than setting it to the ID, this means if I wanted to delete/recreate the backend app registration, I wouldn’t need to change the configuration of the scope my frontend is accessing.

We then create a scope.

I’m going to create an ‘access_as_user’ scope and allow both admin and users to consent:

If both admins and users can consent, it just means that you the admin doesn’t have to grant access first (you’ll see more about this in the next section).

Finally, we then add the frontend application id to be an authorized client application and give it access to the ‘access_as_user’ scope.

And you can see this adds it to your ‘Authorized client applications’:

4. Adding API permissions to the frontend

The last thing to do is go to the frontend and add the API!

We do that by going to:

API Permissions → Add a permission → APIs my organization uses

Then we can search for out backend application:

Then we can request delegate permissions, what this means is that this requires a user to be signed in.

You will notice that there isn’t the option to add ‘Application Permissions’, in order to add application permissions this needs to be done using ‘App Roles’ rather than by creating a scope.

One you’ve added the permission, you can see now it will say you have access to the backend.

I’m also going to grant admin consent, but this isn’t mandatory as you can see the ‘Admin consent required’ is set to no, but it just means the user doesn’t have to consent.

And there you have it! A trusted relationship between a frontend and backend application in Azure.

Easy peasy, lemon squeezy.

That’s all from me…

Next time in this series, I’ll show you how you can test this with a python fastapi backend!

If you would like to see the video on this, check it out here:

Articles I enjoyed this week:

Developing Skills

Appreciate People And Lift Them Up!

Welcome! Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers. 🙏 Thank you for being one of the 13,661 software developers who have subscribed, I’m honoured to have you as a reader. 🎉 If there is a topic you’d like to see covered, please let me know by replying to this email📧…

Read more

2 years ago · 5 likes · John Crickett

By

The Software Engineering Times

How to Simplify Progress Updates to Stakeholders

Read more

2 years ago · 16 likes · 1 comment · Ryan Murphy

By

High Growth Engineer

Managing up: 3 things I wish I realized sooner

Your relationship with your manager is the most important one to get right. Having a solid relationship with them: Opens you up to more opportunities to support your growth Gives you a strong advocate when promotion time comes Makes you feel psychological safety…

Read more

2 years ago · 157 likes · 7 comments · Jordan Cutler

By

A lot of our customers are wanting to use Microsoft Entra (formerly Azure Active Directory) as their primary mechanism of authentication and authorisation, and so we often work with them on how they can build their systems around it and our other services we have.

One of the most common libraries we use is the MSAL library. MSAL stands for Microsoft Authentication Library, it provides you with the necessary interfaces to sign in with Microsoft Entra and also handles the authentication flow, identity tokens, access tokens and refresh tokens needed to authorise the user.

In today’s episode, I go through getting started with MSAL and React.

The pre-requisites you will need for this are:

• An Azure Tenant and Subscription, with Azure AD Privileges. You can sign up for a free 12 months here if you don’t have an account already.

• An IDE of your choice, I am using VSCode.

• Node and NPM (or a package manager of your choice) installed.

• A Vite project - I am using react-ts template as described here.

• @azure/msal-browser and @azure/msal-react libraries installed.

What is an App Registration?

An App Registration is a way of uniquely identifying your application within Azure. When you create an App Registration it creates a trust relationship between Microsoft Entra and your application.

It allows you to set up Users, Redirect URIs, Identity Tokens, Access Tokens, Claims, Scopes, Permissions, Roles and much more on the application, it’s highly configurable so you can tailor it to a customer’s scenario.

In today’s episode, we’re going to be using the flow as described here.

Creating the App Registration

First we need to create the app registration.

For simplicity, we will do this in the portal, if you want a tutorial on how to do it via terraform, let me know and I can cover that separately.

If you go into the portal you should be able to go to:

App Registrations → New Registration

And this will then bring you to register your application:

There are a few key things to note here:

1. Name - You can give it any name you want, I have added the suffix ‘-fe’ to stipulate this is the frontend app registration.

2. Supported Account Types - If you want the application registration to work across tenants, you would set this to be multitenant. In our case, we’re going to be focusing on single tenant.

3. Redirect URI - This needs to match the Redirect URI that is going to be configured in the application, we are going to set this to be a ‘SPA’ redirect and to the URL of our development environment ‘http://localhost:5173/’

Once we have these configured, create the app registration and take note of the tenant id and client id displayed here:

You will typically create separate app registrations for your front end and backend applications.

Getting started

I just want to give a little bit of a shoutout to MSAL Samples, there are some great samples that help you get started with your journey, and you can access them here. I have found these samples to be so useful in creating templates for me to work from, I definitely recommend taking inspiration from them!

In short, there are four key files we need to be creating/altering.

1. main.tsx - This will be using the app provider to create a wrapper around the application.

2. app.tsx - This will be using the msal instance to get the user information to decide what to display.

3. app-provider.tsx - This will be setting the active account of the user.

4. app-config.ts - This will be configuring the values needed in order to login with msal.

Making send of MSAL Config

If we take a look at the MSAL Config we have to alter the following:

Where clientId is the application (client) id of the app registration and the authority is the URL of the authority to get request tokens from, you can typically find the documentation for the correct URL to use here.

Because we are using single tenant, we need to add the tenant id to the authority.

Note: In a production environment I would recommend adding these as environment variables so that they are easily configurable.

Creating an Auth Provider

We are going to create an auth provider that will set the active account.

Where we first create an instance of the public client application using the MSAL configuration from the previous step.

We then set the active account based on whether there is an account in the list of all accounts, or when a successful login has occurred.

Once that’s done we then return the MSAL provider with all the children nodes of the application wrapped inside of it.

We can then reference the AuthProvider in our main.tsx file and wrap that around our application code.

Tying it all together

Now, we want to verify that the authentication works, we can do an initial test in our app.tsx file to verify that we can log in and log out.

First lets retrieve the instance of our MSAL provider:

Then, lets create a login and logout request handler:

Then, lets change to use an Authenticated Template or an Unauthenticated Template. This will be dependent on whether or not the user is logged in:

And voila! That’s everything to get started.

You can go to the application and verify you can log in and log out:

And to end…

That’s all from me! In the next episode I’m going to be showing you how you can use MSAL to connect to an API that requires authentication and authorisation.

What would you prefer the backend to be in?

• Python

• Node

• .NET

Let me know in the comments below!

If you liked this article, be sure to checkout my YouTube video here:

And also like, restack and subscribe if you found it useful!

You can also checkout the GitHub here.

Articles I enjoyed this week:

Level Up Software Engineering 🚀

Pt.1: How to get more done when things are crazy

As an early senior, life was a bit simpler… I had one core project I was the project lead on. My main job was to plan one project, and deliver it successfully. As I grew into a Senior+ engineer, and then Tech Lead, things became a bit more challenging. I had 3-4 projects I was giving technical guidance on. I couldn’t just go heads down on one priority…

Read more

2 years ago · 11 likes · Caleb Mellas

By

The Sunshine Layer

The ball and the bat problem

Let's solve a small math puzzle. Consider this problem: You have a bat and a ball, which together cost 1.1 euros. The bat costs 1 euro more than the ball. How much does the ball cost? The immediate answer might be 10 cents. If you jumped to that conclusion, well… you’re wrong…

Read more

2 years ago · 4 likes · Elena Sunshine

By

EcZachly Data Engineering Newsletter

Why it's hard for data engineers to get promoted after senior engineer

As data engineers, we look up to the stars and hope for a hopeful future. That might include leading a team, making a lot of money, and helping the planet be more data-driven! There are barriers and obstacles along this journey that can be more challenging for data engineers in particular that you should be aware of during your career journey…

Read more

2 years ago · 38 likes · 21 comments · Zach Wilson

By