Earlier quoted context omitted.
>> Remote agent - it's a containerized environment where the agent can run loose and do whatever How is this innovation?
Many people have not experienced the async agent workflow yet and fairly the major providers didn’t have offerings for them until a month or two ago. It’s in fact one of my predictors for if they are going to be enthusiastic about agents or not. And you wouldn’t think containerization would be a big leap but this stuff is so new and moving so fast that combining them with existing tech can surprise people.
Phoenix.new – Remote AI Runtime for Phoenix
191–200 of 283 posts
Re: Phoenix.new – Remote AI Runtime for Phoenix
#192Re: Phoenix.new – Remote AI Runtime for Phoenix
#193"They are not making money off AI".was the most common response to my pointing out they were shilling AI. Feels good to be right.
Re: Phoenix.new – Remote AI Runtime for Phoenix
#194Earlier quoted context omitted.
Yes all 3. It has been weird trying to position/brand this as we started out just going for full-stack Elixir/Phoenix and it became very clear this is already much bigger than a single stack. That said, we wanted to nail a single stack super well to start and the agent is tailored for vibe'd apps atm. I want to introduce a pair mode next for more leveled assistance without having to nag it. You could absolutely treat…
> For me, something like this is the future of programming. Agents fiddling away and we pop in to see what's going on or work on things they aren't well suited for. Honestly, this is depressing. Pop in from what? Our factory jobs?
Re: Phoenix.new – Remote AI Runtime for Phoenix
#195This is very cool. I think the primary innovation here is twofold: 1. Remote agent - it's a containerized environment where the agent can run loose and do whatever - it doesn't need approval for user tasks because it's in an isolated environment (though it could still accidentally do destructive actions like edit git history). I think this alone is a separate service that needs to be productionized. When I run claude…
It does not handle any infrastructure, so no hosting. It allows me to set multiple small tasks, come back and check, confirm and move forward to see a new branch on GitHub. I open a PR, do my checks (locally if I need to) and merge.
Re: Phoenix.new – Remote AI Runtime for Phoenix
#196Earlier quoted context omitted.
1. What's your approach to accessibility? Do you test accessibility of the phoenix.new UI? Considering that many people effectively use Phoenix to write front-ends, have you conducted any evals on how accessible those frontends come out? 2. How do you handle 3rd party libraries? Can the agent access library docs somehow? Considering that Elixir is less popular than more mainstream languages, and hence has less traini…
It seems like they're giving you lower level building building blocks here. It's up to the developer to address these things. Instruct the agent to build/test for accessibility, feed it docs via MCP or by other means.
Re: Phoenix.new – Remote AI Runtime for Phoenix
#197Phoenix creator here. I'm happy to answer any questions about this! Also worth noting that phoenix.new is a global Elixir cluster that spans the planet. If you sign up in Australia, you get an IDE and agent placed in Sydney.
Re: Phoenix.new – Remote AI Runtime for Phoenix
#198Phoenix creator here. I'm happy to answer any questions about this! Also worth noting that phoenix.new is a global Elixir cluster that spans the planet. If you sign up in Australia, you get an IDE and agent placed in Sydney.
Just tried it out, but it's unclear what the different buttons at the bottom of the chat history does. The rightmost one (cloud with an upwards arrow) seems to do the same as the first?
web https://example.com/file.pdf Error: page.goto: net::ERR_ABORTED at https://example.com/file.pdf Call log: - navigating to "https://example.com/file.odf", waiting until "load" at main (/usr/local/lib/web2md/web2md.js:313:18) { name: 'Error' }
/workspace#
Re: Phoenix.new – Remote AI Runtime for Phoenix
#199Phoenix creator here. I'm happy to answer any questions about this! Also worth noting that phoenix.new is a global Elixir cluster that spans the planet. If you sign up in Australia, you get an IDE and agent placed in Sydney.
PS: Why can't I get IEx to have working command-line history and editing? ;-P
Re: Phoenix.new – Remote AI Runtime for Phoenix
#200I've been working with Phoenix a lot the last few months, and I like it a lot. But I do get the sense that the project suffers from wanting to perpetually chase the next new thing, even when that comes at the expense of the functional elegance and conceptual cohesiveness that I think is Phoenix' main strength.
LiveView is a great example. It's a very neat bit of tech, but it's shoe-horned surprisingly awkwardly into Phoenix. There's now a live view and non-live view way to do almost everything in Phoenix, and each has their own different foibles and edge cases. A lot of code needs to work with both (e.g. auth needs to happen at both levels, basically), meaning a surprising amount of code needs to have two, nearly identical variants: one with traditional Plug idioms, and then another using LiveView equivalents. Quick little view helpers end up with either convoluted 'what mode am I in?' branching, or (more likely) in view-mode-dependent wrappers around view-mode-independent abstractions. This touches even the simplest helpers (what is the current path?) and becomes more cumbersome from there. (And given the lack of static analysis for views, it can be non-trivial to even find out what is and isn't actually working where.)
Not every website should be a live view (e.g. hiking directions, for example), but that is clearly the direction of travel in Phoenix. Non-live views get the disparaging moniker 'dead views', and the old Phoenix.HTML helpers have been depreciated in favour of -style live components. The generators depend on those, plus Tailwind, Hero Icons and (soon) DaisyUI, all fetched live from various places on the Internet on build. This tight coupling to trendy dependencies will age poorly, and it makes for bumpy on-boarding (opinionated and tightly coupled isn't necessarily a smoother experience, just a more inflexible one).
So with all of that in mind, while I'm not shocked to see Phoenix jump on the vibe coding hype train, I guess I am disappointed.
The revelation that AI is now writing PRs for Phoenix itself is not confidence inspiring. I rely on frameworks like Phoenix because I don't want to have to think about the core abstractions around getting a website to my users; I want to focus on my business logic. But implicit in that choice is the assumption that someone is thinking about those things. If it's AI pushing out Phoenix updates now, my trust level and willingness to rely on this code drops dramatically. I also do not expect Phoenix' fraying conceptual cohesiveness to get any better if that's the way we're headed.
Phoenix is still an amazing piece of tech, but I wish I felt more at ease about its future trajectory.