SoftwareEngineering

Jev and the architectural relief of an AI that refuses to write

There is a profoundly silly habit currently sweeping the software engineering world. We have a tiny, binary decision to make, so we summon a massive neural network. Is this support ticket urgent? Should the digital agent retry a failed search? Which tool should handle this query? To answer these deeply pedestrian questions, we take a model trained on the entire sum of human knowledge, capable of discussing quantum mechanics and composing a surprisingly competent resignation letter, and we force it to choose between the billing and technical support departments.

It works, in the same way that hiring a Michelin star chef to sort nuts and bolts in the back room of a hardware store works. It gets the job done, but it is a tragic and baffling waste of potential.

At a few requests per minute, nobody notices. At one hundred thousand requests, the architecture begins sending little postcards from reality. Latency rears its ugly head. Token bills pile up like parking tickets. Down in the server racks, the load balancers begin to sweat and hyperventilate because the model is spending vital milliseconds trying to decide which synonym for “frustrated” feels most empathetic, only to stuff that emotional labor into a sterile, soulless JSON output. Then somebody has to create an entirely new dashboard just to monitor the system that was supposed to make everything simpler.

Jev, a model released by TypeSafe AI in September 2026, starts from a refreshingly mundane assumption. Maybe the machine does not need to talk. Maybe it just needs to point.

Words are an expensive luxury for a server

Large language models are fundamentally generative machines. They receive tokens and produce more tokens, one after another, sequentially, until they have constructed an answer. That flexibility is exactly why they are so useful. It is also wildly extravagant when all you actually need is a “true” or “false” boolean.

Picture an exceptionally talented Victorian scholar acting as a modern management consultant. You ask him a simple question about whether a minor software incident should be escalated. The scholar clears his desk, meticulously examines the evidence, writes a beautifully structured three-page memorandum on the nature of urgency, and eventually concludes with a polite “Yes.” Software did not want the memorandum. Software just wanted the yes.

LLMs increasingly support structured output, constrained decoding, and JSON schemas. These tools make them much easier to wedge into modern applications. But underneath the hood, the architecture is still stubbornly built around generating sequences of text. For tasks involving writing, complex reasoning, generating code, or patient explanation, a sequence of text is exactly what we want. For millions of repetitive, strictly bounded decisions, it is a catastrophic overkill.

TypeSafe calls Jev a System One model, borrowing the psychological terminology made famous by Daniel Kahneman. Instead of generating sweeping prose, Jev is designed specifically for fast, blunt decisions that can be swallowed directly by software without chewing. The architectural distinction is far more important than the product itself.

The joyless clerk of the artificial intelligence world

Jev’s interface is almost aggressively uninterested in conversation. You provide some state representing what your program currently knows, and then you ask one or more strictly typed questions about it. The answers come back as typed values attached to probabilities.

There are currently three main primitives. Choice selects from a predefined set of options. Score evaluates something along a defined mathematical scale. Noul handles yes-or-no judgments and returns a probability. Noul is just TypeSafe’s quirky terminology for a Boolean, but we can forgive them for trying to brand it. The API allows several of these dry questions to be submitted in the same request, with the answers neatly mapped back to their question names.

This creates a rather different programming model. An LLM might receive an angry customer message and proudly produce a sentence explaining that the customer appears frustrated, the issue seems technical, and therefore it recommends routing the request to the technical support team with elevated priority. This is wonderfully useful if you are a human being reading a screen.

Software, however, prefers a world that looks like this:

department = technical

frustration = high

urgent = true

Plus, software wants probabilities telling it exactly how much blind faith to place in those decisions. Jev is deliberately built for this second, colder world.

TypeSafe describes the underlying training approach as Reinforcement Learning for Calibrated Decisions. The objective is to produce mathematical probabilities that reflect genuine uncertainty, rather than producing the kind of confident prose that humans find pleasing to read. Questions in the same request are evaluated in parallel rather than being generated one agonizing token after another.

The result is less “conversational artificial intelligence” and more “intelligent conditional logic.” It is a fuzzy if statement. This sounds considerably less exciting than artificial general intelligence, but it turns out to be immensely more useful inside a production system trying to keep the lights on.

Pulling your hand off the hot stove

Kahneman’s System One and System Two distinction provides a brilliant mental model for what is going wrong in our server farms. System Two handles deliberate, exhausting thought. It is the individual who sits rubbing their chin in front of a chessboard, evaluating seventeen possible moves and their downstream consequences.

System One is the primal instinct that makes you violently yank your hand away from a hot stove because you smell burning hair.

Modern reasoning models are spectacular System Two machines. Give them a complicated architectural diagram, a highly ambiguous security incident, or a tricky programming task, and their ability to reason through it can be extraordinary. But production software contains an ocean of System One questions.

Is this credit card transaction suspicious? Which queue gets this mundane ticket? Does this generated response contradict the source material? Should this digital agent search the web? Is this request safe enough to process automatically without calling a lawyer?

We have spent the last few years applying increasingly powerful System Two chess players to a surprising number of System One hot stoves. Jev’s entire existence is an argument that we have been using a massive reasoning hammer on tiny, decision-shaped nails. It is not trying to replace an LLM. It is trying to stop us from calling one when we never needed a paragraph in the first place.

Benchmark trophies and the inevitable vendor asterisk

TypeSafe advertises Jev as reaching roughly 70 to 500 milliseconds end to end. They report gains ranging from tens to hundreds of times in speed and cost on workloads designed around structured decisions. Their headline benchmark currently boasts that Jev is 193.6 times faster and 444.6 times cheaper in their workflow evaluations.

Those are undeniably impressive numbers. They are also vendor numbers, which means they should be treated with the same suspicion you apply to a real estate agent describing a house as “cozy.”

TypeSafe rightfully acknowledges several caveats. Their workflows were created internally, the reference answers come from frontier models rather than objective ground truth, and some comparisons use configurations that are particularly favorable to Jev’s execution model.

Fortunately, more interesting evidence is beginning to appear out in the wild. MotherDuck tested Jev on one hundred thousand articles from a news classification dataset. Jev chewed through them in around forty seconds for fifty cents and achieved an 89 percent accuracy rate.

GPT-4o mini took almost twenty minutes, cost nearly two dollars, and hit 80 percent accuracy. GPT-5.6 Terra achieved 88 percent accuracy but spent nearly thirty-two minutes doing it and cost a staggering thirty-seven dollars.

Now the comparison becomes genuinely useful. Not because Jev is magically four hundred times better than an LLM. It isn’t. The useful conclusion here is that bounded classification may not require generation at all. That is an architectural observation, not a shiny benchmark trophy. And as usual, the only benchmark that will eventually matter is the one running on your own servers.

Putting the rubber stamp before the eccentric artist

The absolute best use of Jev is not replacing an LLM. It is standing directly in front of one like a bouncer at a nightclub.

Consider an AI agent trying to decide which tool to invoke. Perhaps its options are answering directly, searching the web, querying a database, running code, or asking the user for help. There is absolutely no reason the routing decision itself needs a beautifully written paragraph of justification.

Jev can make the routing decision and hand back its confidence score. If the confidence is sufficiently high, the workflow proceeds immediately. If the confidence falls below a set threshold, the system escalates the problem to a more capable, expensive reasoning model. If the consequences are particularly dire, it escalates to an actual human being.

This gives us a beautifully practical architecture. Cheap decisions happen first, and expensive reasoning is reserved for when it is strictly necessary.

The same pattern works flawlessly for support triage, content moderation, incident classification, lead scoring, and agent evaluation. It also creates a fascinating verification layer. Let the expensive, eccentric genius LLM generate an answer. Then, let Jev act as the joyless clerk with a rubber stamp, checking whether that answer actually addresses the question, matches company policy, or is supported by the supplied context. The expensive model creates. The inexpensive model checks. Humans only ever see the weird, uncomfortable edge cases.

That last part matters because the probability score may ultimately be more useful than the decision itself. Automation rarely fails because software cannot choose between option A and option B. Automation fails because nobody knows when the machine should be trusted to make that choice without adult supervision.

Please do not let conference demos dictate your infrastructure

There is one extremely obvious trap here. If your entire architecture depends on confidence thresholds, those mathematical probabilities need to actually mean something.

An independent evaluation published recently tested Jev across thirty-seven datasets and more than three hundred thousand requests. The researchers found Jev’s choice probabilities to be generally well calibrated and highly useful for selective prediction. Binary probabilities, however, were more troublesome when treated with a rigid 0.5 threshold. Performance only improved significantly when those thresholds were tuned using task-specific data.

That is probably the single most useful lesson for a software architect. Do not write a rule that says “if confidence is greater than 0.8” just because somebody used 0.8 on a slide during a flashy conference demo. You have to measure it.

Maybe 0.74 is perfectly safe for routing a low-priority IT ticket. Maybe 0.97 is absolutely necessary before an automated security system blocks a user. Maybe no threshold on earth is acceptable for autonomously deleting customer data, which would be reassuring evidence that human common sense remains a commercially viable trait. Confidence only becomes useful infrastructure when you calibrate it against the consequences of being wrong.

The jobs a joyless clerk should never get

The limitations of this new architecture are unusually easy to explain. Jev cannot write.

If the output needs to be read by a human, explained, rewritten, summarized, or turned into functional code, you still want a traditional language model. Furthermore, the possible answers need to be known completely in advance. The Choice primitive supports a finite set of alternatives, currently with cardinality limits that make it totally unsuitable for arbitrary open-ended generation. (TypeSafe documents Choice cardinality up to 255 options, which is plenty for routing but useless for brainstorming).

It is also currently designed strictly around structured and textual state, rather than being a magical, all-seeing multimodal model.

And sometimes, an explanation matters far more than the blunt decision. A security system shouting “BLOCK 0.96” might be operationally useful in the heat of the moment. But the next morning, an auditor is still going to ask why the block happened. At which point, System Two gets another reluctant invitation to the meeting to explain the mess.

Building an oracle just to empty the digital trash

It is very tempting to treat Jev as just another minor model launch and ask whether it beats GPT-this or Claude-that. Doing so completely misses the impending architectural shift.

For several years, the AI stack has been dominated by one wonderfully convenient but bloated primitive. Send text to an LLM. Receive text from an LLM. Repeat the process until the venture capital funding improves.

Decision models suggest that the software stack is finally beginning to separate its responsibilities. Generative models will be kept around to reason, explain, code, and communicate. Decision models will step in to classify, route, score, verify, and trigger. Normal, boring software will handle everything deterministic that happens in between them.

That is a vastly healthier architecture, because intelligence stops being a single, enormous, expensive API call and becomes just another component that can be composed according to cost, latency, and risk. Jev might dominate this new category, or a competitor might crush them in six months. The category itself is what matters.

The name Jev is a subtle nod to the 19th-century economist William Stanley Jevons and the paradox forever associated with him. The Jevons paradox states that making a resource more efficient does not necessarily reduce our consumption of it. In fact, making it cheaper and more efficient usually makes us use vastly, absurdly more of it.

That might turn out to be the most important part of this whole story. When an intelligent decision costs a dollar, we reserve artificial intelligence for highly important decisions. When it costs fractions of a cent and arrives in milliseconds, we start cramming intelligence into places where nobody in their right mind would have ever considered paying an LLM to look.

We will suddenly find our software making millions of tiny, mundane judgments that nobody previously thought were worth making. Not because AI finally learned how to write better. But because we finally taught it how to shut up and point. And so, we arrive at the ultimate punchline of human engineering. We have successfully invented the most sophisticated reasoning engine in the history of the universe, and we are going to use it to decide whether an email offering a discount on sneakers belongs in the spam folder.

October 4, 2026 by Fernando SRE Cloud stuff Computer Science stuff

Poking dead servers with a long stick

Let us discuss the biological absurdity of the modern distributed system. You took a perfectly healthy, monolithic software organism and chopped it into a thousand fleshy little pieces, hoping they would communicate flawlessly via telepathy. Congratulations on your trendy new microservice architecture. You have not eliminated failure. You have merely sprayed it across a much wider geographic area, much like a sneeze in a crowded elevator. Now, instead of one predictable, honest crash, you get the distinct thrill of watching a single sluggish database slowly asphyxiate an entire ecommerce empire.

Welcome to the domino effect of modern software anatomy.

The pathology of a fragile network

Networks are pathological liars. They will hand you a glossy brochure promising 99.99 percent absolute uptime, but they will gladly drop your data packets into a black void the moment a slightly distracted contractor named Gary clips a buried fiber optic cable with a backhoe in rural Nevada. The physical reality of the internet is just dirt, glass, and human error.

When Service A politely asks Service B for a user profile, and Service B decides to take a spontaneous, catatonic nap, Service A does not simply walk away. It stands there. It holds open a network connection, consumes a vital thread of server memory, and stares blankly into the middle distance.

If you multiply this behavior by ten thousand concurrent users, you trigger a physiological crisis known as thread pool exhaustion. Your servers are now experiencing the digital equivalent of full organ failure. They are holding their breath, turning blue, waiting for a response that will never, ever arrive. The entire system locks up, your CEO’s pager shrieks at three in the morning, and you are left in the unenviable position of explaining why a minor hiccup in a wildly unpopular newsletter signup widget successfully assassinated the global payment gateway.

Treating your infrastructure like a flaky friend

To survive this architectural nightmare, you must abandon the delusion that your servers are reliable professionals. You must treat them like that one unreliable acquaintance who constantly forgets their wallet at dinner and occasionally faints in public. You need to implement an intervention. You need a circuit breaker.

The humble timeout is your first line of defense. This is the fine art of setting a strict, unyielding timer on your own patience. If a downstream service does not respond in two hundred milliseconds, you violently sever the connection. It is exactly like walking away from a barista who has been staring unblinkingly at a single coffee bean for ten consecutive minutes while a line forms out the cafe door. A timeout ensures your system does not waste precious metabolic energy waiting for a lost cause.

Sometimes, of course, a failure is just a biological blip. A momentary digital hiccup. So, you retry the request. But here lies a fatal trap for the overly optimistic engineer. If five thousand instances of your application instantly retry a failing API at the same millisecond, you have not built a resilient system. You have built a self-inflicted stampede.

You must use exponential backoff, which means waiting longer between each frantic attempt, combined with jitter, which adds a sprinkle of mathematical randomness to the wait time. Instead of your requests acting like a synchronized mob of impatient shoppers trying to smash through the glass doors of a mall on Black Friday, they behave like a group of mildly awkward guests politely knocking on a bathroom door at totally irregular intervals.

The anatomy of an electrical intervention

Circuit breakers have three distinct physiological states, and they operate much like a stressed human nervous system. We begin with the closed state. In electrical terms, closed means the current is flowing beautifully. The system silently monitors the background failures, much like your immune system quietly disposes of mutant cells without bothering your conscious brain. As long as the error rate stays below a defined threshold, the circuit remains closed. Ignorance, in this highly specific context, is pure bliss.

But once the failures cross your designated threshold, say, fifty percent of requests vanish into the ether within ten seconds, the circuit violently opens. The breaker trips. All subsequent calls to the failing service are instantly blocked. No waiting, no polite timeouts, just an immediate and hard refusal.

Think of the open state as a digital restraining order. You are giving the overwhelmed, hyperventilating downstream service a chance to breathe, reboot, or extinguish whichever physical server rack is currently melting into a puddle of expensive plastic. You amputate the limb to save the patient.

Eventually, you need to know if the fire is out. After a mandatory cooldown period, the breaker enters the half-open state. It cautiously lets one or two requests slip through the barricade to test the waters. This is the architectural equivalent of poking a corpse with a very long stick to see if it twitches. If those brave scout requests succeed, the system assumes a resurrection has occurred, the circuit closes, and normal traffic resumes. If they fail, the breaker snaps open again, and the waiting period restarts from scratch.

Handing out cardboard boxes to angry toddlers

When the circuit is aggressively open, you need a backup plan. You cannot just leave your users staring at a blank screen. This concept is called graceful degradation.

If your ultra-personalized, wildly expensive artificial intelligence recommendation engine falls unconscious, you do not throw a catastrophic internal server error at your customer. You return a static, heavily cached list of generic top-selling items. It is the exact equivalent of handing a toddler an empty cardboard box because their expensive remote control car just shattered into pieces against a wall. They will not love the box quite as much, but it distracts them, it provides a fleeting moment of joy, and most importantly, it stops the screaming.

How to avoid going to jail over a toaster

We must read the fine print before you run off to implement this on your production servers. Do not casually throw retries at every single problem you encounter.

Retrying a read request, like fetching a user profile picture, is perfectly safe. Retrying a write request that is not idempotent, like charging a credit card, is exactly how you end up the star defendant in a messy class action lawsuit. If your timeout triggered merely milliseconds after the payment processor actually received the initial request, hitting retry means the customer just bought that premium stainless steel toaster twice. Or perhaps three times, depending on how aggressively your system panicked. Your users will not be amused when a pallet of kitchen appliances arrives at their front door.

Furthermore, you must beware of nested timeouts. If your primary API gateway has a timeout of two seconds, but the underlying microservice deep in the server basement has a timeout of five seconds, the gateway will hang up the phone on the client long before the job is done. Meanwhile, the microservice is still cheerfully crunching data in the dark, entirely unaware that the customer has already left.

It is a spectacular waste of compute power. It is akin to a Michelin star chef meticulously garnishing a five-course meal for a restaurant guest who already climbed out the bathroom window and is currently sprinting down the highway.

Ultimately, building resilient systems is not about preventing failure. Believing you can prevent failure is a delusion reserved for people who do not work with computers. Failure is a mathematical certainty, an inevitable decay akin to biological aging. True engineering is about orchestrating that failure so elegantly, so quietly, that nobody notices the kitchen is currently engulfed in flames. You design for disaster, you code for catastrophe, and then, miraculously, you might just get to sleep through the night without your pager screaming at you about a dead database.

AWS Proton or how to stop developers from burning down the infrastructure

Writing code is a clean, almost intellectual pursuit. You sit in a quiet room, sip your beverage of choice, and arrange logic into a beautiful digital tapestry. If you do your job well, the application works perfectly on your laptop. But then comes the moment when you must share your creation with the rest of the world. This is where the poetry ends, and the manual labor begins.

Suddenly, you are no longer a software creator. You are an amateur construction worker trying to pave a highway while driving on it. You find yourself wrestling with security configurations, arguing with network routing protocols, and praying that your cloud deployment pipelines do not collapse under the weight of a single misplaced space in a configuration file. For many developers, managing the cloud feels like buying a brand-new television, only to discover that you have to personally run copper wire to the local power plant just to turn it on.

While looking into how modern cloud infrastructure operates, I spent some time investigating AWS Proton. The philosophy behind this service is fascinating because it tackles one of the oldest, most polite cold wars in the history of office environments, the constant struggle between the people who build software and the people who keep the servers from catching fire.

The high cost of giving matches to creative people

When a software company is small, cloud infrastructure is a domestic affair. You might have two developers and a single cloud account. If someone needs to deploy a new feature, they simply log in, click a few buttons in a console, and hope for the best. It is chaotic, but it is a cozy kind of chaos.

Once a company grows, however, teams multiply. If you leave developers to their own devices without any central coordination, they will inevitably invent their own highly creative, deeply eccentric ways to deploy their code.

One team might rely on custom scripts that only run on a specific laptop currently sitting under a coffee-stained desk. Another team might build a labyrinth of configuration files that are so complex they resemble ancient runic spells. A third team might simply copy and paste outdated templates they found on an internet forum, hoping that nobody notices the glaring security vulnerabilities hidden inside.

Before you know it, your corporate cloud architecture looks less like a modern facility and more like a crowded public pool where nobody is paying attention to the lifeguards. The challenge is no longer about writing good code. It is about preventing the sheer variety of deployment methods from driving your operations team to physical and emotional exhaustion.

Dividing the kitchen between the chefs and the safety inspectors

This is where AWS Proton enters the room, holding a clipboard and looking very serious. The easiest way to understand the service is to look at how a professional restaurant kitchen operates.

If you let every line cook design their own stove, choose their own gas pressures, and source their own fire extinguishers, the restaurant will burn down before the first appetizer is served. Instead, a master chef designs the kitchen layout once, sets up the safety parameters, and ensures the prep stations are stocked. The line cooks can then focus entirely on cooking the food without having to worry about plumbing or municipal gas lines.

AWS Proton does exactly this for cloud deployments by separating your engineering department into two distinct, cooperative camps.

The platform engineers act as the safety inspectors. They define the corporate standards, write the reusable infrastructure templates, and establish secure delivery pipelines. They build a safe sandbox with very tall, very soft walls.

The developers act as the creative chefs. Instead of writing custom deployment configurations from scratch, they simply log into a self-service portal, select an approved template, and deploy their applications. They do not have to know how the network routing works under the hood. They just need to know that their code has a safe place to run.

The magic of filling out a form without crying

To see how this works in practice, we can look at what this separation actually looks like on a file level.

First, the platform team defines what a standard, secure service should look like. They write a schema file using YAML, which is the industry-standard language for telling computers how to build virtual networks.

Here is a simplified example of what a platform engineer might write to define an environment template:

schema:
  format:
    version: "1"
proton: EnvironmentTemplate
index:
  name: "secure-ecs-fargate-environment"
  version: "1.0"
  description: "A standard environment with sensible defaults so nobody accidentally exposes our database to the open internet"

This template is stored centrally in AWS Proton. It acts as an official blueprint.

When a developer wants to deploy a new microservice, they do not need to read through hundreds of lines of infrastructure code. They do not need to learn how to configure an AWS load balancer. Instead, they write a very simple specification file that only asks them for the details that actually matter to their application.

Here is what the developer’s configuration file looks like:

proton: ServiceSpec
  spec:
    inputs:
      image_tag: "v2.1.0"
      container_port: 8080
      cpu: "512"
      memory: "1024"
      billing_tag: "marketing-campaign"

The developer only has to specify the basic dimensions of their application, such as how much memory it needs and which port it uses. AWS Proton takes this small file, combines it with the platform team’s secure blueprint, and builds the entire system automatically. The developer gets their application deployed in minutes, and the platform team can sleep at night knowing that nobody used insecure settings.

The industrialization of the digital assembly line

If you are just learning the basics of cloud computing or building a personal website to display pictures of your cat, AWS Proton is almost certainly more tool than you need. It is the industrial equivalent of buying a commercial cement mixer to repair a crack in your driveway.

But if you look at where the wider technology industry is heading, services like AWS Proton represent a massive cultural shift. For the past decade, the industry told developers that they needed to know everything. They were told to write the code, configure the networks, manage the databases, and monitor the security alerts. We called this DevOps, and while the intentions were noble, it often resulted in highly skilled programmers spending half their week acting as frustrated system administrators.

Companies are starting to realize that cognitive overload is real. If you force a developer to become an expert in cloud networking, they will have less energy to spend on making your product actually work.

The rise of platform engineering is a quiet admission that we need specialists. We need people who are incredibly good at building secure, stable platforms, and we need to let everyone else use those platforms without having to understand the underlying physics of the cloud.

Some parting thoughts on staying warm without catching fire

The more you look at modern cloud architectures, the more you realize that the hardest problems are rarely technical. Computers will almost always do exactly what we tell them to do, provided we format our instructions correctly. The real friction exists in the human systems we build around those computers.

AWS Proton is an attempt to reduce that human friction. By turning infrastructure into a collaborative, template-driven system, it allows different teams to work together without constantly stepping on each other’s toes.

If you are currently studying cloud technologies or preparing for a career in platform engineering, understanding these patterns is incredibly valuable. The future of software development is not about making systems more complex. It is about building elegant interfaces that keep us from burning down the very things we are trying to build.

July 1, 2026 by Fernando SRE Cloud stuff Computer Science stuff DevOps stuff SRE stuff

The upskilling industry is selling you expired AI anxiety

Last week, someone in your LinkedIn feed posted about being thrilled to build AI agents over the weekend. The post had forty-seven likes, a handful of rocket emojis, and several comments praising their growth mindset. You stared at the screen and felt a familiar, dull panic in your gut. It was not inspiration. It was the exact same feeling you get when you watch someone pretend to genuinely enjoy a room-temperature kale and gravel smoothie.

Nobody with a healthy central nervous system is genuinely thrilled to learn prompt engineering frameworks on a Saturday morning. They are just terrified of what happens to their mortgage if they do not.

You probably have your own personal monument to this anxiety. It is a browser tab you keep meaning to open. A course you bought during a Black Friday panic sale and never started. A corporate Slack thread about AI readiness that you skimmed, starred, and immediately buried under a pile of actual work. It is the quiet admission that you do not know enough to stay relevant, paired with the even quieter admission that simply bookmarking the resource made you feel slightly less like a dinosaur.

You have been writing production code, configuring infrastructure, and surviving catastrophic deployment rollbacks for years. By most reasonable measures, you know exactly what you are doing. And yet, that browser tab sits there. It is a digital talisman against obsolescence.

There is a name for this modern condition. I call it competence debt. It is the silent, creeping rot that happens when you trade durable mastery for perishable certifications. And an entire multi-billion-dollar upskilling industry is banking on you never figuring out the difference.

The ecosystem of the forgotten browser tab

That Udemy or Coursera tab has been open in your browser for so long that it has practically developed its own microbial ecosystem. It sits there, glowing faintly between Jira and Slack, judging you with the silent, suffocating disappointment of a stationary bicycle that you now use exclusively for drying wet dress shirts.

You will click it eventually. You will watch the first module at 1.5x speed. Not because the course will teach you something deeply structural about computer science. Not because it will make you meaningfully better at the architectural work that actually keeps your company afloat. You will do it because the credential economy demands constant proof of currency, and currency is exactly what expires.

Buying a deeply discounted course on the latest Large Language Model API is not the acquisition of knowledge. It is the purchase of a psychological suppository for imposter syndrome. You administer it, you feel a warm rush of proactive professional development for exactly twelve minutes, and for the rest of the quarter, the only thing you actually retain is a PDF certificate and a vague, persistent sense of guilt.

This is the business model. The upskilling industry operates exactly like a budget gym in January. They do not want you to use the equipment. If everyone who bought a tech course actually logged in, the servers would melt. The industry relies on the fact that an astonishing ninety percent of Massive Open Online Courses are never completed. They are selling you the sensation of having done something about your career anxiety without the caloric expenditure of actually doing it.

Selling suppositories for imposter syndrome

The pressure does not just come from the manic performance art of LinkedIn. It comes from inside the house.

One morning, you get an email from HR about a new corporate AI readiness initiative. The phrasing strongly suggests that participation is voluntary. Of course it is. It is voluntary in the same way that handing over your wallet to a nervous man holding a broken bottle in a dark alley is voluntary. You do not have to do it, but the alternative involves a lot of messy paperwork and a sudden career transition.

Companies love these initiatives because they are trackable. You can put a dashboard on a PowerPoint slide and show the board of directors that eighty percent of the engineering department has been upskilled.

But Gartner research shows that nearly half of all corporate training is what they elegantly call scrap learning. This is knowledge that is delivered but never actually applied to the job. It is corporate junk food. You spend three hours learning how to write the perfect prompt for a proprietary AI tool, and by the time your performance review rolls around, the tool has been deprecated, the vendor has pivoted to a different business model, and you are still just trying to figure out why the production database is locking up every Tuesday at 3 PM.

Early in your career, you learned a new technology because it was genuinely exciting. It provided a new mental model for building things. You stayed up late reading documentation, not because a middle manager sent you a calendar invite, but because you could not stop thinking about the possibilities. The learning felt like building an extension onto a house you were just beginning to inhabit.

Now, you open an AI course because your company panicked after reading a Forbes article. The curiosity has been entirely surgically removed, replaced by the grim mechanics of survival.

The shelf life of a prompt engineer

Here is the fundamental trick the training industry plays on us. They conflate perishable knowledge with durable skill.

Perishable knowledge has the shelf life of an unrefrigerated avocado. It is the exact syntax for a specific API that will change completely in version two. It is a list of magic words to trick a specific chatbot into ignoring its safety constraints. It is knowing how to navigate the user interface of a cloud vendor dashboard that is scheduled for a total redesign next month.

Durable skill is entirely different. A durable skill is understanding how relational databases handle concurrency. It is the ability to read a latency graph like a seasoned cardiologist reads an electrocardiogram, instantly spotting the flutter of a failing network switch. It is knowing how to design a system that fails gracefully instead of taking the entire company down with it. It is the agonizing, hard-won intuition of knowing when an external vendor is lying to you about their uptime guarantees.

Durable skills do not look good on a digital badge. You cannot take a weekend course on how to develop a gut feeling about a poorly designed architecture. It takes years of getting burned by bad code, surviving late-night outages, and staring at logs until your eyes bleed.

The tragedy of the current AI hype cycle is that it forces brilliant engineers to abandon their compounding, durable skills to chase perishable trivia. It is like telling a master carpenter to drop his tools and spend three months learning how to optimize the instruction manual for an automated nail gun.

Compounding interest in the wrong direction

This brings us back to competence debt.

Every hour you spend forcing yourself to memorize the transient, undocumented quirks of an AI wrapper is an hour you did not spend deeply understanding the legacy systems you are actually paid to keep alive. Every superficial certificate you collect is a minimum payment on a debt of fundamental knowledge that keeps growing in the background.

You look productive. Your corporate training dashboard is completely green. Your profile is heavily peppered with the right buzzwords. But underneath it all, the foundational skills that would actually make you irreplaceable are quietly rusting from neglect.

The industry has taught us to call this frantic hamster wheel growth. The corporate rubrics and performance metrics were meticulously designed to measure it. But the word we are all actually looking for is depreciation.

It is perfectly fine to ignore that browser tab. Let the microbial ecosystem thrive. Close the tab. Close the guilt. The next time you feel the panic rising when someone posts about their weekend AI project, take a deep breath. Remember that the ability to keep a messy, chaotic, real-world system running is a skill that no weekend bootcamp can teach.

Stop buying their expired anxiety, and go back to doing the real work.

March 31, 2026 by Fernando SRE Computer Science stuff

127.0.0.1 and its 16 million invisible roommates

Let’s be honest. You’ve typed 127.0.0.1 more times than you’ve called your own mother. We treat it like the sole, heroic occupant of the digital island we call localhost. It’s the only phone number we know by heart, the only doorbell we ever ring.

Well, brace yourself for a revelation that will fundamentally alter your relationship with your machine. 127.0.0.1 is not alone. In fact, it lives in a sprawling, chaotic metropolis with over 16 million other addresses, all of them squatting inside your computer, rent-free.

Ignoring these neighbors condemns you to a life of avoidable port conflicts and flimsy localhost tricks. But give them a chance, and you’ll unlock cleaner dev setups, safer tests, and fewer of those classic “Why is my test API saying hello to the entire office Wi-Fi?” moments of sheer panic.

So buckle up. We’re about to take the scenic tour of the neighborhood that the textbooks conveniently forgot to mention.

Your computer is secretly a megacity

The early architects of the internet, in their infinite wisdom, set aside the entire 127.0.0.0/8 block of addresses for this internal monologue. That’s 16,777,216 unique addresses, from 127.0.0.1 all the way to 127.255.255.254. Every single one of them is designed to do one thing: loop right back to your machine. It’s the ultimate homebody network.

Think of your computer not as a single-family home with one front door, but as a gigantic apartment building with millions of mailboxes. And for years, you’ve been stubbornly sending all your mail to apartment #1.

Most operating systems only bother to introduce you to 127.0.0.1, but the kernel knows the truth. It treats any address in the 127.x.y.z range as a VIP guest with an all-access pass back to itself. This gives you a private, internal playground for wiring up your applications.

A handy rule of thumb? Any address starting with 127 is your friend. 127.0.0.2, 127.10.20.30, even 127.1.1.1, they all lead home.

Everyday magic tricks with your newfound neighbors

Once you realize you have a whole city at your disposal, you can stop playing port Tetris. Here are a few party tricks your localhost never told you it could do.

The art of peaceful coexistence

We’ve all been there. It’s 2 AM, and two of your microservices are having a passive-aggressive standoff over port 8080. They both want it, and neither will budge. You could start juggling ports like a circus performer, or you could give them each their own house.

Assign each service its own loopback address. Now they can both listen on port 8080 without throwing a digital tantrum.

First, give your new addresses some memorable names in your /etc/hosts file (or C:\Windows\System32\drivers\etc\hosts on Windows).

# /etc/hosts

127.0.0.1       localhost
127.0.1.1       auth-service.local
127.0.1.2       inventory-service.local

Now, you can run both services simultaneously.

# Terminal 1: Start the auth service
$ go run auth/main.go --bind 127.0.1.1:8080

# Terminal 2: Start the inventory service
$ python inventory/app.py --host 127.0.1.2 --port 8080

Voilà. http://auth-service.local:8080 and http://inventory-service.local:8080 are now living in perfect harmony. No more port drama.

The safety of an invisible fence

Binding a service to 0.0.0.0 is the developer equivalent of leaving your front door wide open with a neon sign that says, “Come on in, check out my messy code, maybe rifle through my database.” It’s convenient, but it invites the entire network to your private party.

Binding to a 127.x.y.z address, however, is like building an invisible fence. The service is only accessible from within the machine itself. This is your insurance policy against accidentally exposing a development database full of ridiculous test data to the rest of the company.

Advanced sorcery for the brave

Ready to move beyond the basics? Treating the 127 block as a toolkit unlocks some truly powerful patterns.

Taming local TLS

Testing services that require TLS can be a nightmare. With your new loopback addresses, it becomes trivial. You can create a single local Certificate Authority (CA) and issue a certificate with Subject Alternative Names (SANs) for each of your local services.

# /etc/hosts again

127.0.2.1   api-gateway.secure.local
127.0.2.2   user-db.secure.local
127.0.2.3   billing-api.secure.local

Now, api-gateway.secure.local can talk to user-db.secure.local over HTTPS, with valid certificates, all without a single packet leaving your laptop. This is perfect for testing mTLS, SNI, and other scenarios where your client needs to be picky about its connections.

Concurrent tests without the chaos

Running automated acceptance tests that all expect to connect to a database on port 5432 can be a race condition nightmare. By pinning each test runner to its own unique 127 address, you can spin them all up in parallel. Each test gets its own isolated world, and your CI pipeline finishes in a fraction of the time.

The fine print and other oddities

This newfound power comes with a few quirks you should know about. This is the part of the tour where we point out the strange neighbor who mows his lawn at midnight.

The container dimension: Inside a Docker container, 127.0.0.1 refers to the container itself, not the host machine. It’s a whole different loopback universe in there. To reach the host from a container, you need to use the special gateway address provided by your platform (like host.docker.internal).
The IPv6 minimalist: IPv6 scoffs at IPv4’s 16 million addresses. For loopback, it gives you one: ::1. That’s it. This explains the classic mystery of “it works with 127.0.0.1 but fails with localhost.” Often, localhost resolves to ::1 first, and if your service is only listening on IPv4, it won’t answer the door. The lesson? Be explicit, or make sure your service listens on both.
The SSRF menace: If you’re building security filters to prevent Server-Side Request Forgery (SSRF), remember that blocking just 127.0.0.1 is like locking the front door but leaving all the windows open. You must block the entire 127.0.0.0/8 range and ::1.

Your quick start eviction notice for port conflicts

Ready to put this into practice? Here’s a little starter kit you can paste today.

First, add some friendly names to your hosts file.

# Add these to your /etc/hosts file
127.0.10.1  api.dev.local
127.0.10.2  db.dev.local
127.0.10.3  cache.dev.local

Next, on Linux or macOS, you can formally add these as aliases to your loopback interface. This isn’t always necessary for binding, but it’s tidy.

# For Linux
sudo ip addr add 127.0.10.1/8 dev lo
sudo ip addr add 127.0.10.2/8 dev lo
sudo ip addr add 127.0.10.3/8 dev lo

# For macOS
sudo ifconfig lo0 alias 127.0.10.1
sudo ifconfig lo0 alias 127.0.10.2
sudo ifconfig lo0 alias 127.0.10.3

Now, you can bind three different services, all to their standard ports, without a single collision.

# Run your API on its default port
api-server --bind api.dev.local:3000

# Run Postgres on its default port
postgres -D /path/to/data -c listen_addresses=db.dev.local

# Run Redis on its default port
redis-server --bind cache.dev.local

Check that everyone is home and listening.

# Check the API
curl http://api.dev.local:3000/health

# Check the database (requires psql client)
psql -h db.dev.local -U myuser -d mydb -c "SELECT 1"

# Check the cache
redis-cli -h cache.dev.local ping
# Expected output: PONG

Welcome to the neighborhood

Your laptop isn’t a one-address town; it’s a small city with streets you haven’t named and doors you haven’t opened. For too long, you’ve been forcing all your applications to live in a single, crowded, noisy studio apartment at 127.0.0.1. The database is sleeping on the couch, the API server is hogging the bathroom, and the caching service is eating everyone else’s food from the fridge. It’s digital chaos.

Giving each service its own loopback address is like finally moving them into their own apartments in the same building. It’s basic digital hygiene. Suddenly, there’s peace. There’s order. You can visit each one without tripping over the others. You stop being a slumlord for your own processes and become a proper city planner.

So go ahead, break the monogamous, and frankly codependent, relationship you’ve had with 127.0.0.1. Explore the neighborhood. Hand out a few addresses. Let your development environment behave like a well-run, civilized society instead of a digital mosh pit. Your sanity and your services will thank you for it. After all, good fences make good neighbors, even when they’re all living inside your head.

August 25, 2025 by Fernando SRE DevOps stuff SRE stuff

Essential tactics for accelerating your CI/CD pipeline

A sluggish CI/CD pipeline is more than an inconvenience, it’s like standing in a seemingly endless queue at your favorite coffee shop every single morning. Each delay wastes valuable time, steadily draining motivation and productivity.

Let’s share some practical, effective strategies that have significantly reduced pipeline delays in my projects, creating smoother, faster, and more dependable workflows.

Identifying common pipeline bottlenecks

Before exploring solutions, let’s identify typical pipeline issues:

Inefficient or overly complex scripts
Tasks executed sequentially rather than in parallel
Redundant deployment steps
Unoptimized Docker builds
Fresh installations of dependencies for every build

By carefully analyzing logs, reviewing performance metrics, and manually timing each stage, it became clear where improvements could be made.

Reviewing the Initial Pipeline Setup

Initially, the pipeline consisted of:

Unit testing
Integration testing
Application building
Docker image creation and deployment

Testing stages were the biggest consumers of time, followed by Docker image builds and overly intricate deployment scripts.

Introducing parallel execution

Allowing independent tasks to run simultaneously rather than sequentially greatly reduced waiting times:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install Dependencies
        run: npm ci
      - name: Run Unit Tests
        run: npm run test:unit

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install Dependencies
        run: npm ci
      - name: Build Application
        run: npm run build

This adjustment improved responsiveness, significantly reducing idle periods.

Utilizing caching to prevent redundancy

Constantly reinstalling dependencies was like repeatedly buying groceries without checking the fridge first. Implementing caching for Node modules substantially reduced these repetitive installations:

- name: Cache Node Modules
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

Streamlining tests based on changes

Running every test for each commit was unnecessarily exhaustive. Using Jest’s –changedSince flag, tests became focused on recent modifications:

npx jest --changedSince=main

This targeted approach optimized testing time without compromising test coverage.

Optimizing Docker builds with Multi-Stage techniques

Docker image creation was initially a major bottleneck. Switching to multi-stage Docker builds simplified the process and resulted in smaller, quicker images:

# Build stage
FROM node:18-alpine as builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

The outcome was faster, more efficient builds.

Leveraging scalable Cloud-Based runners

Moving to cloud-hosted runners such as AWS spot instances provided greater speed and scalability. This method, especially beneficial for critical branches, effectively balanced performance and cost.

Key lessons

Native caching options vary between CI platforms, so external tools might be required.
Reducing idle waiting is often more impactful than shortening individual task durations.
Parallel tasks are beneficial but require careful management to avoid overwhelming subsequent processes.

Results achieved

Significantly reduced pipeline execution time
Accelerated testing cycles
Docker builds ceased to be a pipeline bottleneck

Additionally, the overall developer experience improved considerably. Faster feedback cycles, smoother merges, and less stressful releases were immediate benefits.

Recommended best practices

Run tasks concurrently wherever practical
Effectively cache dependencies
Focus tests on relevant code changes
Employ multi-stage Docker builds for efficiency
Relocate intensive tasks to scalable infrastructure

Concluding thoughts

Your CI/CD pipeline deserves attention, perhaps as much as your coffee machine. After all, neglect it and you’ll soon find yourself facing cranky developers and sluggish software. Give your pipeline the tune-up it deserves, remove those pesky friction points, and you might just find your developers smiling (yes, smiling!) on deployment days. Remember, your pipeline isn’t just scripts and containers, it’s your project’s slightly neurotic, always evolving, very vital circulatory system. Treat it well, and it’ll keep your software sprinting like an Olympic athlete, rather than limping like a sleep-deprived zombie.

May 15, 2025 by Fernando SRE DevOps stuff