I think they're grappling with the fact that their positioning needs to be as the operating system but they don't have a leg in currently and destabilising the existing OS players is a monumental task. So they're stuck with the super app direction that just doesn't make sense for how the future of AI UX is envisioned.
The approach sounds interesting but perhaps still too focused on current development paradigms.
Where shared collaboration I think becomes much more interesting is when agents start behaving like a member of your team. Not someone you delegate to, but someone that actively seeks out conversations and interacts with others as though they're just another member of the team.
You shouldn't be aware that version control is happening behind the scenes, you're just interacting with a persistent persona through Slack/teams/notion/figma/linear/etc with something that's logging issues, fixing bugs, writing PRDs, designing mockups, etc. The only point at which you know there's version control is when you're asked to review something before it's integrated.
The funny thing is my expectation was that adoption of AI coding would kill the joy of getting into a flow state but I've actually found myself starting to slip into an alternate type of flow state.
Instead of hammering out code manually over an hour the new flow state is a back and forth with the LLM on something that's clear in my mind. It's a collaborative state where I'm ultimately not writing much code manually but I'm still bouncing between technical thoughts, designing architecture, reviewing code, switching direction etc.
Yeah - similar thing for me as well. A lot of times there would be something I want to work on that would be boilerplate/repetitive/laborious work and I would just procrastinate it for as long as possible, working on other things, until I'd finally get around to doing it. Now those are just immediately completed with a simple prompt and instead of going with the initial implementation, I have the bandwidth to tweak and refine details that I would have skipped over before just to ship.
We also recently cut our build times in half moving from Webpack to Turbopack on production builds after jumping to NextJS 16. We'd already been using Turbopack in development for a while which yielded massive DX improvements related to performance. Production build times will drop further once Turbopack production build caching is stable.
Webpack -> Turbopack is the smart initial migration. I'd bet Railway went straight from Webpack -> Vite not realising that their real gains sat with the build tooling, not NextJS vs Tanstack.
This cost seems wild. For comparison GitHub Copilot Code Review is four cents per review once you're outside of the credits included with your subscription.
Not sure about that, I find it's generally pretty good at finding niche issues that aren't as easily caught by humans. Especially with newer LLMs it gets even better.
Type "owejdpowejdojweodmwepiodnoiwendoinw welidn owindoiwendo nwoeidnweoind oiwnedoin" into ChatGPT and the response is "The text you sent appears to be random or corrupted and doesn’t form a clear question." because the prompt doesnt correlate to training data.
Unless my understanding is incorrect about how these tools work that last point isn't really a quality of LLMs as such? It gets attributed because the lines are blurred but the tireless trial and error is actually just a quality of a regular programatic loop (agent/orchestrator) that happens to be doing the trickiest part of its work via an LLM.
AFAICT this is already baked into the GitHub Copilot agent. I read its sessions pretty often and reviewing/testing after writing code is a standard part of its workflow almost every time. It's kind of wild seeing how diligent it is even with the most trivial of changes.
GH Copilot is definitely far better than just a linter. I don't have examples to hand but one thing that's stood out to me is its use of context outside the changes in the diff. It'll pull in context that typically isn't visible in the PR itself, the sort of things that only someone experienced in the code base with good recall would connect the dots on (e.g. this doesn't conform to typical patterns, or a version of this is already encapsulated in reusable code, or there's an existing constant that could be used here instead of the hardcoded value you have).
