Why did system design get more valuable, not less?

Amit Shekhar from Outcome SchoolNov 2, 2026

Why did system design get more valuable, not less?

Why a wrong design costs more when code is cheap

Nov 2

System design got more valuable, not less, because a coding agent made writing code cheap but left the decisions behind it just as hard, so a wrong decision now gets built faster and spreads further.

In this blog, we will learn about why system design got more valuable, not less. We will also see what got cheap and what did not, what system design decides that a single piece of code cannot, one photo sharing app growing from one server to several regions, why a wrong design costs more when code is cheap, and how we work with the agent on design.

We will cover the following:

What got cheap and what did not
What system design decides
One photo sharing app, from one server to several regions
Why a wrong design costs more when code is cheap
How we work with the agent on design

I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

I teach AI and Machine Learning at Outcome School.

Let’s get started.

What got cheap and what did not

With a coding agent like Claude Code, writing an endpoint or a migration takes minutes instead of hours.

So, the cost of producing code dropped, but the cost of a decision did not. Deciding where the data lives and what happens when one part is down still needs the same thinking.

When writing code gets cheap, the decisions become most of the effort. The biggest of those decisions are system design, and that is where our judgment now goes.

What system design decides

System design is the set of decisions about how the parts of a system fit together: where data is stored, how requests flow, and what happens when something fails.

These decisions span many files. The agent writes a correct upload handler when we tell it where the file goes. It does not know that the app is about to serve users on three continents or that the team plans to add video. We know those facts. The agent sees only the code and our prompt.

Hence, the agent answers “how do we write this?” well. We still answer “what must we build, and where must it live?”

One photo sharing app, from one server to several regions

Let’s say we run a photo sharing app on one server. A user uploads a photo, the server writes the file to its own disk, saves a row in the database, and serves the photo back from the same disk. This works for the first few thousand users.

Now, the app grows. Users join from Europe and Asia, while the server sits in one region. Three decisions now matter more than any single piece of code.

Storage: Photos cannot stay on the server’s disk, because a second server cannot read them. We move photos to object storage and keep only the metadata in the database.
Upload flow: If every upload passes through our server, the server spends its CPU and bandwidth copying bytes. We give the client a short-lived signed URL, the client uploads straight to storage, and then tells our server that the upload is done.
Serving images: A user in Asia waits longer for every image that comes from a server in another region. We put a CDN in front of storage, store resized versions of each photo, and serve the right size from a location near the user.

None of these decisions needs hard code to implement. The signed URL endpoint and the resize job are short, and the agent writes them quickly once we decide they must exist.

If we only ask the agent to “make uploads faster”, it does what the request says. It speeds up the handler on our one server, and the diff passes every test. But every upload still goes through one server in one region, and that is the real problem.

Why a wrong design costs more when code is cheap

When we wrote an upload flow and its tests by hand, it took days, and that slow pace gave the team time to ask, “Why are the files on the server’s disk?”

Now, the agent writes code for a wrong design just as fast as for a right one. In one afternoon, we can have an upload pipeline, a thumbnail job, and tests, all assuming that photos live on the server’s disk. Each diff passes a line-by-line review, because it is correct for the design it was given.

The cost shows up when the app needs a second region. The wrong decision is now spread across many files, many tests, and every photo already stored. Moving those photos and rewriting every path that reads them is far more work than writing the original code.

So, cheap code does not make design mistakes cheap. It makes them bigger, because more code is built on them before anyone checks the design.

How we work with the agent on design

Directing and verifying the agent on design means the following:

Decide first: Before the agent writes code for the new regions, we write down where photos are stored, how uploads reach storage, and how images get served. Every task we give the agent then follows those decisions.
Ask the agent to explore, not to decide: We ask it to list what changes if photos move from the server’s disk to object storage, or to sketch the signed URL flow. We read the answer and make the choice.
Review the diff against the design: The first question is not “is this code correct?” It is “does this code follow the design?” A handler that writes a photo to the server’s disk is a correct function and a wrong design.
Verify the system, not only the function: A passing unit test proves that the resize function works. It does not prove that a user in Asia sees photos load quickly. We open the app from a client in another region and check where each image is served from.

The time we used to spend typing code now goes into these decisions. We decide where the photos live, how they travel, and how they reach a user far away, so that the agent’s fast code is built on the right design.