My first taste of server-side code

The worst part of maintaining my first website wasn't the design. It was the navigation bar. Every time I added a page, I had to manually edit the HTML of every other page to add the new link. A five-page site meant five tedious edits. A twenty-page site was an exercise in pure, error-prone repetition. The web, for me, was a collection of static, brittle documents. It felt more like digital typesetting than engineering.

The Prison of the Static File

In those early days, a website was a literal folder of .html files sitting on a server. When a browser requested /about.html, the web server found that specific file and sent its contents, byte for byte, down the wire. It was simple, robust, and completely deterministic. The output was a literal copy of a file on disk. It was also creatively stagnant.

This model treated every user identically. There was no "you," no context, no memory. The server couldn't greet a returning visitor, display the current date, or even process a contact form. It was just a file cabinet. My job was to be the frustrated librarian, manually keeping all the cards in the catalog synchronized. To escape this, I needed a way for the server to compute, not just retrieve.

The CGI Gateway

The answer was the Common Gateway Interface, or CGI. It feels ancient now, but the concept was a revolution. CGI was a simple protocol, later formalized in documents like RFC 3875, that allowed a web server to execute an external program and stream its output back to the browser. Instead of pointing to an .html file, you could point to a script.

When a request came in, the server didn't just send the file's contents. It ran the file. The program's only job was to print text to standard output: first a content-type header, then a blank line, then the HTML. Suddenly, the server wasn't just a file cabinet. It was a computer. A web page was no longer a noun to be retrieved; it was the output of a verb to be executed.

A Humble Counter, a Universe of Problems

My first server-side program was a page view counter written in Perl. The logic was comically simple: open a text file, read a number, increment it, write it back, and print the HTML with the new number. It worked, and it felt like magic. It also immediately introduced every problem that still defines enterprise architecture.

State management was first. The counter.txt file was a primitive database. I had to wrestle with file permissions, learning the hard way about security vulnerabilities. Then came concurrency. If two people visited at the same millisecond, both scripts could read the same number, increment it, and write it back. One of the hits would be lost. I had stumbled into a race condition and had to learn about file locking. Grappling with that simple file lock is the same fundamental problem as managing database transaction isolation levels or distributed locks in a microservices environment. The tools are more sophisticated now, but the challenge is identical.

The Great Separation

My Perl script was a tangled mess. Logic for reading files was interleaved with print statements containing raw HTML. Changing the layout meant editing strings inside a program. Changing the logic risked breaking the HTML. This pain was the first sign of a durable principle, later formalized by thinkers like Robert C. Martin with concepts like the Single Responsibility Principle: the separation of concerns.

My code was doing two things at once—managing data and presenting it. The solution that won out over the years, through countless frameworks, was to split these jobs. A script should get the data, then hand it off to a separate template responsible only for rendering. While other approaches like server-side XSLT transformations had their moment, they often failed because they created new kinds of complexity. The clear boundary between logic and presentation proved to be the pattern that survived. It's the ancestor of every modern API-driven frontend.

The Deterministic Bedrock Meets the Agentic Wave

That primitive CGI script contained the DNA of modern cloud architecture. The request/response cycle, where a client triggers a computation that returns a result, is the foundation of everything. A serverless function on AWS Lambda is, in essence, a highly evolved, massively scalable CGI script. The execution context is more sophisticated, but the pattern is the same.

This is the architecture of deterministic automation, perfected over 25 years. It is predictable, testable, and reliable. But this bedrock now supports a new kind of workload. What happens when the computation we trigger is not a simple script, but a non-deterministic LLM agent? What happens when the "result" is not a predictable HTML document, but a series of actions taken against other systems? This is the central architectural tension of our time. The reliable, deterministic patterns I learned from that first counter are now the foundation we must use to manage and contain the powerful, probabilistic, and often unpredictable work of AI agents.

Concrete Takeaways

Computation is the engine. The ability to run code during a request is what turns a document repository into an application platform. This is true for a CGI script rendering HTML or an agentic system deciding its next action.

State is always the hard part. As soon as a system must remember something, you invite problems of persistence, concurrency, and security. This hasn't changed from a text-file counter to a vector database.

Separate logic from presentation. Tangling business rules with display code creates a brittle system. This principle now extends to separating deterministic data processing from non-deterministic agentic reasoning.

Deterministic systems are our foundation. The durable, request/response pattern is our primary tool for building reliable software. The key architectural challenge today is how to compose these systems with agentic counterparts, using the former to ground and control the latter.