I have had both frustration and joy working with AI.

I have found it is far better at understanding - and, with prodding, determining the root causes of bugs - in big sprawling codebases than it is at writing anything in even simple code bases.

Recently I had it compare and contrast two implementations of the same API written in different languages to find differences, and it found some very subtle things and impressed me. It got a lot wrong, but that was because one of the implementations had lots of comments that it took at face value. I then wrote a rough spec of what the API should do and it compared the implementations to the API and found more problems. Was a learning experience for me writing specs too.

Also recently I asked an AI to compare two sets of parquet files and it did sensible things like downloading just bits of them and inspecting metadata and ended up recommending that I change some of the settings when authoring one of the sets of parquet files to improve compression. It needed esc and prodding at the halfway point but still it got there. Was great to watch.

And finally I've asked it a detailed question about database internals and vectorising predicates and it got talking about 'filter masks' and then, in the middle of the explanation, inserted in image to illustrate. Of 'filter masks' in the PPE sense. Hilariously wrong!

This post resonates a lot with me. I've been experimenting with Claude Code to write code that interacts with the SolidWorks SDK. It is both extremely complex (method calls with 15+ bools, doubles, strings; abbreviated parameters; etc) and obscure. It has been like pulling teeth. Claude would hallucinate methods, parameters etc.

I tried using Context7 MCP with the SolidWorks docs but the results were not satisfactory. I ended up crawling SW's documentation in HTML, painstakingly translating it to markdown and organizing it to optimize greppability [1]. I then created a Claude skill to instruct CC to consult the docs before writing code [2]. It is still stubborn and sometimes does not obey my instructions but it did improve the quality of the code. Claude would need 5 to 10 rounds of debugging before getting code to compile. Now it gets it in 1 to 2 rounds.

[1] https://github.com/pedropaulovc/offline-solidworks-api-docs

[2] https://github.com/pedropaulovc/harmonic-analyzer/blob/main/...

This post is a mess. The best advice is clear and specific, and this is neither.

The examples are at best loosely related to the points they're supposed to illustrate.

It's honestly so bad that I cynically suspect that this post was created solely as a way to promote click3, in the first bullet, and then 4 more bullets were generated to make it a "whole" post

I played a lot with LLMs over the last year and built a multitude of products with it and it’s always just the same bottom line outcome: - be specific - keep it small - be precise when adding context - don’t expect magic and shift deterministic requirements to deterministic code execution layers

All this is awfully painful to manage with current frameworks and SDKs, somehow a weird mix of over-engineered stuff while missing the actual point of making things traceable and easy changeable once it gets complex (my unpopular personal opinion, sorry). So I have built something out of my own need and started to offer it (quite successfully so far)to family & friends to get a handle on it: Have a look: https://llm-flow-designer.com

Perhaps we can add that using LLMs for logical, creative or reasoning tasks (things the technology isn’t capable of doing) is an anti-pattern.