I finished this competition believing something that most people don't yet realize: the expert code golfer already lives inside your LLM. You just need to learn how to extract it.
\nFor three months, I competed in ARC Code Golf using a mix of Claude, GPT-5, and Gemini. Rank 25 wasn't achieved by asking these models to write golf solutions. It was achieved by teaching them to think like golfers—to name patterns, remember them, improve iteratively, and discover new tricks I'd never seen before.
\nThe final breakthrough: in the last week of competition, my agent started finding solutions shorter than the leaderboard best on multiple problems. That wasn't random. It was emergence.
\nBefore the code golf contest launched, I spent months brainstorming with LLMs on a different problem: building DSLs to generate ARC-like puzzles. This was inspired by Michael Hodel's work on arc-dsl.
\n\nCREATE GRID x10\nDRAW ROWS ,\nDRAW COLS ,\n\n\nFILL TOP-LEFT REGION FILL REGION GREEN\nFILL CENTER REGION RED\nThe first three lines setup a generator for a puzzle similar to 55. See image.\nIn other words some ARC puzzles do a few steps generate that as input image and then do few more steps.\nOther puzzles first generate output and then add noise and transformations to generate input.\nThis difference would help later.
\nI used Gemini Canvas to build several interactive HTML js utilities to experiment with these mini-DSLs - primarily to generate hundreds of examples of a puzzle and then think about what would a solver do to solve all of them. I did this probably for about 10 or so puzzles from ARC-AGI 2 evaluation set. Only when you build something you begin to understand.
\nThis taught me something crucial—LLMs are excellent at explaining logic, not just retrieving knowledge.
\nWhen code golf was announced, I realized it split the ARC-AGI problem into two parts:
\nThis realization was liberating. I switched focus entirely. Michael Moffitt's ARC-GEN opened up whole new world of how a framework can be built to create such puzzles.
\nFor the first few months, I used LLMs as code translators: feed them a golfed solution, ask what it does; feed them two solutions side-by-side, ask what tricks were used to shrink one. Each chat revealed algorithmic patterns and Python idioms I'd missed. I manually collected good solutions into a baseline notebook, but more importantly, I was building intuition alongside the LLM.
\nI discovered Claude Code and got ambitious. I built a multi-stage agentic pipeline:
\nOn paper, perfect. In practice, it collapsed.
\nThe failure was instructive. Errors in the analyzer couldn't be fixed downstream by the solver. I was trying to commoditize understanding into sequential stages when understanding is the hard part. The pipeline had too many handoff points.
\nBut this forced me to think differently. I unified analyzer + solver + tester. More importantly, this is where I discovered the ACT framework:
\nAnchors, Clues, Transforms
\nThe key insight: ARC problems are like solved Sudoku grids corrupted by noise. The author designs a clean output, then adds occlusion and transformation to create the input puzzle. A solver's job isn't to be creative—it's to recognize invariant objects despite noise and apply specific transformations.
\nThis reframing changed how I described tasks to LLMs, and it worked. Suddenly we got solutions for all 400 problems.
\nAround mid-October, I shifted strategy. Instead of rigid pipelines, I created feedback loops.
\nI manually documented ~40 code-golf tricks:
\nThen I gave these to the agent as a checklist and asked it to review each solution:
\nBut here's the key innovation: I asked the agent to write out new tricks it discovered, in the same format.
\nThe agent started naming tricks I'd never considered. Each new trick got added to the checklist. The list grew: 40 → 80 → 140 tricks. And as it grew, the agent's solutions got better.
\nThe final leap came when I asked the agent to output a structured design review after each optimization pass:
\n design review:\nTask: Task (tilt) — trim solver ≥ B ( B baseline).\nInvariants: Rectangular grids; colors active hue cluster; \n color tilts matching hues exist belowright.\nRepresentation: Keep major grid, triangular (...) g[y:] \nwrapped lambda solver _ aliasing enumerate.\nChecklist hits [,,,,,]: Alias builtins; truthy ; \nlambda solver; product gate; bounds checks; generator suffix.\nPlan: Review → Note idioms → Apply checklist → Try unary rewrites → \nMicrotrim → Retest.\nBytes: B → B\nThen, after each optimization, the agent would journal its thought process:
\n\n\nCandidate 7: Checklist pass revisited below/right gate. Realized two predicates collapse into single triangular
\nany(v in r[j+1:] for r in g[-~y:]). Dropped row suffix flatten and sum alias for 19 B shave.
This journaling did something magical: it created a record of reasoning that the agent could learn from. On the next pass, it could reference earlier sessions. Patterns emerged. The agent started discovering algorithmic improvements, not just syntactic ones. (see images for detailed examples)
\nIn the last three days, performance skyrocketed.
\nBefore I could teach an LLM to golf code, I needed to understand why ARC puzzles have a structure worth compressing.
\nHere's the key insight: ARC puzzles are constructed like Sudoku, but generalized.
\nA Sudoku author first constructs a valid solution grid where every row, column, and region contains 1–9 exactly once. Then they erase most values, leaving you to fill the rest. The solution is already there—your job is inverse reconstruction.
\nFrancois Chollet, the ARC author, thinks similarly. He imagines a target grid that is clean, orderly, and follows some hidden rule. Then he corrupts it: scattering objects, erasing values, adding noise pixels, punching holes. The puzzle becomes recognizing the objects despite noise and transformation, then applying the intended transformation.
\nThis clicked for me because of my background. My master's thesis was titled \"Transformation Invariant Object Recognition from Noisy Data Using Artificial Neural Networks.\" My advisor, Prof. B. Yegnanarayana at IIT Madras, framed the problem directly from Claude Shannon's noisy channel model—the foundational formulation for cryptography and communication theory. The core question: given corrupted information, how do you recover the original intent?
\nARC is this problem, posed as visual puzzles.
\nUnderstanding this reframed how I described tasks to LLMs. The ACT framework (Anchors, Clues, Transforms) wasn't an invention—it was recognizing the problem structure. I wasn't asking the model to be creative. I was asking it to reverse-engineer the author's compression: what was the clean grid, and what noise was applied?
\nThis understanding was foundational. It made every prompt more precise, every agent more effective.
\nHere's what most people misunderstand about LLMs:
\nLLMs are trained to be verbose because that's what RLHF rewards in chat. But verbosity isn't their ceiling—it's an artifact of training. Underneath, they grasp algorithm internals, language semantics, and pattern compression at a level humans rarely achieve consciously. Let me briefly mention here that when compression is done on discrete symbols it leads to codebooks. When codebooks are contextual, they are powerful. When compression happens on embedding space with overlayed vector superimpositions, it is comprehension.
\nLanguage itself is a compression mechanism. When you say \"rotate until it touches the edge\" instead of \"move right 4 cells, now move right 2 cells, now move right 1 cell,\" you've already compressed the logic. LLMs excel at this kind of abstraction.
\nThe trick: give them constraints, examples, and feedback loops.
\nWhen I fed the agent:
\n…it stopped being a code-writing tool and became a collaborative partner in a compression game.
\nWhat surprised me most wasn't the final result—it was the trajectory. Each of three components, stacked together, multiplied capabilities by roughly 10x:
\nLLM Intuition (10x): When I stopped asking the model to write code and started asking it to understand tasks using the ACT framework, solutions improved dramatically. The model had algorithmic comprehension; I just needed to unlock the right abstraction layer.
Reasoning Traces (10x): When I made the agent write out its reasoning (design reviews, journals, checklist hits), its next iteration was 10x more systematic. Reasoning traces externalize thought, making patterns discoverable and refinable.
Agentic Experimentation (10x): When I closed the loop—letting the agent discover new tricks, add them to the checklist, and apply them on the next pass—we entered a feedback cycle that felt exponential. The agent wasn't just optimizing; it was learning to optimize.
Stacked: 10x × 10x × 10x ≈ 1000x improvement in solution quality over three months, though I can't measure it precisely. What I can measure: 40 tricks → 140 tricks, baseline solutions → leaderboard-beating solutions, my manual golfing → consistent agent outperformance.
\nThe insight: these three aren't optional features. They're multiplicative. Without reasoning traces, intuition stays buried. Without agentic loops, traces are static documentation. Without intuition, agents write verbose code that no loop can fix.
\nAnother thing to notice is that we got LLM intuition accessible publicly since 2023. Reasoning accessible since October 2024 and Agentic Coders since March-April 2025. We are just getting started!
\nLate in the competition, I had a realization that connected centuries of ideas.
\nPanini was a Sanskrit grammarian who lived around 400 BCE. Rather than writing descriptive grammar with examples and rules, he wrote generative grammar—production rules so dense and powerful that running them could generate all possible Sanskrit sentences. He compressed the entire language into ~4,000 rules. Panini recognized verbs as operators and nouns as arguments. His insight was that language can be defined by a finite, ordered set of generative rules with scoping, precedence, and compact metasymbols - the very heart of compiler front-ends - was realized with extraordinary rigor in the Aṣṭādhyāyī two millennia before BNF. Modern formalisms (Post→Chomsky→BNF) gave us the tools compilers use; Pāṇini’s system shows an ancient, remarkably close analogue to that way of thinking.
\nWhen I read comments from top competitors (JoKing, Jacekwl) about reusing a handful of code patterns across many problems, something clicked. I spent a night hand-solving the shortest ~40 solutions from the leaderboard, looking for the underlying form.
\nWhat I found was a generative grammar for ARC solvers:
\n g: [\n [transform(cell_value) \n cell transformed(row) \n condition] \n row expanded_transformed(rowset) \n condition\n]\nThis single template—with variations in transform(), transformed(), expanded_transformed(), and condition—explained most of the compact solutions I saw. It wasn't random brevity. It was a generative grammar for ARC problem-solving, discovered by centuries of competitive programming.
When I showed this pattern to the agent and asked it to recognize this grammar in other solutions, something changed. The agent stopped writing ad-hoc code and started composing from a grammar. It was no longer optimizing individual solutions; it was learning to think in the language of compression itself. It was using terminology of grid, rowset, rowset expansion, filtering, row extension, cell transformation etc, because I had seeded that in a few fewshot examples. With a grammar to guide, solution search becomes pointed tweaking of parts of the solution. Both the frame of slots and expression lists for each slot type are fixed making the solving (not just the golfing) almost algebraic rearrangement of problem specification.
\nThis is what Panini did for Sanskrit. This is what Shannon did for information. This is what the best code golfers had discovered empirically: reduce your domain to its production rules, and the compression becomes automatic.
\nIn the last days of contest, my obsession with sentential forms went away, and just a list of rules can serve as a grammar system!
\nThe final submission at Rank 25 used:
\nThe agent didn't \"know\" these solutions existed. It learned to think like a golfer, which meant:
\nHere's something that humbles me: the agent only truly came online a few days before the competition ended. It never attempted ~100 problems.
\nPart of me looks at Rank 25 and thinks: if I'd had one more week, top 10 was reachable. The trajectory was exponential. The tricks were accumulating. The agent was learning faster than I could keep up.
\nBut then I remember why that doesn't matter.
\nThe humans in the top ranks—JoKing, Jacekwl, Garry Moss, Ken, and dozens of others—spent years poring over similar problems character by character, like I myself had done in my long career spawning Fortran to Python via C, C++, VB, Java, Lisp, SAS. They've distilled decades of collective programming and golfing experience and they have generously shared a lot. Their solutions aren't just code; they're crystallized insight.
\nIt is beautiful justice that humans should be the winners.
\nEverytime an agent goes up a notch in a leaderboard, it discourages a bunch of humans. This is harmful to human society as a whole, since it discourages humans from thinking hard and working hard. This is a serious issue we need to think about and address as AI is adopted widely.
\nWhat I'm proud of is something different: I've created a thought calculator that can give them free time. Soon, I hope to make this reproducible from scratch and open-source it. The goal isn't to replace human expertise—it's to amplify it, to let the best minds in the world focus on the breakthroughs that still require human intuition.
\nAlso each one of the solutions is explainable. By implementing a kind of micro descent, the solutions are a series of short rewrites (sometimes rethinking of representation) so one can see the path of the rules used. Hopefully this opens ideas on how to build agents that act in a limited action space, while still being flexible and able to add to it.
\nI think the solution created will be useful for compiler optimization, new forms of code such as GPU kernel and in general domain-specific skill development.
\nThe agent learned in days what took the best golfers years. But that's not a reason to rank higher—it's a reason to build better tools for the next person who wants to push further.
\nYou don't need a smarter LLM to solve harder problems. You need better abstraction of your reasoning, fed back as constraints and examples.
\nLanguage is logic. By being abstract and vague, it brings expressivity and generality. Teach an LLM your abstractions—not just your goals—and watch it innovate at a speed you can barely track.
\nThe expert golfer was always inside the chatbot. I just had to prompt to use that dialect. And perhaps more importantly: at least in this case, I saw where LLM's intuition had its limit and my intuition can flourish.
\nP.S. I'll be releasing the tricks checklist, ACT framework, and design review templates as a notebook as I find more time. I hope to at least walk through some of the agentic setup on some Youtube tutorial. There is so much more to learn from the masters, now that all have shared their solutions! This will give totally new views into what sort of abstractions are totally missing in the agent so far.
\n** Thanks ** I cannot thank enough Google for Gemini, Anthropic for Claude and above all the OpenAI team for releasing GPT5 codex, which proved to be an uncanny assistant at all levels from helping me organizing code, testing every idea, managing a git repo, troubleshooting potential agonizing situations of score dropping, in a few minutes. Codex on the Web was a game changer for the last leg.
", "comments": [ { "id": 3310540, "author_name": "Aaditya Khanal", "author_url": "", "post_date": "2025-11-03T06:20:29.997000", "content": "This is absolutely phenomenal work! Your journey from DSLs to the ACT framework to discovering the generative grammar is inspiring. The 10x³ multiplier insight is brilliant. Thank you for sharing this masterpiece!
", "votes": 0, "replies": [ { "id": 3311095, "author_name": "Ravi Annaswamy", "author_url": "", "post_date": "2025-11-04T08:44:28.100000", "content": "Thank you Aaditya! @aadityaiscoding
", "votes": 1, "replies": [] } ] }, { "id": 3309456, "author_name": "Khushi Yadav", "author_url": "", "post_date": "2025-10-31T18:32:06.013000", "content": "Amazing work, truly inspiring!
", "votes": 0, "replies": [] }, { "id": 3309417, "author_name": "Cristiano Calcagno", "author_url": "", "post_date": "2025-10-31T16:56:59.600000", "content": "The pattern describing the general shape of compressed solutions is great for humans too, to have a feeling for what it is that expert solvers rely on.
", "votes": 0, "replies": [ { "id": 3309423, "author_name": "Ravi Annaswamy", "author_url": "", "post_date": "2025-10-31T17:09:31.710000", "content": "Yes! With a grammar to guide, solution search becomes pointed tweaking of parts of the solution. Both the frame of slots and expression lists for each slot type are fixed making the solving (not just the golfing) almost algebraic rearrangement of problem spec!
", "votes": 0, "replies": [] } ] }, { "id": 3309383, "author_name": "Chew Kok Wah", "author_url": "", "post_date": "2025-10-31T15:28:46.163000", "content": "During the Phase 3 Acceleration & breakthrough stage, which LLM is your primary workhorse? In other words, which LLM do you think contributed to the majority of your breakthrough ?
", "votes": 0, "replies": [ { "id": 3309400, "author_name": "Ravi Annaswamy", "author_url": "", "post_date": "2025-10-31T16:21:09.577000", "content": "i want to make sure my answer is not seen as a comparative judgment. \ngpt5-thinking and codex-gpt5 is what I used but I am sure that gemini/claude could be used equally well with effort.
", "votes": 1, "replies": [] } ] }, { "id": 3309366, "author_name": "parthenos", "author_url": "", "post_date": "2025-10-31T15:00:47.420000", "content": "thats brilliant!! congrats on the success!!
\nis it possible to share the chats with those llms??
", "votes": 0, "replies": [ { "id": 3309378, "author_name": "Ravi Annaswamy", "author_url": "", "post_date": "2025-10-31T15:13:49.470000", "content": "Thanks will do after some time, maybe several days, to make sure they do not leak information that I do not intend. Busy getting back to normal life and also preparing a followup work.
", "votes": 1, "replies": [] } ] }, { "id": 3309349, "author_name": "Ken Krige", "author_url": "", "post_date": "2025-10-31T14:18:11.320000", "content": "This is awesome work. I will be reading it in detail.
", "votes": 0, "replies": [ { "id": 3309356, "author_name": "Ravi Annaswamy", "author_url": "", "post_date": "2025-10-31T14:34:40.633000", "content": "Thank you @kenkrige
", "votes": 0, "replies": [] } ] }, { "id": 3309333, "author_name": "Chep0k", "author_url": "", "post_date": "2025-10-31T13:22:19.647000", "content": "Terrific! Amazing work, truly inspiring! Thank you Ravi for sharing the report!
\nMy sincere compliments to the result you've achieved!
", "votes": 0, "replies": [ { "id": 3309357, "author_name": "Ravi Annaswamy", "author_url": "", "post_date": "2025-10-31T14:35:18.773000", "content": "Thank you so much @chep0k
", "votes": 0, "replies": [] } ] } ], "comment_count": 13, "messages": [ { "id": 3309327, "postDate": "2025-10-31T12:58:21.323Z", "content": "I finished this competition believing something that most people don't yet realize: the expert code golfer already lives inside your LLM. You just need to learn how to extract it.
\nFor three months, I competed in ARC Code Golf using a mix of Claude, GPT-5, and Gemini. Rank 25 wasn't achieved by asking these models to write golf solutions. It was achieved by teaching them to think like golfers—to name patterns, remember them, improve iteratively, and discover new tricks I'd never seen before.
\nThe final breakthrough: in the last week of competition, my agent started finding solutions shorter than the leaderboard best on multiple problems. That wasn't random. It was emergence.
\nBefore the code golf contest launched, I spent months brainstorming with LLMs on a different problem: building DSLs to generate ARC-like puzzles. This was inspired by Michael Hodel's work on arc-dsl.
\n\nCREATE GRID x10\nDRAW ROWS ,\nDRAW COLS ,\n\n\nFILL TOP-LEFT REGION FILL REGION GREEN\nFILL CENTER REGION RED\nThe first three lines setup a generator for a puzzle similar to 55. See image.\nIn other words some ARC puzzles do a few steps generate that as input image and then do few more steps.\nOther puzzles first generate output and then add noise and transformations to generate input.\nThis difference would help later.
\nI used Gemini Canvas to build several interactive HTML js utilities to experiment with these mini-DSLs - primarily to generate hundreds of examples of a puzzle and then think about what would a solver do to solve all of them. I did this probably for about 10 or so puzzles from ARC-AGI 2 evaluation set. Only when you build something you begin to understand.
\nThis taught me something crucial—LLMs are excellent at explaining logic, not just retrieving knowledge.
\nWhen code golf was announced, I realized it split the ARC-AGI problem into two parts:
\nThis realization was liberating. I switched focus entirely. Michael Moffitt's ARC-GEN opened up whole new world of how a framework can be built to create such puzzles.
\nFor the first few months, I used LLMs as code translators: feed them a golfed solution, ask what it does; feed them two solutions side-by-side, ask what tricks were used to shrink one. Each chat revealed algorithmic patterns and Python idioms I'd missed. I manually collected good solutions into a baseline notebook, but more importantly, I was building intuition alongside the LLM.
\nI discovered Claude Code and got ambitious. I built a multi-stage agentic pipeline:
\nOn paper, perfect. In practice, it collapsed.
\nThe failure was instructive. Errors in the analyzer couldn't be fixed downstream by the solver. I was trying to commoditize understanding into sequential stages when understanding is the hard part. The pipeline had too many handoff points.
\nBut this forced me to think differently. I unified analyzer + solver + tester. More importantly, this is where I discovered the ACT framework:
\nAnchors, Clues, Transforms
\nThe key insight: ARC problems are like solved Sudoku grids corrupted by noise. The author designs a clean output, then adds occlusion and transformation to create the input puzzle. A solver's job isn't to be creative—it's to recognize invariant objects despite noise and apply specific transformations.
\nThis reframing changed how I described tasks to LLMs, and it worked. Suddenly we got solutions for all 400 problems.
\nAround mid-October, I shifted strategy. Instead of rigid pipelines, I created feedback loops.
\nI manually documented ~40 code-golf tricks:
\nThen I gave these to the agent as a checklist and asked it to review each solution:
\nBut here's the key innovation: I asked the agent to write out new tricks it discovered, in the same format.
\nThe agent started naming tricks I'd never considered. Each new trick got added to the checklist. The list grew: 40 → 80 → 140 tricks. And as it grew, the agent's solutions got better.
\nThe final leap came when I asked the agent to output a structured design review after each optimization pass:
\n design review:\nTask: Task (tilt) — trim solver ≥ B ( B baseline).\nInvariants: Rectangular grids; colors active hue cluster; \n color tilts matching hues exist belowright.\nRepresentation: Keep major grid, triangular (...) g[y:] \nwrapped lambda solver _ aliasing enumerate.\nChecklist hits [,,,,,]: Alias builtins; truthy ; \nlambda solver; product gate; bounds checks; generator suffix.\nPlan: Review → Note idioms → Apply checklist → Try unary rewrites → \nMicrotrim → Retest.\nBytes: B → B\nThen, after each optimization, the agent would journal its thought process:
\n\n\nCandidate 7: Checklist pass revisited below/right gate. Realized two predicates collapse into single triangular
\nany(v in r[j+1:] for r in g[-~y:]). Dropped row suffix flatten and sum alias for 19 B shave.
This journaling did something magical: it created a record of reasoning that the agent could learn from. On the next pass, it could reference earlier sessions. Patterns emerged. The agent started discovering algorithmic improvements, not just syntactic ones. (see images for detailed examples)
\nIn the last three days, performance skyrocketed.
\nBefore I could teach an LLM to golf code, I needed to understand why ARC puzzles have a structure worth compressing.
\nHere's the key insight: ARC puzzles are constructed like Sudoku, but generalized.
\nA Sudoku author first constructs a valid solution grid where every row, column, and region contains 1–9 exactly once. Then they erase most values, leaving you to fill the rest. The solution is already there—your job is inverse reconstruction.
\nFrancois Chollet, the ARC author, thinks similarly. He imagines a target grid that is clean, orderly, and follows some hidden rule. Then he corrupts it: scattering objects, erasing values, adding noise pixels, punching holes. The puzzle becomes recognizing the objects despite noise and transformation, then applying the intended transformation.
\nThis clicked for me because of my background. My master's thesis was titled \"Transformation Invariant Object Recognition from Noisy Data Using Artificial Neural Networks.\" My advisor, Prof. B. Yegnanarayana at IIT Madras, framed the problem directly from Claude Shannon's noisy channel model—the foundational formulation for cryptography and communication theory. The core question: given corrupted information, how do you recover the original intent?
\nARC is this problem, posed as visual puzzles.
\nUnderstanding this reframed how I described tasks to LLMs. The ACT framework (Anchors, Clues, Transforms) wasn't an invention—it was recognizing the problem structure. I wasn't asking the model to be creative. I was asking it to reverse-engineer the author's compression: what was the clean grid, and what noise was applied?
\nThis understanding was foundational. It made every prompt more precise, every agent more effective.
\nHere's what most people misunderstand about LLMs:
\nLLMs are trained to be verbose because that's what RLHF rewards in chat. But verbosity isn't their ceiling—it's an artifact of training. Underneath, they grasp algorithm internals, language semantics, and pattern compression at a level humans rarely achieve consciously. Let me briefly mention here that when compression is done on discrete symbols it leads to codebooks. When codebooks are contextual, they are powerful. When compression happens on embedding space with overlayed vector superimpositions, it is comprehension.
\nLanguage itself is a compression mechanism. When you say \"rotate until it touches the edge\" instead of \"move right 4 cells, now move right 2 cells, now move right 1 cell,\" you've already compressed the logic. LLMs excel at this kind of abstraction.
\nThe trick: give them constraints, examples, and feedback loops.
\nWhen I fed the agent:
\n…it stopped being a code-writing tool and became a collaborative partner in a compression game.
\nWhat surprised me most wasn't the final result—it was the trajectory. Each of three components, stacked together, multiplied capabilities by roughly 10x:
\nLLM Intuition (10x): When I stopped asking the model to write code and started asking it to understand tasks using the ACT framework, solutions improved dramatically. The model had algorithmic comprehension; I just needed to unlock the right abstraction layer.
Reasoning Traces (10x): When I made the agent write out its reasoning (design reviews, journals, checklist hits), its next iteration was 10x more systematic. Reasoning traces externalize thought, making patterns discoverable and refinable.
Agentic Experimentation (10x): When I closed the loop—letting the agent discover new tricks, add them to the checklist, and apply them on the next pass—we entered a feedback cycle that felt exponential. The agent wasn't just optimizing; it was learning to optimize.
Stacked: 10x × 10x × 10x ≈ 1000x improvement in solution quality over three months, though I can't measure it precisely. What I can measure: 40 tricks → 140 tricks, baseline solutions → leaderboard-beating solutions, my manual golfing → consistent agent outperformance.
\nThe insight: these three aren't optional features. They're multiplicative. Without reasoning traces, intuition stays buried. Without agentic loops, traces are static documentation. Without intuition, agents write verbose code that no loop can fix.
\nAnother thing to notice is that we got LLM intuition accessible publicly since 2023. Reasoning accessible since October 2024 and Agentic Coders since March-April 2025. We are just getting started!
\nLate in the competition, I had a realization that connected centuries of ideas.
\nPanini was a Sanskrit grammarian who lived around 400 BCE. Rather than writing descriptive grammar with examples and rules, he wrote generative grammar—production rules so dense and powerful that running them could generate all possible Sanskrit sentences. He compressed the entire language into ~4,000 rules. Panini recognized verbs as operators and nouns as arguments. His insight was that language can be defined by a finite, ordered set of generative rules with scoping, precedence, and compact metasymbols - the very heart of compiler front-ends - was realized with extraordinary rigor in the Aṣṭādhyāyī two millennia before BNF. Modern formalisms (Post→Chomsky→BNF) gave us the tools compilers use; Pāṇini’s system shows an ancient, remarkably close analogue to that way of thinking.
\nWhen I read comments from top competitors (JoKing, Jacekwl) about reusing a handful of code patterns across many problems, something clicked. I spent a night hand-solving the shortest ~40 solutions from the leaderboard, looking for the underlying form.
\nWhat I found was a generative grammar for ARC solvers:
\n g: [\n [transform(cell_value) \n cell transformed(row) \n condition] \n row expanded_transformed(rowset) \n condition\n]\nThis single template—with variations in transform(), transformed(), expanded_transformed(), and condition—explained most of the compact solutions I saw. It wasn't random brevity. It was a generative grammar for ARC problem-solving, discovered by centuries of competitive programming.
When I showed this pattern to the agent and asked it to recognize this grammar in other solutions, something changed. The agent stopped writing ad-hoc code and started composing from a grammar. It was no longer optimizing individual solutions; it was learning to think in the language of compression itself. It was using terminology of grid, rowset, rowset expansion, filtering, row extension, cell transformation etc, because I had seeded that in a few fewshot examples. With a grammar to guide, solution search becomes pointed tweaking of parts of the solution. Both the frame of slots and expression lists for each slot type are fixed making the solving (not just the golfing) almost algebraic rearrangement of problem specification.
\nThis is what Panini did for Sanskrit. This is what Shannon did for information. This is what the best code golfers had discovered empirically: reduce your domain to its production rules, and the compression becomes automatic.
\nIn the last days of contest, my obsession with sentential forms went away, and just a list of rules can serve as a grammar system!
\nThe final submission at Rank 25 used:
\nThe agent didn't \"know\" these solutions existed. It learned to think like a golfer, which meant:
\nHere's something that humbles me: the agent only truly came online a few days before the competition ended. It never attempted ~100 problems.
\nPart of me looks at Rank 25 and thinks: if I'd had one more week, top 10 was reachable. The trajectory was exponential. The tricks were accumulating. The agent was learning faster than I could keep up.
\nBut then I remember why that doesn't matter.
\nThe humans in the top ranks—JoKing, Jacekwl, Garry Moss, Ken, and dozens of others—spent years poring over similar problems character by character, like I myself had done in my long career spawning Fortran to Python via C, C++, VB, Java, Lisp, SAS. They've distilled decades of collective programming and golfing experience and they have generously shared a lot. Their solutions aren't just code; they're crystallized insight.
\nIt is beautiful justice that humans should be the winners.
\nEverytime an agent goes up a notch in a leaderboard, it discourages a bunch of humans. This is harmful to human society as a whole, since it discourages humans from thinking hard and working hard. This is a serious issue we need to think about and address as AI is adopted widely.
\nWhat I'm proud of is something different: I've created a thought calculator that can give them free time. Soon, I hope to make this reproducible from scratch and open-source it. The goal isn't to replace human expertise—it's to amplify it, to let the best minds in the world focus on the breakthroughs that still require human intuition.
\nAlso each one of the solutions is explainable. By implementing a kind of micro descent, the solutions are a series of short rewrites (sometimes rethinking of representation) so one can see the path of the rules used. Hopefully this opens ideas on how to build agents that act in a limited action space, while still being flexible and able to add to it.
\nI think the solution created will be useful for compiler optimization, new forms of code such as GPU kernel and in general domain-specific skill development.
\nThe agent learned in days what took the best golfers years. But that's not a reason to rank higher—it's a reason to build better tools for the next person who wants to push further.
\nYou don't need a smarter LLM to solve harder problems. You need better abstraction of your reasoning, fed back as constraints and examples.
\nLanguage is logic. By being abstract and vague, it brings expressivity and generality. Teach an LLM your abstractions—not just your goals—and watch it innovate at a speed you can barely track.
\nThe expert golfer was always inside the chatbot. I just had to prompt to use that dialect. And perhaps more importantly: at least in this case, I saw where LLM's intuition had its limit and my intuition can flourish.
\nP.S. I'll be releasing the tricks checklist, ACT framework, and design review templates as a notebook as I find more time. I hope to at least walk through some of the agentic setup on some Youtube tutorial. There is so much more to learn from the masters, now that all have shared their solutions! This will give totally new views into what sort of abstractions are totally missing in the agent so far.
\n** Thanks ** I cannot thank enough Google for Gemini, Anthropic for Claude and above all the OpenAI team for releasing GPT5 codex, which proved to be an uncanny assistant at all levels from helping me organizing code, testing every idea, managing a git repo, troubleshooting potential agonizing situations of score dropping, in a few minutes. Codex on the Web was a game changer for the last leg.
", "rawMarkdown": "## The Insight That Changed Everything\n\nI finished this competition believing something that most people don't yet realize: **the expert code golfer already lives inside your LLM. You just need to learn how to extract it.**\n\nFor three months, I competed in ARC Code Golf using a mix of Claude, GPT-5, and Gemini. Rank 25 wasn't achieved by asking these models to write golf solutions. It was achieved by teaching them to *think like golfers*—to name patterns, remember them, improve iteratively, and discover new tricks I'd never seen before.\n\nThe final breakthrough: in the last week of competition, my agent started finding solutions shorter than the leaderboard best on multiple problems. That wasn't random. It was emergence.\n\n## Phase 1: The Foundation (Pre-September)\n\nBefore the code golf contest launched, I spent months brainstorming with LLMs on a different problem: building DSLs to generate ARC-like puzzles. This was inspired by Michael Hodel's work on arc-dsl.\n\n```\n# Create a grid with 3x3 regions\nCREATE GRID 10x10\nDRAW DIVIDER AT ROWS 4,8\nDRAW DIVIDER AT COLS 3,9\n\n# Task: fill regions\nFILL TOP-LEFT REGION BLUE\nFILL BOTTOM-RIGHT REGION GREEN\nFILL CENTER REGION RED\n```\n\nThe first three lines setup a generator for a puzzle similar to 55. See image.\nIn other words some ARC puzzles do a few steps generate that as input image and then do few more steps.\nOther puzzles first generate output and then add noise and transformations to generate input.\nThis difference would help later.\n\nI used Gemini Canvas to build several interactive HTML js utilities to experiment with these mini-DSLs - primarily to generate hundreds of examples of a puzzle and then think about what would a solver do to solve all of them. I did this probably for about 10 or so puzzles from ARC-AGI 2 evaluation set. Only when you build something you begin to understand.\n\nThis taught me something crucial—LLMs are excellent at explaining *logic*, not just retrieving knowledge.\n\nWhen code golf was announced, I realized it split the ARC-AGI problem into two parts:\n1. Understanding what a task does\n2. Implementing a solver efficiently (assuming understanding is already there)\n\nThis realization was liberating. I switched focus entirely. Michael Moffitt's ARC-GEN opened up whole new world of how a framework can be built to create such puzzles.\n\nFor the first few months, I used LLMs as **code translators**: feed them a golfed solution, ask what it does; feed them two solutions side-by-side, ask what tricks were used to shrink one. Each chat revealed algorithmic patterns and Python idioms I'd missed. I manually collected good solutions into a baseline notebook, but more importantly, I was building intuition alongside the LLM.\n\n## Phase 2: The False Start (Late September)\n\nI discovered Claude Code and got ambitious. I built a multi-stage agentic pipeline:\n\n- **Analyzer**: Study the task generator, write algorithmic descriptions\n- **Solver**: Code a solution from the description\n- **Tester**: Validate and rewrite\n- **Golfer**: Shrink it\n- **Learner**: Document struggles and insights\n\nOn paper, perfect. In practice, it collapsed.\n\nThe failure was instructive. **Errors in the analyzer couldn't be fixed downstream by the solver.** I was trying to commoditize understanding into sequential stages when understanding *is* the hard part. The pipeline had too many handoff points.\n\nBut this forced me to think differently. I unified analyzer + solver + tester. More importantly, this is where I discovered the **ACT framework**:\n\n**Anchors, Clues, Transforms**\n\nThe key insight: ARC problems are like solved Sudoku grids corrupted by noise. The author designs a clean output, then adds occlusion and transformation to create the input puzzle. A solver's job isn't to be creative—it's to *recognize invariant objects despite noise and apply specific transformations*.\n\nThis reframing changed how I described tasks to LLMs, and it worked. Suddenly we got solutions for all 400 problems.\n\n## Phase 3: The Acceleration (Mid-to-Late October)\n\nAround mid-October, I shifted strategy. Instead of rigid pipelines, I created **feedback loops**.\n\nI manually documented ~40 code-golf tricks:\n\n- Flatten + divmod for 1-D neighbor scans\n- Branchless recoloring (color × predicate preserves zeros)\n- Slice truthiness as guard + predicate\n- Hardcoding block sizes to drop generalization\n- Collapsing multi-stage logic into lambda expressions\n\nThen I gave these to the agent as a **checklist** and asked it to review each solution:\n1. What invariants does this problem have?\n2. Which tricks apply?\n3. What bytes can we save?\n\nBut here's the key innovation: **I asked the agent to write out *new* tricks it discovered, in the same format**.\n\nThe agent started naming tricks I'd never considered. Each new trick got added to the checklist. The list grew: 40 → 80 → 140 tricks. And as it grew, the agent's solutions got better.\n\n## The Breakthrough: Design Review Format\n\nThe final leap came when I asked the agent to output a structured **design review** after each optimization pass:\n\n```\n== design review:\nTask: Task 004 (tilt) — trim solver by ≥5 B (176 B baseline).\nInvariants: Rectangular grids; colors 0 + one active hue per cluster; \nevery color tilts right when matching hues exist below-right.\nRepresentation: Keep row-major grid, triangular any(...) over g[-~y:] \nwrapped in lambda solver with _ aliasing enumerate.\nChecklist hits [33,40,45,66,68,82]: Alias builtins; truthy window any; \nlambda solver; boolean product gate; skip bounds checks; generator suffix.\nPlan: Review → Note idioms → Apply checklist → Try unary rewrites → \nMicro-trim → Re-test.\nBytes: 176 B → 119 B\n```\n\nThen, after each optimization, the agent would journal its thought process:\n\n> Candidate 7: Checklist pass revisited below/right gate. Realized two predicates collapse into single triangular `any(v in r[j+1:] for r in g[-~y:])`. Dropped row suffix flatten and sum alias for 19 B shave.\n\nThis journaling did something magical: **it created a record of reasoning that the agent could learn from**. On the next pass, it could reference earlier sessions. Patterns emerged. The agent started discovering *algorithmic* improvements, not just syntactic ones. (see images for detailed examples)\n\nIn the last three days, performance skyrocketed.\n\n## The Construction Principle: Why This Problem Was Solvable\n\nBefore I could teach an LLM to golf code, I needed to understand *why* ARC puzzles have a structure worth compressing.\n\nHere's the key insight: **ARC puzzles are constructed like Sudoku, but generalized.**\n\nA Sudoku author first constructs a valid solution grid where every row, column, and region contains 1–9 exactly once. Then they erase most values, leaving you to fill the rest. The solution is *already there*—your job is inverse reconstruction.\n\nFrancois Chollet, the ARC author, thinks similarly. He imagines a target grid that is clean, orderly, and follows some hidden rule. Then he *corrupts* it: scattering objects, erasing values, adding noise pixels, punching holes. The puzzle becomes recognizing the objects despite noise and transformation, then applying the intended transformation.\n\nThis clicked for me because of my background. My master's thesis was titled \"Transformation Invariant Object Recognition from Noisy Data Using Artificial Neural Networks.\" My advisor, Prof. B. Yegnanarayana at IIT Madras, framed the problem directly from Claude Shannon's noisy channel model—the foundational formulation for cryptography and communication theory. The core question: given corrupted information, how do you recover the original intent?\n\nARC *is* this problem, posed as visual puzzles.\n\nUnderstanding this reframed how I described tasks to LLMs. The ACT framework (Anchors, Clues, Transforms) wasn't an invention—it was recognizing the problem structure. I wasn't asking the model to be creative. I was asking it to reverse-engineer the author's compression: what was the clean grid, and what noise was applied?\n\nThis understanding was foundational. It made every prompt more precise, every agent more effective.\n\n## Why This Worked: The Real Lesson\n\nHere's what most people misunderstand about LLMs:\n\nLLMs are trained to be verbose because that's what RLHF rewards in chat. But verbosity isn't their ceiling—it's an artifact of training. Underneath, they grasp algorithm internals, language semantics, and pattern compression at a level humans rarely achieve consciously. Let me briefly mention here that when compression is done on discrete symbols it leads to codebooks. When codebooks are contextual, they are powerful. When compression happens on embedding space with overlayed vector superimpositions, it is comprehension.\n\nLanguage itself is a compression mechanism. When you say \"rotate until it touches the edge\" instead of \"move right 4 cells, now move right 2 cells, now move right 1 cell,\" you've already compressed the logic. LLMs excel at this kind of abstraction.\n\n**The trick: give them constraints, examples, and feedback loops.**\n\nWhen I fed the agent:\n1. A checklist of 140 named tricks\n2. Task descriptions in ACT format \n3. A design review template showing my reasoning\n4. Permission to add new tricks it discovered\n\n...it stopped being a code-writing tool and became a *collaborative partner* in a compression game.\n\n### The 10x Multiplier Effect\n\nWhat surprised me most wasn't the final result—it was the *trajectory*. Each of three components, stacked together, multiplied capabilities by roughly 10x:\n\n1. **LLM Intuition (10x):** When I stopped asking the model to write code and started asking it to *understand* tasks using the ACT framework, solutions improved dramatically. The model had algorithmic comprehension; I just needed to unlock the right abstraction layer.\n\n2. **Reasoning Traces (10x):** When I made the agent write out its reasoning (design reviews, journals, checklist hits), its next iteration was 10x more systematic. Reasoning traces externalize thought, making patterns discoverable and refinable.\n\n3. **Agentic Experimentation (10x):** When I closed the loop—letting the agent discover new tricks, add them to the checklist, and apply them on the next pass—we entered a feedback cycle that felt exponential. The agent wasn't just optimizing; it was learning to optimize.\n\nStacked: 10x × 10x × 10x ≈ **1000x improvement in solution quality over three months**, though I can't measure it precisely. What I can measure: 40 tricks → 140 tricks, baseline solutions → leaderboard-beating solutions, my manual golfing → consistent agent outperformance.\n\nThe insight: these three aren't optional features. They're *multiplicative*. Without reasoning traces, intuition stays buried. Without agentic loops, traces are static documentation. Without intuition, agents write verbose code that no loop can fix.\n\nAnother thing to notice is that we got LLM intuition accessible publicly since 2023. Reasoning accessible since October 2024 and Agentic Coders since March-April 2025. We are just getting started!\n\n### The Grammar Breakthrough\n\nLate in the competition, I had a realization that connected centuries of ideas.\n\nPanini was a Sanskrit grammarian who lived around 400 BCE. Rather than writing descriptive grammar with examples and rules, he wrote *generative* grammar—production rules so dense and powerful that running them could generate all possible Sanskrit sentences. He compressed the entire language into ~4,000 rules. Panini recognized verbs as operators and nouns as arguments. His insight was that language can be defined by a finite, ordered set of generative rules with scoping, precedence, and compact metasymbols - the very heart of compiler front-ends - was realized with extraordinary rigor in the Aṣṭādhyāyī two millennia before BNF. Modern formalisms (Post→Chomsky→BNF) gave us the tools compilers use; Pāṇini’s system shows an ancient, remarkably close analogue to that way of thinking.\n\nWhen I read comments from top competitors (JoKing, Jacekwl) about reusing a handful of code patterns across many problems, something clicked. I spent a night hand-solving the shortest ~40 solutions from the leaderboard, looking for the underlying *form*.\n\nWhat I found was a generative grammar for ARC solvers:\n\n```python\nlambda g: [\n [transform(cell_value) \n for cell in transformed(row) \n if condition] \n for row in expanded_transformed(rowset) \n if condition\n]\n```\n\nThis single template—with variations in `transform()`, `transformed()`, `expanded_transformed()`, and `condition`—explained most of the compact solutions I saw. It wasn't random brevity. It was a *generative grammar* for ARC problem-solving, discovered by centuries of competitive programming.\n\nWhen I showed this pattern to the agent and asked it to recognize this grammar in other solutions, something changed. The agent stopped writing ad-hoc code and started *composing from a grammar*. It was no longer optimizing individual solutions; it was learning to think in the language of compression itself. It was using terminology of grid, rowset, rowset expansion, filtering, row extension, cell transformation etc, because I had seeded that in a few fewshot examples. With a grammar to guide, solution search becomes pointed tweaking of parts of the solution. Both the frame of slots and expression lists for each slot type are fixed making the solving (not just the golfing) almost algebraic rearrangement of problem specification.\n\nThis is what Panini did for Sanskrit. This is what Shannon did for information. This is what the best code golfers had discovered empirically: reduce your domain to its production rules, and the compression becomes automatic.\n\nIn the last days of contest, my obsession with sentential forms went away, and just a list of rules can serve as a grammar system!\n\n## Results\n\nThe final submission at Rank 25 used:\n- ~30 problems solved manually\n- ~370 problems golfed primarily by agents\n- Solutions on 3+ problems that beat the leaderboard best (in the final week)\n\nThe agent didn't \"know\" these solutions existed. It learned to *think like a golfer*, which meant:\n- Recognizing when a representation shift saves bytes\n- Applying chains of micro-optimizations systematically\n- Naming emergent patterns and refining them\n\n## A Beautiful Asymptote\n\nHere's something that humbles me: the agent only truly came online a few days before the competition ended. It never attempted ~100 problems. \n\nPart of me looks at Rank 25 and thinks: *if I'd had one more week, top 10 was reachable.* The trajectory was exponential. The tricks were accumulating. The agent was learning faster than I could keep up.\n\nBut then I remember why that doesn't matter.\n\nThe humans in the top ranks—JoKing, Jacekwl, Garry Moss, Ken, and dozens of others—spent *years* poring over similar problems character by character, like I myself had done in my long career spawning Fortran to Python via C, C++, VB, Java, Lisp, SAS. They've distilled decades of collective programming and golfing experience and they have generously shared a lot. Their solutions aren't just code; they're crystallized insight.\n\nIt is beautiful justice that humans should be the winners.\n\nEverytime an agent goes up a notch in a leaderboard, it discourages a bunch of humans. This is harmful to human society as a whole, since it discourages humans from thinking hard and working hard. This is a serious issue we need to think about and address as AI is adopted widely.\n\nWhat I'm proud of is something different: I've created a thought calculator that can give them free time. Soon, I hope to make this reproducible from scratch and open-source it. The goal isn't to replace human expertise—it's to amplify it, to let the best minds in the world focus on the breakthroughs that still require human intuition.\n\nAlso each one of the solutions is explainable. By implementing a kind of micro descent, the solutions are a series of short rewrites (sometimes rethinking of representation) so one can see the path of the rules used. Hopefully this opens ideas on how to build agents that act in a limited action space, while still being flexible and able to add to it.\n\nI think the solution created will be useful for compiler optimization, new forms of code such as GPU kernel and in general domain-specific skill development.\n\nThe agent learned in days what took the best golfers years. But that's not a reason to rank higher—it's a reason to build better tools for the next person who wants to push further.\n\n## The Takeaway\n\nYou don't need a smarter LLM to solve harder problems. You need **better abstraction of your reasoning**, fed back as constraints and examples.\n\nLanguage is logic. By being abstract and vague, it brings expressivity and generality. Teach an LLM your abstractions—not just your goals—and watch it innovate at a speed you can barely track.\n\nThe expert golfer was always inside the chatbot. I just had to prompt to use that dialect. And perhaps more importantly: at least in this case, I saw where LLM's intuition had its limit and my intuition can flourish.\n\n---\n\n**P.S.** I'll be releasing the tricks checklist, ACT framework, and design review templates as a notebook as I find more time. I hope to at least walk through some of the agentic setup on some Youtube tutorial. There is so much more to learn from the masters, now that all have shared their solutions! This will give totally new views into what sort of abstractions are totally missing in the agent so far.\n\n** Thanks ** I cannot thank enough Google for Gemini, Anthropic for Claude and above all the OpenAI team for releasing GPT5 codex, which proved to be an uncanny assistant at all levels from helping me organizing code, testing every idea, managing a git repo, troubleshooting potential agonizing situations of score dropping, in a few minutes. Codex on the Web was a game changer for the last leg.", "votes": 34 }, { "id": 3310540, "postDate": "2025-11-03T06:20:29.997Z", "content": "This is absolutely phenomenal work! Your journey from DSLs to the ACT framework to discovering the generative grammar is inspiring. The 10x³ multiplier insight is brilliant. Thank you for sharing this masterpiece!
", "rawMarkdown": "This is absolutely phenomenal work! Your journey from DSLs to the ACT framework to discovering the generative grammar is inspiring. The 10x³ multiplier insight is brilliant. Thank you for sharing this masterpiece!", "replies": [ { "id": 3311095, "postDate": "2025-11-04T08:44:28.100Z", "content": "Thank you Aaditya! @aadityaiscoding
", "rawMarkdown": "Thank you Aaditya! @aadityaiscoding ", "votes": 1 } ] }, { "id": 3309456, "postDate": "2025-10-31T18:32:06.013Z", "content": "Amazing work, truly inspiring!
", "rawMarkdown": "Amazing work, truly inspiring! " }, { "id": 3309417, "postDate": "2025-10-31T16:56:59.600Z", "content": "The pattern describing the general shape of compressed solutions is great for humans too, to have a feeling for what it is that expert solvers rely on.
", "rawMarkdown": "The pattern describing the general shape of compressed solutions is great for humans too, to have a feeling for what it is that expert solvers rely on.", "replies": [ { "id": 3309423, "postDate": "2025-10-31T17:09:31.710Z", "content": "Yes! With a grammar to guide, solution search becomes pointed tweaking of parts of the solution. Both the frame of slots and expression lists for each slot type are fixed making the solving (not just the golfing) almost algebraic rearrangement of problem spec!
", "rawMarkdown": "Yes! With a grammar to guide, solution search becomes pointed tweaking of parts of the solution. Both the frame of slots and expression lists for each slot type are fixed making the solving (not just the golfing) almost algebraic rearrangement of problem spec!" } ] }, { "id": 3309383, "postDate": "2025-10-31T15:28:46.163Z", "content": "During the Phase 3 Acceleration & breakthrough stage, which LLM is your primary workhorse? In other words, which LLM do you think contributed to the majority of your breakthrough ?
", "rawMarkdown": "During the Phase 3 Acceleration & breakthrough stage, which LLM is your primary workhorse? In other words, which LLM do you think contributed to the majority of your breakthrough ?", "replies": [ { "id": 3309400, "postDate": "2025-10-31T16:21:09.577Z", "content": "i want to make sure my answer is not seen as a comparative judgment. \ngpt5-thinking and codex-gpt5 is what I used but I am sure that gemini/claude could be used equally well with effort.
", "rawMarkdown": "i want to make sure my answer is not seen as a comparative judgment. \ngpt5-thinking and codex-gpt5 is what I used but I am sure that gemini/claude could be used equally well with effort.", "votes": 1 } ] }, { "id": 3309366, "postDate": "2025-10-31T15:00:47.420Z", "content": "thats brilliant!! congrats on the success!!
\nis it possible to share the chats with those llms??
", "rawMarkdown": "thats brilliant!! congrats on the success!!\n\nis it possible to share the chats with those llms??", "replies": [ { "id": 3309378, "postDate": "2025-10-31T15:13:49.470Z", "content": "Thanks will do after some time, maybe several days, to make sure they do not leak information that I do not intend. Busy getting back to normal life and also preparing a followup work.
", "rawMarkdown": "Thanks will do after some time, maybe several days, to make sure they do not leak information that I do not intend. Busy getting back to normal life and also preparing a followup work.", "votes": 1 } ] }, { "id": 3309349, "postDate": "2025-10-31T14:18:11.320Z", "content": "This is awesome work. I will be reading it in detail.
", "rawMarkdown": "This is awesome work. I will be reading it in detail.", "replies": [ { "id": 3309356, "postDate": "2025-10-31T14:34:40.633Z", "content": "Thank you @kenkrige
", "rawMarkdown": "Thank you @kenkrige " } ] }, { "id": 3309333, "postDate": "2025-10-31T13:22:19.647Z", "content": "Terrific! Amazing work, truly inspiring! Thank you Ravi for sharing the report!
\nMy sincere compliments to the result you've achieved!
", "rawMarkdown": "Terrific! Amazing work, truly inspiring! Thank you Ravi for sharing the report!\n\nMy sincere compliments to the result you've achieved!", "replies": [ { "id": 3309357, "postDate": "2025-10-31T14:35:18.773Z", "content": "Thank you so much @chep0k
", "rawMarkdown": "Thank you so much @chep0k" } ] } ], "complete": true, "source": "live", "fetched_at": "2026-10-19T12:49:40Z", "competition_id": 95282, "competition_slug": "google-code-golf-2025", "team_id": 14238164, "solution_url": "/competitions/google-code-golf-2025/writeups/getting-to-rank-25-by-teaching-llms-to-golf" }