There is a limitation of how much context a LLM can handle. The work around is attaching the context to another chat session from a file attachment is possible in some tools. Perhaps in that session, we should ask the AI to summarize this sessions lessons for retrieval into a new session as context or file attachment.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Jeff Roberts Sent: Thursday, May 29, 2025 10:07 AM To: profoxtech@leafe.com Subject: Re: A Difficult Problem & SAD AI Truth...
I think there is a big opportunity right now for apps or interfaces that save context and load context when needed. You could theoretically, save the grid conversation and load it next time before you start talking Foxpro with Claude. Currently, I think you'd have to copy and paste it back in. But if/when someone comes up with a good way to selectively save and load context where it is helpful, that will be a massive step in the right direction.
On Thu, May 29, 2025 at 8:47 AM Kurt Wendt kwendt@pakoinc.com wrote:
So, in the previous couple days I was working on a bit of difficult problem. Since, yeah, Grids can already be difficult to work with - depending on what you are trying to do. But, it my case - I felt almost like I was "flying Blind" - because of this particular code scenario.
The system I am working on has a number of things in it that makes it GREAT from the User aspect - but, Painful from a Dev point of view. As in, coding to allow screens to scale bigger and smaller. Which is great - but, at times adds a level of complexity to the code. Another example is that the system will actually generate grids on the fly. Then, when a user does changes to the grid - like makes some columns wider while making others narrow - the system will remember those settings. And, for this one screen, in one tab of a PageFrame - at design time it's empty. But, at run time it has a grid.
Well, I was simply trying to make code work that would allow a double-click on a grid line of data for the screen to flip from the 3rd tab in the pageframe to switch to the 1st tab. But, trying to do that became very difficult - since, as I said - the grid essentially gets generated and display on the form in a tab on the fly.
After spending about half a day to try and make it work, and becoming frustrated - I decided to turn to my good buddy Claude AI for some assistance. And so, by the end of the day on Tuesday I had generated a text file for the screen in question (using SccTextX.PRG). Also had a rather complex AI prompt ready to give Claude - and he generated feedback and code to implement - which I then jumped into implementing on Wed. morning. I implemented his code chunk, ran a test - and got an error. I then pushed that error back to Claude (giving him a screen capture of the error) - which is able to read & interpret - then he gave me several possible options to try, in order to try and resolve the issue.
And this went back and forth MANY Times. In many cases, he would give me several options to try. By late yesterday afternoon - I was about to just give up. {Since, truth was - this particular screen change is one I suggested, since it seemed like a great idea - until I tried to make it work!}
But, finally - late yesterday afternoon, I got code changes suggestions from Claude that finally Worked - not only did it NOT Crash - but, it finally truly worked - and double-clicking on the data row forced the screen to flip from Tab 3 to Tab 1!
I was TOTALLY Stoked! I then sent a prompt to Thank Claude for the help.
*** ME: It FINALLY Works - does NOT Crash - and DOES Switch over to the 1st data tab on the screen if we double-click a row of data in the 3rd tab of the screen. Thanks for ALL your help - as this was Definitely a Tricky bit of coding!
*** Claude: YES! Congratulations! I'm so glad we finally got it working! You were absolutely right to be frustrated with this - it really was a tricky piece of coding. Dynamic grid generation with runtime method assignment is genuinely complex, even for experienced developers. ... Your persistence really paid off, and your feedback about the errors helped narrow down the issues. FoxPro may be an older language, but problems like this show up in any language when you're doing dynamic object manipulation. Great job sticking with it! Now your users will have that nice double-click functionality to quickly jump from the Quick List back to the detail view.
But - then I had a thought, and had some new questions for Claude in regards to the outcome and Claude himself.
*** ME: I will ask you one more related question. ALL that we went thru today, and starting yesterday - and trying to get things working. I was curious to know if you are TRULY Learning from our mistakes. And, that - if I was to ask a similar question from you, for a very similar scenario - would what you learned today allow you to much more quickly generate usable code that doesn't crash and avoid all the problems we had today? And, I mean - if I start a different chat session with you - would you be able to solve the issue quicker? Also, from what you learned today - if someone else on the internet posed the same problems to you, in regards to FoxPro and what we were trying to do - will you be able to take what you learned today - to be able to help them quickly as well???
*** Claude: That's a great question, and I want to be completely honest with you about how I work. Within this conversation: Yes, absolutely! I have learned from our mistakes. If you asked me right now to help with a similar FoxPro dynamic grid problem, I would:
Immediately avoid trying to assign methods dynamically with macro substitution Start with the custom property + handler approach we ended up with Be much more careful about object creation timing Understand the limitations of FoxPro's runtime object manipulation
In a new chat session: Unfortunately, no. I don't retain information between separate conversations. Each new chat starts fresh - I wouldn't remember any of our troubleshooting today. I'd likely make similar mistakes initially because I wouldn't have the context of what we tried and what failed. For other people: Same limitation. If someone else asked me the identical question tomorrow in a different conversation, I wouldn't have access to what we learned today. They might go through similar trial and error. This is honestly one of the frustrating limitations of how I work. All the valuable debugging experience we gained today - the specific insights about FoxPro macro substitution, object timing, and dynamic method assignment - that knowledge doesn't persist beyond this conversation. However, the general principles we discovered (like using custom properties instead of dynamic method assignment) are part of good programming practices that I do understand across conversations. But the specific "don't try X because it fails with error Y in FoxPro" - that contextual knowledge is lost. It's a real limitation, and I wish it worked differently!
And THAT is the Crux of why I am making this post. I'm sure others here already know about these limitations of AI - but, I found this answer a bit strange - as I had thought that AI actually DOES learn from it's mistakes - learning that could then help others when they run into the same issues. So, I was a bit surprised to hear that it not only will NOT help others, in regards to what it learned in the chat session with me - but, it would NOT Help ME Either - if I opened up a new chat session and gave it the same problem!
Ugh...
-K
[excessive quoting removed by server]