A friend of mine, Jose, sent me a conversation he’d had with an AI assistant about an article he’d been reading. The article was The Tacit Dimension by Christian Ekrem. Jose’s observation was sharp: he’d been frustrated by the same thing the article describes, AI assistants that produce confident output without surfacing any of the reasoning behind it, the implicit design decisions staying implicit. The conversation he shared was good enough that I went and read the article itself.

It made me put my phone down. Not because it was wrong, but because it was pointing at something real and uncomfortable, and because it immediately made me think about my son.

The article builds on Michael Polanyi’s 1966 claim: we can know more than we can tell. Polanyi’s observation was that expert knowledge is structurally tacit. It lives in the body, in practice, in the pattern-recognition accumulated over years of doing a thing. You can’t extract it. You can’t train a model on it, because it was never written down. And you can’t transfer it except by working alongside someone who has it.

Ekrem applies this to AI-assisted software development and argues we are sleepwalking into a crisis: juniors are being apprenticed to AI assistants instead of to seniors, the “why does this work this way?” questions are drying up, and the tacit knowledge that used to flow through teams is quietly bankrupting out of codebases. The seniors retire. Nobody knows why the auth system works the way it does. The code keeps running.

It’s a well-argued piece. But it has a gap in it, and that gap leads somewhere interesting.

Where the Argument Holds

Ekrem’s strongest point isn’t about AI. It’s about what happens when any shortcut severs the connection between doing and understanding.

His illustration is a colleague who spent an afternoon refusing to merge a PR that was technically correct. Tests passing, CI green, everything fine on paper. He kept saying “I just don’t believe this code.” Forty minutes into walking the author through it line by line, the author said offhand: “this assumes the queue is FIFO, but I think that’s safe.” It wasn’t. The queue was FIFO in development and best-effort-FIFO in production, buried in a runbook nobody had read in two years.

The colleague had smelled it from the diff. Not from reading a document. From a decade of looking at similar things and accumulating a mental model of where pain tends to come from. That kind of knowledge doesn’t show up in any training corpus because it was never written down in any single place. It was always distributed across experience, context, and memory.

An AI can’t replicate that. Not because current models are too limited, but because the knowledge is structurally absent from anything a model could be trained on. That’s the actual claim, and it survives scrutiny.

Where I Push Back

The argument assumes that the median junior, given access to an AI assistant, will use it as a replacement for thinking. And honestly? A lot of them will. But that’s not a fact about AI. That’s a fact about the median junior and the absence of good mentorship. The same junior, given access to Stack Overflow, Google, or a patient senior who answers every question without making them think first, will also atrophy. The crutch varies. The dynamic doesn’t.

A good junior understands that AI is a tool to unblock you on things you need to understand, not an infinite knowledge base to stop thinking. The operative word is understands. That understanding doesn’t come automatically. It has to be built. And that’s what the article is really pointing at without quite saying it: the apprenticeship model isn’t failing because of AI, it’s failing because nobody is teaching juniors how to learn.

Ekrem calls one failure mode the Fluency Mask: AI’s verbal fluency about code being mistaken for understanding of code. It’s real. But it’s a trap that only closes on someone who isn’t watching for it. The senior’s job has always been to teach juniors to watch for exactly that kind of thing. Confident outputs that feel like understanding but aren’t grounded in anything. Stack Overflow answers with high vote counts. Code that compiles. Documentation that reads clearly but documents the wrong thing. AI is a new instance of an old problem.

My son will grow up in a world where AI is as ambient as the internet was for my generation. He won’t know a time without it. The question isn’t whether he’ll use it, he will and he should, but whether he’ll use it well or badly. The distinction I want him to carry is simple: AI is a tool to resolve a specific gap, not a replacement for developing the judgment to know where the gap is. Think first. Reach when stuck. Understand what you got back. Inverting that sequence is where the damage happens.

Building the Muscle

The most important window is before he can fluently use AI, which is shrinking fast. The cognitive capacity I want him to develop is tolerance for not-knowing: the ability to sit with an unresolved problem without immediately reaching for relief. Everything downstream of that, debugging, reasoning, designing, the smell that something is wrong before you can name what, depends on being able to stay in the discomfort long enough to actually think.

The way to build that tolerance is not by explaining it. It’s by not rescuing him. When he’s stuck, the temptation is to solve it. Resist it. Sit with him in the stuck. Ask questions that point at the problem without resolving it. Let him feel the friction. That discomfort is the exercise. Skipping it is skipping the rep.

When AI is in the picture, I want to use it with him out loud, narrating why I’m reaching for it. “I know what I want here but I’ve forgotten the syntax, I’ll check” is different from “I don’t know what I want yet, so I need to think before I ask anything.” He needs to see that distinction made consciously, by someone he trusts, before it becomes instinct.

After he’s worked through something, I want to ask him to explain it back. Not as a test. As genuine curiosity. The act of explanation forces him to consolidate what he actually understood versus what he pattern-matched. The gaps surface immediately. He’ll say something and pause because he doesn’t actually know why it works that way. That pause is the whole point. Recognising it as a gap rather than papering over it with confident-sounding words is the habit I want him to have.

The Actual Apprenticeship

The most direct version of all of this is the simplest: when I’m working through something, a problem, a piece of code, a decision, let him watch sometimes. Not to teach him the domain. To show him what thinking looks like. The false starts. The “hmm, that’s not right.” The moment something clicks. Most kids never see an adult genuinely wrestling with a hard problem because adults hide the struggle. Showing him the struggle, including my own uncertainty, is probably the most valuable thing I can do.

The threat isn’t AI. The threat is the absence of people willing to do the slow work of the apprenticeship model: to let juniors watch them think, to push back on “I don’t know why but trust me,” to pair and review and explain. AI makes the shortcut more available and more seductive. But the shortcut was always there. The question was always whether someone cared enough to make you take the longer road.

For my son, that’s the job. Not to keep him away from AI, that ship has sailed and the destination is fine, but to make sure he gets enough reps on the longer road first that he knows what it feels like and why it’s worth walking.

The kids who figure that out will be the ones the next generation of teams desperately needs.

Inspired by The Tacit Dimension by Christian Ekrem, and by a conversation with an AI assistant that was, appropriately, more useful than I expected.

Tenho a impressão de que frontend está entrando em uma nova fase em relação a motion.

Durante muito tempo, animação na web dependia de bibliotecas relativamente pesadas porque o CSS simplesmente não oferecia controle suficiente sobre timelines, sincronização e estados contínuos.
Agora isso está mudando rápido.
Features como animation-timeline, scroll-driven animations e melhorias nas APIs de view transitions começam a trazer para o navegador capacidades que antes exigiam GSAP ou implementações complexas em JavaScript.
O impacto disso vai além de “efeitos visuais”.
Motion bem implementado melhora:

• percepção de performance
• clareza de hierarquia
• feedback de interação
• sensação de fluidez do produto
• compreensão de estado da interface

E acho que o mercado também amadureceu nesse ponto.
Hoje, a diferença entre uma interface “moderna” e uma interface realmente premium raramente está em componentes isolados. Normalmente está na consistência do comportamento visual.

Timing, easing, aceleração, continuidade e responsividade começaram a funcionar como tipografia funciona no design gráfico: quando estão ruins, todo mundo percebe. Quando estão bons, quase ninguém nota conscientemente (mas a percepção de qualidade sobe muito.).

Curioso para ver como o ecossistema vai evoluir nos próximos 2 anos, principalmente com browsers assumindo mais responsabilidades que antes ficavam em libraries externas.

There’s a hidden cost senior engineers pay every morning when they open Cursor. It compounds quietly, it doesn’t show up on any dashboard, and at a typical senior billing rate it’s worth thousands of pounds a year. I call it the Context Tax. Here’s why it happens, what it actually costs, and the four-rule architecture I built to eliminate it.

The 15-minute problem

Open Cursor on Monday morning. New chat. You’re picking up where you left off Friday — adding a caching layer to OrderService. You type:

“Add Redis caching to this method.”

And the AI returns something technically correct, but architecturally wrong. It instantiates ConnectionMultiplexer directly in the service constructor. It uses IMemoryCache as if your project doesn’t already register IDistributedCache. It writes a synchronous wrapper around an async call.

You sigh. You type the preamble. Again.

“This project uses Mediator and Result<T>. We register caching through IDistributedCache in /Infrastructure/Caching. Don’t reach into ConnectionMultiplexer directly. Don’t put any caching logic in the Service layer — wrap it via a decorator in Infrastructure. And we never instantiate dependencies, we inject them via constructor.”

Three paragraphs. Maybe four. By the time the AI has the context it needs to actually be useful, you’ve spent fifteen minutes typing what your codebase has already shown it dozens of times before.

That’s the Context Tax.

Why it happens

Cursor — like every other AI coding tool right now — has no persistent memory between sessions. Each new chat starts fresh. Every architectural decision your team has ever made, every refactor your codebase has ever absorbed, every “we tried that, it doesn’t work for us” — gone the moment you close the window.

The AI isn’t stupid. It’s amnesiac.

Worse: even within a session, the AI’s understanding of your architecture is a fragile probability cloud. By Wednesday afternoon it has “forgotten” the convention it followed on Monday. It starts suggesting patterns that violate your boundaries. You correct it. It double-downs. You correct it again. It loops on the same hallucination, burning tokens, burning your time.

This is what I call AI drift, and on a long project it’s the single biggest reason senior engineers go from “Cursor is incredible” to “I’ve turned the autocomplete off.”

The cost

Let’s do the uncomfortable math.

• 15 minutes per day spent on re-context and correcting drift.
• ~250 working days per year.
• That’s 62.5 hours. Nearly eight full working days annually.
• At a UK senior dev billing rate of around £75/hour, that’s £4,687.50 of senior time, per engineer, per year — bleeding out invisibly.

On a five-engineer team that’s the cost of a junior hire.

The instinct that doesn’t work

The obvious response is to write a long system prompt with all your conventions and paste it at the top of every new chat. Most senior engineers I know have tried this. It fails for three reasons:

1. Token bloat. A 2,000-token preamble at the start of every prompt is expensive and slow. Worse, the AI’s attention to specific rules degrades as the preamble grows.
2. Discipline decay. You’ll do it for a week. By week two you’ll start skipping it for “quick” prompts. The drift returns.
3. Static knowledge. Your architecture evolves. The preamble doesn’t. It’s a snapshot from whenever you last bothered to update it.

You don’t need a longer prompt. You need persistence.

What persistence actually looks like

The breakthrough — once you stop thinking of Cursor as a chat-bot and start thinking of it as a stateful pair-programmer — is that the AI needs three things to behave like a senior:

1. A long-term memory file that lives in the repo, that the AI reads on every session start, and that the AI itself updates whenever it learns something new. Architectural Decision Records (ADRs) for the AI, by the AI.
2. Scoped, directory-aware rules that load only when relevant — a DI rule fires on Startup.cs and ServiceCollectionExtensions.cs, not on every controller. Token budget preserved.
3. A circuit breaker that detects when the AI is in a hallucination loop and forces it to stop, re-read the file, and ask a question rather than double down.

None of these are exotic. They’re standard senior-engineering moves applied to the AI itself.

The four-rule architecture

I packaged the pattern I’ve been using on real .NET codebases into four .mdc files Cursor reads natively:

• arch-core.mdc — boundary enforcement. Detects which layer the current file lives in and refuses suggestions that cross it.
• dotnet-di.mdc — DI auditor. Catches Scoped → Singleton capture, HttpClient instantiation, IConfiguration leaks into business logic.
• bug-breaker.mdc — the circuit breaker. Watches for repeated failed attempts on the same problem and forces re-reading instead of doubling down.
• persistence.mdc — the engine. Maintains LEARNING_LOG.md across sessions. Auto-appends decisions in an ADR-style format. Hydrates the AI on session start.

The whole thing lives in .cursor/rules/ and a single root-level LEARNING_LOG.md. Zero config. Zero build step. Commit it to your repo, your whole team gets the same baseline.

What “after” looks like

Monday morning, two months in. New chat:

“Add Redis caching to OrderService.”

The AI responds:

“Detected Scoped lifetime conflict with IMemoryCache (Singleton). Following Log Entry #27: ‘Prefer IDistributedCache abstraction in /Infrastructure/Caching.’ Applying decorator pattern via Scrutor per arch-core.mdc §3…”

No preamble. No correction loop. The AI already knows.

Try one rule for free

The arch-core-lite.mdc rule is a stripped-down version of the kit’s boundary guardian. Drop it in your .cursor/rules/ folder and watch your AI start respecting your layers today. Free download, no signup:

👉 Download arch-core-lite.mdc

Or just stop the Context Tax today

The full Agentic Architect kit — 4 specialist rules + the persistence engine + Learning Log template — is £19.99 one-time. Lifetime updates. MIT-licensed. 14-day no-questions refund.

👉 Get the full framework — £19.99

Originally published at agenticstandardcontact-byte.github.io/agentic-architect/blog. Canonical URL is set so the original gets the SEO juice.

We wanted to sell software licenses to customers in over 120 countries without any payment restrictions. The platform stores we had been using didn’t allow direct sales in certain countries due to sanctions and regulatory compliance issues.

The Problem We Were Actually Solving

Our architecture was designed to handle the complexities of international payment processing, but the platform stores’ limitations kept us from reaching a significant portion of the global market. Our revenue was stagnant, and we couldn’t grow our customer base as much as we wanted. We had to decide whether to work around the limitations of the platform stores or create our own infrastructure to handle direct sales.

What We Tried First (And Why It Failed)

Initially, we tried using third-party solutions that allowed us to bypass the payment restrictions, but these solutions came with high transaction fees, which cut into our revenue margins. We also implemented workarounds to manually process payments from restricted countries, but this introduced errors and inconsistencies in our bookkeeping. The system was brittle and prone to failures, and our customer support team was overwhelmed with inquiries about payment issues.

The Architecture Decision

After months of struggling with the limitations of the platform stores, we decided to build our own infrastructure for direct sales. We chose a headless e-commerce architecture with a RESTful API for payment processing and a modern warehouse as the data storage layer. This allowed us to handle payments and bookkeeping in a centralized location, eliminating the need for third-party solutions and manual workarounds. We also implemented robust error handling and monitoring to ensure that our system could withstand the increased traffic and volume of sales.

What The Numbers Said After

Our pipeline latency decreased by 30% after the transition to our own infrastructure, allowing us to process payments and fulfill licenses in real-time. Our query cost on the warehouse decreased by 50% due to the improved architecture and data storage. We were able to hit an average freshness SLA of 5 minutes for our sales data, which gave us more accuracy and confidence in our business decisions. Our team experienced a significant reduction in support requests and errors, freeing up resources to focus on growth and innovation.

What I Would Do Differently

In hindsight, I would have started with a more incremental approach to building our own infrastructure. We should have begun by migrating a small subset of customers to our new system and monitoring their behavior and feedback before scaling up. This would have allowed us to identify and address potential issues earlier in the process. I would also have invested more in automated testing and CI/CD to ensure that our new system was thoroughly tested and validated before going live. By taking a more incremental and iterative approach, we could have minimized the risks and downtime associated with the transition and ensured a smoother experience for our customers.

Quantum computing today is firmly in the NISQ (Noisy Intermediate-Scale Quantum) era. In theory, everything sounds brilliant: quantum advantage, exponential speedup, and the ability to solve problems far beyond the reach of classical computers. However, in practice, anyone diving into algorithms like QAOA (Quantum Approximate Optimization Algorithm) eventually hits a “wall”—usually around 20–30 qubits.

But what if your task involves analyzing a social graph with tens of thousands of nodes? Take the Epinions dataset, for example, which contains over 75,000 users linked by thousands of trust relationships. Classical simulators simply “choke” on memory when attempting to process such a state vector.

In this article, I will show you how I turned this limitation into an engineering challenge. Instead of trying to “stuff the unstuffable” into a quantum processor, I developed a hybrid orchestrator that decomposes massive networks into quantum-accessible fragments. We’ll walk through the entire pipeline: from loading a GZIP archive to generating an optimized CSV report.

Architecture: Divide and Optimize
The main problem with large graphs is their connectivity. My approach relies on three stages, the logic of which is illustrated in the diagram above:

1. Decomposition: We use classical community detection algorithms (Greedy Modularity). We break the massive graph into clusters where nodes are tightly connected internally but loosely connected between clusters. This localizes the MaxCut problem.

2.Quantum Solver (QAOA Core): Each cluster is passed to an optimizer based on PennyLane. Here, we run QAOA to find the configuration of states that maximizes the cut weight.

3.Orchestrator (Aggregation Layer): This is the “heart” of the system. It tracks the mapping between local and global IDs and aggregates the results of individual quantum circuits into a single report.

Technical Implementation: Code that “Cuts” Graphs
The foundation of our orchestrator is a streamlined pipeline for graph partitioning.

Simplified Orchestrator Logic

def run_orchestrator(graph_path):
# 1. Load and decompose
graph = load_graph(graph_path)
clusters = decompose_graph(graph, algorithm=’greedy_modularity’)

results = {}
for cluster_id, nodes in clusters.items():
    # 2. Map global IDs to local indices
    mapping = create_node_mapping(nodes)
    subgraph = graph.subgraph(nodes)

    # 3. Execute Quantum Solver
    if len(nodes) <= 20:
        results[cluster_id] = run_qaoa_solver(subgraph, mapping)
    else:
        # Recursive handling for large clusters
        results[cluster_id] = handle_large_cluster(subgraph)

return aggregate_results(results)

Key components:
decompose_graph: Breaks the graph down so the task becomes solvable on accessible hardware.

run_qaoa_solver: The quantum “brain.” Here, the MaxCut problem is mapped onto quantum gates.

run_orchestrator: A manager that iterates through all clusters and reconstructs the global picture.

Engineering Note: In real-world scenarios, cluster sizes vary. It is crucial to include a check like if len(nodes) > 20: to force the orchestrator to split overly large clusters, preventing memory overflow.

Hurdles: Why It Wasn’t Easy
Implementation was a battle against data limitations. Here are three problems I had to solve on the fly:

1. Indexing: NetworkX reindexes nodes within a subgraph. I added a layer of mapper dictionaries (node_mapping) that preserves the link between a cluster’s local index and the original graph’s global ID.

2.Simulator Overflow: If the modularity algorithm produces a cluster that is too large, I implemented recursive partitioning. This turns the system into a hierarchical “tree-like” optimizer.

3.GZIP Handling: For 75k nodes, I use streaming (via yield) so the orchestrator processes the graph in parts without loading the entire file into RAM.

Conclusion
This project is not the finish line, but a proof of concept that hybrid systems are already capable of handling workloads that exceed the capacity of “off-the-shelf” quantum simulators. My next steps include integration with a real quantum backend and further optimization of the orchestrator.

I’d love to hear your feedback: How do you solve scalability issues in your quantum tasks?

Repository link: github