[m-users.] (cough) "AI"

[John Zabroski]

The purpose is not to have a junior programmer but to have a model of a
problem in English text.

I would encourage you to read Omar Khattab's writings on Late Interaction
models like ColBERT and ColBERT v2, as well as his work on DSPy and prompt
optimization and automated LLM as judges.

My day job is as a C# engineer and I was able to systematically refactor
almost 2,000 files with 230,000 lines of code. - I've also used it to
understand really complex business domains and generate sample code that
would have taken me 6 months or more to learn how to do by myself. In this
way, it is also like having my own personal post-doc available.

On Sun, Nov 30, 2025, 10:34 Mark Brown <mark at mercurylang.org> wrote:

> Hi Tomas,
>
> On Sun, Oct 26, 2025 at 7:31 AM Tomas By <tomas at basun.net> wrote:
> >
> > Hi all,
> >
> > Just read this on Slashdot:
> >
> > | I'm a programmer who started out hesitant about AI, and at first I
> > | thought all that it could do was auto-complete better.
> > | Then I tried Claude Code, and it really is like having your own
> > | personal junior dev assisting you're every need. Like a junior, it
> > | makes mistakes, but using the *massive* amount of good code that it
> > | creates, and fixing what's left, is so much faster than writing it
> > | all from scratch yourself.
> >
> https://slashdot.org/story/25/10/25/0324244/meet-the-people-who-dare-to-say-no-to-ai
> >
> > and wonder if anybody has tried this with Mercury?
>
> Over the weekend I tried getting Claude to write a random maze
> generator that can do square or hex mazes with a bunch of algorithms,
> outputting a customized SVG file. This took ~150 non-trivial prompts
> for several thousand lines of code and a thousand or so lines of
> markdown documentation. Testing it thoroughly was beyond the scope of
> the experiment, but the output looks pretty good to me with some quick
> tests. The finished code looks pretty good, too, for the most part (if
> I wanted to work on it any further I'd ask Claude to work on improving
> boundary.m and render.m next). Claude put "2024" as the copyright
> year, which is kinda funny. Needs more recent training data!
>
> Transcripts are included with the project, if anyone wants to know how
> it was produced. Fwiw this is genuinely how I imagined holodecks would
> be programmed, except without the voice recognition :-)
>
> https://github.com/markbrown/amaze
>
> >
> > I suspect that (1) this person uses C[*]/Java, and (2) the usefulness
> > of this "AI" stuff for Mercury will be proportionally less in a
> > similar magnitude as code length for same functionality, ie a factor
> > ten or so.
>
> The source code for the above project is really the Markdown, not the
> Mercury. From what I've seen so far the choice of programming language
> doesn't particularly matter.
>
> As a separate experiment, I asked Claude to read the Mercury compiler
> source and write a document outlining the design. The result is
> attached. Most of it doesn't add more than the existing
> compiler/notes/compiler_design.html file, but the "Compilation
> Workflows" section looks useful.
>
> Cheers,
> Mark
>
> >
> > Anybody has any experiences?
> >
> > /Tomas
> > _______________________________________________
> > users mailing list
> > users at lists.mercurylang.org
> > https://lists.mercurylang.org/listinfo/users
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20251130/7a741dbf/attachment.html>