My "Move 37" Moment With Coda AI

For years now, I have used a simple trick to convert a Coda Table into a Markdown string, so I can pass it over to an AI or a Pack.

I wrote my own formula that used the hidden ToHtml(aCodaPage) to capture the page containing the Coda Table View that I wanted and render it as HTML, and then had my own cobbled-together formula to convert that elaborate HTML encoding into a simple Markdown version of the tables in the page.

So I decided to spruce-up the formula by asking the Grammarly Go side-panel to write a ‘proper’ formula to do this.

At first it generated a hideous formula that did not understand the actual structure of the HTML generated by ToHtml() and was totally unintelligible to a human - meh!, but it worked.

But my inner CFL wrangler was uncomfortable with such an affront to the senses. So I prompted it further to generate a more elegant solution. I pointed out that we could trust the HTML to always have the same structure, and that it could be traversed as a tree structure, level by level, to find the TABLEs, the HEADERS, the ROWS, and the CELLS, always in the same places in the forest of HTML tags.

Then it came back with the formula below.
:collision:Boom! It was a real “Move 37” moment for me.

The AI had come up with a new (for me) and interesting way of expressing itself in CFL that was both sophisticated (I’ve never used Regex expressions so cleverly) and crystal clear (it named each step with a Let() function).

This is impressive because the amount of training data for CFL is extremely limited for modern LLMs (compared to the vast amounts of Python or JavaScript they are trained on).

But it used the new MCP Tool formula_execute to try out countless variations of the formula pieces to discover how CFL works, how the RegexExtract() function works, and how to assign results to a variable name to use later.

The resulting code is stunning.
And VERY different in style to anything I would have written.

But from now on, I will be writing CFL formulas using the same style.

Each step in the complicated process is “labeled” and stored in a variable using the .Let(name, ... function. So a human reader can see what each line is doing.

I hinted at the need to add comments to help us see what was being closed by the closing parentheses (from experience, I had learned this was useful).

But otherwise, the code is entirely generated by the Grammarly Go AI side panel.

Here it is in all its glory: it works PERFECTLY every time…

Let(Character(10), NL,
Let(RegexExtract(thisRow.HTML, "(?<=<table[^>]*>).*?(?=</table>)", "g"), tableBlocks,
Let(ForEach(tableBlocks, Let(CurrentValue, tableHtml,
  Let(RegexExtract(tableHtml, "(?<=<h2>).*?(?=</h2>)"), tableName,
  Let(RegexExtract(tableHtml, "(?<=<thead>).*?(?=</thead>)"), theadHtml,
  Let(RegexExtract(tableHtml, "(?<=<tbody>).*?(?=</tbody>)"), tbodyHtml,
  Let(RegexExtract(theadHtml, "(?<=<th[^>]*>).*?(?=</th>)", "g"), columnNames,
  Let("| " + Join(" | ", columnNames) + " |", headerRow,
  Let("| " + Join(" | ", ForEach(columnNames, "---")) + " |", separatorRow,
  Let(RegexExtract(tbodyHtml, "(?<=<tr>).*?(?=</tr>)", "g"), rowBlocks,
  Let(ForEach(rowBlocks, Let(CurrentValue, rowHtml,
    Let(RegexExtract(rowHtml, "(?<=<td[^>]*>).*?(?=</td>)", "g"), rawCells,
    Let(ForEach(rawCells, Let(CurrentValue, cellHtml,
      RegexReplace(cellHtml, "<[^>]+>", "") // result
    )), cells,
    "| " + Join(" | ", cells) + " |" // result
    )
  ))), bodyRows, // ends rawCells, rowHtml (ForEach rowBlocks)
  "### "+tableName+NL+NL+headerRow+NL+separatorRow+NL+Join(NL, bodyRows) // result
  )))))))) // ends bodyRows, rowBlocks, separatorRow, headerRow, columnNames, tbodyHtml, theadHtml, tableName
)), markdownTables, // ends tableHtml (ForEach tableBlocks)
Join(NL + NL, markdownTables) // return the final MD text
)) // ends markdownTables, tableBlocks
) // ends NL

It gave useful names to all the intermediate steps; tableBlocks, tableName, columnNames, etc. You may not understand the code for each step, but you see what the step produces.

And then it delivers the coup de grace in the penultimate line that returned the final Markdown text - et voila - QED!

I am not replaced (yet) by AI, but I am now humbled by it, and the master has now become the student.

Once again chapeaux to the Coda MCP and the Grammarly AI teams for their amazing work.

I am humbled
:lobster:Max

“Move 37” refers to a specific play AlphaGo made against world champion Lee Sedol in Game 2 of their 2016 Go match.
On move 37, the AI played a stone on the fifth line; a placement so contrary to centuries of human Go convention that commentators assumed it was a mistake; Lee Sedol reportedly left the room to compose himself after seeing it.
It turned out to be a brilliant, winning move that no human player would have considered, and it’s since become shorthand in tech culture for a moment when a machine produces a solution that looks wrong by expert convention at first glance, but reveals a better way of thinking about the problem once you actually sit with it.

Of course the gnarly part of this formula is all the advanced RegexExtract() magic it does.
I have been using regex for decades (since it emerged in the early QED & grep days in the 1970s), but I had to do some careful study of this formula to finally understand how it worked.

I know that it is not essential to understand how vibe coded formulas actually work.

But I am like those old-fashioned steam-train engineers who just HAD to open the hood of their motor cars (‘horseless wagons’?) to ensure they understood how the engine worked.

So the regex magic revolves around two special tricks, called ‘look around assertions’.
There are two types; the ‘look ahead’ and the ‘look behind’ patterns.

So the most often used regex cases look like this…
(?<=<h2>).*?(?=</h2>)
Will extract the text that occurs between the <h2> and the matching </h2> tags.

Its anatomy is..

  • (?<= starts a look behind block the ? means ‘look for’ and the <=means ‘look backwards’
  • <h2> is the literal text to find to begin the match
  • .*? means match the shortest string of text between the two groups
  • (?= starts a look ahead pattern, the absense of the < means ‘look forwards’
  • </h2> is the literal text to find to mark the end of the match

Then there is the more complex cases that look like this…
(?<=<table[^>]*>).*?(?=</table>) which also uses the “g” flag for ‘global’ matching
The “g” flag means ‘dont just return the first match’, instead return them all in a list.

This extracts texts between the <table...> and </table> tags in the html.
But is ignores anything between <table and its matching > (lots of junk to ignore)

Its anatomomy is…

  • (?<= as before, starts a look behind pattern
  • <table the literal text that starts the pattern
  • [^>]* means 'ignore anything thats not the > character - ie: ignore the junk
  • > is the character that ends the start of the match pattern
  • .*? as before, meand grab and return the shortest string of text between the 2 groups
  • (?= as before, starts the look ahead pattern for the second group
  • </head> is the literal text to find to mark the end of the pattern

So this regex extracts ALL the blobs of HTML for the tables on the page.

So using these two patterns, the formula parses the HTML from the Coda page, and finds the parts that define the Tables, their Names, their Column-Names, their Rows, and all the cells within those rows, and renders them as simple Markdown text.

Anyway, I just had to get down deep into this amazing “move 37” magic and understand every aspect of it.

respect,
:lobster:Max