Inventing a new thing "for agents" always feels counter-productive. Your new thing isn't in the training data, so you have to teach it how to use your thing. Why not use tech that's already in the training data? Agents know Python and Django. Or, better (because the performance, maintainability, and deployment story are much nicer with no extra work, since agents write the code), agents know Go.
The very nature of LLMs means you can't invent a thing for current agents to use that they'll be better at using than the things they already know how to use from their immense training data. You can give them skills, sure, and that's useful, but it's still not their native tongue.
To make a thing that's really for agents, you need to have made a popular thing for humans ten years ago, so there's a shitload of code and documentation for them to train on.
This makes sense, but it also causes concern. With AI whether it is content or programming, losing the new novel approaches which may wind up being better in the long run, get shut down for expediency in the short run. This is nothing new and not AI specific behavior, large comoanies have been doing this forever, but it leads to a death of innovation and a spiral inward of self reinforcing loops. You are absolutely right that llms won’t know it and will need to learn something like this all over, but they are good at that and if we stop to find better patterns (which is what humans are great at doing) we keep creativity alive and find meaning while making our work more productive in the long term.
this was true a year ago, but if you give an agent a new spec to follow (e.g. a .md file), it will follow it.
we have a custom .yaml spec for data pipelines in our product and the agent follows it as well as anything in the training data.
while I agree you don't need to build a new thing "for agents", you can get them to understand new things, that are not in the training data, very easily.
Just because they can doesn't mean inventing a new framework "for agents" is going to be superior to letting agents use what's in their training data. I suspect it'll be worse, but the time/resources needed to prove that is beyond what I'd be willing to invest.
What makes something like this "for agents", anyway? It's opinionated...a human's opinions, I assume, since agents don't want anything and thus can't have opinions. But, many existing tools are opinionated. Types are good for agents, because it keeps them honest, but many existing things in this space have types. Python is good for agents, because there's a shitload of Python code and documentation in their training data, but many existing things are built with Python (and TypeScript, Go, and Rust are also typed languages and well-represented in the training data).
I dunno. I think a lot of folks are sitting around with an agent thinking, what can I build? And, a lot of things "for agents" are being built, as a result. I think most of them don't need to be built and don't improve software development with agents. They often just chew up context and cache with extra arbitrary rules the agent needs to follow without delivering improvements.
> we have a custom .yaml spec for data pipelines in our product and the agent follows it as well as anything in the training data.
Doesn't this end up being way more expensive, because you don't pay for model parameter activations but for the tokens in/out, meaning that anything not in the training data (and therefore, the model) will cost you. I could make Opus use a new language I came up with if I wanted to and it'd do an okay job with enough information... but it'd be more expensive and wasteful than just telling it to write the same algorithms in Python, and possibly a bit more error prone. Same with frameworks and libraries.
The whole point of AI is that it can generalise to stuff outside its training set, and anyone who uses Claude on a daily basis completes tasks that have not already been completed elsewhere.
These models excel at tool use. They’re using CRMs, word processors and dozens of other systems that weren’t programmable before - lots of tools have opened MCP/API/CLI interfaces for the first time specifically to support AI, and it works.
I don’t know where this meme comes from, but we haven’t “invented the last language” and we’re not going to be frozen in 2023 for tooling, any more than the Industrial Revolution led to automation of artisan workshops rather than the invention of the modern factory system.
That's not what I'm saying. I'm saying that if you make "Django, but different" it isn't for agents.
Django, but different is not a "tool use" situation. It is a framework with a ton of conventions and libs, etc. Agents will be better able to write Django than "Django, but different". Will they work with your new libraries? Of course. They're very good at all sorts of coding tasks, and they can read docs, search the web, experiment, and correct themselves in an agentic context even absent any relevant training data. But, what may have been a one-shot with Django code, might require several tries with your new thing.
That is not an argument against making new things. I'm not make any argument against making new things, anywhere in this thread. My argument is that if you make "Django, but different", it isn't "for agents", because agents already know Django and they know your new thing considerably less. Your new thing is more work for the agent.
My comment is about being honest with yourself and others about what you're building and for whom.
This Show HN post doesn't seem to be by the author and it's not presenting the project in a good way in my opinion. I also don't like the agent framing of the project home page, but after reading the about, I'm willing to tone down my criticism.
The framework seems like an interesting project to keep an eye on.
Hope this doesn't become a trend 'cause it can become very problematic.
Lots of newbies could replicate and this can produce waste of tokens as a first issue.
Also this creates additional problems, for example binding something new to a single AI vendor or tool (and also to an unpredictable model behind other than some pay subscription) is conceptually wrong.
Nothing against AI obv, but we must start to address the use and abuse of it.
Some sorts of patterns in the usage, having a documentation or a readme as in this case is ugly and should be catalog under "anti-pattern".
This is just an example, in a WIP project and okays, it's not a sin.
But maybe we should start addressing, backed by big players an in big proportion by no profit foundation and academic (public and private) institutions, the problem of:
How to use AI, what kind of things is useful doing with it and what not, how to evaluate that, in what stages of things can one have space to misuse this tool and in what not.
This not much as a mandatory thing, but as a starting point for everyone approaching the use of AI as a building tool. A guideline. A market standard.
So that anybody can address at moment 0 landing on a repo, if it's compliant with some standard or not. Because have in mind, as a compass, what somebody investing some effort put into this field.
Could be argued that common sense already addresses this very efficiently and that it's a matter of iteration and we all as a whole can build this common sense on ai use, but I think that having some credible org write it in a easy, accessible, verifiable, and used is a milestone toward it. And can accelerate the process with a small effort. Also can affect directly the various AI tools.
Best practices, and concept, must be shared and easy to be access by everyone, as always have been in this field.
I'm not very good at counting lines of code, but it seems like it's slightly less than Django. From a cursory glance the main difference I saw was that only postgres is supported, not necessarily a bad thing.
Ignore all the hate in the comments here, anyone denying the direction of software development and it aggressively becoming agentic have their own reckonings to deal with…
I love this concept. While I’m a Rails guy myself, I appreciate the value of Django too, and an agent-optimized version of it makes sense.
I feel like the next logical steps are this exact concept but in Go / Rust to get even more performance out of everything and to also get the single deployable binary too
I've actually been vibe coding a port of Django to Rust as a fun learning experience. I didn't expect it to be possible, but I've already got the core ORM working (including makemigrations, migrate, and inspectdb) with basic admin support running.
Single file deployment, and the process seems to only use 3-4 MB of memory.
I've been able to use inspectdb on existing Django databases, and then browse and change that data using the rust admin.
I am probably not the right person to build a production ready version of this - since I am not a Rust developer - but gee I am impressed by how good it is becoming.
UPDATE - should this be a Show HN? This isn't posted by the author and there are better links to share with more info about the who, what and why: https://plainframework.com/about/
From the Show HN guide/rules:
> The project must be something you've worked on personally and which you're around to discuss. See these tips about how to present your work.
Class-based views were a problem when they were introduced in Django, and they’re still a problem.
Especially for the so-called AI-ready framework. Because of indirection, you either have to go read all the basic classes, or read documentation three times over. Instead of just reading the self-contained view function itself, once.
Especially true for an agent, it will have to go read the new framework’s docs and source over and over and over…
There are very specific reasons to use Django’s class-based views, so much so that it doesn’t really strike me as “multiple ways to do one thing”.
Case 1. You are simply writing a view. Request comes from the router, you want to run some logic and return a response. Either it is part of the end project, or it is simple and small enough that the end project would prefer to just override the entire thing. Write a function!
Case 2. You are working on an end project, and you want to take a view shipped by Django or some library and override bits of its behaviour. The view is already shipped as a class, and writing it as a function would be unwieldy because there is a bunch of logic you’d need to repeat. No-brainer: just inherit and go.
Case 3. You are writing a library that is intended to be customised by the end project. You ship a view that performs a somewhat complex sequence of actions as part of handling a request (e.g., validating input, constructing a query, fetching a QuerySet, serializing it in some way). You want to give the end project an easy way to borrow your view and override only specific parts of that logic. Consider writing a class-based view, and basing it on some pre-existing class-based view if possible (the above looks a bit like ListView, for example).
In my experience, your Case 2 plays out a bit differently. "Just inherit and go" and in many cases you end up with more lines of code in total than doing the same thing in my own function with some kind of helper. Even in the dead standard thing, like displaying a list of objects with pagination. But now I don't own the flow!
Any kind of customization and I need to go jump through the hoops, I need to go look at the code what exactly happens there. But this class inherits a couple other classes, and I need to go read them as well. What for? Grug not want read seven basic multiple-inherited class just to display a list of objects.
So I disagree that it's a no-brainer. It's a no-no brainer for me.
As for writing the libraries, I have the same problems with all libraries that provide class-based API, where I need to inherit from libraries' classes to do my thing.
I like my code to be stupid and linear, to own the flow, so I can read the code and understand what happens there. Same is true for agents!
I am also willing to accept some LoC penalty for my approach. But it's shorter in practice, so win-win for me.
I was using Django since 2006 up to ~2012, and then again touched in 2014-2015. Never again.
If it’s easier to just write a function view, then sure, just write a function view. I did phrase it specifically: if you want to take stock logic and just override a specific part, then CBV is a pretty intuitive way of doing it.
My point was mostly: stick to function views by default, don’t bother devising your own class-based views in an end project, maybe do if you ship a library and have carefully thought about extension points that are ergonomical for your users, and do take advantage of a pre-existing CBV if it feels like a natural, sustainable, low-LoC solution.
For example, as a default choice, if I need to show a list of items, I would in fact just write a function view. However, once I need more features (the turning point for me is probably pagination), I’d brush up on the docs, subclass a ListView, and enjoy well-tested logic taking care of things for me. In the simplest case I’d just set class attributes without overriding any methods at all; maybe I’d take over get_context_data() to give the template some project-specific variable that doesn’t make sense in context processor. If I need something significantly more custom, I’d switch back to a plain function view and use in it pagination primitives that Django exposes. Done all of the above at different times and I think it worked pretty well.
Yes, it did come with practice and I did ship some spaghetti at first, but I also was a relative noob/junior when CBVs came out.
Fine, it is subjective, so there is more than one way of doing things here, and it is not great, but I still think CBVs have their place.
> I don't own the flow
Sir, this is a framework, we don’t own the flow. (I’m slightly jesting.)
> I like my code to be stupid and linear
I am in the same boat, but to me overriding a CBV method seems pretty stupid.
I used Django for from pre-1.0 (the latest time was in 2021 and that project is still live), been to one PyCon and contributed some really minor fix or two. While I have seen hairy Django codebases, I still think it’s a very sane and the best-documented framework.
As someone who is leaning into this vibe coding thing recently, kind of interested to know the sentiment here. What was the tell? Like can you give line numbers or some reference. Feel like 100% certified organic code is a pretty high bar going forward.
I've been excitedly following the development of Plain for a while now, it's so cool to see so many of the rough edges in Django get fixed in a nice comprehensive solution.
Great job Dave Gaeddert!
I'm saddened to see some of the other comments saying it's slop, he was working on this long before vibecoding became common! I think there's a lot of really good design decisions and I hope people don't write it off just because he's trying the "for agents" marketing approach lately.
Something like this has been on my mind for a while. When using LLMs for coding I believe it is a significant benefit, if the amount of lines to be reviewed by humans is as small as possible. An app, which is not much more than a configuration in a dense, custom made DSL with minimal coding to specify business logic would be the simplest artifact that a human can review quickly and an LLM can manipulate with ease (provided there's good docs / linting / errors / maybe even a finetuned model at some point).
Everything which just works "by convention" or by "opinionated defaults" (allowing a tightly coupled but very feature rich framework) helps to reduce the noise / lines that needs to be reviewed.
While this approach might not be optimal for every project, I'm certain the opinionated defaults can work for many endeavours. And the reduction of complexity might be one important aspect, which can make an "agentically engineered" project sustainable.
>Everything which just works "by convention" or by "opinionated defaults" (allowing a tightly coupled but very feature rich framework) helps to reduce the noise / lines that needs to be reviewed.
This is exactly why I've gone back to Ruby with Sinatra or Rails for my personal side projects, despite Ruby's horrid performance.
As long as you are content to remain on e.g. Rails' "Happy Path", then I've found agents do a fantastic job because there's lots of Ruby in the training set and there's less surface area where a context mismatch/hallucination can end up going off the rails. Pun only partially intended.
I'm not against this idea in principle, but I'm also not sure why that is better than what's already out there, except maybe you save some tokens by not vibe coding this yourself?
I do think in the future we'll see some novel libraries that are agent-optimized first. I'm not sure if this is it, though.
The models are training on examples, and there are a lot of Django examples to learn from. Where is the advantage here? A surface for more potential bugs?
* this dev can merge what he want instead of being stopped by those evil django developers
* it looks very cool on your cv
* hence the function name changes and the tiny notion at the bottom that the project is "inspired" by another. Absolutely crucial!
I think the "agents only know what's in training data" argument never made sense to me. I've watched Claude read a markdown skill file and correctly invoke a CLI it had never seen before.
The thing that actually matters is whether your interface is predictable consistent verbs, typed errors, no magic. Agents are surprisingly good at learning from docs, they're just terrible at guessing.
The real question for Plain isn't "will agents know it", it's whether the opinionated defaults actually reduce the surface area they have to reason over. Django's flexibility is kind of a nightmare for agents because there are 6 ways to do everything. If Plain picks one, that's genuinely useful.
Anyway, "designed for humans and agents" is going to be on every framework README by EOY whether it means anything or not, so might as well be the one that actually thought about it first ;P
This looks pretty neat and the anti-AI hate in here is getting pretty tiresome.
From what I can tell looking at the codebase compared to Django's, the top-level modules are structured much better and more obvious for AI to discover them. And then inside each module is a descriptive README with lots of description and examples that are helpful to an agent (and human). Not sure why this is being written off as slop or arbitrary changes, it seems pretty obvious to me this is the direction of frameworks.
I think this has been around for a while, if it's the same thing I'm thinking of. It started out as an opinionated fork of Django, but appears to have now been rebranded to jump on the agent hype-train. Not sure if I'm in the minority, but I'm now less interested in this given its focus on agents.
Inventing a new thing "for agents" always feels counter-productive. Your new thing isn't in the training data, so you have to teach it how to use your thing. Why not use tech that's already in the training data? Agents know Python and Django. Or, better (because the performance, maintainability, and deployment story are much nicer with no extra work, since agents write the code), agents know Go.
The very nature of LLMs means you can't invent a thing for current agents to use that they'll be better at using than the things they already know how to use from their immense training data. You can give them skills, sure, and that's useful, but it's still not their native tongue.
To make a thing that's really for agents, you need to have made a popular thing for humans ten years ago, so there's a shitload of code and documentation for them to train on.
This makes sense, but it also causes concern. With AI whether it is content or programming, losing the new novel approaches which may wind up being better in the long run, get shut down for expediency in the short run. This is nothing new and not AI specific behavior, large comoanies have been doing this forever, but it leads to a death of innovation and a spiral inward of self reinforcing loops. You are absolutely right that llms won’t know it and will need to learn something like this all over, but they are good at that and if we stop to find better patterns (which is what humans are great at doing) we keep creativity alive and find meaning while making our work more productive in the long term.
That's a different conversation than the one I'm having. I haven't made any argument against making new things.
I'm saying "Django, but different" isn't for agents. It makes agents work harder, in general.
Make anything you want. Just don't lie to yourself and others about who it's for.
this was true a year ago, but if you give an agent a new spec to follow (e.g. a .md file), it will follow it.
we have a custom .yaml spec for data pipelines in our product and the agent follows it as well as anything in the training data.
while I agree you don't need to build a new thing "for agents", you can get them to understand new things, that are not in the training data, very easily.
Just because they can doesn't mean inventing a new framework "for agents" is going to be superior to letting agents use what's in their training data. I suspect it'll be worse, but the time/resources needed to prove that is beyond what I'd be willing to invest.
What makes something like this "for agents", anyway? It's opinionated...a human's opinions, I assume, since agents don't want anything and thus can't have opinions. But, many existing tools are opinionated. Types are good for agents, because it keeps them honest, but many existing things in this space have types. Python is good for agents, because there's a shitload of Python code and documentation in their training data, but many existing things are built with Python (and TypeScript, Go, and Rust are also typed languages and well-represented in the training data).
I dunno. I think a lot of folks are sitting around with an agent thinking, what can I build? And, a lot of things "for agents" are being built, as a result. I think most of them don't need to be built and don't improve software development with agents. They often just chew up context and cache with extra arbitrary rules the agent needs to follow without delivering improvements.
> we have a custom .yaml spec for data pipelines in our product and the agent follows it as well as anything in the training data.
Doesn't this end up being way more expensive, because you don't pay for model parameter activations but for the tokens in/out, meaning that anything not in the training data (and therefore, the model) will cost you. I could make Opus use a new language I came up with if I wanted to and it'd do an okay job with enough information... but it'd be more expensive and wasteful than just telling it to write the same algorithms in Python, and possibly a bit more error prone. Same with frameworks and libraries.
Yeah this is just wrong.
The whole point of AI is that it can generalise to stuff outside its training set, and anyone who uses Claude on a daily basis completes tasks that have not already been completed elsewhere.
These models excel at tool use. They’re using CRMs, word processors and dozens of other systems that weren’t programmable before - lots of tools have opened MCP/API/CLI interfaces for the first time specifically to support AI, and it works.
I don’t know where this meme comes from, but we haven’t “invented the last language” and we’re not going to be frozen in 2023 for tooling, any more than the Industrial Revolution led to automation of artisan workshops rather than the invention of the modern factory system.
That's not what I'm saying. I'm saying that if you make "Django, but different" it isn't for agents.
Django, but different is not a "tool use" situation. It is a framework with a ton of conventions and libs, etc. Agents will be better able to write Django than "Django, but different". Will they work with your new libraries? Of course. They're very good at all sorts of coding tasks, and they can read docs, search the web, experiment, and correct themselves in an agentic context even absent any relevant training data. But, what may have been a one-shot with Django code, might require several tries with your new thing.
That is not an argument against making new things. I'm not make any argument against making new things, anywhere in this thread. My argument is that if you make "Django, but different", it isn't "for agents", because agents already know Django and they know your new thing considerably less. Your new thing is more work for the agent.
My comment is about being honest with yourself and others about what you're building and for whom.
Read the about page (https://plainframework.com/about/).
This Show HN post doesn't seem to be by the author and it's not presenting the project in a good way in my opinion. I also don't like the agent framing of the project home page, but after reading the about, I'm willing to tone down my criticism.
The framework seems like an interesting project to keep an eye on.
First time I've seen this pattern in the "getting started" guide for a project:
https://plainframework.com/start.mdLooks like that usually runs:
Which runs this: https://tools.simonwillison.net/zip-wheel-explorer?package=p...Hope this doesn't become a trend 'cause it can become very problematic. Lots of newbies could replicate and this can produce waste of tokens as a first issue. Also this creates additional problems, for example binding something new to a single AI vendor or tool (and also to an unpredictable model behind other than some pay subscription) is conceptually wrong.
Nothing against AI obv, but we must start to address the use and abuse of it. Some sorts of patterns in the usage, having a documentation or a readme as in this case is ugly and should be catalog under "anti-pattern".
This is just an example, in a WIP project and okays, it's not a sin.
But maybe we should start addressing, backed by big players an in big proportion by no profit foundation and academic (public and private) institutions, the problem of:
How to use AI, what kind of things is useful doing with it and what not, how to evaluate that, in what stages of things can one have space to misuse this tool and in what not.
This not much as a mandatory thing, but as a starting point for everyone approaching the use of AI as a building tool. A guideline. A market standard. So that anybody can address at moment 0 landing on a repo, if it's compliant with some standard or not. Because have in mind, as a compass, what somebody investing some effort put into this field.
Could be argued that common sense already addresses this very efficiently and that it's a matter of iteration and we all as a whole can build this common sense on ai use, but I think that having some credible org write it in a easy, accessible, verifiable, and used is a milestone toward it. And can accelerate the process with a small effort. Also can affect directly the various AI tools.
Best practices, and concept, must be shared and easy to be access by everyone, as always have been in this field.
That is perhaps the most egregiously complicated way to run "git clone" and a post-install script I've ever seen...
It looks like it's a fork of Django that just kinda changed a bunch of stuff arbitrarily?
From the readme: Plain is a fork of Django, driven by ongoing development at PullApprove — with the freedom to reimagine it for the agentic era.
I'm not very good at counting lines of code, but it seems like it's slightly less than Django. From a cursory glance the main difference I saw was that only postgres is supported, not necessarily a bad thing.
> the main difference I saw was that only postgres is supported, not necessarily a bad thing.
Then why not just delete the other files that you don't want? Why also completely change Django's API?
Very likely its being changed by an AI model, driven by human prompts.
That would be good if the changes are to slim it down by 80%.
Same thoughts as soon as I saw the code in the readme
Ignore all the hate in the comments here, anyone denying the direction of software development and it aggressively becoming agentic have their own reckonings to deal with…
I love this concept. While I’m a Rails guy myself, I appreciate the value of Django too, and an agent-optimized version of it makes sense.
I feel like the next logical steps are this exact concept but in Go / Rust to get even more performance out of everything and to also get the single deployable binary too
I've actually been vibe coding a port of Django to Rust as a fun learning experience. I didn't expect it to be possible, but I've already got the core ORM working (including makemigrations, migrate, and inspectdb) with basic admin support running.
Single file deployment, and the process seems to only use 3-4 MB of memory.
I've been able to use inspectdb on existing Django databases, and then browse and change that data using the rust admin.
I am probably not the right person to build a production ready version of this - since I am not a Rust developer - but gee I am impressed by how good it is becoming.
You're absolutely right!
1. Steal codebase of Django, and rename functions so thats hidden 2. Claim its needed for "the new AI era" 3. ? 4. Profit
Django is bsd licensed. This is bsd licensed. I fail to see the issue?
Nice. Love the idea behind this. I have been using Django for most of my vibe coded side projects just for the reasons stated in this thesis.
Django code is pretty easy to review quickly. LLMs are good at writing it.
Django is just old and bloated, so the fork is a good idea. Maybe I will use this for my next side project.
"X is just old" is a tired criticism of most things in my experience. Bloated would've sufficed, even if it's subjective.
UPDATE - should this be a Show HN? This isn't posted by the author and there are better links to share with more info about the who, what and why: https://plainframework.com/about/
From the Show HN guide/rules:
> The project must be something you've worked on personally and which you're around to discuss. See these tips about how to present your work.
Class-based views were a problem when they were introduced in Django, and they’re still a problem.
Especially for the so-called AI-ready framework. Because of indirection, you either have to go read all the basic classes, or read documentation three times over. Instead of just reading the self-contained view function itself, once.
Especially true for an agent, it will have to go read the new framework’s docs and source over and over and over…
There are very specific reasons to use Django’s class-based views, so much so that it doesn’t really strike me as “multiple ways to do one thing”.
Case 1. You are simply writing a view. Request comes from the router, you want to run some logic and return a response. Either it is part of the end project, or it is simple and small enough that the end project would prefer to just override the entire thing. Write a function!
Case 2. You are working on an end project, and you want to take a view shipped by Django or some library and override bits of its behaviour. The view is already shipped as a class, and writing it as a function would be unwieldy because there is a bunch of logic you’d need to repeat. No-brainer: just inherit and go.
Case 3. You are writing a library that is intended to be customised by the end project. You ship a view that performs a somewhat complex sequence of actions as part of handling a request (e.g., validating input, constructing a query, fetching a QuerySet, serializing it in some way). You want to give the end project an easy way to borrow your view and override only specific parts of that logic. Consider writing a class-based view, and basing it on some pre-existing class-based view if possible (the above looks a bit like ListView, for example).
In my experience, your Case 2 plays out a bit differently. "Just inherit and go" and in many cases you end up with more lines of code in total than doing the same thing in my own function with some kind of helper. Even in the dead standard thing, like displaying a list of objects with pagination. But now I don't own the flow!
Any kind of customization and I need to go jump through the hoops, I need to go look at the code what exactly happens there. But this class inherits a couple other classes, and I need to go read them as well. What for? Grug not want read seven basic multiple-inherited class just to display a list of objects.
So I disagree that it's a no-brainer. It's a no-no brainer for me.
As for writing the libraries, I have the same problems with all libraries that provide class-based API, where I need to inherit from libraries' classes to do my thing.
I like my code to be stupid and linear, to own the flow, so I can read the code and understand what happens there. Same is true for agents!
I am also willing to accept some LoC penalty for my approach. But it's shorter in practice, so win-win for me.
I was using Django since 2006 up to ~2012, and then again touched in 2014-2015. Never again.
If it’s easier to just write a function view, then sure, just write a function view. I did phrase it specifically: if you want to take stock logic and just override a specific part, then CBV is a pretty intuitive way of doing it.
My point was mostly: stick to function views by default, don’t bother devising your own class-based views in an end project, maybe do if you ship a library and have carefully thought about extension points that are ergonomical for your users, and do take advantage of a pre-existing CBV if it feels like a natural, sustainable, low-LoC solution.
For example, as a default choice, if I need to show a list of items, I would in fact just write a function view. However, once I need more features (the turning point for me is probably pagination), I’d brush up on the docs, subclass a ListView, and enjoy well-tested logic taking care of things for me. In the simplest case I’d just set class attributes without overriding any methods at all; maybe I’d take over get_context_data() to give the template some project-specific variable that doesn’t make sense in context processor. If I need something significantly more custom, I’d switch back to a plain function view and use in it pagination primitives that Django exposes. Done all of the above at different times and I think it worked pretty well.
Yes, it did come with practice and I did ship some spaghetti at first, but I also was a relative noob/junior when CBVs came out.
Fine, it is subjective, so there is more than one way of doing things here, and it is not great, but I still think CBVs have their place.
> I don't own the flow
Sir, this is a framework, we don’t own the flow. (I’m slightly jesting.)
> I like my code to be stupid and linear
I am in the same boat, but to me overriding a CBV method seems pretty stupid.
I used Django for from pre-1.0 (the latest time was in 2021 and that project is still live), been to one PyCon and contributed some really minor fix or two. While I have seen hairy Django codebases, I still think it’s a very sane and the best-documented framework.
that's so true, I still prefer function based views
It’s vibe-coded, too. Pass.
As someone who is leaning into this vibe coding thing recently, kind of interested to know the sentiment here. What was the tell? Like can you give line numbers or some reference. Feel like 100% certified organic code is a pretty high bar going forward.
1) Good luck using anything in a few years.
2) Of course it's vibe coded, it's made for vibe coders.
I've been excitedly following the development of Plain for a while now, it's so cool to see so many of the rough edges in Django get fixed in a nice comprehensive solution.
Great job Dave Gaeddert!
I'm saddened to see some of the other comments saying it's slop, he was working on this long before vibecoding became common! I think there's a lot of really good design decisions and I hope people don't write it off just because he's trying the "for agents" marketing approach lately.
I agree its very good job he is doing
Something like this has been on my mind for a while. When using LLMs for coding I believe it is a significant benefit, if the amount of lines to be reviewed by humans is as small as possible. An app, which is not much more than a configuration in a dense, custom made DSL with minimal coding to specify business logic would be the simplest artifact that a human can review quickly and an LLM can manipulate with ease (provided there's good docs / linting / errors / maybe even a finetuned model at some point).
Everything which just works "by convention" or by "opinionated defaults" (allowing a tightly coupled but very feature rich framework) helps to reduce the noise / lines that needs to be reviewed.
While this approach might not be optimal for every project, I'm certain the opinionated defaults can work for many endeavours. And the reduction of complexity might be one important aspect, which can make an "agentically engineered" project sustainable.
>Everything which just works "by convention" or by "opinionated defaults" (allowing a tightly coupled but very feature rich framework) helps to reduce the noise / lines that needs to be reviewed.
This is exactly why I've gone back to Ruby with Sinatra or Rails for my personal side projects, despite Ruby's horrid performance.
As long as you are content to remain on e.g. Rails' "Happy Path", then I've found agents do a fantastic job because there's lots of Ruby in the training set and there's less surface area where a context mismatch/hallucination can end up going off the rails. Pun only partially intended.
TLDR:
- fork of django
- it's opinionated
- typed
- comes with skills / rules / docs baked in
I'm not against this idea in principle, but I'm also not sure why that is better than what's already out there, except maybe you save some tokens by not vibe coding this yourself?
I do think in the future we'll see some novel libraries that are agent-optimized first. I'm not sure if this is it, though.
(edit: formatting)
The models are training on examples, and there are a lot of Django examples to learn from. Where is the advantage here? A surface for more potential bugs?
Its better because:
* this dev can merge what he want instead of being stopped by those evil django developers * it looks very cool on your cv * hence the function name changes and the tiny notion at the bottom that the project is "inspired" by another. Absolutely crucial!
Great take!
I think the "agents only know what's in training data" argument never made sense to me. I've watched Claude read a markdown skill file and correctly invoke a CLI it had never seen before.
The thing that actually matters is whether your interface is predictable consistent verbs, typed errors, no magic. Agents are surprisingly good at learning from docs, they're just terrible at guessing.
The real question for Plain isn't "will agents know it", it's whether the opinionated defaults actually reduce the surface area they have to reason over. Django's flexibility is kind of a nightmare for agents because there are 6 ways to do everything. If Plain picks one, that's genuinely useful.
Anyway, "designed for humans and agents" is going to be on every framework README by EOY whether it means anything or not, so might as well be the one that actually thought about it first ;P
This looks pretty neat and the anti-AI hate in here is getting pretty tiresome.
From what I can tell looking at the codebase compared to Django's, the top-level modules are structured much better and more obvious for AI to discover them. And then inside each module is a descriptive README with lots of description and examples that are helpful to an agent (and human). Not sure why this is being written off as slop or arbitrary changes, it seems pretty obvious to me this is the direction of frameworks.
Oh, I do like the format of the models. Just like how strawberry graphql does this. I suspect that model format would be a much better development UX.
You lost me at Python.
I cannot wait until all the tooling in Python that is the only reason most people use Python is trivially rewritten by LLM’s in other languages
Django desperately need competition so this is a good thing.
Interesting approach — curious how this scales under real load.
I think this has been around for a while, if it's the same thing I'm thinking of. It started out as an opinionated fork of Django, but appears to have now been rebranded to jump on the agent hype-train. Not sure if I'm in the minority, but I'm now less interested in this given its focus on agents.
So a sloppified Django spit out by Claude? Good luck with that.
How does this compare to FastAPI + SQLModel?