By Mark Working in an engineering organization, I often see internal team dynamics shift whenever a new technology trend emerges. In today’s tech landscape, these shifts are larger than ever before. With Large Language Models (LLMs) and Retrieval-Augmented Generation (RAG) becoming deeply integrated into everyday engineering workflows, team discussions and architecture reviews look fundamentally different. I found the phrase “According to AI” to be new.
There are clear, positive changes. High-potential junior engineers are leveraging LLMs to rapidly understand frameworks and architectural patterns that previously took years of traditional apprenticeship to master. When juniors combine senior mentorship with AI as a pair-programming partner, their output and technical insights can be impressive.
At the same time, senior engineering ranks are undergoing a clear sorting process. Those who relied purely on seniority or superficial design talk without deep technical substance are finding it difficult to stay relevant. Conversely, engineers with genuine technical fundamentals are treating this shift as an opportunity. Rather than relying solely on past heuristics, they use LLM tutoring and deep reasoning modes to study modern stacks and evolve into continuous learners. The gap between superficial seniors and truly capable engineers is clearer than ever.
Beneath these positive developments, however, lies a significant organizational problem: the uncritical reliance on “According to AI”—treating whatever an AI outputs after a few seconds of prompting as absolute truth. When combined with internal workplace politics, this dynamic frequently undermines sound technical decision-making.
A Series on Interesting Phenomena Emerging in the AI Era
Stage 1. Early Adoption (Ignorance, Blind Faith & Misuse)
- Ep. 1 | Leaks & Costs: AI Turned into a PII Classifier — Reckless data ingestion and the reality of runaway token bills
- Ep. 2 | Distrust: When “AI Says So” Trumps Decades of Senior Expertise — Hallucinated answers replacing seasoned engineering judgment
Stage 2. Diffusion (Role Collapse & Contribution Conflicts)
- Ep. 3 | Delusion: The Manager’s Vibe-Coding Fantasy — Underestimating engineering complexity by thinking anyone can build production software
- Ep. 4 | Chaos: Why Coding Requirements Infiltrated DBA Job Postings — The role-inflation trap driven by the “everyone must code” hype
- Ep. 5 | Dismissal: “AI Wrote It, So What Did You Actually Do?” — Distorted performance reviews that erase architecture and debugging efforts
Stage 3. Endgame (Debt Explosion & Loss of Control)
- Ep. 6 | Technical Debt: Product Managers Writing Code and the Compounding Interest — Prototype-level spaghetti code boomeranging into unmaintainable systems
- Ep. 7 | Complacency: “Vulnerabilities? We’ll Just Have AI Swap the Library” — Ignoring dependency graphs and architectural blast radiuses until a security breach hits
- Ep. 8 | Betrayal: This Isn’t the Deterministic System You Thought It Was — Non-deterministic behavior, context drift, and total systemic collapse
As an experienced engineer who reviews code and monitors production systems daily, I occasionally wonder whether I am viewing these shifts objectively. Yet across the industry, seasoned engineering judgment is increasingly being dismissed simply because someone insists, “Well, according to AI, this is the way to do it.”
Table of Contents
Stage 1. Early Adoption: Ignorance, Blind Faith, and Misuse
When an organization first adopts a major technology, it typically passes through a phase marked by ignorance, uncritical trust, and misuse. Teams often assume AI will eliminate all engineering bottlenecks. Instead of evaluating probabilistic errors or operational limits, they focus primarily on the speed of answers delivered under the banner of “According to AI.”
Senior Heuristics vs. Probabilistic Text Generation
In systems engineering, “experience” does not mean memorizing API syntax. It is the sum of real-world troubleshooting: handling midnight database deadlocks, managing network interface packet drops during traffic surges, and tracing memory leaks down to asynchronous bugs in third-party libraries. These form an engineer’s operational heuristics.
By contrast, the “According to AI” narrative is backed purely by probabilistic text generation. An LLM calculates statistically likely token sequences within a given context window. Even when integrated with internal wikis and technical documentation via RAG, the output remains a statistical synthesis rather than an innate understanding of runtime realities.
When engineers or non-technical managers lack foundational systems depth, they often mistake articulate text for sound engineering. When an engineer argues that “According to AI,” an asynchronous queue pattern is an industry best practice, that neat bulleted summary easily overshadows a senior engineer’s practical warning that the approach will exhaust connection pools under real-world traffic profiles.
How “According to AI” Disrupts Technical Consensus
This erosion of trust frequently surfaces in architecture reviews and sprint planning sessions.
Cherry-Picking Minor Oversights to Invalidate Architectural Judgment
Consider a real-world scenario involving database sharding and cache tier redesign for a high-throughput transaction and settlement system. A lead engineer explains on the whiteboard:
“Given the synchronization intervals of our legacy data pipeline and the memory constraints on our Redis cluster, using local in-memory caches and targeted index tuning is safer for reducing latency this quarter. Introducing distributed locks prematurely risks payment confirmation delays and potential downtime.”
A junior engineer responds by presenting an AI-generated architecture report created by feeding table schemas and business requirements into an internal RAG assistant:
“I ran our schema and requirements through our AI architecture model. According to AI, an in-memory distributed cache combined with an event-driven architecture (EDA) over Kafka is significantly more scalable. The AI notes that your approach creates tight data consistency coupling and leads to technical debt.”
The senior engineer’s recommendation was shaped by unwritten operational context: internal network bandwidth experiences packet loss during specific peak windows, and external payment gateway APIs handle asynchronous events poorly, requiring manual reconciliation batches.
During the discussion, however, the senior engineer makes a minor mistake regarding a deprecated configuration parameter in a newer open-source release. The junior engineer and manager immediately focus on this detail:
“Wait, that parameter is deprecated in version 2.4. According to AI and the official docs it cited, that syntax throws an error. If basic syntax is wrong here, isn’t your concern about distributed locks just an overly conservative assumption based on legacy systems?”
This illustrates a common failure mode: seizing on a minor syntactic mistake to dismiss a comprehensive architectural assessment, using “According to AI” as an indisputable trump card.
The Alignment of Workplace Politics and “According to AI”
Engineering managers and project leads often focus on delivery timelines, roadmaps, and executive reporting rather than writing implementation code. Their primary incentives are meeting deadlines and presenting defensible technical rationales.
Historically, managers had to rely on senior engineers for realistic task estimation and risk assessments. If a senior stated that edge-case testing and data consistency verification required six weeks, that estimate had to be factored into planning.
With LLMs, managers now cite “According to AI” to challenge those estimates:
- Prompt: “What is the standard sprint duration and resource allocation to build a settlement system for 1 million users using Spring Boot and microservices with modern automated testing tools?”
- LLM Output: “With modern CI/CD pipelines and containerized environments, two experienced engineers can deliver an initial prototype with core features and unit tests within two weeks.”
A manager can then leverage this against the engineering team: “According to AI, two weeks is enough for a standard sprint plan. Why are you requesting six weeks? Is this an engineering roadblock, or an overly conservative timeline?”
This dynamic creates an unhelpful alignment between non-technical management and less experienced engineers. Juniors deliver rapid ticket turnarounds using boilerplate and defend it with “According to AI,” while managers present these metrics to leadership as successful adoption. Meanwhile, engineers who focus on baseline infrastructure limits and production failure modes risk being viewed as slow bottlenecks.
The Operational Paradox: Who Actually Validates the Output?
This dynamic leads to a clear paradox: the only people capable of distinguishing safe solutions from high-risk failure modes within an “According to AI” design are the experienced engineers whose input is being discounted.
+-------------------------------------------------------------------------+
| LLM / RAG Architecture ("According to AI") |
| - Polished structure, standard patterns, modern tech stack |
+-------------------------------------------------------------------------+
│
▼
┌────────────────────────────┼────────────────────────────┐
│ │ │
▼ ▼ ▼
[ "According to AI" Believers ] [ Superficial Seniors ] [ Continuous Learners ]
- Accepts AI as absolute - Lacks modern fundamentals - Uses AI to test hypotheses
- Overlooks edge cases - Relies only on past title - Identifies race conditions
│ │ │
▼ ▼ ▼
Pushes to Production Unable to Defend Designs Builds Guardrails & Verifies
│ │
└────────────────────────────┬────────────────────────────┘
│
▼
+-------------------------------------------------------------------------+
| Production Runtime Failure |
| - Connection pool exhaustion and data integrity issues |
| - Excuses shift to "Well, that's what AI told us to do" |
| - Requires experienced engineers to analyze memory dumps & fix |
+-------------------------------------------------------------------------+
Unchecked Failure Modes Behind “According to AI”
While modern reasoning models generate code effectively, the “According to AI” rationale does not account for physical hardware boundaries or runtime environmental variables:
- Concurrency Bugs: Code may pass unit tests in single-threaded environments while harboring race conditions that trigger only when thousands of worker routines access shared database resources concurrently.
- Transaction Isolation Conflicts: An “According to AI” async pattern can conflict with database isolation levels (such as Read Committed versus Repeatable Read), leading to phantom reads or data discrepancies.
- Partial Failure Handling: In distributed systems where a network partition causes one service to commit while an upstream call times out, an “According to AI” suggestion frequently generates “happy path” logic without designing compensation transactions (such as Saga patterns) to handle rollbacks.
When junior developers submit pull requests because their code passes local tests and linters, they often defend design flaws by stating, “Both Claude and ChatGPT confirmed this is the optimal approach.” If a senior engineer comments that the logic will exhaust database connection pools during traffic spikes, the pushback is predictable: “According to AI, this runs asynchronously without blocking, and benchmark prompts showed no issues.”
Without firsthand experience debugging production failures, teams easily mistake logical fluency for operational reliability.
The Divergence Among Senior Engineers
The availability of advanced tooling is also reshaping how senior engineers operate:
- Engineers Who Update Their Skills: Experienced engineers possess an internal index of failure modes. When reviewing an “According to AI” diagram, they can quickly spot write-amplification risks or disk I/O bottlenecks. They use targeted prompts—such as inquiring how to tune LSM-tree storage engines to handle write amplification—turning the model into an effective research assistant rather than an oracle.
- Engineers Who Rely on Outdated Playbooks: Those who stopped learning modern systems cannot effectively challenge the “According to AI” arguments brought by juniors. Without up-to-date foundational knowledge, they fail to provide structured technical counterarguments, further eroding their credibility.
Superficial Alignment vs. Operational Reality
Systems eventually expose poor architectural choices. While polished documentation and rapid demos satisfy initial planning meetings, production infrastructure operates purely on technical constraints.
When unverified “According to AI” architectures face real production traffic and fail, generic troubleshooting prompts rarely resolve the issue. Prompts such as “The application is unresponsive under load” yield basic advice to review logs or add compute resources. Recovering the system requires inspecting memory dumps, tracing thread contention, and manually untangling execution paths—work that ultimately falls back on experienced engineers.
Engineering Guidelines for Restoring Technical Decision-Making
Addressing this issue requires updating engineering processes rather than treating it as an interpersonal or generational disagreement:
1. Ban “According to AI” as a Technical Argument
Phrases like “According to AI” or “The AI recommended this” must not be accepted as valid technical justifications in pull requests or design documents. The author must be able to explain the underlying mechanics, operational trade-offs, and failure scenarios independently.
Engineers should explain how consumer lag is handled under backpressure in an asynchronous pipeline, rather than relying on assertions that the pattern is safe because an AI generated it.
2. Mandatory Failure-Mode Testing
Disagreements regarding architectural trade-offs should be evaluated through stress testing and chaos engineering in staging environments rather than abstract debates.
If a senior warns that an architecture will exhaust connection pools under peak loads, the design should be benchmarked under simulated load profiles. Observing error rates and resource limits directly demonstrates the practical validity of operational experience, cutting through the “According to AI” rhetoric.
3. Senior-Led Verification Frameworks
Instead of letting teams rely on unguided “According to AI” snippets, senior engineers should design internal linting rules, static analysis checks, and automated validation pipelines that reflect organization-specific operational constraints. AI-assisted contributions can then be evaluated systematically against these baseline rules.
Focusing on System Fundamentals
Throughout previous technology transitions—such as the shift from on-premises hosting to cloud platforms—engineers who understood low-level networking and operating system fundamentals continued to provide the most value as system architects.
The current transition is no different. Anyone can generate articulate technical proposals using AI. High-potential juniors will use those answers to dive into core principles, while true seniors will rigorously stress-test those answers to refine their own capabilities.
The only people who become obsolete are those who hide behind “According to AI” without understanding the system, and those who stop learning while hiding behind their years of tenure.
If an organization cannot look past the superficial authority of “According to AI”, its architecture will remain fragile. Genuine engineering does not lie in quoting what an AI produced; it lies in the persistence required to identify, test, and fix the hidden flaws within those answers.