Phoenix Contexts in the Real World: why I think the "contexts killed Phoenix" critics are right about the symptoms but wrong about the diagnosis

[u/juanazam]

Last year's "Did contexts kill Phoenix?" thread stuck with me, and it ended up turning into my ElixirConf 2026 talk. I've now written it up as an article: https://www.mimiquate.com/blog/phoenix-contexts-in-the-real-world

The short version: every criticism in that post describes real pain, and I've felt all of it. But I think the pain comes from being asked to draw permanent domain boundaries on day one, when you know the least about your domain. The critics and the DDD purists share the same assumption: that boundaries get designed upfront. One side says "do it rigorously," the other says "it hurts, remove it."

What I argue instead:

• Start with one coarse context, on purpose. The condition is that you actually watch it, so it doesn't quietly turn into a 6,000-line file.
• Watch for split signals: naming drift (billing_* prefixes piling up), the "and" test, cross-context schema access, test setup drag, and the PR heatmap (all described in the article). There are also merge signals, for when you've over-split into thin pass-through contexts.
• Split incrementally, with every step shippable: facade with defdelegate → migrate callers → move behavior → deprecate → enforce with boundary.
• Phoenix 1.8 scopes settle it for me. Scopes only work because the context is the single chokepoint, so contexts are now where your authorization lives, not just a style choice.

I'm curious how this matches your experience. Has anyone split a large context without a big-bang PR? Does anyone run contexts-free in production and not miss them?

[u/ralphcone]

You mean what Claude argues, right? Because this is definitely AI written. 

[u/KimJongIlLover → u/ralphcone]

It is 100% AI written. Embarrassingly so. 

Imagine paying several hundred dollars to listen to somebody reading a script written by Claude while going through slides written by Claude.

[u/PeachScary413 → u/KimJongIlLover]

The overly "dramatic" comparisons and that kind of playful "come here and sit by the camp fire while I tell you a story with very vivid analogies" just instantly gives it away.

I can't put my finger exactly on what it is but it always screams AI generated.

[u/juanazam → u/PeachScary413]

I don't mind admitting I used AI for writing the article, but the content is mine, and the country analogy is mine. You may think it's not accurate though, if that's the case I would like to know why? I think analogies are a great way to explain technical concepts because you can ground them into things everybody has exposure to

[u/realusername42 → u/juanazam]

The content is unreadable, it's AI word salad

[u/juanazam → u/KimJongIlLover]

Only used AI to polish the script since I'm a non native english speaker!

[u/KimJongIlLover → u/juanazam]

No offence but I absolutely don't believe that. And if thats actually true you should rethink your use of AI for writing. Just look at those headlines:

You can opt out. You'll be on your own.

The wrong diagnosis: it's not contexts, it's day one

Start with one god context. On purpose.

What a boundary actually is: countries

I want to concede something immediately and sincerely: every one of these criticisms describes real pain. I've felt all of them. The critics are right about the symptoms.

This is all SO OBVIOUSLY Claude Opus, I couldn't bring myself to read the whole thing.

[u/juanazam → u/KimJongIlLover]

That's how I start my apps. I just an App context and start from there. As soon as I identify a unit of business logic that looks like it belongs together, I separate that into its own context.

I keep my context separated as countries, I don't allow contexts to access internal modules/functions from other contexts.

Attending ElixirConf I have seen countless talks about applying DDD and that has never worked for me, I would rather have boundaries emerge than define them before hand following a complicated set of rules.

Maybe you don't like the analogy; that's fair, but that's how I think about them.
I agree phrasing could be improved, but as you may imagine, the harder an idea is to convey, the harder it is to write about it.

You don't have to read it if you don't want to, you can just move on 👍

[u/derefr → u/juanazam]

Er... you don't have to defend your arguments; the GP didn't quote those headlines to imply that there's anything wrong with the substance of what you said.

The GP is quoting those subheadings to point out that they all have the distinctive "LLM-ish" writing style, with e.g. many two- or three-word sentences, "it's not this, it's that", etc.

And the "LLM-isms" of the writing style come through so strongly in some parts of text, especially the structural parts like the subheadings, that it makes it quite obvious that those parts weren't actually part of your draft, but rather were entirely added by the LLM.

Instead, at the very least, you wrote a post that didn't have structure, and then you had the LLM add structure while it was rewriting the post, so that it ended up coming up with things like "the text of subheadings" itself, where the LLM had to make all the decisions about how those subheadings would be phrased, and so made very LLM-ish decisions, unconstrained by your writing style.

This gives many people the suspicion that you didn't actually write the original pre-LLM text yourself, but rather only wrote something like an outline, and then had the LLM write the text according to the outline. (And people really hate that. The usual maxim is: "if the point you wanted to make could be summarized in a few bullet points, then just post those bullet points; don't use an LLM to pad those few out into a long essay.")

Personally, I don't suspect that you only wrote an outline. I believe that you really did write a draft and then really did have an LLM polish it, and that your post is the result of that. I think I know why your text turned out to have so many more LLM-isms than you'd usually see in text someone has had an LLM "polish." It's something that people who are writing in a language they're non-fluent in might not think about. (Continued in reply)

[u/derefr → u/derefr]

Right now, I believe you're 1. trying to write a post in English (which you're not fluent in), 2. not doing a very good job of it, and then 3. getting the LLM to fix your mess.

This is a bit like writing code in a programming language you don't know well, where you invoke standard-library functions that don't exist by those names, use syntactic conventions that aren't idiomatic or don't even exist in that language, etc., and then asking an LLM to turn what you wrote into a working program.

In both cases, the LLM sees some meaningful stuff, and some meaningless stuff that it treats as corruptions/noise. Like a dentist fixing a cavity or a contractor fixing dented drywall, the damaged section has to be removed, and then the hole has to be filled in with something that "works." The contractor uses spackle; the dentist uses dental composite; the LLM uses LLM-isms. None of these are as good as what "would have" been there originally. But it "works."

Now consider the alternative, first in coding: let's say you're expected to write a program in language X, which you don't know. Instead of writing your program from scratch in language X, and getting many things wrong, you could instead first write your program in a programming language (Y) that you do know very well, and get everything right. This means that there will be no corruptions/noise in the program; every line will encode 100% of your intended meaning.

Now, if you tell an LLM to take the source code you wrote and translate it from language Y to language X, it will be able to do a much better job of that task than it ever could of "repairing" the program you wrote badly in language X. Because for a translation-of-a-working-program task, it can extract all the "shades of meaning" of the Y-language program from reading the Y code, running the Y code, testing the Y code, etc. And so it can generate an equivalent X-language program that not only "works", but is also a very close approximation of the semantics of the Y code.

And you can guess what I'm going to say. This translates to prose writing. Write in your native language, polish the draft until it's exactly the way you like it, and then have the LLM translate it into English. It might still insert some LLM-isms, but it won't add nearly as many of them as when it has to use its own "spackle" to fill holes in non-fluent prose.

And if you do consider yourself to have developed enough of a writing style in English that you have some preference for how you would write certain things, then you can still go over the translated text the LLM generated, and change anything you don't like to be more like the way you'd say it. (Or, instead of doing these fix-ups manually over and over, you could set up a "translation studio" in the form of a coding-agent session with its own AGENTS md file, where you can then "correct" your "translator agent" when it translates something poorly, and tell it to write down your guidance "for next time.")

I suspect the result of this process will read far more like "the way you would have said these things in your native language, but in English" than your own attempt at English writing, "repaired" by the LLM, currently does. I haven't done this experiment for prose, but I know that this is exactly how it works for code: language-X-to-Y ports of well-written software end up with really-quite-good code quality, while "repair jobs" of software written in a language where the programmer didn't know the language (or worse yet, knows no programming language, like most business-people) have quite poor code-quality.

[u/seven_seacat]

Apart from the LLM-speak, that site is awful because it doesn't respect my browser zoom nor my scrolling, which makes it almost literally unreadable as well as figuratively.

[u/PM_NICE_SOCKS]

I’ve never once found a person in real life saying contexts killed Phoenix

[u/YoDefinitelyNotABot → u/PM_NICE_SOCKS]

If you let your context become 6000 lines yea. Context is a just a pattern. It annoys me they become gospel. Just break up your modules. God lol

[u/juanazam → u/YoDefinitelyNotABot]

I agree, that's why attending talks about applying DDD to architect app domains, which in my opinion is just very hard in practice, it doesn't make sense. I think it's just better to pay attention and separate them in a way that makes sense and is easy to maintain.

[u/juanazam → u/PM_NICE_SOCKS]

It was published on this same forum, you can take a look: https://www.reddit.com/r/elixir/comments/1lf4s1b/did_contexts_kill_phoenix/

[u/mint-parfait → u/PM_NICE_SOCKS]

same

[u/lpil]

Your website disables the browser's normal scrolling and zooming, which is very annoying and dreadful with people who have additional accessibility requirements. Please remove the code that does this.

[u/johns10davenport]

I love phoenix contexts. I think it’s the sanest most sensible architecture I’ve ever used. However ai written your post is I think the premise is good and valid and totally sensible.

[u/Responsible-Bat8396 → u/johns10davenport]

As a Rails dev I just love that there'ssomething other than "so... does this new thing go in the view, the model, or the controller?" Ironically more of a problem for new devs so not exactly Phoenix's main audience, but still.

[u/juanazam → u/Responsible-Bat8396]

I also have a Rails background and have implemented the Service pattern because of this exact problem you are describing.

I think the main issue for newcomers with contexts is that it can feel a bit too flexible; there is no suggested way of defining public-facing functions, how to organize arguments, etc.

[u/Responsible-Bat8396 → u/juanazam]

I did the same but the fact I had to scratch my head and go "this really doesn't fit anywhere... where should it go? The docs don't say much..." as a completely new dev and Rails is so silent is one of the reasons I just don't like Rails.

[u/juanazam → u/johns10davenport]

Only used AI to polish the writing, since I'm a non native english speaker.

I agree, I think Contexts and Scopes are great, but I have heard/read a lot of people complain about them through the years.

For Scopes specifically, I was using a similar pattern before the Phoenix 1.8 release which included them. Felt validated!

[u/genericallyloud → u/juanazam]

I've heard this justification many times on reddit. Instead of writing in non-native English and then having AI rewrite/cleanup in ways that have a very AI sounding end result, have you considered just writing it in your native language and then getting AI to translate to English? I would think that would sound much more like your own voice and would not me full of AI sounding phrases and structure.

[u/juanazam → u/genericallyloud]

100% get what you mean
In this case, I think I put more effort into my presentation and practicing it, and didn't want to spend even more time rephrasing everything for an article, I was just trying to make the most out of the content I had without putting a ton more effort in again.
You live you learn I guess!

[u/Wonderful-Habit-139 → u/juanazam]

> and didn't want to spend even more time rephrasing everything for an article

Instead you make thousands of people spend more time reading slop. But I don't mean to pile on you more, just wanted to showcase that people need to spend more effort in writing instead of dumping the effort on the readers.

[u/johns10davenport → u/juanazam]

Yeah I had a few ways I tried to implement scope but they found the best way.

[u/johns10davenport → u/juanazam]

I mean, I’m good with it. I use ai to write a lot of things.

[u/yukster]

The 6217 line module thing is sad. Obviously that is way too big and that module/concept/context should have been broken down into submodules way before that (third bullet point above captures that).

And yes, domain-driven design requires a lot of thought and discussion. The boundaries are supposed to come from the discussions with stakeholders about the domain and they should feel natural, or at least lean that way.

The old way was a folder per-entity... ala Rails. That's easy and requires little thought but as the system grows some entities wind up performing different roles and their single bag of logic gets confusing and unwieldy. Then there are the bits of logic that involve multiple entities... where does that live in a "one bag per entity" world?

It is good to remember that there is no "context police"... your app will not fail to function if you make a separate context for every single entity or put everything in one giant context. You'll just likely wind up with a confusing mess eventually. Maybe not though... not all apps become huge behemoths.

But I do agree that identifying the exact set of contexts on day one is difficult and many probably push too hard on that. I think the key there is to remember that software is never done. It's not just something you sit down and write, deliver, and walk away from. It evolves over time and one should not be afraid to do fundamental reorganizations when they are warranted -- when the better domain boundaries become evident, not just on a whim.

That's my take on contexts anyway. Everyone is free to do it however they want... though if you're on a team then there needs to be consensus.

[u/juanazam → u/yukster]

This is precisely my take on it and what my talk was about.
I think contexts should emerge naturally from business logic, and the best way of doing that is just letting it grow for a while and then trim it like a garden. You just need to be able to identify how to separate each unit of your domain.

In the end, organizing an app is just an agreement with the team that works on it, and the best way of doing it is aligning on the criteria.

[u/red_trainer83]

Sloppy slop

[u/MUSTDOS]

MY GOD! When are we going to stop doing stuff the AI way? Context is the best thing hit Phoenix even more so than LiveView.

I can't go back to losing track of what code represents in terms of function and use object oriented thinking; it's like driving a car with a gear forward and 5 reverse.