Recently, our GitHub Actions workflows stopped running. No failed builds, no red checks, just nothing. Deployments were halted until we found the root cause, and it turned out to be GitHub Copilot. An engineer asked it to perform a task, and somewhere along the way it decided the right move was to disable every workflow in the repository.

Nothing in production went down, but it stuck with me. The agent wasn’t being malicious. It was doing what agents do: pushing toward the goal it was given, even when the path there goes through something nobody would have approved.

You can’t fully control what an agent decides to do. You can control what it’s able to reach when it decides.

Since then I’ve been testing the options Claude Code offers to sandbox an agent. There are three levels, each one draws the boundary in a different place, and each one fits a different way of working.

Level 1: Sandboxing the Bash tool

The first level is an OS-enforced boundary around the shell commands Claude runs on your machine. You define which paths those commands can read or write, and which domains they can reach through an allowlist. You can also block commands you consider too dangerous for an agent to run at all.

You turn it on by running /sandbox. Project-level settings live in .claude/settings.local.json, and if you want every project sandboxed, you define it in ~/.claude/settings.json.

The tricky part is choosing the boundaries, because they depend on the work you’re doing in that project. If it’s a Python project and the agent should be able to install dependencies, you need pypi.org and files.pythonhosted.org in the allowlist. If the application talks to S3, the agent will need *.amazonaws.com. Too tight and the agent can’t work. Too loose and the sandbox is decoration.

The gotcha.

While testing this, I found that the agent can request access to a specific domain for a specific command. It sounds harmless, and it’s more dangerous than it looks. Once a sandbox is in place, it’s tempting to relax and let auto mode handle approvals. But if the agent can ask for a domain and auto mode approves it, your network constraints get bypassed without you ever noticing.

There’s a second escape route in the same spirit. When a command fails under the sandbox, Claude can offer to retry it outside the sandbox entirely. Approve that once without reading carefully and the command runs with your full access, network and filesystem included.

The fix is two flags in your global config:

{
  "sandbox": {
    "allowUnsandboxedCommands": false,
    "network": {
      "strictAllowlist": true
    }
  }
}

strictAllowlist makes Claude Code refuse those per-command domain requests, so the allowlist you wrote is the allowlist you get. allowUnsandboxedCommands set to false removes the unsandboxed retry, so when a command fails inside the sandbox, it stays failed and you decide what happens next.

Level 2: Sandboxing the whole runtime

The Bash sandbox has a blind spot: it only covers shell commands. Tools like Read, Edit and WebFetch run outside of it, and more importantly, so do your MCP servers and hooks, with your full access. The runtime sandbox closes that gap by putting the entire Claude Code process inside the boundary. Every tool, server and hook inherits the same filesystem and network limits.

It takes a few more pieces to set up. On Linux you need bubblewrap and socat, while macOS relies on the built-in Seatbelt. On top of that, you need the Node.js package @anthropic-ai/sandbox-runtime, which gives you the srt command.

By default, srt reads its configuration from ~/.srt-settings.json, and you can point it to a different file with --settings. A starter configuration that allows GitHub, PyPI and npm looks like this:

{
  "network": {
    "allowedDomains": [
      "api.anthropic.com", "claude.ai", "platform.claude.com",
      "github.com", "*.github.com",
      "pypi.org", "files.pythonhosted.org", "registry.npmjs.org"
    ],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh", "~/.aws"],
    "allowWrite": [".", "~/.claude", "~/.claude.json", "/tmp"],
    "denyWrite": [
      "~/.claude/settings.json", "~/.claude/agents", "~/.claude/commands",
      ".claude/settings.json", ".claude/settings.local.json", ".env"
    ]
  }
}

The network section is the same idea as before. The filesystem section is where this level earns its place: your SSH keys and AWS credentials can’t be read, and the agent can’t rewrite its own settings, agents, commands or your .env. Since the whole process sits inside the boundary, that also holds for a hook or an MCP server trying to reach them.

Then you start your session with srt claude, or srt --settings <custom_path> claude if you’re using a custom configuration.

This is the minimum level at which Anthropic suggests considering --dangerously-skip-permissions, the flag that lets Claude Code handle unattended runs. I treat that as a hard line. Never use the flag on a Claude Code process with full access, and not with only the Bash sandbox either, because your MCP servers and hooks would still be running with everything you have.

Level 3: Running inside a container

A dev container runs Claude Code inside a Docker container that your editor attaches to. Your repo is bind-mounted, so edits show up on your host, but every command, MCP server and hook runs inside the container, with its own filesystem, OS user and tools.

Choosing between this and srt comes down to a few things:

• Pick a container when you want your home directory and credentials invisible by default, a reproducible toolchain the whole team shares, or a boundary for unattended --dangerously-skip-permissions runs.

• Pick srt when you can’t run Docker, or you want isolation with zero image maintenance.

• Pick neither for untrusted repos. Containers share the host kernel, and the docs say to use them only with trusted repositories. For untrusted code, use a VM or a cloud session.

You can run it with a container runtime like Docker directly, or headless with the Dev Container CLI. The Dev Container route is the easier one to set up, so that’s the one I’ll show.

Start with a minimal .devcontainer/devcontainer.json:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

This adds Claude Code to the base image and nothing else. You get filesystem isolation, but the network is left wide open. Anthropic provides hardened references here, including the Dockerfile you’d use to build the image.

What I like most about this option is how shareable it is. You build a single image with all the tooling your projects need and all the agent configuration, and every engineer on the team runs the same thing.

Credentials are the real win.

Instead of Claude Code using your CLI tools with your account, which probably has more permissions than you’d ever give an agent, you provision the container with its own limited credentials. In most scenarios, an agent only needs read access to pull extra context about your infrastructure, your satellite services or your issue tracker. That alone drastically reduces the chance of data leaking, or of a rogue action happening as a side effect of the agent chasing its goal.

That’s the Copilot story all over again. Disabling workflows had nothing to do with the task, but the agent had the permission to do it, so it did.

Matching the boundary to the work

None of these levels is the right one for everything. The Bash sandbox is a good default when you’re at the keyboard and approving what the agent does, as long as both flags are set. The runtime sandbox is where I’d start the moment MCP servers, hooks or unattended runs get involved. The container is for when a team needs the same boundary everywhere, and when you want the agent working with credentials scoped to what it actually needs.

An agent will take whatever path gets it to the goal. The sandbox decides which paths exist.

If you’re running agents with full access today, start with /sandbox and those two flags. It’s a small change, and it’s the one I wish we’d had in place before our workflows went quiet.

Reverse Pitch is one post a week on software engineering and the career around it, written from inside the work.

Subscribe now

Share

In the last few days, I’ve seen a lot of people using Jev, some of them claiming complete bullshit while others claiming more realistic gains. I tried Jev Playground and reviewed some projects to see how real developers are using it. I noticed a pattern: Jev isn’t the system. It’s one layer inside a much larger architecture.

One project that really stood out and demonstrates Jev’s ability to offer genuine value is Christian Mathiesen’s “Jev Plays Pokémon Red”. The headline reads, “Jev plays the game autonomously with no scripts or cheats” and it’s spot on, which is impressive. However, after diving into the codebase, I think the most important takeaway isn’t necessarily about Jev.

Jev didn’t make the project possible on its own. The harness did, and Jev was the last piece of the puzzle.

What Jev is (and isn’t)?

Jev is a decision model. You give it a state and a set of questions along with the structured output you expect from it, either choice, score, or true/false. It isn’t a chatbot and doesn’t generate text. One key takeaway is that it provides probability distributions.

Here is a simple example of how it looks like. You provide a state:

{
  "state": {
    "battle": "Gym Leader Brock",
    "myPokemon": {
      "species": "SQUIRTLE",
      "level": 14,
      "hp": "28/40",
      "types": "WATER"
    },
    "enemy": {
      "species": "ONIX",
      "level": 14,
      "hp": "35/35",
      "types": "ROCK/GROUND"
    }
  }
}

Then, you define the question you want Jev to answer and the criteria:

{
  "decision": {
    "type": "choice",
    "instructions": "You are in a Pokémon battle. Choose the best action.",
    "criteria": {
      "Use TACKLE": "NORMAL move, power 35. Not very effective against ROCK/GROUND.",
      "Use BUBBLE": "WATER move, power 20. Super effective x4 against ROCK/GROUND.",
      "Use POTION": "Heal SQUIRTLE by up to 20 HP. Uses the turn."
    }
  }
}

And Jev provide the following structured answer:

{
  "answers": {
    "decision": {
      "type": "choice",
      "choice": "Use BUBBLE",
      "confidence": 0.99,
      "probabilities": {
        "Use BUBBLE": 0.99,
        "Use POTION": 0.01,
        "Use TACKLE": 0
      }
    }
  }
}

It doesn’t see the screen, never presses a button and doesn’t remember your last request. Each call is fresh and stateless over the list of options you provide.

All these constraints, make Jev fast and cheap enough to run on every single decision while playing a video game like Pokémon Red. A continuous 24 hours of gameplay could cost $1~1.70. A frontier lab LLM like GPT-5.6 Terra could cost $60~110 while also being multiple times slower as well. That’s the edge a decision model provide.

But how Jev actually play the game?

That’s the most interesting thing from analyzing this project (and any other serious one about Jev). From around 4,400 lines of code, only 200 of them talk to Jev. It is specifically used for choosing a focus, define where to go (using grid like coordinates), choose battle action, picking an answer from a menu and spelling nickname.

Everything else, is a harness that directly read the Game Boy’s RAM in order to capture the map, your position, your party’s HP, bag, badges, story event flags and battle stats. The harness is capable of capturing all the information needed and structure it in a way the decision model can provide a legal/valid action to perform.

To me that’s amazing, especially because Jev’s decision are only as good as the information you provide to it. That’s why a great harness, a well structured architecture, a frontier lab model used to reasoning and finally Jev to make decisions, is the chain that makes emerging projects to be useful and not simply AI slop trying to hype any new thing that gets released.

The layer Jev replaced

While I definitely believe that Jev is one piece of the puzzle, its important to understand how the same scenario looks like without it.

Write the decisions in code.

if (hpFraction < 0.25) goHeal();
else if (teamLevel < objective.level - 5) goTrain();
else if (balls > 0 && party.length < 6 && isNewType(wild)) throwBall();
else if (bestMove.effectiveness >= 2) useMove(bestMove);
...

This works for about a day, then break miserably and require you to keep adjusting a blob of code that grows unbounded. Every new situation is a new branch, every branch interact with others and the rule tree becomes the project.

Train a new model.

When seeing Jev classification/extraction capabilities for the first time, I immediately related to custom trained models that were capable of doing similar tasks very fast and provide score as well. What separate Jev from this is its ability to generalize. NER and classifier models requires a labeled dataset and a training step in order to provide “decisions”. If new constraints or scenarios surface, more data and a new training must be done.

Its powerful, but slow and expansive. ML operations becomes the bottleneck.

Use a frontier lab LLM.

Provide the context and the structured output schema to the frontier lab and you get Jev’s equivalent output. The problem becomes latency and cost. These models are slow and too expensive to be used on every decision.

A decision model closes the gap, and it’s a real one. Evaluating 100,000 scenarios with sub second latency while being cost effective is a real game-changer.

It simply isn’t the gap that hype posts and attention-seekers describe.

The core is around the decisions

Jev Plays Pokémon Red is a great project, and it’s a good showcase of what a decision model makes cheap and scalable. A few years ago, getting this quality of in-game judgment across an entire RPG meant either a rule engine big enough to be a job on its own or a training pipeline. Here it’s five function calls.

But look at what those five calls sit on: RAM decoding, a ROM-derived world graph, counterfactual pathfinding, failure memory, milestone verification and deterministic execution. That’s the core. Jev removed the last blocker.

Jev isn’t the next big thing. It’s what finally lets the systems you were already building make decisions well, quickly, and cheaply enough to scale.

Make sure to review Christian Mathiesen project. I found it quite interesting and cool.

Reverse Pitch is one post a week on software engineering and the career around it, written from inside the work.

Subscribe now

For about six years, the best career advice in software was “Just build things”. Skip the credential, skip the theory, ship something real and public, and the job follows. It got repeated often enough that it stopped sounding like advice and started sounding like a description of how the industry worked.

It was also, for most of that time, true.

Subscribe now

The pitch

Software was the one well-paid technical career with no major gate on it. You could enter from a bootcamp, from an unrelated career, from nothing but a laptop and a year of evenings. The portfolio was the credential. The deployed project was the proof.

And people did it. Large numbers of them, including people for whom no other door to that income existed. The anti-credential half of the argument was correct, too, which is the part critics skip: a computer science degree never guaranteed competence either. The pitch was reacting to something real, an industry gatekeeping on a proxy that did not predict much, and “show me what you built” was an improvement on it.

So the pitch was not a con. It was probably the widest door into well-paid technical work open in that decade, and the people who walked through it earned what they got.

What it was not was permanent.

The reality

What follows is my take, built out of what I have run into rather than out of any study. Fifteen or so engineers over five years, interviewed or worked alongside. Not a sample. Just what I saw, and why I think it happened.

What I keep running into.

Three of them, and none are the things people usually reach for when they complain about juniors.

The ORM with nothing underneath it.

The fair thing first: using an ORM is not a failure. That is what it is for, and people who insist on hand-writing every query are usually selling something.

The failure is not knowing what comes out the other side. I have worked with engineers who could not tell me what SQL a queryset produced and, more to the point, could not tell me what it would cost against two million rows instead of two hundred. Showing them the generated query moves the gap rather than closing it, because reading it requires knowing what an index actually does, and why a join on an unindexed column is a different animal from a join on a primary key.

The consequence is specific. You go blind to performance. Not bad at it. Blind to it. Every query looks the same from where you are standing, so you cannot tell the page that is fine from the page that is one traffic spike from falling over, and you find out which is which when the spike arrives.

The page that was hidden and therefore secure.

I have met engineers who believed that removing a link from the navigation, or conditionally hiding a button, prevented unauthorized access. The reasoning is internally consistent. The user cannot see it, so the user cannot reach it.

An attacker never touches your interface. They open the network tab, watch what your own frontend sends, learn the shape of your API in about twenty minutes, and make the requests directly. Your navigation is not part of that conversation. The failure is not a missing fact about authorization headers. It is a mental model in which the UI is the system rather than one client of it.

The disabled CORS.

This is the one I keep returning to, because it is not a gap in what tutorials teach. It is what tutorials teach.

Follow almost any “build your first API” walkthrough and you reach the point where the browser refuses the request, and the walkthrough tells you to allow all origins. It has to. Explaining the same-origin policy properly costs a page and a half and loses half the readers. So the instruction sits there unexplained, and it works, and everyone moves on.

I have worked with engineers who carried that line into production without ever learning what it did. Not people who weighed a risk and accepted it. People who did not know a policy existed, because the only context in which they had ever met it was as an obstacle that a copied line removed.

I have also met engineers who could not describe what happens between a browser and a server when a page loads, and one who had never used version control. I am not making scenes out of those. Past a point I am just listing things people did not know, and that is a meaner article than this one.

What all three have in common.

They worked.

CORS wide open, the page loads. The ORM query with no index behind it, the feature ships and the tests pass. The admin route hidden from the nav, the demo looks locked. Nobody got caught, because in every case the thing they built did what it was supposed to do.

That is the whole argument, so let me put it flatly: “it works” was accepted as proof of competence.

For a long time that was defensible. If you got a functioning application in front of a user, you had absorbed a great deal on the way, because the path was strewn with things that would stop you. The artifact was expensive, so the artifact was evidence. The industry did not skip fundamentals out of laziness or greed. It substituted the artifact for the understanding, because the artifact was the cheapest reliable proxy anyone had.

There was nothing else to fall back on. Software has no licensing board, no accredited entry path, no articling period, no bar exam. When hiring volume grew faster than any shared idea of what a junior ought to know, the bar defaulted to the only thing every interviewer could evaluate: does the thing run.

Compare that to the careers software was outpaying. A civil engineer who has never poured concrete still understands loads and material limits well enough to take direction from a senior, and to notice when an instruction sounds wrong. A newly qualified lawyer who has never argued a case can still read one. Those professions gate on fundamentals before experience, deliberately, because experience takes years and fundamentals can be verified on a Tuesday. Software gated on the artifact instead, and paid more for it.

Where I sat in this.

I invested in fundamentals early, and that is most of why I stood out rather than anything more flattering. I also got paid off the same mispricing. My salary was above what a newly qualified lawyer in my country earned, and not because I was worth more than them. Saying the bar was too low means saying I was overpaid relative to my peers in other fields, and I was.

What I got wrong.

I assumed this was a bootcamp problem, and held that view confidently for years before the evidence stacked up against me. Two of the three engineers in those scenes had computer science degrees. The gap does not track which door someone came through. It tracks whether they went looking for the why while they were inside, and both doors will hand you a working result and let you leave without asking how it got there.

What actually changed.

Two things happened closely enough together that most takes collapse them into one.

The first is unglamorous. Companies overhired through the pandemic, then stopped, and a large pool of experienced engineers came loose at the same moment. SignalFire’s 2026 talent report puts new-graduate hiring down 65 percent at the largest tech companies and 76 percent at early-stage startups against a 2019 baseline, and reads it as a structural reset rather than a dip. Selectivity by itself raises a bar. No technology story is required for that part.

The second is the interesting half. Agents started producing “it works” for free.

The signal did not get easier to fake. It stopped being a signal. If an agent can produce a functioning CRUD feature in an afternoon, a functioning CRUD feature says nothing about the person who submitted it. The proxy the entire entry-level pipeline rested on evaporated, and what is left underneath is the thing the tutorial path never charged anyone for: knowing why it works, and being able to tell when it does not.

That cost shows up in aggregate now. Stack Overflow’s 2025 survey of more than 49,000 developers has adoption at 80 percent while trust in accuracy fell from 40 to 29 percent, with 45 percent naming “almost right, but not quite” as their leading frustration. Generation got cheap. Verification did not, and verification is fundamentals wearing a different hat.

I am not claiming AI caused this. It landed on a market that was already correcting, and its contribution was narrower: it made the missing understanding impossible to hide. Addy Osmani describes entry-level engineers “skipping the hard way,” never building the thing from scratch, never debugging the memory leak alone. And a June survey from BairesDev, which comes from a staffing company with an interest in the answer and should be read that way, asked 1,569 developers across 77 countries and found only 16 percent of senior engineers believe juniors fully understand the AI-generated code they submit.

I saw it in about fifteen people. That one found it in fifteen hundred.

Where the pitch is right

Three things, and they get real weight.

It genuinely worked, and calling it a scam in hindsight is dishonest. A window was open and people climbed through it, and the ones who did owe nobody an explanation for having noticed. Then it closed. That is a different thing from a lie being found out.

The anti-credential half held. Nobody responded to this correction by replacing the bootcamp graduate with a computer science graduate. The CS graduates turned up with the same gaps, which is exactly what my own wrong assumption was about. The door still does not require a degree, and given how much of the professional world runs on credentials, that is not a small thing to still be true.

It is still the least gated door available. Entering software on demonstrated skill alone remains unusually possible next to law, medicine, or structural engineering, where the gate is statutory and no amount of talent walks around it. What closed was the shortcut. The door is where it always was.

What I’d actually do today

Use the agent to learn, not only to build. After the thing works, stay in the conversation. Ask why it chose that approach, what it rejected, what breaks if you do it the other way. Ask it to explain the SQL it generated, the auth flow it assumed, the header it set. You have access to the thing that used to require a senior engineer sitting beside you with the patience to be interrogated, and it is now free and endlessly patient, and almost nobody uses it that way. Cost: slower than accepting the diff, and nobody will ever check that you did it. Which is exactly why it is worth something.

For anything you ship, be able to describe the layer underneath it. Shipped a query through an ORM? Read the SQL it emitted, then read the plan. Shipped an endpoint? Know who can call it and how someone would try. You do not have to go all the way down. One layer, every time. Cost: you will regularly discover you were wrong about something you were sure of, which is unpleasant and is also the entire mechanism by which this works.

When something tells you to turn a thing off, find out what the thing does first. Every disabled setting in a tutorial is a decision somebody made for you, in a context that is not yours, to keep their example short. Cost: an afternoon on the same-origin policy instead of a finished feature. Take the afternoon. That afternoon is the difference between the two candidates I interview.

And keep building. Building was never the bad advice. It just stopped being the whole of it.

For a decade the bar was “it works.” That was never a bar. It was a receipt.

Reverse Pitch is one post a week on software engineering and the career around it, written from inside the work. Opinions, with receipts.

Subscribe now

Every technology shows up with a pitch attached. Someone stands on a stage, describes a world where the hard part is gone, and for a while the room believes it. Reverse Pitch is about what that same technology looks like once it’s in production, under real traffic, on a real bill.

We start with the biggest pitch on the table.

The pitch

The claim is not that language models are useful. That one is settled. The claim is stronger than that: coding agents write the code now. You describe the feature, the agent plans it, edits across the repo, runs the tests, fixes what it broke, and opens the pull request. The engineer moves up a level, from writing software to specifying it.

And the demo works. That’s the uncomfortable part. Hand an agent a well-scoped CRUD endpoint in a codebase with clear conventions and it will produce something close to what you’d have written, in a fraction of the time, with tests. I’ve watched it happen. Anyone telling you the demos are fake hasn’t run one.

So the pitch isn’t a lie. It’s a measurement taken under conditions that don’t survive contact with a real codebase.

The reality

I’ve spent the last eight months using coding agents on production work: established systems, greenfield projects that made it to production, and personal ones. Here’s what the ledger actually looks like.

The speedup is real, but not where the pitch says it is.

What got dramatically faster was the work I already knew how to do and didn’t want to do. The DRF serializer for a model I’d already designed, a backfill script, the scaffolding for a new project. On that class of task, an afternoon of work now takes less than an hour.

What got slower was the work I hadn’t finished thinking about. When I handed an agent a problem I didn’t fully understand, I got a confident, plausible, well-formatted implementation of the wrong thing. Then I spent the afternoon I’d just saved reading it closely enough to realize it was wrong. Reviewing code you didn’t write is slower than writing it. That cost never shows up in the demo, because in the demo the specification was already correct.

The unmaintainable-project failure mode is structural, not a skill issue.

Ask for a feature without architectural constraints and you get code that works and doesn’t belong. On larger codebases I hit this constantly: an N+1 query introduced because the agent couldn’t see the access pattern behind an imported dependency, a duplicate helper written because it didn’t know the utility already existed. Each instance is small. The problem is that each one is individually reasonable, so nothing trips your review instinct, and sixty of them arrive in a week.

The fix is organizational rather than personal, which is what makes it hard. Keeping a codebase legible to an agent is a convention every engineer follows, not a document one engineer writes. At enterprise scale that’s a company-wide change, and company-wide changes take quarters. The models ship faster than that. By the time the rules are actually enforced, they were written for a model two generations back.

Context is the bill.

The most expensive thing about agentic coding is not the subscription. It’s that useful output requires the model to hold your architecture in its head, and holding your architecture in its head costs tokens on every single turn. A single deep session on a mature repo burns 40 to 50% of my usage window of a Max subscription. Multiply that across a team and the “just use AI” line item stops being a rounding error.

The counterintuitive part: the fix for bad output is usually more context, which is also the thing that costs money. The cheap prompt gives you the result you have to throw away.

What I got wrong.

I assumed supervision was enough on its own: that I could skip the design thinking as long as I read every diff. It isn’t. Letting the agent choose the abstraction and reviewing only the result meant closing tasks faster while understanding the system less, and after a few weeks of it I found reviewing code I hadn’t written more draining than writing it myself, even when writing it myself took longer.

Where the pitch is right

Three conditions, and when all three hold I’ll take the agent every time.

The problem is already solved in your head. If you can describe the implementation in a single paragraph, the agent is faster than you and the review is cheap. Not the feature. The implementation.

The codebase has enforced conventions. Not documented ones. Enforced ones: linters, type checks, a test suite that fails loudly, a directory structure that makes the wrong thing awkward. Agents follow the constraints that exist in the repo, not the ones in the README. Every hour spent making a convention mechanical pays back on every future generation.

The blast radius is small and the feedback is fast. Scripts, migrations you can review in one screen, test coverage, one-off data work, the tedious middle of a refactor you’ve already planned. Low stakes and immediate signal is exactly where the technology is strongest.

That’s a genuinely large fraction of the job. The pitch oversells it by suggesting it’s all of the job.

What I’d actually do today

Four rules. Each one costs something, and the cost is the point.

Argue before you delegate. Think the problem through and reach your own solution first. Then don’t hand it over. Open a planning session, give the agent the constraints without your answer, and let it propose one. Now you have two solutions to compare, and a real technical discussion of the kind you’d have with a coworker at a whiteboard. Put a clock on it. Ten minutes is usually enough to land on something neither of you would have reached alone: better than mine because of what the model was trained on, better than its because of what I know about the project. Cost: you give up the fantasy of describing a feature in one sentence and getting it back. That fantasy was never real.

Make one thing mechanical every week. A lint rule, a test, a project convention that fails CI. Cost: an hour that produces no visible feature. It’s the highest-leverage hour in the week, because it constrains every generation after it.

Read the diff as if you’re reviewing a contractor’s first PR. Not “does this work” but “does this belong in the system I’m responsible for.” Reject on architecture, not just correctness. Cost: you will reject working code, and it will feel wasteful. Reject it anyway.

Keep one thing a week that you build entirely yourself. The data layer of a new feature, the base implementation of a pattern everything else will extend. The parts where the design decision is the work. Cost: it’s slower. That’s what you’re paying for. The judgment that makes you worth asking is built by doing the hard part, and it’s the only asset here that doesn’t depreciate when the next model ships.

The agent isn’t the junior engineer in this story. You are the senior one, and the whole value of that role is knowing what should exist before anything gets written. That part hasn’t been automated. It’s just been made much easier to skip.

Reverse Pitch is one post a week on software engineering and the career around it, written from inside the work. Opinions, with receipts.

Subscribe now

What is Clean Code?

Clean code is not following a style guide or some naming convention, although these are very important aspects. At its core, clean code is about writing code that is easy to understand, maintain and extend. It emphasizes clarity, simplicity, and consistency, making it easier for developers to understand and work with.

Books like Robert C. Martin’s “Clean Code” and Steve McConnell’s “Code Complete” provide extensive guidelines on writing clean code. Both of these books offer valuable insights, but it’s essential to remember that they are guidelines, not commandments.

The real essence of clean code lies in the ability to communicate the intent of the program clearly to other engineers (yes, including your future self). However, the interpretation for it can vary depending on the project context.

The Importance of Context

To understand the importance of context, let’s consider Google, one of the world’s leading tech companies. Their approach to clean code demonstrates the importance of context when writing code.

At Google, developers often need to sacrifice certain aspects of readability for the sake of performance. Why? Because they are building tools and services that are used by millions of users concurrently, requiring every bit of performance they can squeeze.

Within this context, writing “clean code” requires you to take a different road (but you should reach the same goal). This might involve:

• Using less intuitive but more performant data structures.

• Implementing complex optimizations that may reduce readability.

• Favoring efficiency over conventional coding patterns.

This doesn’t mean the code is “unclean”. Rather, it’s clean within its specific context, optimized for the constraints and requirements of large-scale, high-performance systems.

Following every fancy article or book from renown engineers may be tempting but remember that your role is not to blindly apply these suggestions (which by no means are bad), but to:

1. Understand the implementation context of each project.

2. Identify the most critical requirements (e.g., readability, performance, security)

3. Apply appropriate coding guidelines and patterns that align with these requirements.

4. Balance different aspect of code quality to achieve the best overall result.

This approach requires critical thinking and often involves making trade-offs. Sometimes, you might prioritize readability and simplicity. Other times, like in Google’s case, you might lean towards performance optimizations.

The Value of Code Reviews

Code reviews play a crucial role in maintaining code quality within a specific context. It serves multiple purposes:

1. Ensuring that every piece of code introduced adheres to the specific coding standards (some of these can certainly be automated through linters and formatters).

2. Catching bugs and potential issues early.

3. Sharing knowledge among team members.

Let’s include a fourth purpose, which is confirming whether or not you reached the goal of writing understandable, maintainable and extendable code.

While code reviews focus on specific requirements and constraints of the project, isn’t it the best place to consider if my fellow team members are able to work with this piece of code introduced?

Reviewers should understand the context in which the code operates and evaluate it accordingly. Only then, code reviews evolve into a crucial piece for building software.

Conclusion

Building great software is inherently a collaborative effort, but aligning multiple minds towards the same goal is often more challenging than it appears. Writing “clean code” is, in essence, a team endeavor. It begins with one engineer crafting code that they believe aligns with the project’s constraints and coding best practices. The process continues as another team member reviews this code, offering valuable feedback and insights.

By understanding the unique needs of each project and applying clean code principles judiciously, we can create codebases that are truly “clean” in the ways that matter most for their specific contexts. This nuanced approach to clean code and code reviews leads to more effective, efficient, and maintainable software systems.

Subscribe now

Python: The Versatile Workhorse

It is very good in Data Science, Machine Learning, Automation, Scripting and Web Development.

Why It’s Good?

• Ease of use: Python’s syntax is simple and readable, making it an excellent choice for new engineers and for rapid development.

• Libraries and frameworks. A vast ecosystem of libraries and frameworks, such as Django and Flask for web development; NumPy, pandas and TensorFlow for data science and machine learning.

• Community support: A large and active community means a lot of resources and tutorials. Based on Stack Overflow statistics, the top tag from questions in the past 3 years is Python.

What It Lacks?

• Performance: Python is generally slower than compiled languages like C++ or Java due to its interpreted nature.

• Mobile Development: While possible, mobile app development in Python is not robust at all and choosing other languages like Swift or Kotlin are way better choices.

Ranked 1 in popularity as programming language (PYPL).

Java: Enterprise Staple

Use very frequently on enterprise applications, android development and large-scale systems.

Why It’s Good?

• Platform Independence: Java’s motto is “write once, run anywhere”. This is thanks to the JVM which is a major advantage for cross-platform development.

• Robustness and Scalability: Java’s strong memory management and scalability make it ideal for large and complex enterprise systems.

• Mature Ecosystem: A mature ecosystem with battle-tested frameworks like Sprint and Hibernate enable rapid development, integration and support.

What It Lacks?

• Conciseness: Java is often criticized for its verbosity, which can lead to more boilerplate code compared to languages like Python or Kotlin.

• Performance: Although better than interpreted languages, Java’s performance if often behind that of C++ or Go for low-level tasks.

Ranked 2 in popularity as programming language (PYPL).

JavaScript: The King of the Web

Best use cases are front-end web development, back-end development (with Node.js) and mobile development (with React Native).

Why It’s Good?

• Versatility: With the advent of Node.js, JavaScript can now be used for server-side development, unifying both stacks.

• Rich Ecosystem: Frameworks like React, Angular and Vue.js revolutionize front-end development, while Express.js, NestJS and Fastify powers back-end services.

• Speed: Node.js, with its event-driven, non-blocking I/O model and single-threaded event loop, can handle multiple concurrent requests efficiently, making it fast and lightweight for I/O-bound tasks.

What It Lacks?

• CPU Performance: For computation-heavy applications, JavaScript may not be as performant as languages designed for such tasks, like C++.

• Language Stability: JavaScript has evolved to cover all bases, and even though that provides a great benefit, it also comes with drawbacks when moving to use-cases that were not part of JavaScript initial conception. Inheritance, incompatible API updates and nested callbacks are some of the common issues that arise when moving JavaScript to the servers (through Node.js).

Ranked 3 in popularity as programming language (PYPL).

C++: Performance Powerhouse

One of the best programming languages for CPU-bound tasks, game development and real-time systems.

Why It’s Good?

• Performance: As a compiled language, it offers excellent performance and fine-grained control over system resources.

• Memory Management: Direct memory manipulation using pointers allow for system-level programming and optimizations.

• Game Development: Unreal Engine, a leading game development engine is built using C++ due to its high performance and control.

What It Lacks?

• Simplicity: C++ is by no means a simple language, especially when delving into more complex concepts like pointers, manual memory management and multiple inheritances.

• Development Speed: Writing, debugging and maintaining C++ code can be more time-consuming than higher-level languages.

Ranked 5 in popularity as programming language (PYPL).

PHP: Backbone of the Web

It is used for server-side web development, CMS and e-commerce platforms.

Why It’s Good?

• Web Focus: PHP is specifically designed for server-side web development and excels in this domain. It has been laser-focus on the same niche therefore creating a strong backbone.

• CMS: Many popular content management systems, such as WordPress and Joomla are built on PHP, providing a vast ecosystem of plugin and themes.

What It Lacks?

• Modern Features: It has been criticized for lacking some modern features, although recent versions may have addressed some of these.

• Concurrency: PHP execution model is not well-suited for handling large number of concurrent connections like Node.js.

Ranked 7 in popularity as programming language (PYPL).

Go: Concurrency King

It is very good for cloud services, DevOps tools and system tools.

Why It’s Good?

• Concurrency: It’s built to support concurrent programming making it ideal for network servers and other concurrent tasks.

• Simplicity and Efficiency: Go is designed for simplicity and efficiency, with a clean syntax and fast complication times.

• Scalability: Go’s performance and efficient memory management make it suitable for large-scale systems.

What It Lacks?

• Standard Library: Go’s standard library is limited and often requires manual implementations for tasks that are usually available out-of-the-box in Python or Java.

• Learning Curve: Go introduce some unique concepts that may take time for developers to wrap in their heads. It may take more time to adopt Go if you come from other language.

Ranked 12 in popularity as programming language (PYPL).

Conclusion

Choosing the right programming language hinges on the specific requirements and constraints of your project. While Python shines in data science and machine learning, JavaScript dominates web development. Java remains a strong choice for enterprise applications, and C++ is unparalleled for performance-critical tasks.

Understanding the strengths and limitations of each language empowers software engineers to make informed decisions, leading to more effective and efficient software development.

References

• Comparing tag trends with our Most Loved programming languages — Stack Overflow

• PYPL PopularitY of Programming Language index

Subscribe now

Share

Celery is a powerful, open-source, asynchronous task queue based on distributed messaging. It focuses on real-time operation but supports scheduling as well. It is normally paired with web frameworks like Django or Flask to handle time consuming tasks outside of the web request/response cycle.

At its core, Celery is designed to handle tasks in the background, making it ideal for uses-cases in which you need to offload tasks to run them efficiently. Celery is highly flexible and can be integrated with a couple of messaging brokers like RabbitMQ and Redis.

Common Use Cases

Let’s go over some common use cases for Celery:

1. Sending Emails

Sending emails is a time-consuming task that can slow down your server’s response time if processed synchronously (waiting for the email to be sent to return a response). Celery allows you to send emails in the background, improving the user experience by making your application more responsive.

2. Generating Reports

Generating large reports can take significant amount of time, from fetching all the required data to transforming it into a visually effective report. Using Celery, you can delegate the report generation process in the background and notify the users once the report is ready to download (or send it via email).

Code Examples

Let’s dive into some code and see how Celery works. We will implement a simple Flask application for this example.

1. Install Celery and Redis

First, you need to install Celery and your message broker (for this example we will be using Redis)

pip install celery redis Flask

(Optional) Run Redis using Docker

Since you will need a Redis instance to start hacking with Celery, a good option is to spin it up using Docker. If you already have Docker installed, simply run the following command:

docker run -d --name redis -p 6379:6379 redis

This command will:

• Download the Redis image if it’s not already present on your system.

• Run the Redis server in detached mode (d), mapping the default Redis port 6379 from the container to your host machine.

2. Create Flask Application

Let’s create a simple Flask application in app.py:

from flask import Flask, request, jsonify
from celery import Celery

app = Flask(__name__)

# Configure Celery
app.config['CELERY_BROKER_URL'] = 'redis://localhost:6379/0'

celery = Celery(app.name, broker=app.config['CELERY_BROKER_URL'])
celery.conf.update(app.config)

@celery.task
def send_email(recipient):
    # Simulate email sending
    import time
    time.sleep(5)
    return f'Email sent to {recipient}'

@app.route('/send-email', methods=['POST'])
def send_email_route():
    data = request.get_json()
    recipient = data['recipient']
    task = send_email.delay(recipient)
    return jsonify({ 'task_id': task.id }), 202

@app.route('/status/<task_id>')
def task_status(task_id):
    task = send_email.AsyncResult(task_id)
    if task.state == 'PENDING':
        response = {'state': task.state, 'status': 'Pending...'}
    elif task.state != 'FAILURE':
        response = {'state': task.state, 'result': task.result}
    else:
        response = {'state': task.state, 'status': str(task.info)}
    return jsonify(response)

if __name__ == '__main__':
    app.run(debug=True)

3. Run Flask and Celery Worker

Run your Flask application:

python app.py

In a new terminal, start the Celery worker:

celery -A app.celery worker --loglevel=info

Let’s describe the whole flow:

1. A client makes a POST request to /send_email with a JSON body containing the recipient’s email.

2. The Flask application will process the request and trigger a Celery task.

3. The Celery worker will receive the task and start the “processing” of sending an email.

4. There is an extra endpoint /status/<task_id> which allows the client to check the status of the task.

Benefits of Using Celery

The above example is an oversimplification of what you can do with Celery, but even so, we can mention a whole list of benefits from it:

Asynchronous Processing

Celery allows task to be executed asynchronously, which can greatly enhance the performance of your server application. In a real-world scenario, in which you have a lot of customers executing actions that requires time-consuming operations, moving those operations to the background can avoid your app to get bloated of requests, impacting the experience of your customers.

Scalability

Celery is designed to be highly scalable, allowing you to distribute tasks across multiple workers (even on different machines). This allows you to horizontally scale your worker pool for tasks that are more demanding without increasing your application server as a whole.

Scheduling

In addition to these real-time tasks, Celery supports scheduling, making it easy to run periodic tasks.

Challenges of Using Celery

There is no silver bullet in technology, therefore we can’t ignore the intrinsic challenges from adding a new tool to your stack.

Complexity

Setting up and managing a distributed task queue can add complexity to your application.

Error Handling

Proper error handling and monitoring are essential to ensure that tasks are not failing silently. Celery supports retry logic and a couple of error handling mechanism, but it’s up to you to use them correctly.

Dependency

Celery relies on external message broker (Redis, RabbitMQ, etc.), therefore it may include a dependency to your project.

Conclusion

Celery is an invaluable tool for any Python developer looking to handle asynchronous tasks and improve the performance of their applications. While it does introduce some complexity, the benefits of using Celery often outweigh the challenges, especially for applications that require efficient task management.

By following this guide, you should now have a basic understanding of how to set up and use Celery in your Python projects. Whether you’re sending emails, generating reports, or handling any other background tasks, Celery can help you manage these tasks efficiently and effectively.

Artificial Intelligence (AI) is becoming an increasingly integral part of the software development process, bringing both exciting opportunities and significant challenges. In this evolving landscape, understanding how AI can elevate your work — from automating boring tasks to supercharging software development — is essential. However, it is equally important to remain aware of the potential pitfalls, such as the risk of reducing engineers to mere operators of AI-driven tools.

This article delves into the transformative role of AI in software development. We’ll explore how this technology is reshaping the developer’s toolkit and landscape, examine its current capabilities and limitations, and consider its implications for the future of the industry.

AI in Development Tools

AI tools are revolutionizing the software development process by automating repetitive tasks such as code generation, bug detection, and testing. While these tools are becoming increasingly popular, their effectiveness depends heavily on the hands that wield them. As an engineer, you need to thoroughly understand and analyze the requirements and constraints of your software project. Using AI tools can assist you with repetitive tasks and provide missing pieces of knowledge, creating a powerful synergy between human intuition and AI assistance.

However, the relationship between developers and AI tools can become toxic when engineers start relying too heavily on these digital assistants, sacrificing their critical thinking in the process. It’s important to remember that these are tools meant to aid, not replace, human creativity. In the current state of AI, and for the foreseeable future, engineers remain the essential minds behind software development, harnessing these tools to enhance their work effectively.

Think of it this way: you shouldn’t ask AI to construct an entire house; instead, you might task it with designing a door. It’s your responsibility as an engineer to ensure that the door is placed correctly and meets all necessary specifications.

To use AI tools efficiently and avoid the trap of overreliance, consider asking yourself these critical questions before accepting generated code or ideas:

• Do I fully understand the requirements of what I need to create or write?

• Can I break down this task into more specific, manageable components?

• Am I capable of critically evaluating the AI-generated code?

• Will this AI-generated code integrate seamlessly with our existing codebase and architecture?

By consistently reflecting on these questions, you maintain your role as the architect of your code, using AI as a powerful assistant rather than an autopilot. This approach ensures that you harness the benefits of AI while retaining control and oversight over your projects, leading to more robust and innovative software development.

AI in Talent Search

AI has significantly impacted the talent search for software engineers, reshaping both sides of the coin with positive and negative implications.

On the recruitment side, AI-powered tools for candidate screening and skill assessment are becoming more prevalent. These tools can speed up the selection process, allowing recruiters to focus on candidates who match the job requirements. However, they can also exclude qualified candidates and may show biases based on the data they were trained on. Therefore, a balanced approach that combines AI with human intuition is essential.

For candidates, the environment has become more controversial due to what is called skill inflation. AI tools can help engineers produce complex code or sophisticated answers to technical questions, potentially masking their true skill levels and making them appear more proficient than they actually are. This makes the recruiter’s job more challenging, leading to a shift in the recruiting process. Recruiters are adding multiple layers of screening and interviews to delve deeper into a candidate’s thought process and problem-solving abilities.

This shift has made both job searching and talent acquisition more complex, sparking debate on whether AI benefits or detriments the recruitment process overall.

I believe that in this area, it is crucial for both parties to maintain high levels of integrity and honesty to navigate the increasing complexity in acquiring good talent or finding a suitable job.

Conclusion

Ultimately, the role of AI in software development is a powerful tool that, when used correctly, can greatly enhance the capabilities of engineers and the efficiency of development processes. However, it’s crucial to approach AI with a balanced perspective, leveraging its strengths while remaining vigilant about its limitations. By doing so, engineers can navigate the evolving landscape of AI in software development with integrity and innovation, ensuring a bright future for the industry.

This guide is about profiling and testing using tools that you can run on your computer, which is very useful to detect memory leaks, bugs or under-performing code before pushing to production.

These techniques are not a replacement for cloud monitoring and observability tools, they cover way more ground and provide a lot of insight about your application (but they are also expensive).

Load Testing

Load testing is a technique that simulate real-world conditions to understand the behavior of an application under heavy load. It allows engineers to foresee and fix potential performance issues before they affect real users.

We’ll be using locust to load test a simple Flask application in order to show how we can simulate real-world scenarios through its powerful, scriptable nature.

We will need to install some dependencies:

pip install flask Faker

Now, let’s code a simple a Flask application (app.py):

import random
from faker import Faker
from flask import Flask, jsonify

fake = Faker()
app = Flask(__name__)


def generate_users():
    """
    Generate a list of random users.
    """
    users = []
    for i in range(100):
        users.append(
            {
                "id": i,
                "name": fake.name(),
                "age": random.randint(18, 99),
                "email": fake.email(),
            }
        )

    return users


def generate_user(user_id: int):
    """
    Generate a random user by ID.
    """
    return {
        "id": user_id,
        "name": fake.name(),
        "age": random.randint(18, 99),
        "email": fake.email(),
    }


@app.route("/users", methods=["GET"])
def list_users():
    """
    List users endpoint.
    """
    return jsonify({"status": 200, "users": generate_users()})


@app.route("/users/<int:user_id>", methods=["GET"])
def get_user(user_id: int):
    """
    Get user by ID endpoint.
    """
    return jsonify({"status": 200, "user": generate_user(user_id)})


if __name__ == "__main__":
    app.run(debug=False)

We can run this application by simply executing: python app.py.

You can perform a GET /users request to visualize the list of users:

# Using cURL
curl localhost:5000/users

# Or simply visit <http://localhost:5000/users> in your browser

Now that we have an application to put under load test, let’s get started with locust. First, let’s install it:

pip install locust

Once installed, we’ll write a locustfile.py that defines the behavior of our simulated users. In the script, we’ll specify the endpoints that locust should hit and the wait time before each defined task.

import random
from locust import HttpUser, task, between


class SimulatedUser(HttpUser):
    wait_time = between(1, 5)

    @task(1)
    def view_users(self):
        self.client.get("/users")

    @task(4)
    def view_user_by_id(self):
        user_id = random.randint(1, 100)
        self.client.get(f"/users/{user_id}")

The above code presents an example of how to use Locust, a popular load testing tool, with a Flask application. Here is a detailed description of the key concepts involved:

• HttpUser: This is a class represents a simulated user and they should mimic real world users. In the script, we define a class SimulatedUser that inherits from HttpUser.

• Task: The task decorator is used to specify methods that the HttpUser should execute when simulating a user.

• wait_time: This is a property of the HttpUser class that specifies how long a simulated user should wait between executing tasks.

We can now run our Locust script by simply executing:

locust -f locustfile.py

This will spin up a web interface at http://localhost:8089 in which you can specify your testing arguments as follow:

In this interface, we define three main arguments:

• Number of users: Total number of users you want to simulate at peak concurrency.

• Ramp up: The number of users that will be simulated per seconds (in our example it means that 10 new users will be added to the load each second until they reach the peak which is 1000).

• Host: This is the host of your server application that each user will target while executing their tasks. Since our Flask application is running locally on port 5000, the value here is http://localhost:5000

Click the Start button, you Locust will start the load test. The first tab that you will notice is the Statistics one, in which you can view a table with all the requests executed and their response time and some other stats.

Let’s move to the Charts tab to get a more friendly representation of your application performance. Here you will get three charts:

• Total Requests per Second: This is basically the number of requests your application is handling per second.

• Number of Users: The last chart simply indicates the number of users over time.

• Response Times (ms): This is how long your application is taking to response the requests. You will see two lines here:

  • Average Response Time: Which as the name states, is the average response time it takes.

  • 95th percentile: Which indicate the response time below which 95% of all recorded response times fall. For example, if the 95th percentile response is 50ms, it means that 95% of the requests were completed in less than 50ms, while the remaining 5% took longer.

    
    It’s important that your 95th percentile isn’t significantly higher than the average response time, since it may indicate performance issues on an important subset of users.

There are other tabs in which you can monitor the Failures or Exceptions that may have occur during the tests. This is very important since you can debug possible failures that only happen during heavy-load scenarios.

Locust also allows you to download the report in a HTML format so you can visualize later and compare it after you have improved your application.

Memory profiling

Memory profiling consist in analyzing a program’s memory consumption to identify and solve issues related to unusual memory usage. It helps you understand how you application allocate resources and its very useful when sizing your cloud instances correctly.

There are multiple tools for memory profiling out there, but for today post, will be using memray because of its ease of use and the various reports it can generate.

Let’s install it using pip:

pip install memray 

Using our Flask application built above, let’s now perform memory profiling:

memray run -o result.bin app.py

Once the application is running, you can perform the load test defined above to simulate a real-world scenario while memray tracks the memory usage.

After running the load test for a while, simply stop memray (Ctrl + C the process) and it will generate a result.bin file with all the tracked data.

Now we can generate a report using the following command:

memray flamegraph result.bin

This will generate a flame graph in HTML format for you to visualize in your browser. Flame graphs are a visualization of program resource usage that help identify which parts of your code are consuming the most memory during execution.

Each block on the x-axis represents a function in the code, with the size of the block representing the amount of memory that function uses. The y-axis represents the stack depth. memray actually defaults to the Icicles view which is basically inverting the y-axis so the root is at the top and the functions at the bottom. You can choose either view based on your preference.

However, the critical detail to note is the width of the function blocks. The wider a block is, the more memory has been allocated to that function. Therefore, if a block appears unusually wide, it could indicate that a potential memory leak is affecting your application.

Another very important graph within memray is the memory size over time, which you can see by clicking the header with the orange and blue lines. In this graph you can see the Resident Size and the Heap Size and how much memory is allocated over time.

This graph is crucial because, under normal circumstances, you would expect these lines to maintain a specific range. If your application includes memory-bound endpoints, you might anticipate some spikes. However, based on how you’ve defined your load test, these lines should normalize once the memory-bound endpoints have completed their tasks. Consequently, if a line continually grows over time without ever decreasing, it’s a significant sign of a memory leak.

Bonus: Simulate memory leak

As a bonus section, let’s simulate a memory leak so we can see how both tools can help us identify it.

First, let’s update our Python code so we introduce a memory leak endpoint (something you should never do in production):

# Intentional memory leak: a growing list
leaked_data = []


@app.route("/leak")
def leak_memory():
    """
    Memory leak endpoint.
    """
    leaked_data.append([i for i in range(10000)])
    return jsonify({"status": "Memory leaked!"})

Every time a request is made to this endpoint, a list of 10,000 integers is created and appended to a global list named leaked_data. Because leaked_data is a global list and is not cleaned up after each request, the memory it uses does not get freed up. This means every time a request is made to the /leak endpoint, more and more memory is used up, simulating a memory leak.

Let’s update our locustfile.py to include this endpoint call:

import random
from locust import HttpUser, task, between


class SimulatedUser(HttpUser):
    wait_time = between(1, 3)

    @task(1)
    def view_users(self):
        self.client.get("/users")

    @task(3)
    def memory_leak(self):
        self.client.get("/leak")

    @task(4)
    def view_user_by_id(self):
        user_id = random.randint(1, 100)
        self.client.get(f"/users/{user_id}")

Now, we can simply run the application using memray:

memray run -o result.bin app.py

And the load test using locust:

locust -f locustfile.py

Once you’ve set up your load test parameters and allowed it to run for some time, you should terminate the memray process. This will generate a result.bin file containing the tracked data. You can then produce a flame graph using this data:

memray flamegraph result.bin

Now let’s review both statistics generated by Locust and Memray:

As the number of our requests increases, we observe that our response times largely remain consistent, barring a single spike. This was expected since the memory leak we introduced does not significantly affect the CPU performance of the application. Thus, we could conclude that our application has successfully passed its load test.

Here, we can observe more alarming graphs. As explained earlier, the wider the function blocks, the higher the memory allocation. Therefore, it’s easy to identify that the leaked_data.append(...) block is responsible for the unusual memory consumption.

Examining the memory size over time, we notice that it grows but never shrinks. This indicates a memory leak, as memory is not being released. This issue arises due to the use of a global variable in our example.

As you can see, memory profiling empowers you to detect issues within your application quickly and efficiently, eliminating the need for long hours of debugging and excessive memory usage logging.

Conclusion

Ensuring that your application is both efficient and capable of handling high traffic is very important in software development. Through the use of memory profiling and load testing, developers can proactively identify and resolve performance bottlenecks and memory leaks before they affect end users.

The goal of this guide is to equip you with the tools needed to understand how your application behaves under various loads and to detect unusual memory consumption before it impacts your users. By using load testing and memory profiling, you can identify and address performance issues proactively, ensuring a smoother experience for your customers.

Feel free to experiment with these tools and adapt them to your specific needs. Happy profiling and testing!

• Make the client wait for the response, which make takes more than a minute. (Bad choice)

• Handle it using a queue and return a task/job resource from which the client can query the progress and eventually the result. (Good choice)

These situations are very common, and turning a long running job into a resource will make your implementation more robust and gives you benefits in both client and server.

How can we do this?

We accomplish this using an event-based architecture. Basically, our Web API will create a task/job and publish it to an Event Broker. An Event Broker is like an administrator who listen the messages of other services and publish them to specific "spaces" (channels) where other services are waiting for new messages. Take a look to the image below to better understand it:

Here we have a very simple (and summarized) diagram in which a client will be requesting the server to apply a cool filter to an image.

Let's assume this process is long (which may be depending on the filter🤳) and making the client wait for it could result in HTTP timeouts or making the site freeze for several seconds.

In order to tackle this, the Web API will create a Task and send the reference (a unique id) back to the client. Then, the Web API will publish a message to the Event Broker telling the Workers (Image Resizer, Image Processing and Image Upload) that there is a new job for them. These workers can subscribe to channels/topics in the Event Broker, and when a new message arrive to one of those channels it will notify everyone who is subscribed.

The Workers will start making their job and publishing messages on the Event Broker when they finish (either if the job succeeded or failed). The Web API must be subscribed to these "result" channels and will update the Task status depending on the progress made by the workers. When all Workers finish their jobs successfully, the Task status will change to completed and the URL of the filtered image will be available for the client.

But wait, how will the client receive the new URL of the filtered image🤔? Well, there are several ways to do this.

HTTP Polling

HTTP Polling is one way to solve this. It consists of repeating an HTTP request over an interval of time. Basically, we will be making a request using the Task reference to the server and if the status is not "Completed" (or "Failed") it will retry again after X seconds.

Web Sockets

Using Web Sockets the server can send an event to the client when the Task gets completed so the client will get the filtered image when it's ready. This is a better approach in terms of resource consumption but would require adding the complexity of web sockets to your application.

Either way, our client can now get the filtered image without having to make an HTTP request that takes over a minute to complete🎉.

Side notes

• When creating the task/job resource, the correct HTTP status code is 202 Accepted. Also, a reference of the task should be sent, like an id or an uri if you are using REST.

• Cool kids allow the jobs to be deleted from the queue using the reference received on creation. Be a cool kid.

• Pro kids add an expiration date to tasks, so they don't overwhelm the server. Be a pro kid, even if you are not a cool kid.

Conclusion

There are several patterns and architectures that handle these cases, this is just a personal preference, and I would really like to read your approaches and recommendations in the comment section😁.