Jack VS the AI Machine

Jack VS the AI Machine

# discuss# ai# softwareengineering# softwaredevelopment
Jack VS the AI MachineSara A.

The Specialist and the Box There once was a developer who knew Kubernetes. Let’s call him...

The Specialist and the Box

There once was a developer who knew Kubernetes. Let’s call him Bruno.

Not “has deployed something once.” Not “can read a tutorial.”

Bruno knew it. If there was a question about Kubernetes, Bruno was already answering it. If a project involved Kubernetes, there would inevitably be a moment where Bruno stood in front of a diagram explaining how everything worked. When something behaved strangely, everyone turned to Bruno.

And slowly, without anyone announcing it, a box formed.

The box had boundaries: containers, clusters, networking, scaling policies, resource limits. Inside those boundaries, Bruno was fluent. He knew the failure modes. He knew the edge cases. Outside the box… that was someone else’s diagram.

He no longer needed to be fully allocated to projects. He floated. He was invited when “scaling” appeared in a document.

Eventually, the company made it official. Bruno became the Kubernetes Titan. It appeared in org charts, in email signatures, and at least in one PowerPoint template. The box now had a name.


Inside the Box, Life Is Good

Life is good inside the box.

Bruno does not attend daily stand-ups. He does not debug pipelines. He is summoned when the topic is “orchestration.” He writes the guidelines: platform standards, deployment principles, slides titled “Kubernetes Strategy 2025.” He no longer reviews YAML — that is project work. Bruno defines what “good YAML” means.

If something doesn’t fit the standards, the answer is simple:

The application must adapt.

After all, the platform is correct. If something fails, it must be elsewhere. Inside the box, responsibility has edges. Bruno owns the platform. Everything else belongs to “the product.” Life is clean when responsibility is clean.

Lately, though, the questions feel different. They are not about scaling thresholds or deployment patterns. They are about how everything fits together.

Those are not Kubernetes questions.

Bruno prefers Kubernetes questions.


The Machine Eats the Box

At first, Bruno doesn’t notice. Then he does.

The meetings are shorter. Fewer architecture reviews. Fewer “Can we align on this?” messages. People still use Kubernetes — they just don’t need Bruno to explain it.

There is a new habit in the company. Logs go into chat windows. Diagrams go into chat windows. Entire systems get described to agents that reply in seconds. Instead of asking Bruno, they ask the machine.
No meeting required.

The machine answers quickly — deployment structures, scaling rules, example configurations. The answers are not perfect. But they are fast. And often… good enough.

Bruno tries it too. When the question stays inside the box, he can judge the answer. He can correct it. But when the question crosses into application design, database structure, integration flows…

Bruno reads the answer and does not know if it is right.

He knows Kubernetes. He does not know the system.

For the first time, that difference matters.

Jack notices this sooner. Jack has been using the machine for weeks — not for Kubernetes, for everything.


Jack Knows Where to Click

Jack works in the same company.

He is not a Titan. Not a Wizard. Not a Pro Whisperer. Jack just… works on things. He has written Java, Python and Typescript, built Docker images, fixed pipelines, written tests, removed tests, shipped things.

He does not know Kubernetes like Bruno does. But he understands the core ideas. And he understands something else: Kubernetes is powerful. It is also sometimes a cannon. And occasionally we are hunting flies.

When Jack works on an application, he tries to understand what it is supposed to achieve — not just how it runs, but why it exists. He understands what the data represents, what the business expects to see, what monitoring should detect, what the pipeline guarantees. He reads the requirements — sometimes twice.

Yes, Jack is kind of a bore. He has opinions about traceability.

He ties things together: orchestration, data, business rules, monitoring, pipelines, documentation.

When the machine produces an answer, Jack does not treat it as truth. He treats it as material. He knows which constraints matter and which assumptions cannot break. He doesn’t ask for a solution in isolation. He gives the machine the context — and asks for something that fits.

And when the machine answers confidently, Jack reads carefully. Sometimes he can’t explain why something feels off. But he can tell. And when he cannot tell, he knows where to look.

He doesn’t need to master one box.

He needs to move between them — and recognise when the machine is guessing.


Jack Has the Big Red Button

Let’s drop the story for a moment.

Kubernetes is just an example. This isn’t about Kubernetes. It isn’t about specialists being useless. It’s about boxes — and what happens when we stay inside them too long.

There’s a lot of noise about AI replacing juniors. Maybe. But there’s another group quietly at risk: the specialist who lives entirely inside one box.

AI does not just generate code. It connects things. It drafts architecture. It crosses boundaries without asking for permission.

If you only understand one layer deeply — but not how it interacts with others — you struggle differently. You don’t know what to ask. You don’t know what context matters. You don’t know whether the answer is subtly wrong.

This didn’t start with AI. The industry has been accelerating for years. Safe niches become narrow corridors.

The generalist — the so-called “jack of all trades” — never had the comfort of one box. They had to adapt. And AI rewards adaptation. It rewards context. It rewards people who can see across layers.

For years, I have been skeptical of rigid separation: developers here, validators there, DevOps in another silo. Those structures often create friction, duplicated effort, and systems that feel stitched together rather than designed. With AI in the mix, those walls become even more problematic.

If the machine sees the whole system, but the engineers only see their slice, the machine will move faster than the humans.
The generalist isn’t powerful because they know everything. They are powerful because they connect things. And the person who connects things decides what gets built.

The machine can generate. The machine can connect.

But someone still has to decide what makes sense.

That’s the button.
Jack presses it.
Carefully.