OpenLume retweeted
What actually happens when you run `terraform apply`? A quick visual walkthrough of how Terraform turns configuration into real infrastructure changes. #Terraform #DevOps
0
1
2
53
OpenLume retweeted
Why does Terraform need a state file? A quick visual explanation of how Terraform tracks real infrastructure, compares it with your configuration, and decides what to change. #Terraform #DevOps
0
1
4
83
OpenLume retweeted
Kubernetes Pods keep dying and getting new IP addresses.
So how does anything reliably connect to them?
That problem is exactly why Services exist.
Here’s the traffic flow visually, made using @OpenLume
#kubernetes #devops
So how does anything reliably connect to them?
That problem is exactly why Services exist.
Here’s the traffic flow visually, made using @OpenLume
#kubernetes #devops
0
1
2
35
OpenLume retweeted
Pod. ReplicaSet. Deployment.
Three Kubernetes objects that look like they’re doing almost the same thing.
They aren’t.
Here’s why Kubernetes needs all three.
#kubernetes #devops #containers
Three Kubernetes objects that look like they’re doing almost the same thing.
They aren’t.
Here’s why Kubernetes needs all three.
#kubernetes #devops #containers
0
1
2
38
OpenLume retweeted
You create a Kubernetes Pod.
Who decides which node runs it?
And when it crashes, what actually brings it back?
I made a short visual walkthrough of the full scheduling + recovery path with @OpenLume.
Who decides which node runs it?
And when it crashes, what actually brings it back?
I made a short visual walkthrough of the full scheduling + recovery path with @OpenLume.
0
1
3
29
Ask a technical question, get an interactive explainer video
Why are some technical explanations so hard to follow?
Sometimes the video tutorial is technically correct, but you still lose the thread halfway through.
The voice is flat. The pacing is off. Nothing gets enough emphasis, so your brain has to work harder just to follow along.
That’s the part I’ve been trying to fix.
New @OpenLume explainers now sound much more natural and teacher-like, with better pacing, pauses and emphasis around the parts that actually matter.
They also include a small question during the explanation, so you get a quick chance to check whether the idea really clicked. You can answer it, take a moment, or just listen while the narrator explains it and carries on.
Think of one technical concept you’ve been meaning to understand properly and give it another go in OpenLume 👇
0
0
1
27
Vibe reviewing... interesting 😀
We talk a lot about vibe coding. I think we need to talk about vibe reviewing too.
You ask AI to review a PR. It finds a few issues, explains them, and suggests fixes. Your coding agent makes the changes. The reviewer is happy. You skim the summary and approve.
You haven’t really read the code. But the review happened, the checks passed and the explanation made sense.
That feels like vibe reviewing to me.
@karpathy’s original vibe coding post described letting AI handle the implementation without reading the diffs. Vibe reviewing takes that a step further. We trust AI to tell us whether the implementation is good enough too.
After a decade in software engineering, I find that a bigger shift than getting AI to write the code.
Writing code and deciding whether to trust it have always been different responsibilities. A review was a chance for someone else to understand the change, question the assumptions and spot what the author missed.
With vibe reviewing, that second understanding may belong to another agent.
One agent writes the code. Another challenges it. They go back and forth. We see the conclusion.
I can see the appeal. Reconstructing the context of a change takes real effort. When agents can produce several changes while you’re still understanding the first one, you start wondering how much of that understanding you need to build yourself.
And honestly, human review has never been a guarantee either. We’ve all seen an LGTM on a change that deserved a closer look.
What interests me is what happens to the approval.
The button is the same. Your name is still attached to it. But you may now be saying “I trust the agents and the checks” rather than “I understand this change well enough to approve it.”
That’s a meaningful change in responsibility, even if the workflow looks familiar.
Two agents agreeing could give us more confidence. They could also share the same wrong assumption. A clear summary won’t necessarily tell us which happened.
I don’t have a neat answer for where that trust should stop.
0
0
0
24
This is something we think about a lot at @OpenLume too.
Before giving someone more logs, traces or docs, help them build the right mental model first.
Before giving someone more logs, traces or docs, help them build the right mental model first.
One pattern I have noticed over years of debugging production incidents:
Most engineers start with the tools.
Open alerts. Search logs. Check metrics. Look at traces. Maybe jump into the source code.
Experienced troubleshooters usually do the opposite.
First look at the error and symptoms and form 2 or 3 hypotheses about what could be happening.
Then go to logs, metrics, traces and code looking for evidence to prove or reject those hypotheses.
This sounds like a small difference, but during a real incident it changes everything.
Without a hypothesis, you are mostly searching.
With a hypothesis, every query has a purpose.
Observability tools give you evidence.
Debugging is still a reasoning problem.
0
0
2
27
The more AI writes, the less code becomes the bottleneck. Understanding does.
@OpenLume is built for that shift. Ask how a system works, and get the architecture, flow and concepts explained visually until they actually click.
@OpenLume is built for that shift. Ask how a system works, and get the architecture, flow and concepts explained visually until they actually click.
Abstraction over abstraction over abstraction. I am tired of software engineering.
Now add AI coding agents on top of all this. They are generating code against abstractions we barely understand ourselves.
You start with a simple problem. Somehow you end up with a framework on top of a library on top of an SDK talking to a managed service running on Kubernetes behind a load balancer with retries, queues, caches, service discovery and three layers of config.
Most of the time you do not even know half of it exists.
Everything looks clean while it works. Then something breaks and suddenly you are debugging a connection pool, DNS, some hidden retry, a container limit, an SDK timeout, or cloud behaviour you never even knew was part of your system.
We keep saying abstractions make software easier. Maybe they do when everything is healthy. But mostly they move complexity somewhere else until nobody really has the full picture anymore.
And now agents can generate and change these systems faster than we can understand them.
0
1
2
31
OpenLume retweeted
Good. Fast. Cheap. Pick two.
If engineers have to fully own AI generated code and reviewers partially own everything they approve, I suspect “fast” is the one that starts disappearing 😄
If engineers have to fully own AI generated code and reviewers partially own everything they approve, I suspect “fast” is the one that starts disappearing 😄
We have two rules for code going to production @PhonePe :
1. You own the code you commit
2. You partially own the code you review and approve
How the code is generated is irrelevant. Been working out fine so far for the most part.
1
1
4
992
OpenLume retweeted
I’ve spent most of my career close to infrastructure, build systems and developer tooling and I think there’s an important idea underneath this thread.
Software engineering isn’t disappearing. The abstraction boundary is moving again.
We moved from assembly to higher-level languages, from servers to cloud, from manual infrastructure to declarative systems. Each time, engineers stopped caring about some details and became responsible for a larger system.
Agents are another, much bigger, jump.
When an agent can produce thousands of lines of code in minutes, reviewing every line stops scaling. The interesting questions move up a level:
1/ Does the system do what we intended?
2/ What assumptions did the agent make?
3/ What happens under failure, load or partial degradation?
4/ Are the boundaries and dependencies right?
5/ Can we observe it well enough to know when reality diverges from intent?
I’m less convinced that tests, terminals or code review simply “die.” Their role changes. We’ll test behaviour more than implementation. Review intent and architecture more than syntax. Observability becomes part of verification, not something added after deployment.
And I think one skill becomes more valuable: building a mental model of a system you didn’t personally write.
That’s something I’m thinking about a lot while building @OpenLume too. If agents increasingly produce the implementation, humans need better ways to understand the architecture, flows and decisions around it. Maybe visually, interactively, without reading 20,000 lines of generated code?
The engineer of the future may write far less code. But they’ll need to understand far more software.
Software engineering isn’t disappearing. The abstraction boundary is moving again.
We moved from assembly to higher-level languages, from servers to cloud, from manual infrastructure to declarative systems. Each time, engineers stopped caring about some details and became responsible for a larger system.
Agents are another, much bigger, jump.
When an agent can produce thousands of lines of code in minutes, reviewing every line stops scaling. The interesting questions move up a level:
1/ Does the system do what we intended?
2/ What assumptions did the agent make?
3/ What happens under failure, load or partial degradation?
4/ Are the boundaries and dependencies right?
5/ Can we observe it well enough to know when reality diverges from intent?
I’m less convinced that tests, terminals or code review simply “die.” Their role changes. We’ll test behaviour more than implementation. Review intent and architecture more than syntax. Observability becomes part of verification, not something added after deployment.
And I think one skill becomes more valuable: building a mental model of a system you didn’t personally write.
That’s something I’m thinking about a lot while building @OpenLume too. If agents increasingly produce the implementation, humans need better ways to understand the architecture, flows and decisions around it. Maybe visually, interactively, without reading 20,000 lines of generated code?
The engineer of the future may write far less code. But they’ll need to understand far more software.
Most predictions I see are still way too conservative.
Here's mine
0
1
4
326
OpenLume retweeted
If YouTube and ChatGPT had a very productive meeting, with Udemy quietly taking notes, you’d get something like @OpenLume.
Ask a technical question. Get an interactive explainer video.
openlume.com
Ask a technical question. Get an interactive explainer video.
openlume.com
0
1
3
91
OpenLume retweeted
Over the last few months, I have noticed something changing in the way I work and I am seeing the same thing with engineers around me.
Coding agents have made it normal to move four or five pieces of work forward at the same time.
One agent is investigating a build issue. Another is changing infrastructure code. I am reviewing a design, checking a rollout and making decisions across all of them.
The velocity is impressive.
But I am starting to think the harder problem is no longer writing code.
It is shared context.
I see this in standups. A story that sounded simple yesterday may already have changed direction, picked up new dependencies and gone through several implementation decisions.
Now multiply that across five stories and an entire team.
In infrastructure and platform engineering, this matters even more because a small change in build tooling, CI, deployment or observability can affect many teams.
The code is moving faster than the team’s shared understanding of the code.
I do not think the answer is more meetings.
We need better ways to capture decisions as they happen and make context easy to discover.
AI is making individual engineers faster.
The next challenge is making sure the whole team can still move together at that speed.
Coding agents have made it normal to move four or five pieces of work forward at the same time.
One agent is investigating a build issue. Another is changing infrastructure code. I am reviewing a design, checking a rollout and making decisions across all of them.
The velocity is impressive.
But I am starting to think the harder problem is no longer writing code.
It is shared context.
I see this in standups. A story that sounded simple yesterday may already have changed direction, picked up new dependencies and gone through several implementation decisions.
Now multiply that across five stories and an entire team.
In infrastructure and platform engineering, this matters even more because a small change in build tooling, CI, deployment or observability can affect many teams.
The code is moving faster than the team’s shared understanding of the code.
I do not think the answer is more meetings.
We need better ways to capture decisions as they happen and make context easy to discover.
AI is making individual engineers faster.
The next challenge is making sure the whole team can still move together at that speed.
2
2
3
2,183
OpenLume retweeted
AI coding agents are making architectural decisions. Some teams are still reviewing them as autocomplete. Give an agent an unclear requirement and it can quietly turn its interpretation into behavior your system now depends on.
“Retry on failure” sounds harmless until the first attempt succeeds but the response gets lost. “Handle missing data” sounds obvious until missing becomes zero. “Make the import resilient” sounds sensible until half the batch succeeds and nobody has agreed on how recovery should work.
Each implementation can look clean and come with passing tests. If the agent wrote those tests around the same assumptions, you now have a well-tested interpretation of a requirement nobody actually settled.
That’s where I want engineering review to go deeper. What guarantees must hold? What happens after a partial failure? How expensive will this decision be to reverse once customers and real data depend on it? A locally reasonable choice can create an operational problem somewhere else.
This is also why code volume is such a poor measure of AI productivity. Every additional change introduces behavior someone has to understand, operate, and maintain. Saving an hour on implementation can create months of obligations for the team.
I want AI to help us compare designs, surface uncertainty, and test failure scenarios while changes are still cheap. That takes strong fundamentals and judgment about where to spend our attention.
If we can’t explain the behavior we’re committing to, the review is unfinished, however green the checks look. What’s a reasonable-looking assumption an agent made that would have been expensive in production?
“Retry on failure” sounds harmless until the first attempt succeeds but the response gets lost. “Handle missing data” sounds obvious until missing becomes zero. “Make the import resilient” sounds sensible until half the batch succeeds and nobody has agreed on how recovery should work.
Each implementation can look clean and come with passing tests. If the agent wrote those tests around the same assumptions, you now have a well-tested interpretation of a requirement nobody actually settled.
That’s where I want engineering review to go deeper. What guarantees must hold? What happens after a partial failure? How expensive will this decision be to reverse once customers and real data depend on it? A locally reasonable choice can create an operational problem somewhere else.
This is also why code volume is such a poor measure of AI productivity. Every additional change introduces behavior someone has to understand, operate, and maintain. Saving an hour on implementation can create months of obligations for the team.
I want AI to help us compare designs, surface uncertainty, and test failure scenarios while changes are still cheap. That takes strong fundamentals and judgment about where to spend our attention.
If we can’t explain the behavior we’re committing to, the review is unfinished, however green the checks look. What’s a reasonable-looking assumption an agent made that would have been expensive in production?
1
3
3
99
OpenLume retweeted
Most Kubernetes YAML is written for machines, not humans.
So I built a free tool in @OpenLume that turns your YAML into a visual explanation of what each part is actually doing.
No signup. No docs rabbit hole. 👇
So I built a free tool in @OpenLume that turns your YAML into a visual explanation of what each part is actually doing.
No signup. No docs rabbit hole. 👇
2
1
2
96
OpenLume retweeted
@OpenLume Paste any Kubernetes manifest and see workloads, services and their connections as a diagram with a plain-English walkthrough
openlume.com/explain/yaml
openlume.com/explain/yaml
0
1
1
5
OpenLume retweeted
Your GitHub Actions YAML shouldn’t need detective work.
Paste it into @OpenLume and see what triggers, what runs, and how the whole workflow connects — visually.
Free. No signup. 👇
Paste it into @OpenLume and see what triggers, what runs, and how the whole workflow connects — visually.
Free. No signup. 👇
1
2
1
563
OpenLume retweeted
@OpenLume Paste any GitHub Actions workflow and see triggers, jobs and dependencies as a diagram with a plain-English walkthrough.
openlume.com/explain/github…
openlume.com/explain/github…
0
1
1
18
OpenLume retweeted
Most Dockerfiles look simple right up until the image is huge, slow, or broken.
Paste yours into @OpenLume and get a visual breakdown of what every instruction, stage, and layer is actually doing.
Free. No signup. 👇
Paste yours into @OpenLume and get a visual breakdown of what every instruction, stage, and layer is actually doing.
Free. No signup. 👇
1
1
1
96
OpenLume retweeted
@OpenLume Paste any Dockerfile and see stages, layers and what each instruction does with a plain-English walkthrough.
openlume.com/explain/docker…
openlume.com/explain/docker…
0
1
1
4