Creations - the Intern dilemma

issues & bugs
1

@simon I have to admit that I am thrilled … and troubled at the same time. :zany_face:

I’ve been working to ramp up and learn as quickly as possible how to build some new apps using Intern. I ran into issues early on - my first two attempted to use the GPS and Accelerometer - with no success as I now understand these hardware sensors are not readily available to apps, or Intern doesn’t know how to access them. BUT … creating apps is an incredible feature that I believe could transform the industry and the future of personal devices.

The more troubling experience was last night. I had posted yesterday on Discord trying to create an app that would POST some JSON to my server endpoint. It’s a simple app with a couple of input fields that also have date pickers, and submit buttons associated with each. It built the app, but the app didn’t work. It turns out my fault to some degree. I used the web portal version of Intern to run the app in Chrome and quickly spotted the problem using the developer tools: blocked by HTTPS/HTTP mismatch. I was trying to POST to an HTTP endpoint I had given Intern, but the app was obviously delivered over HTTPS. Time to add SSL/TLS to my endpoint. It still failed. But again, I then saw while doing this I had not configured CORS on my server. Great!

The issue then came down to using Intern to change the endpoint to HTTPS - burned a credit - and then to see that introduced a bug. The app was now doing two POSTs to the new HTTPS endpoint - one empty, one with the proper JSON. Hmmm … work with Intern to ask it to debug/remove the extra post. Burned another credit. And now it changed the app name, and a font size issue appeared. Asked to fix that - burning a credit - and the double POSTing issue came back.

In the end, burned four credits and my app is still not working - the double POSTing is occuring and the font size issue is still there. I mean, the app is sort of working, but my server has to filtr the bogus first POST each time. And the font size breaks the date picker since you can’t see the last digit of the year. :frowning:

I fully understand this puts you guys in a dilemma. I did use Intern and you have to pay for that. But now I burned four credits for a broken app. Even if I download the source of the app, and attempt to fix it by hand, I’m not clear how to then “upload” or “deploy” the fixed app to my r1. Is this documented someplace?

Just to be clear … at a CTO event this morning I shared all of this experience with those present and indicated that I think you guys are onto something huge here. This model, IMHO, truly tranforms personal mobile devices and applications development, with very cool AI integration and usage. What I’m trying to determine is how can I use this if I now used up 5 credits building an app that is breaking back and forth.

Anyhow … just wanted to report and get some thoughts. I think you guys are on the right track, but I want to better understand how this can work for developers in a cleaner way.

2 Likes
2

Thank you so much for sharing!

I think there’s a few different ways that we resolve this over time. Any of them, or any combination, or all of them may solve this type of thing for users in general.

  1. The agent stack in Intern gets better. We’re actively improving it and fine-tuning it all the time. Every example of something like what you’ve shared gives us more to work with for the fine tuning, as well as the general improvements that happen over time as models themselves get better.

  2. Cost structure for follow ups. Right now, the cost structure for follow ups is what it is because the feature is new, and it’s not totally nailed down yet what an iteration/follow up should be able to do vs what it should not be able to do. This means that essentially it’s fairly easy for it to consume the same amount of tokens as an original task. We need time and more data to work with here, but essentially it’s not hard to imagine a future where (hypothetically) each task comes with x amount of follow ups, or any other suitable better structure. Every follow up costing a task to the user is not ideal, we just didn’t have better options in order to get it shipped at this point.

  3. Distribution only.
    This is technically possible, yes, but again it would use a task, so it’s only marginally better than a follow up fix in the sense that you can be more confident the fix works before deploying. Zip up the fixed files to intern and tell intern it’s an r1 plugin / creation and it will likely work. I say likely because… LLM based systems often do whatever they want. But it does know what an r1 creation is if you tell it, and you can also try specifically instructing it to not modify any code. I want us to come up with a better solution here otherwise it feels to me like we’re effectively penalising the people who build using the SDK, when we should be encouraging usage of it for people to do things beyond the capability of where intern is on it’s own (for example, anything with a backend!)

Hopefully that gives you an idea of some of the directional thinking, at least from my perspective. And, if you send me a DM I’m happy to give you a few extra credits for the ones that were wasted, especially since you were happy to share this feedback - it really does help :folded_hands:

1 Like
3

Hi Simon,

Hope you’re well! I am facing a similar dilemma with an intern task except now I have lost all access to the task as it has been stuck “In Progress” since Tuesday. So aside from burning credits to fix issues with the original creation, I feel like I have no choice but to start over again and lose everything due to it being stuck. I submitted a ticket on Thursday with the task ID but have yet to hear back. Wondering if you can help. Thank you in advance!