Code Is the Byproduct

A counterexample to the Jacobian Conjecture was discovered by an LLM, and mathematician Terence Tao used ChatGPT to explore its implications, showcasing how domain experts can engage with AI. Tao's terse, precise prompts yielded narrow, useful responses, contrasting with typical broad queries that produce superficial output. The interaction highlights that LLMs extract depth from prompt specificity, and users should keep requests narrow and cumulative to build understanding.

Code is the Byproduct Recently, the Jacobian Conjecture was disproven https://xcancel.com/ alpoge /status/2079028340955197566?ref=yagmin.com by a counterexample discovered by an LLM. Shortly thereafter, a ChatGPT session from mathematician Terence Tao https://chatgpt.com/share/6a5fdc7a-d6f8-83e8-bbea-8deb42cfed56?ref=yagmin.com made the rounds online. In his chat, Tao uses ChatGPT to help him wrap his head around the implications of the result. If you use LLMs in your day-to-day, it is worth taking a look at his chat, even if or especially if you have no interest in higher level mathematics. The "Understanding Bubble" Most of us interact with LLMs within our own domain bubble. We spot inaccuracies where we have deep experience and validate their output when necessary. On the other hand, we get burned around the edges of our understanding when we know enough to understand the answer, but not enough to confidently refute an LLM when it is wrong. Reading Tao's chat is something else entirely. We rarely get to see a world-class expert interact with an LLM in a domain obscure to most humans. Terence Tao immediately begins communicating with ChatGPT about high level concepts and the LLM responds in kind. If this was chat was posted 5 years ago, we would assume it is a chat between two eminent mathematicians, not a human and a stochastic parrot. It is remarkable that the jacobian is constant, that is an exceptional amount of cancellation. Does this polynomial map have any symmetry or other structure that makes this cancelation less miraculous? Because the math itself is beyond most readers, what stands out is the shape of the interaction. Tao starts his inquiry by noting a single, precise detail that intrigues him. He then drills into the responses, expanding or narrowing his focus based on his own train of thought. This is an expert engaging with an LLM on his own terms. Narrow Focus, Great Depth What happens when a normal user tries to understand the Jacobian Conjecture counterexample by chatting with an LLM? Our questions are broad, our terms are vague and and the LLM mirrors our surface-level phrasing and understanding. In other words, LLM have been talking down to us. We know a single word can reframe what a prompt produces, which has been used as a sign of "LLM randomness". But on a deeper level, recognize that an LLM extracts every nanogram of understanding from a prompt that it can. For example, as a programmer if I say "make this code clean" the LLM will do one thing, but saying "revise according to DRY principles" gives the LLM a much clearer domain of understanding from which to make changes. Your words do more than convey a request. They anchor the depth of an LLM's data retrieval before it even begins to assemble a response. Short Prompts, Specific Details Note what Tao is not doing. He is not building a rich contextual background for the LLM to unpack. He does not list his credentials or say, "you are a mathematical genius, make no mistakes." Instead, he is terse and precise. He asks narrow questions and gets narrow responses. He does not say "Generate a 20 page report that analyzes and describes this finding." That produces a wall of text that looks impressive but conveys little. Keep your requests narrow and specific. Let the output compound through repeated inquiries. Engage with the goal of improving your personal understanding. The Goal is Understanding Many users treat LLMs as asset factories write code, generate images, or draft emails. Because we focus on the final asset, we skip the process of building deep comprehension. Much of the time, a "roughly correct" output is good enough for our needs. But for a request that needs specificity, establishing a shared understanding through the LLM is a necessary waypoint. How do you construct shared understanding? By narrowing the LLM's focus through domain-specific wording and keeping requests specific and cumulative. This is how ChatGPT is able to respond to Tao's mathematical concerns without needing heaps of extraneous detail. Tao pins ChatGPT to a "deep mathematics" headspace through terminology and the specificity of his question. If you don't understand something, set the stage for the LLM and it will capably fill in the missing 20%. Curiosity Beats Capability Curiosity is the new superpower, not raw capability. LLMs are capable workers, but they need precision to return accurate results. Without domain understanding, we fall back to broad requests and fuzzy answers. LLMs mirror our understanding. Product or Byproduct? As a software engineer, I have shifted my focus from asking for code to asking for clarity . Code is written only after understanding is constructed. Here are some ways I use LLMs in my day to day: - When planning a feature: - Can this feature reuse any existing code? Is there an existing pattern the design of this feature should follow? Describe the architecture of this feature. Where are the bottlenecks? Is this an extensible approach if I want to add Feature B down the road? Is there a way to implement this without affecting this other part of the codebase? - When writing/generating code: - Does this consider edge cases along these lines? Are there any performance concerns? Are there security issues? How are permissions managed? Is there a way to simplify this approach? Can this be moved to a shared function? Are there any downstream implications of this change? Ignore this concern for now and ensure this other part is handled first. How can this be revised to minimally solve the request? - While reading code/doing code review: - What is this function doing? How many callers does this function have? Does this consider the following edge case? Describe/make a diagram for the architecture of this feature. What is the user flow on this page? How are errors propagated? Are there any gaps here? Is there documentation, inline comments or tests around this, and do they match the functional logic? - When writing docs, PR descriptions, summaries, etc.: - What are the product implications of these changes for users? How does this affect downstream usage of this function? Update the architecture diagram to match these changes. Which engineers work on this code and should need to be informed about these changes? To me, this is the most valuable output of an LLM. My understanding can improve in broad strokes, at different levels of abstraction, along multiple paths of concern from infrastructure to user experience. Because of LLMs, I can know more about our product, understand recent changes, discover broad problems or make cross-cutting improvements. I can learn about architectural weaknesses or latent bugs. I can improve documentation, help other engineers on the team and spread understanding across the company. At the end of the day, I am paid to produce code, but code remains the byproduct of understanding.