Grok helped me build a DuckDB Qlik Extension

Imagine having the power, as a non-techie, to create your own extensions?

In my professional life, I am known as an "app-tech"—an apps guy who fiddles with tech. Some would say this makes me dangerous; others, just curious.

With 30 years of managing apps, #ERP systems, infrastructure, and change, I thought it high time I got to grips with the power of #AI. And what better challenge than to build a Qlik Extension to deploy DuckDB into Qlik Cloud, running natively with no cheating?

The first spring weekend in March 2025, with no lawn to mow (too early), I set about my goal. I set the scene with Grok and was told to go get a bunch of stuff needed to complete the task. Actually, not as much as I’d imagined, but brick walls would soon appear everywhere.

Grok and I battled things out like two heavyweight boxers for two days (and what felt like nights), and eventually, the DUCKDB2 Qlik Extension was hatched. And it works. It works brilliantly, in fact. I am pleased.

But why did I do it? For two reasons. First, mental health: I wanted to ensure I could still take a first-principles project to completion despite all obstacles and deliver. Check.

The second reason is that Qlik needs this functionality in its platform—the ability to bring your own compute (in this case, query via DuckDB) and augment the already brilliant Qlik Analytics. Check.

Both these are possible, and the glue is that both DuckDB and Qlik Analytics use Parquet files (see my Parker on Parquet posts) to read data from.

What went well?

Grok. It worked like a Trojan to help. It was meticulous in how it approached the task—perhaps too much. But given a limit of 15 interactions (prompts) every two hours, I had to choose my responses with care, else be sat with not a lot to do for a while.

On that note, Grok did not appear to apply the limit at the weekend. Less busy, perhaps? Anyhow, this meant I could crack on, as we might say in the UK.

Working within the constraints of Qlik Extension rules—max file size, etc.—Grok was clever and managed around this.

What didn’t go so well?

Grok. Whilst relentless in the pursuit, it did forget things, including a whole file it wrote, and also totally fluffed some bits. Particularly when building CSS, it messed up the punctuation repeatedly, meaning time wasted on rework. Given it had written 5,000 lines of code, to mess up a bit of CSS isn’t that bad. The issue is that Qlik Cloud is unforgiving—if it cannot render CSS, it will fail. It did.

Working assumption #1: using NYC TAXI data. This failed due to things I don’t understand about read permissions. It didn’t matter, as it wasn’t critical to the test. A new location was found. Then we hit another snag: Content Security Policy "Header Limits" (that’s all I’m going to say—new sources found).

Will I do it again?

Never say never, but no. I don’t need to. This, for me, was like a lesson in prompt engineering—and it was a long lesson. One where I had to stay mentally sharp to keep Grok on track and quash its often insistent but incorrect facts (aka hallucinations). Much of Grok’s ‘thinking’ was based on assumptions of older technology, so it wasn’t fully prepared to work on something as bleeding-edge as a minified JS tool as an extension. But we got there. We probably got there the hard way. That doesn’t matter, though—I have a working solution. That’s what counts.

It just so happened I mentioned the exact same thing to my friends at ancoreSoft , and they too have developed the capability of reading (and writing) to Parquet files and have announced they can create DuckDB objects natively in Qlik Cloud, to be shown at #QlikConnect 2025.

I fear my invention is already for the archives. Was it worth it? Yes, definitely yes..

PS Happy to share the extension, as is.