Programmers Who Can Only Call APIs Are Being Made Obsolete by AI Coding Tools

A Soul-Searching Question About a Shopping Cart

A technical interview conversation recently went viral online. The interviewer asked a candidate to describe how to implement a simple shopping cart system. The candidate's response exposed a fatal weakness common among many modern programmers — they can only call framework APIs but know nothing about underlying computer science principles.

The interviewer's question was straightforward: "Using your technical knowledge, how would you build a shopping cart?" The candidate's answer: start a Spring Boot service, define data entities, write a Controller, register with Nacos, configure load balancing... A stream of framework jargon rolled off the tongue, yet never touched upon the most fundamental question — what data structure would you use to store the items in the shopping cart?

This conversation reflects more than just an individual's skill gap — it reveals the collective predicament of an entire generation of programmers cultivated under the "frameworks above all" mindset. And this is precisely the type of work that AI coding tools can most easily replace.

The Interviewer's Approach: Starting from the Essence of the Problem

The interviewer laid out an extremely clear technical approach that every developer should reflect on:

Step 1: Choose a data structure. A shopping cart is essentially a container for storing items. The simplest approach is to use a Map, with the product name as the Key and product information as the Value.

A Map (also known as a hash table) is one of the most fundamental and important data structures in computer science. It stores data through key-value pairs, and its average O(1) lookup time complexity makes it a natural choice for shopping cart scenarios. In Java, this manifests as HashMap or ConcurrentHashMap; in Python as dict; in Redis as the Hash type — all are concrete implementations of this same abstraction. Understanding why you'd use a Map instead of a List or array requires understanding hash functions, collision handling, load factors, and other underlying mechanisms — this is precisely the part that frameworks cannot think through for you.

Step 2: Add distributed capabilities. A Map in memory has no distributed capability on its own, but through an HTTP Server or TCP protocol, remote clients can access this Map.

Step 3: Handle concurrency. When multiple users access this map simultaneously, you need concurrency handling. This touches one of the most complex areas in computer science. In a single-machine scenario, Java's ConcurrentHashMap achieves thread safety through segment locks (JDK 7) or CAS+synchronized (JDK 8+); in distributed scenarios, you need distributed locks (such as Redis's SETNX command or Zookeeper's ephemeral nodes) or optimistic locking (version number mechanisms). The shopping cart's concurrency problem is particularly classic: when the same user operates the cart simultaneously on multiple devices, how do you ensure data consistency? This involves trade-offs in the CAP theorem — during network partitions, do you choose consistency (CP) or availability (AP)? These architectural decisions require deep understanding of distributed systems, far beyond the scope of framework configuration.

Step 4: Consider persistence. If you need to save data to disk, write the data from the map into a database.

The core characteristic of this approach is: start from the essence of the problem and incrementally add capabilities. Data structure → network communication → concurrency control → persistent storage — each step has a clear technical rationale, rather than piling on frameworks from the start. This reasoning method stems from First Principles Thinking — rejecting the analogical thinking of "everyone else does it this way" and instead deriving solutions from the most basic physical constraints and mathematical principles. Every step the interviewer demonstrated has clear computer science foundations rather than being a stack of industry conventions. This capability is difficult for AI to replace because it requires creative derivation on entirely new, never-before-seen problems, rather than pattern matching on existing solutions.

The Framework Thinking Trap: Services Cannot Replace Data Structures

The candidate's answer represents a very typical "framework thinking" pattern: immediately jumping to microservices, Nacos service registry, Spring Cloud load balancing, while remaining completely blind to the most basic data structure questions.

The interviewer hit the nail on the head: "Your Service cannot replace the most basic fundamentals of data structures."

This exposed several serious cognitive deficiencies:

Not Understanding the Relationship Between Memory and Databases

The interviewer emphasized that computers cannot constantly read from databases during runtime because memory is "a million times" faster than databases. This claim is not an exaggeration — looking at the storage hierarchy: CPU register access takes about 0.3 nanoseconds, L1 cache about 1 nanosecond, memory (DRAM) about 100 nanoseconds, SSD random reads about 100 microseconds, and mechanical hard drives about 10 milliseconds. This means memory access is approximately 1,000 times faster than SSDs and about 100,000 times faster than mechanical hard drives. Database disk I/O is precisely where performance bottlenecks lie — this is the fundamental reason why in-memory databases like Redis and Memcached exist. The Von Neumann architecture dictates that computation must occur in memory; understanding this is the starting point for all performance optimization. The correct approach is to keep data in memory as much as possible and only write to the database when persistence is needed. The candidate's mental model was: throw data directly into the database, query when needed — completely ignoring performance considerations.

Not Understanding the Essence of Databases

The interviewer further explained that a database is essentially a mechanism for persisting in-memory data to disk while providing efficient read/write queries. Good databases have internal cache mechanisms that load disk data into memory through specific algorithms. When we interact with databases, "most of the time we're actually interacting with the cache."

Modern databases (such as MySQL InnoDB, PostgreSQL) all implement Buffer Pool mechanisms internally. The core idea is to cache frequently accessed disk data pages in memory, managing cache replacement strategies through algorithms like LRU (Least Recently Used). MySQL's innodb_buffer_pool_size parameter directly determines how much data can reside in memory. This means when you execute a SQL query, the database engine first checks the Buffer Pool — if it hits, it returns directly; only on a miss does it trigger disk I/O. Understanding this mechanism explains why "hot data"