MCP demo

Author: 1cg

www/content/essays/ai-and-compilers.md

@@ -0,0 +1,87 @@
++++
+title = "AI & Compilers"
+description = """\
+  In this essay, Carson Gross discusses whether or not current AI tools are similar to early compilers"""
+date = 2026-03-18
+updated = 2026-03-18
+authors = ["Carson Gross"]
+[taxonomies]
+tag = ["posts"]
++++
+
+A common refrain that we hear today is that the move to AI-based tools for coding is like the move from assembly to
+high level programming languages [using compilers](https://x.com/Steve_Yegge/status/1966230719212220457).  In 
+["Yes, and..."](@/essays/yes-and.md) I mentioned that I don't agree with that simile and in this essay, after a conversation
+with a good friend on the topic, I want to expand on that idea.
+
+## LLMs Are Not Deterministic
+
+In ["Yes, and..."](@/essays/yes-and.md) I make the point that LLMs are stochastic systems and compilers are not.  This alone should make any
+direct comparison between the two technologies suspect, but it bears repeating: given the same input, compilers should
+produce the same output in a deterministic manner, whereas LLMs are designed explicitly to (statistically speaking) 
+*not* give the same output.
+
+## Prompts Are Not Source Code
+
+Another major difference between the move to high level languages and AI tools today builds on the first observation:
+prompts are not source code.
+
+Prompts are not typically saved alongside the resulting actual code.  Sometimes design documents are stored alongside
+the actual code and are fed into LLMs to continue working on a given area of code, but the entire series of prompts that
+lead to the current state of the codebase is typically not captured.  
+
+Even if the entire series _was_ captured, because of point 1, there isn't any mechanism for deterministically understanding
+why the code is in the state that it currently is in.
+
+Again, this contrasts with the way that compilers work: you have the entire high-level language source for a project, you 
+compile it into an executable (or bytecode or whatever.)
+
+Now, there may be decisions in the high-level language that are not obvious given the current state of the high-level code
+but that's the point: the high-level code is _there_, in your codebase, in a way that prompts are not.
+
+## You Can't Debug A Prompt
+
+High-level languages have a wonderful tool associated with them called [a debugger](https://en.wikipedia.org/wiki/Debugger),
+which lets you step through code in a high-level language and "watch" what happens.
+
+This is possible because of the deterministic relationship between high-level code and the actual operations occurring
+in the underlying machine (or virtual machine) which allows a mapping between the two.
+
+Such a mapping cannot exist between prompts and running code.
+
+In fact, "debugging a prompt", if it makes any sense at all, probably sounds like a code-time activity rather than 
+either a compile time or runtime activity to most people reading this, which is telling.
+
+## "I haven't written any code in months!"
+
+I see people saying this, but they are engaged in a sleight of hand, intentionally or not.  They _have_ written code (often
+lots of code!) in the past few months, they just haven't _typed_ that code.
+
+The actual artifacts on disk, the "source of truth" is _still_ the code that they generated (and perhaps 
+[do not understand](https://www.youtube.com/watch?v=GFiWEjCedzY).)
+
+If something is wrong, and you want to understand what it is, you _have_ to read the code.  The prompts made the code
+but the prompts are gone, leaving only the code and perhaps some tests for you to work from.
+
+Someone might reply that they will just have an LLM read the code, which is a plausible response but again differentiates
+AI from high-level programming languages.
+
+## Code Complexity Still Matters
+
+
+
+## This is not an Anti-AI Essay
+
+Again, as I said in "Yes, and...", I am not anti-AI, and I am figuring out how to effectively use AI in my own coding
+workflows.  I tend to use it in an exploratory manner and as a coding assistant, rather than as a code-generator.  My
+experience with code generated by AI is mixed: sometimes it does a decent job, often it doesn't.  But that is my own
+experience and involves some subjectivity around what is decent code and what isn't.
+
+My point is not that AI is bad, but rather that simplistic mappings of AI-based coding onto the shift to high-level languages
+is, at the current time, wrong-headed and misleading.  Maybe we will develop AI-native languages that allow us to specify
+systems deterministically using much higher level language[^1].
+
+But until we start seeing things like that we should be skeptical of people who claim 
+
+
+[^1] - Personally, I think that's called lisp and, despite that, I still choose to code in java.