#First AI contributor
1 messages ยท Page 1 of 1 (latest)
๐งต
My guess is that it will only work if the issue is very well scoped and doesn't require major refactoring
@shrewd hazel you've been particularly focused on "long tail" issues so I'm especially interested in your suggestions
we have one in-progress dagger update. though I have most of the changes in, it will be good to see how AI deals with that
Would we ask the AI to finish the PR you started?
we can try both try to finish the PR and do it from scratch
This one: https://github.com/dagger/dagger/issues/8726 is fairly easy to implement, just a new method on Container, maybe we need to add a bit more context to the issue so the AI can understand but it's easy to do. (If we want to do it, since it seems it's just a sugar syntax)
I went through the TS issues and I don't see any that could be handle by an IA, it's mostly complex issues/questions.
Btw, wouldn't it be useful to use an IA to help answering our GH issues when it's related to questions? Or like a way to summary/improve issue resolution? Like you describe a bug and it creates a repro automatically? ๐
I think we could also use these AI to generate a bunch of our doc example, that would make use gain a gigantic amount of time (cc @fathom crystal )
We are testing an AI, both for docs answers and to see if it is able to convert examples from one sdk to another: #t-documentation message
I actually have an issue on documenting how to set up the git credentials, which has in the comments a working example for gitlab ; I'd love to see that ported to Azure / github / bitbucket
I'd be extremely curious how it'd do at generating an SDK for a language we don't support yet (using a few existing SDKs as context). Seems like a stretch but maybe within reach? Even if it only gets like 75% there could save a lot of effort filling in/fixing the last 25%
@velvet yew is it possible to give Guillaume and Erik access to the kapa eval slack so they can try it for the above requirements?
If not and/or if there's a seat limit, I'll have a go at these questions with my account
Iโll try now
Invites sent โ
OK, after a detour getting the AI to use dagger properly so it can test its own work... I selected this starter issue: https://github.com/dagger/dagger/issues/7388
Here's the AI's plan:
Plan Overview:
Add File() method to Query type in core/schema/directory.go, allowing direct file creation without Directory().WithNewFile()
Implement file creation using existing NewFileWithContents functionality in core/file.go
Update GraphQL schema to include new Query.file field
Run tests with dagger shell -c "test | specific", verify lint passes locally, and create PR with gh CLI linking to issue #7388
Here it is... first AI-contributed PR ๐ https://github.com/dagger/dagger/pull/9116
Love that I can watch it work in real time ๐
i wonder if this thing can shepard along dependency bumps effectively, especially major versions... like plz fix all compile errors and make tests pass
idk how important that is in dagger, but in corporate monorepos there's big $$$ to be saved
Yeah definitely. That's very close to @rare isle 's use case as well ๐
@oak merlin in our case there is a big need for scaling maintenance of modules - like updating to new engine versions etc
also, potentially automating the daggerizing of new projects - cc @keen sequoia @velvet yew @junior oasis
I still haven't given up on the proto from the internal hackathon -- at least for breaking changes
and, potentially writing new modules or even SDKs (as @queen basalt suggested above) from scratch
ah yeah i hadn't even thought about module dep bumps, definitely applies there
Also adding module and function descriptions ๐
actually let me try that right now
@keen sequoia we are making the CI-less dream a reality ๐ https://github.com/dagger/dagger/pull/9116#issuecomment-2521680238
poor CS grads, it's faster than an intern
i am kinda mistrustful of its ability to run codegen as opposed to doing the codegen itself
every time i call it "it" im afraid its gonna go skynet on me
I've been teaching it to use dagger
You can see it work in real time, look for local traces with a robot icon: https://v3.dagger.cloud
What's really interesting is that it gets confused in the same ways a human would. See this for example: https://v3.dagger.cloud/dagger/traces/70768c26bf25ab6b161c50da7cf2614e
I just said "everything is available in the dagger shell, there's codegen in there somewhere, figure it out".
It discovered a top-level generate function, makes sense, so it calls that.
-
it's the wrong
generate, callsdagger developon our modules, but doesn't codegen our SDK. This is objectively shitty UX on our module. Any human contributor would be confused by thus -
generatedoesn't write back the generated dir to the local fs. Hard to guess, hard to discover, etc
### Generate
Generate SDK static files (replace `<sdk>` with one of the supported SDKs, or "all" for all of them):
dagger call sdk <sdk> generate export --path=.
If you've made changes to the GraphQL schema, you will need to generate all sdks in one go prior to committing:
dagger call sdk all generate export --path=.
> [!NOTE]
>
> For `PHP` and `Elixir` SDKs it's important to manually delete the generated folder before running
> this command
i can't tell how much it's learning from you and inference vs the various readmes
@oak merlin what's your dagger email? I'll add you to the backend
--> this led to the unsuccessful dagger shell -c generate
This experience makes me want to make the dev environment 100% daggerized.
At this point the only command the AI needs that isn't available in the dagger shell, is the git workflow on its local checkout git pull, commit, rebase, push etc
i suspect it's gonna have an easier time if we tell it to rtfm lol, then teach it to translate "call" into shell
yeah possibly. I also have my parallel agenda to teach it the shell specifically, so that it can become more adaptable faster (easier to do discovery from the shell, and I have a successful prototype on the side of raw gpt4o navigating successfully)
but at some point if using the shell becomes the main obstacle., we can switch bacj
@oak merlin you should have an invite
i totally see the throughline to shell being more adaptable with the .doc and whatnot, but i also feel like LLMs like large static chunks of text as input, not small discoverable ones
.doc --recursive so you can give it the whole tree of downstream docs lol
I've been looking at the changes AI is pushing. I see now it is changing the api for "uninstall". @oak merlin , do you know why it is making that change?
i do not, it seems like it's confused by the compile failure solomon pointed out on the issue
yes 100% I actually meant to open an issue for that.
A second merged PR ๐ฅ https://github.com/dagger/dagger/pull/9130
Surprising: my prompt from devin leaks into the PR itself, will iterate with it ; some good and bad -- but kinda ok in my opinion, once bad removed
Why has the dagger binary been committed
I think we still need to have engine devs reviewing engine related prs - I do have comments about this actially
It's added way too much logging, we should have added a test for this (this has fragile logic), and also it's committed the dagger binary, the string is hard coded in various places, there are no docs, etc
Regardless of whether its human written or AI written, we still need to follow the same quality standards here ๐
I also think this env name should be prefixed with _EXPERIMENTAL right? Or we could have put this into a config file, instead of adding more complexity into the dagger environment.
Or at least we could have discussed where this should go.
made a follow-up pr in https://github.com/dagger/dagger/pull/9134
why do you think
sorry I saw comments from @hot hamlet and assumed there had been a full review. I scanned through the pr but missed the binary. Should we force push to main to remove it?
I've added the removal in https://github.com/dagger/dagger/pull/9134 - we should review it and discuss it there
You can force push, I'm not sure who has permissions to do that (I think it's banned for everyone), so needs repo settings changes to temporarily allow it
We should get it out of the history, to avoid all clones needing to pull it
I'll have more time to follow up with that on Monday
I don't understand the issue with just merging your follow-up PR ? ๐ค -- It is indeed a mistake, if we were to force push we would have to do it prior a new PR gets merged
if we don't force-push it, then the binary is in the git history forever, which inflates it (since every clone would download it)