mu4e-snooze and adventures with AI co‑programming

Before starting, let's understand what email snoozing means and how we can design a system to do this.

Snoozing refers to the action of moving an email out of inbox with a commitment on date and time when it would appear back in inbox. This is helpful to move things out of sight that you can't attend to right now anyway. This maps to defer action in the inbox-zero vocabulary. This is not a feature that you would get out-of-the-box in email servers, or clients for that matter.

Keeping in mind the rough design mentioned above, my initial expectations was that GPT4 should be good enough to handle the project end to end. It could come with different concrete choices for the abstractions mentioned above, but generally it should get the job done without much intervention.

I don't know why I had such high expectations, even though I actively believed this problem might be challenging for GPT4.

But as I started working on this, I got disillusioned. Here are a few observations, in no specific order:

1. There were many confident mistakes. If you poke holes, you will get an apology and a slightly improved solution. But then you will have to know the system to really be able to trust GPT4 output.
2. The output code, and notes along with it, was very hand-wavy. "Do this and that and done, simple.". Almost like the end goal was not to actually run the code but to provide some explanation or pseudo-code to the seeker. And inevitably this was missing a whole lot of details that were super critical for the code to run.
3. Unless it's totally autonomous—we are not there yet—you will have to dive in the solution specifications in addition to problem specifications. And writing a solution specification is difficult. I had to see the written code multiple times to finally say that "Hey, I want this and not that because xyz". I guess this gets easier as you co-program for a while.
4. Probably a minor point, but there was a background anxiety around seeing code close enough to have stylistic annoyances but not the right kind of control to do anything about them. I am assuming this will improve drastically in the future. We probably just don't have the right language for conveying how right now. In the end how won't even matter but is still an important area—personally—for the time being.
5. Finally I had to write the program on my own anyway, so that was the biggest disappointment. I could see places where small portions of the problems were done well but together they were not solving the problem completely.

Though in terms of the 3 challenging aspects of this problem mentioned earlier, I believe Emacs Lisp didn't pose any. There were no stupid language related mistakes, even though there were many semantic mistakes around how few sub-problems could be solved.

You can see my interaction log in the Appendix.

In spite of the annoying experience, there were many patterns that seemed promising. Almost all are some form of cognitive heuristics working on a layer above the core reasoning system. Few are:

1. Keep asking questions around the implementation, ask to explain, ask to 'make things better or correct'. These don't need any specific details but work well. Approaches like Chain of Thoughts fall in similar category.
2. Spend time setting boundaries via asking to write tests. LLMs can do a decent job of self criticism. Same model with different context can evaluate its own output well, unlike classical ML setting. In ways this is obvious and expected in in-context-learning as you should probably look at same LLM with different contexts as different classical ML models.
3. Coupled with the previous point, a lot of issues seem fixable with access to runtime system. I believe products geared towards proper programming assistance (GPT4 via ChatGPT is obviously not) would utilize this a lot.

Let's keep analysis—code reviews, static analysis, testing, etc.—and assistance—copilot and other similar current generation IDE features—out of the picture. In terms of pure automation, I believe there are problems where you can get automation to the level of subsumption even right now where you don't need to worry about the underlying substrate, code, at all. For example an interface for plotting data in common ways is possible with an AI writing throwable matplotlib code on every prompt⁴. But to get to similar level for a lot of what we do in programming, there is still much to be done.

An interesting question I have is around the future of cognitive heuristics mentioned earlier. Will they remain part of architecture over LLMs or will they be subsumed inside? I believe it will be the latter, but I would like to understand the shelf life of such things in practical products for the next, say, 2-3 years.

It will also be interesting to deconstruct the abilities needed to make a 'todo app' vs 'snooze feature' which can help to define what to solve. A major part of this will be familiarity in training data, like with humans. But in the end I don't want to have an AI system that does better on creating shopping websites since they are more common on GitHub. So this is not enough. Pretty sure there is some study here that I need to find which might be guiding next upgrades in LLMs that can program.

This post is a relatively shallow evaluation. Folks working on programming LLMs can give you much better insights, and I am not one of them, yet. But I can make few general statements: Working with GPT4 doesn't feel like a Product Manager working with an Engineer. Neither does it feel like an Engineer working with another. Nor like an Engineer working with a Junior Engineer. It's in reality more like:

an Engineer working with a Junior Engineer who is asked to write code, send results without reflections, and without access to a runtime, but with access to stackoverflow.

I am very confident that this would start to feel like the PM working with a Good Engineer pattern soon, but there are a few more steps to get there.