We (the GitHub Next team) use and love Apache Spark. So we made sure to connect with ASF before releasing GitHub Spark, and confirm they were comfortable with us using this name.
We felt like there was sufficient difference between the two products, that there wouldn’t be any confusion. Especially with the target audience that GitHub Spark ultimately intends to reach.
That said, we plan to validate this during the Technical Preview phase. Since we absolutely want to be respectful of Apache Spark, and its impact on software.
The GitHub Next team sounds more like a department than a team. It also sounded odd to hear that a group of that size uses and loves something that is unlikely to be used by a large percentage of the team directly. Yay corporate motivational speak! I can use another look at https://despair.com/collections/demotivators after this.
When GitHub Next asked for this, there was already pressure in place for ASF to give that to them, because they're locked into GitHub, so it may not have been given entirely freely. You can say that you're confident it was, but to me it seems impossible to know for sure. I don't know if it was or not. It might be that they would have decided to give it freely but the thought of their relationship with GitHub came to mind while they were considering it. In any case, it's a big ask, because if this takes off, soon the phrase Spark Application that another commenter mentioned will be ambiguous.
With more than 10, I tend to prefer the term department, though the term department could also be used for an organizational division with a smaller number of people.
On the GitHub jobs page, there isn't such a selection, but in autocomplete there are two results for team and none for department or group: https://www.github.careers/careers-home/jobs
You can see the originating issue and the resulting PR from there. And note that while the initial spec/plan/code was mostly good, I iterated on a couple parts of the plan, and then made a minor tweak to the code manually (everything in CW is editable). Which is a key part of our goal with CW: to help bootstrap you with a task (or think out loud with AI), and then provide the iteration primitives to explore further.
We definitely intend to explore a VS Code extension in the not too distant future. And we decided to build a web client + integrated cloud terminal, simply because that allowed us to create an experience that is one-click away from an issue, and could be accessed from anywhere and any device (i.e. we’ve deeply optimized CW for mobile, and I do quite a bit of code thinking in that modality).
In the meantime, when you open a Codespace from Copilot Workspace, you could open that Codespace in VS Code desktop. And use that as a companion editor to the web client (since we bi-directionally sync file changes between them). But totally agreed that a more integrated VS Code experience will be compelling!
I can definitely echo the challenges of debugging non-trivial LLM apps, and making sure you have the right evals to validate progress. I spent many hours optimizing Copilot Workspace, and there is definitely both an art and a science to it :)
That said, I’m optimistic that tool builders can take on a lot of that responsibility, and create abstractions that allow developer to focus solely on their code, and the problem at hand.
For sure! As a user, I would love to be able to have some sort of debugger like behavior for debugging the LLM's output generation. Maybe some ability for the LLM to keep on running some tests until they pass? That sort of stuff would make me want to try this :)
I'm sure we'll share some of the strategies we used here in upcoming talks. It's, uh, "nontrivial". And it's not just "what text do you stick in the prompt".
One of our main goals with Copilot Workspace is to help offer a "thought partner"/rubber duck for developers, and potentially even other members of a software team (as you said, PMs, designers, etc.). And code generation is obviously just one means of helping you think through a problem, along with a fleshed out spec (what are you trying to accomplish?), and plan for how to approach the problem (how might you actually accomplish it?).
And so while we want to help generate code for tasks (e.g. from issue->PR), we also find that it's just super helpful to take an idea and make it more tangible/concrete. And then use that Workspace session to drive a conversation amongst the team, or spark the implementation. Especially since that might only take a couple clicks.
Within the GitHub Next team, I'll often file issues on one of the team's project repos, and then pause for a moment, before realizing I'm actually curious how it might be accomplished. So I'll open it in CW, iterate a bit on the plan, and then either 1) realize it's simple enough to just fix it, or 2) understand more about my intentions and use a shared session to drive a discussion with the team. But in either case, it's pretty nice to give my curiosity the space to progress forward, and also, capitalize on serendipitous learning opportunities.
So while AI-powered code generation is clearly compelling, I agree with you that there are other, more broadly interesting benefits to the idea->code environment that CW is trying to explore. We have a LOT of work to do, but I'm excited about the potential :)
That's not a bad description. I don't have a good comparison— we mostly just built this as a tool that we personally needed. I like to think of it like W&B but also in the world of logging tools like Prometheus.
LLMs are a funky thing to work with, and we need a whole suite of new tools to make them prod-ready.
> No one interacts with my tweets anymore. Meanwhile, I get response on Mastodon that reminds me of the early days of Twitter, before they betrayed their developer community and hired a legion of people to cut ad deals.
Out of curiosity: is your excitement about ActivityPub, based largely on a greater amount of perceived engagement, as compared to other channels?
Wow, this looks awesome! I noticed that the sample notebook doesn’t include SD 2.0 by default, and says that it’s too big for Colab. Is that a disk size/RAM limitation?
As an aside, it would be cool if you versioned that notebook in the repo, so that it could be easily opened with Codespaces.
Understanding Michael Porter: The Essential Guide to Competition and Strategy
This is a commonly cited book about “strategic thinking”. But despite that, it’s one of the few business books that I actually read every page (as opposed to spotting fluff and selectively skipping pages), and it had a notable impact on the way I think/write/communicate.
Personally, I find “learning through demystification” really effective. So putting the humor aside, I’d love to see more things written like this.