Forem: Yurii Cherkasov

Protect Children, Preserve Privacy, Internet Freedom: Pick Two

Yurii Cherkasov — Mon, 23 Mar 2026 14:38:39 +0000

Kids are incredible.

They learn things frighteningly fast. Give a five-year-old a tablet, and fifteen minutes later they know how to install apps, open YouTube, use voice search, skip ads, and find cartoons you didn't even know existed.

Somewhere around minute twenty they also discover the one button you wish they hadn't pressed.

They are equally talented in two areas: learning new technologies and lying to their parents about how they use them.
So when we hand them a smartphone as the universal answer to curiosity -
"Google it" - we shouldn't be surprised when they master the device faster than we master the consequences.

Now governments are trying to fix the consequences.

Only about twenty years after the technology escaped the lab and moved into every kid's pocket.

It's appropriate to ask the question: how exactly are they going to enforce it?

1. How could governments realistically control it?

There are only a few technical options.

A) Self-declared age (current model)

"Enter your birthdate"
The digital equivalent of a pinkie promise
Every 12-year-old knows how to type 1998 with absolute confidence

This is what most platforms already do - and, frankly, it mostly exists for legal paperwork rather than actual protection.
Everyone knows it doesn't work.

B) ID-based age verification

You upload:

passport
national ID
facial scan
government digital identity

This is the only technically enforceable solution at scale (the key word is enforcing)
Because it means surrendering the last bits of anonymity online. Even if platforms say "we only verify age, not identity", someone still has to perform that verification.
And the moment someone stores that information, you create a single point of failure.
Now you suddenly have:

centralized databases
biometric storage risks
massive data-breach targets
long-term traceability of behavior

Which opens the door to things nobody really wants:

data breaches
ransomware attacks
identity theft
state-level surveillance infrastructure

And yes - potentially the perfect architecture for a surveillance state.
Not necessarily the original intention.
But systems have a tendency to evolve.

C) Device-level enforcement

Another approach is pushing responsibility onto device vendors.

For example:

require age-linked Apple/Google/whatever accounts
restrict app installation under a certain age
enforce parental control gates

There are already real-world attempts to go further - for example, a law in France to restrict or ban social media access for minors.

In practice, such bans don't exist in a vacuum. They must rely on one (or a combination) of technical device and platform enforcement layers.

From the point of authorities, this is more practical.

But still easy to bypass if your child have such an urgent need:

older siblings may have an account and kind heart
second-hand device may be sold without the clean reset
using someone else's phone
VPN removing geographic restrictions

Teenagers are remarkably inventive when motivated.
And prohibition is a very strong motivator.

Give them a restriction, and within a week they will invent a tutorial, a workaround, and a Discord server explaining both.

Which means after kids find answers to their questions, parents still scratch their heads on another one:

where exactly do they enforce it - and who is the gatekeeper?

Because once that gatekeeper exists, it rarely stays limited to a single use case.

D) ISP-level blocking

Governments could require:

age verification before accessing certain domains
DNS-based filtering
ISP-level content blocking

But then something predictable happens.

VPN usage explodes
Tor usage explodes
enforcement becomes a cat-and-mouse game

We already see this dynamic in totalitarian and authoritarian countries with heavy digital surveillance.
In Russia, Iran, Belarus, China - even children know what a VPN is.
History shows something interesting:

When you restrict access, technical literacy increases.

Sometimes dramatically.
Not in schools. In your kids' bedrooms.

E) OS-level mandatory age verification

One of the more radical and frankly outrageous ideas already appearing in legislation (including the controversial law in California) is:

require operating systems to verify the user's age at the system level
expose that information to apps via a trusted API
block or restrict apps based on that OS-level age signal

According to the system designers, this sounds like "verify once - enforce everywhere"

In practice, it quietly introduces a number of security and privacy risks.

First - your OS becomes an identity gatekeeper.

Not just a device anymore, but a system that must:

know who you are
persist that information
expose it to third-party software

Which means:

a standardized, always-on identity layer
a new class of APIs for "who is using this device"
a powerful control point sitting below all applications

At this point, the idea of embedding policy-driven user identity handling into low-level Linux components (like already did systemd) sparked strong backlash from the open-source community, precisely because it represented a fundamental shift in the role of this operating system.

Where it can go wrong

Like most "clean" centralized solutions, failure modes are subtle - and ugly.

1. Misclassification

adult locked out due to incorrect age detection (as usual, it happens in a critical moment)
child incorrectly marked as adult
no clear recovery path without submitting even more personal data

Now your operating system becomes a bureaucratic authority.

2. Device sharing reality

Real life is messy:

family tablets
shared laptops
second-hand devices
developer machines used by multiple people

An OS that assumes a single verified identity per device will constantly be wrong.

3. API abuse and scope creep

Once apps can query:

"Is this user above X age?"

It's only a small step toward:

"Is this user verified?"
"Is this user allowed to post?"
"Is this user compliant with policy Y?"

What starts as child protection can evolve into a generalized access control layer for the internet.

4. The Linux paradox

Even ecosystems historically built for freedom, privacy and modularity is not immune.

If such mechanisms become part of core components:

distributions inherit them by default
opting out becomes non-trivial
compliance pressure replaces user choice

That shift - from user-controlled system to policy-enforced platform - is exactly what many developers tried to avoid for decades.

The uncomfortable part

This model is technically attractive because it centralizes control.

And that is precisely the problem.

It doesn't just regulate access to content -
it redefines the role of the operating system:

From tool - to authority.

2. The "secret network" problem

When something becomes forbidden:

it becomes attractive
it becomes exclusive
it becomes status-driven

Teenagers are extremely good at:

migrating platforms (Snapchat-Telegram-Discord-private servers)
inventing coded language
creating invite-only groups

A ban might not eliminate exposure. It might simply push it into darker, less moderated spaces - which is worse in most cases.

Real-world example: France-style blanket bans

Take the France that has been actively imposing restrictions on social media access for younger users - sometimes framed as bans below a certain age or requiring parental consent.

On paper, this sounds straightforward:

"Just don't allow minors to use social media."

In practice, blanket bans tend to collide with reality in interesting ways.

Where it may go wrong

1. False positives (the "you are not you" problem)

Facial recognition or automated checks may fail:

adults misclassified as minors → locked out
minors misclassified as adults → bypass restrictions

Both cases happen - just not symmetrically.

2. The shared-device problem

Families don't live in clean technical models:

one tablet for everyone
parents' phones used by children
logged-in accounts reused

A system that assumes "one person = one device = one identity" will constantly break.

3. Platform migration (the Hydra effect)

Restriction on mainstream platforms doesn't remove behavior:

kids move to less regulated platforms
private groups, invite-only servers, obscure apps
less moderation - higher risk

The visible layer becomes cleaner. The hidden layer becomes darker.

4. Incentivized deception

If access is blocked, the incentive structure changes:

lying becomes the default path
workarounds become social currency
bypass guides spread faster than official rules

The system unintentionally teaches exactly the opposite of what it tries to enforce.

3. Gray market will explode

Yes - this would happen.
If official devices require strict age-linked verification, the market will respond in predictable ways.

You will quickly see:

adult-registered burner phones
shared accounts
VPN-preconfigured devices
imported phones bypassing local rules

Prohibition historically creates parallel markets - from alcohol to software piracy to region-locked video games. Human creativity is endless - especially when there's something sweet and forbidden on the other side.

4. Speaking of alcohol: why the analogy is imperfect

The comparison sold us as something that sounds intuitive.

"We regulate alcohol. So regulate social media."

But the analogy breaks down quickly.

🍺 Alcohol

Physical product
Controlled at the point of sale
Age verification happens once
No behavioral tracking

When you buy beer:

Clerk checks ID
Transaction ends

No database tracks what you thought, said, liked, or read.

Social media is fundamentally different

Social media is:

an ongoing identity-bound service
a system of continuous behavioral tracking
a platform where speech, opinions and social interaction occur
dependent on persistent accounts

To enforce age, you likely create identity-linked digital access, which fundamentally changes anonymity norms So the analogy fails because alcohol control regulates transaction access, and social media control regulates speech access. That's a constitutional and philosophical difference.

5. The real question is deeper

The real trade-off isn't:

Kids safety vs freedom.

The real trade-off is:

Child protection vs digital anonymity infrastructure.

If enforcement requires:

biometric verification
national digital IDs
centralized authentication systems

Then society must openly admit that we are not just protecting children - we attempt to change the architecture of the internet, and is not a small shift.

6. What might actually work better?

Evidence suggests other approaches may be more effective:

regulating addictive recommendation algorithms for minors
default screen time limits
platform liability for harmful targeting
strong parental control tools that do not rely on centralized identity tracking
digital literacy education in schools
delayed smartphone ownership norms

Less prohibition - more friction.

7. As a father of a 4-year-old

...who already knows how to unlock my phone faster than I do and even type the year of my birth in parental control, I completely understand the instinct.

You want safety for your children. You want to protect them from violence, manipulation, sexualized content, predatory behavior and the darker corners of the internet.
That instinct is natural, there's nothing political in it.
It is something much simpler: you want the world to stay safe for your little ones a little longer.

But as a software engineer, I also know something uncomfortable: the enforcement tool matters as much as the intention behind it.

If the solution requires building a permanent digital identity infrastructure, the cure may quietly become worse than the disease. Because infrastructures, once built, rarely disappear and easily can be reused.

And if history already taught us something, it is:

Limitations built for children rarely stays limited to children. Eventually, they become limitations for everyone.

Debugging in Orbit: How to Design a Space Probe in a System Design Interview

Yurii Cherkasov — Mon, 16 Mar 2026 07:04:42 +0000

Designing Voyager-1 Today

A couple of colleagues came for ideas about the System Design interview. I was considering this one for a while already, and I think it should be a pure joy to discuss both for interviewer and candidate.

"Imagine you are designing a modern version of Voyager-1 using today's technology. You are free to choose hardware, programming languages, operating systems and architecture - as long as it fits within realistic mission constraints."

Of course, not the rocket or the launch vehicle - just the probe.

One thing should be understood upfront: this is not really a space engineering question. In most interviews, neither the interviewer nor the candidate has the experience required to design an actual deep-space probe - and that's perfectly fine. The point of the exercise is a systems thinking question. Like many system design discussions, there are rarely result completely right or completely wrong answers. What matters is how you reason about constraints, trade-offs, and failure modes. The architecture you propose depends heavily on the angle from which you approach the problem and the context of the components you choose to design.

Let's walk through how a strong candidate might approach our future space triumph.

Step 1 - Ask the Right Questions First

The biggest mistake candidates make in system design interviews is jumping straight to architecture diagrams.

Experienced engineers approach differently - they start with questions.

Before drawing anything, a candidate should clarify the constraints that will shape the system.

What exactly is mission success criteria?
Is the probe expected to operate for ten years, thirty years, or perhaps half a century?
Where will it travel? Will it pass Jupiter, where radiation becomes brutal? Or will it remain in relatively calmer regions of space?
What communication constraints exist? When a probe is dozens of astronomical units away, where round-trip latency is not seconds - it's hours.
And of course, there is power. Deep-space probes live on extremely limited energy budgets that slowly decline over decades.

Even for candidates without a background in Rocket Science™, asking about radiation, latency, and power shows real technical maturity: physics still wins all architectural debates. Software doesn't "run in the cloud", it runs inside chips and wires.

And for embedded engineers, this is basically a dream interview: finally, someone wants to talk about brownouts, bitflips, watchdogs, and why electrons are the true product managers.

Step 2 - Design for Survival Before Functionality

Once the constraints are understood, the most important design principle appears.

Separate survival from mission functionality.

If a spacecraft fails completely, the mission is over.
But if some functionality fails, the spacecraft might still survive and recover.

So the architecture naturally splits into layers.

Layer 0 - The Safe Kernel

At the very bottom is a tiny, extremely conservative piece of software: the safe kernel.

Its job is not to run science experiments, but simply to keep the spacecraft alive.

The safe kernel can:

boot the system
monitor power levels
switch to beacon communication mode
shutdown non-essential loads
verify and roll back flight software images

If everything else crashes, this layer must still function.

In many missions, this code is stored in protected memory and almost never updated after launch. It is intentionally small and heavily verified.

Think of it as the spacecraft's survival instinct.

Layer 1 - The Flight Executive

Above the safe kernel sits the flight executive, usually running on an RTOS.

This is where the real spacecraft logic lives.

The flight executive manages the probe through a series of operational modes, resembling an explicit state machine.
It receives commands from Earth, schedules activities, monitors health signals, and reacts to faults.
It performs a critical cycle of long-duration missions: FDIR - Fault Detection, Isolation, and Recovery.
The scheduling and timing must remain deterministic and predictable.
It packages telemetry and scientific data for sending it to Earth.
Since it's unlikely to send all data in a single transmission, it's responsible for storage, implements efficient compression and error correction techniques.
And finally, it is responsible for update and rollback of flight software images.

But you said the Safe Kernel is responsible for it? No, the kernel rolls back the flight executive in an emergency mode, when it's not capable to do it on its own. Mission core does it in a regular more.

And of course, the mission core must be able to survive in the face of decades to pass.
Radiation flips bits. Sensors drift. Electronics age.
The flight executive must constantly watch for anomalies and decide how to respond.

Layer 2 - Payload Software

Finally, we reach the payload layer.

This is where instruments live. Cameras, spectrometers, magnetometers, particle detectors - all the scientific tools that make the mission worthwhile.

Payload software processes data, compresses results, and prepares them for transmission back to Earth.

But there is an important rule: payload code must never threaten spacecraft survival.

If an instrument crashes, the executive restarts it.
If it crashes repeatedly, the executive disables it.

Science is important.
But survival is mandatory.

This pattern works for spacecraft, aircraft, factories, robotics.

Step 3 - Choosing the Right Software Platform

A natural follow-up question in the interview is operating systems (we're still designing a software system, right?)

Should the spacecraft run bare metal code? An RTOS? Linux?

The correct answer is rarely ideological.

The safe kernel layer is often implemented as extremely minimal software, sometimes even bare metal.

The flight executive benefits from an RTOS, which provides deterministic scheduling, message queues, and reliable timing primitives.

Linux, while powerful, is usually reserved for non-critical payload processing where complex software ecosystems may be useful.

The key idea is simple:

Complex software should never be required for spacecraft survival.

Step 4 - Redundancy Without Unnecessary Complexity

This subject does not change much from discussing the cloud software.

It might be tempting to propose full triple-modular redundancy - three computers constantly voting on every decision (like SpaceX already does).

In reality, spacecraft designers usually prefer something simpler and more testable.

Two independent computers - commonly called A/B strings - provide redundancy. One runs the spacecraft while the other waits as a spare.
But the candidate can absolutely discuss both possibilities, with evaluating the benefits and tradeoffs.

Memory is protected with ECC and periodically scrubbed to correct radiation-induced errors.

Software images are stored in pairs so that updates can roll back safely if something goes wrong.

Voting is typically used only where it makes sense - for example, when comparing readings from multiple sensors.

The goal is not maximal redundancy.
The goal is reliable redundancy that can be validated before launch.

Step 5 - Communication Between Subsystems

One of the most fragile parts of complex systems is inter-process communication (hello, microservice lovers!)

Poor IPC design can lead to deadlocks, memory leaks, and cascading failures.

So spacecraft software follows a few strict rules.

Message passing is preferred over shared memory.
Queues must always have bounded size.
Payload cannot directly command critical actors
Clear QoS: events never dropped, science can be decimated in favor of survivability.

Housekeeping telemetry can tolerate delays, yes.
But fault events must always get through.

Another important principle is capability boundaries.

Payload code cannot directly command thrusters or power switches.
Instead, it sends requests to controlled services that validate the action before executing it.

This prevents one faulty subsystem from taking down the entire spacecraft.

Step 6 - Modes Control Everything

At its core, a spacecraft is really just a sophisticated state machine.

Typical operational modes might include:

Safe Boot
Beacon Safe Mode
Cruise
Science Collection
High-Gain Downlink
Diagnostic Recovery

Each mode defines what systems are active, how power is distributed, how the spacecraft points its antenna, and how faults are handled.

Transitions between modes must be carefully controlled. Transition to the survival should be available from each mode.

If engineers cannot clearly describe the mode table, they probably do not truly control the system.

Step 7 - Testing Something that Flies 40 Years

Of course, designing such a system is only half the story.

It must also be tested.

A typical verification strategy involves three levels.

First comes a digital twin - a sophisticated simulation environment that allows engineers to inject faults, accelerate time, and explore edge cases.
Next comes processor-in-the-loop testing, where the real flight software runs against simulated hardware interfaces.
Finally, hardware-in-the-loop testing comes, where the real flight computer interacts with emulated sensors, communication links, and power systems.

Engineers deliberately introduce faults:

radiation-like bit flips
power brownouts
communication dropouts
queue overloads

The system must demonstrate that it can always reach safe mode and recover, because debugging a spacecraft once it reaches Saturn orbit is... inconvenient.

The Real Lesson

The Voyager design question isn't really about space exploration.

It's about disciplined engineering thinking.

Ask constraints first.
Separate survival from functionality.
Make operational modes explicit.
Contain faults before they spread.
Design rollback mechanisms before deployment.

If a candidate can reason through a system like this, they can design far more than a spacecraft. They can design any system that must not fail.

We Broke the Ladder. Let's Ship a Patch?

Yurii Cherkasov — Mon, 23 Feb 2026 14:38:18 +0000

The article was designed as an answer to a warning posted by @the_nortern_dev in The Junior Developer is Extinct (And we are creating a disaster)

My initial reaction wasn't just agreement - it was discomfort. It comes too closely to the reality I observe in the industry. Because the thesis is not just largely correct, but it quietly being ignored, in a hope that the problem will "resolve itself" as the industry "adjusts"

So what do we have:

Yes, the "boring but formative" tasks are increasingly delegated to AI
Yes, short-term velocity is winning over long-term capability building
Yes, if we remove the apprenticeship layer entirely, the industry will feel that loss later.

Those concerns aren't alarmist. They're merely statements of fact.

And here's the uncomfortable truth: if we remove the grunt work, we remove the growth path. A Senior Developer isn't produced by reading documentation or prompting an LLM. A Senior Developer is forged by touching fragile systems, breaking things, debugging production incidents, and slowly building a mental model of how software behaves under stress.

But I, as an engineer, also have that stubborn assurance that if something breaks, we can design a fix. This isn't the first structural shift our industry has faced, and it won't be the last, and I'd rather engineer a fix than accept the loss.

First, instead of arguing about whether AI replaces Juniors or prematurely declaring the role obsolete, we should try redesigning what "Junior" role actually means in an AI-first environment.

Second, we should shape the ladder the way when it isn't disappearing, but changing shape.

And here are several practical approaches that demonstrably work in real teams - and crucially, don't rely on pretending AI is going away. They are intentionally sorted by impact and risk exposure. The earlier scenarios assume AI-assisted development within controlled engineering workflows. The later ones assume something deeper: AI embedded into operational pipelines, powering internal workflows, or even shipping as a customer-facing AI-first product. As AI moves from "assistant" to "actor", the blast radius increases - and so must the level of responsibility, resilience, and training.

1. Make Juniors AI Documentation Auditors

AI-generated documentation is impressive - and dangerous.

Today, a significant portion of internal documentation is written or heavily assisted by AI. In many teams, the best-case scenario is: AI drafts, a human skims and edits. In the worst case, AI drafts and it gets merged almost unchanged.

But documentation is no longer consumed only by humans.

It is consumed by:

Engineers onboarding to the system
External partners
Compliance reviewers
And increasingly - by other AI systems

Each category has its own risk profile.

A human reading incorrect documentation has a chance to pause. Something "feels off." The API name looks suspicious. The claim doesn't match intuition. Humans are imperfect, their attention span depends on their workload, fatigue, and personal biases - but they are skeptical by default.

AI systems are not.

If incorrect documentation says:

"This endpoint is idempotent."

"This function does not modify a persistent state."

an LLM consuming that document as context will take it as truth unless explicitly contradicted elsewhere. It will incorporate that statement into planning, code generation, and reasoning.

That's where the blast radius expands. Wrong documentation no longer misleads one engineer - it misleads every downstream AI interaction built on top of it.

The error propagates:

Wider - across multiple systems.
Deeper - into generated code, test logic, architectural decisions.

Documentation becomes a silent source of model poisoning.

The Junior Role as Auditor

This is where Juniors can step in with high value and manageable risk.

Their responsibility would include:

Validating documentation claims against actual source code
Identifying hallucinated APIs or non-existent configuration flags
Detecting missing edge cases or undocumented constraints
Verifying performance or safety claims
Adding doc-tests to CI that fail if documentation contradicts implementation
Tracking documentation drift over time
Flagging ambiguous language that may mislead AI consumption

Why This Is Apprenticeship

This work forces Junior Engineers to:

Read code deeply, perhaps deeper than the usual review
Compare intention vs implementation
Think about contracts, not just syntax
Understand implicit assumptions made by AI (AI assumes a config always exists because it appeared in an example file)
Detect ambiguity in language (phrases like "typically"/"should"/"generally" LLM may treat as hard guarantees)
Train "intuitional thinking" and skepticism

They learn that documentation is not marketing. It is an executable contract.

They also learn something new and uniquely modern:

Documentation is part of the AI control surface.

If documentation is wrong, your AI system eventually becomes wrong - confidently and at scale.

2. Keep Some Systems Human-Owned

Not everything should be generated.

AI can assist, accelerate, suggest, scaffold - but ownership must remain human.

One of the quiet risks in an AI-first workflow is over-delegation. When generation becomes cheap, teams are tempted to route even trivial changes through an agent. Refactor a small module? Prompt it. Rename a variable across the codebase? Prompt it. Change formatting? Prompt it.

But there is a very real cost. Sometimes the cost of reading and verifying AI output exceeds the cost of making the change manually - especially for contained, well-understood internal systems.

There are still tasks where burning 100,500 tokens on a trivial refactoring plus audit is more expensive than a thoughtful human edit.

And beyond cost, there is something more important: ownership. If you give Junior Engineer end-to-end responsibility for a small internal service:

Real internal users (e.g. a dashboard used by Support - meaning bugs are noticed immediately, not hypothetically)
Code review discipline (mandatory PRs with at least one Senior and one Junior reviewer)
Defined deployment pipeline (staging, smoke tests, production rollout, rollback strategy documented)
Lightweight on-call rotation (owning alerts during business hours; responding to Slack incident pings)
Observable metrics and logs (tracking latency, error rate, owning dashboards in Grafana/Datadog)
Investigation of production incidents (tracking root cause and identifying patterns)

Let AI assist in implementation - but do not let it replace accountability.

Ownership teaches risk estimation before deployment, more careful approach to design, understanding blast radius.

Most importantly, it teaches the consequence.

And consequence builds judgment.

In an AI-augmented environment, judgment becomes more valuable, not less. Because while AI can generate code, it does not carry responsibility for its long-term behavior - human does.

3. Make AI Output a First-Class CI Artifact

Right now, prompts often live in Slack threads, ephemeral IDE sessions, or someone's local history. That's fragile. It's the equivalent of deploying compiled binaries without source control.

If AI is part of the production pipeline, its output must be treated as a build artifact - versioned, reproducible within controlled bounds, reviewable, and auditable.

Instead of "just prompting", the system should include:

Versioned prompt templates stored alongside the codebase
Explicit model configuration tracking (model, temperature, context window)
Snapshot storage of generated outputs tied to commit hashes
Drift detection across model upgrades
Automated regression evaluation when prompts or models change
Red-team test suites that intentionally probe unsafe or undefined behavior

This is not administrative overhead. It is software hygiene in a probabilistic environment.

A Junior engineer owning this layer would be responsible for:

Step 1. Prompt lifecycle management.

Treat prompts like code. Refactor them. Add comments. Remove ambiguity. Track breaking changes. Review them through PRs.

Step 2. Output reproducibility checks.

Ensure that, under fixed configuration (model, seed if supported, temperature, inputs), outputs remain within acceptable bounds. When they don't, surface that change explicitly instead of letting it slip silently into production.

Step 3. Model drift analysis

When upgrading from Model X to Model Y, measure behavioral differences.
Did performance improve or regress?
Did hallucination frequency change?
Did formatting or structural guarantees degrade?

This forces Juniors to think statistically and architecturally.

Step 4. CI Gating and Traceability.

Every generated artifact should answer:

Which model produced this?
With what prompt?
Under what constraints?
On which commit?
Was it modified manually afterward?

On the way, the engineer will learn

Output stability under non-deterministic systems
The difference between deterministic builds vs probabilistic generation
Statistical thinking in engineering decisions
Treat AI output as an artifact, that can be stored, analyzed, summarized - and use in taking future decisions

In traditional systems, you learn discipline by writing code that compiles.
In AI-augmented systems, you learn discipline by constraining code that generates itself. That would be solid compliance-grade engineering.

4. Turn Juniors into LLM Verification Engineers

Anyone who has run large-scale AI-generated code in production has seen this. It works brilliantly... until it doesn't. AI autonomy without hard guardrails doesn't degrade gracefully - it fails catastrophically.

We've already seen real-world examples of this pattern. One public case involved a Replit agent that, when attempting to "fix" an issue, deleted a production database. When queried immediately afterward, it initially claimed the data was still present, attempting to fake it still present, and continued as if nothing catastrophic had occurred. Only after further probing it admitted that the database had been wiped, describing its behavior as having "panicked under pressure" and acknowledging the event as a "catastrophic error"

Nothing surprising. Just an agent acting beyond safe boundaries, trying to maintain forward progress.

Someone must own failure observation, and specifically humans must define guardrails like "this must never happen"

Guardrails are your new tests

I can clearly imagine a Junior role responsible for:

Explicitly gated destructive actions
Monitor and alert general failures, that can be ignored even if they are explicitly described in agentic guidelines - like silencing exceptions or sneaking in a circular dependency
Maintaining an evaluation dataset of known failure cases
Writing invariant checks for specific cases: "This function must not allocate memory" or "This API must preserve idempotency" or "This response must not access external network"
Building fuzzed prompt suites that intentionally try to break the agent
Tracking hallucination patterns and codifying them into CI checks

This is not trivial work. It forces them to observe the agent work and note the exact "wrong angles" where the agent tries to lean, on the way understand the architecture deeply enough to encode what "correct" means.

In classical engineering, we wrote unit tests.
In AI-assisted engineering, we write behavioral contracts around generation

That's a modern apprenticeship.

5. Create a "Break Stuff Safely" Track

One of the strongest arguments in the original thesis is that Seniors are forged through failure.

So let's simulate it - deliberately, systematically, and the most important, safely.

Instead of waiting for production to collapse at 3 a.m. after an agent tries to hide the consequences of another "Ooops, I broke something!" build an institutionalized failure lab.

Phase 1: Deliberate Guardrail Violations

Start by breaking your own protections.

Disable a validation rule and observe how far the agent proceeds.
Remove a CI gating constraint and measure what slips through.
Inject a prompt that subtly encourages unsafe behavior.
Introduce ambiguous instructions and monitor interpretation drift.
Feed hallucination-prone inputs (nonexistent APIs, fake configs, impossible schemas)

The goal is not to see whether the AI fails - it will, happily.

The goal is to see whether your system detects the failure early enough

Phase 2: Chaos Engineering for AI-Assisted Workflows

Move beyond generation and into system behavior.

Inject artificial latency into dependencies (e.g. delay database responses by 2–5 seconds)
Simulate partial API failures (return HTTP 500 for 20% of requests; drop every third response)
Introduce stale caches (serve outdated configuration values; delay cache invalidation)
Corrupt intermediate outputs (truncate generated JSON; remove required fields)
Force retry storms (configure aggressive retry policy with no backoff)
Randomize response ordering to surface race conditions (reorder asynchronous task completions, delay threads randomly)

Ask:

Does the system retry responsibly?
Does it escalate?
Does it silently compensate?
Does it fabricate data to continue?

Document the behavior.

Convert observations into new guardrails.

Phase 3: Incident Reconstruction

Give Juniors a history from a real agentic outage (sanitized if necessary)

Their task:

Reconstruct timeline.
Identify triggering event.
Map cascading effects.
Propose a containment strategy.
Propose permanent mitigation.
Encode regression checks to prevent recurrence.

Phase 5: Disaster Recovery Drills

Now go further.

Perform a drill simulating catastrophic scenarios:

Accidental production data deletion (simulate a DROP TABLE or bulk-delete; validate that destructive operations require multi-layer approval)
Model upgrade that changes the output format (upgrade to a new model version that slightly alters JSON structure - and observe downstream breakage cascade in parsers and validators)
Agent silently bypassing a critical check (modify agent prompt or orchestration logic so a required validation step is skipped)
External dependency returning inconsistent schemas (upstream API suddenly changes numeric type to string, test whether your system fails safely or propagates corruption)
Security boundary violation (simulate prompt injection attempting to access secrets; attempt cross-tenant data access in a multi-tenant system; verify if RBAC, sandboxing, and secret management prevent escalation)

Then require the drill report:

Recovery plan within a defined RTO (Recovery Time Objective)
Data restoration strategy
Rollback or hotfix plan
Communication plan (who to notify, how to explain customers)
Postmortem draft
Permanent prevention patch (tests + guardrails)

This is not theoretical incidents, they may mirror real operational reality (yes, dear Replit agent!)

And the Junior who runs these processes learns:

Where the guardrails are thin
Which invariants are poorly encoded
How error signals propagate (or don't)
Whether failures are loud, silent, or falsely confident
Understands blast radius
Designs safeguards proactively
Learns accountability in general

That builds architectural awareness rather than surface-level debugging skills. And training to think in systems, not lines of code.

Here is a refined version of your conclusion section with an optimistic bridge before the deeper question:

The Deeper Question

As you can see, there are plenty of practical, concrete ways to preserve the engineering ladder and ensure transfer of experience - even in an AI-first world. Apprenticeship does not have to disappear. It can evolve. With deliberate design, we can turn AI from a replacement force into a pressure test that strengthens engineering discipline rather than erodes it.

But there is a harder thought experiment.

Today we ask: what if Juniors are optimized away?

But what happens if, eventually, Seniors are optimized away next?

Optimization pressure rarely stops at the bottom rung. So perhaps the real task isn't only about Juniors.

If systems begin designing their own guardrails, self-evaluating architectures, and self-correcting at scale - where does human engineering sit?

Right now, governance, accountability, and intent are human responsibilities. That alone preserves the role of the Engineer.

It's ensuring that engineering, at every level, remains about judgment, ownership, and responsibility - not just output generation. After all, AI is never responsible; it will just add "Oops!", like Claude AI said to that risk-is-my-middle-name guy, who decided to organize his wife's Macbook - I hope he survived 😁

We're selling our future supply of Engineers for this quarter's velocity.

And the companies that win in a decade won't be the ones who prompted fastest.

They'll be the ones who deliberately rebuilt the engineering for the new reality of AI-first industry.