6 ms·

Show HN: Plain – The full-stack Python framework designed for humans and agents

97 points by focom 6mo ago

petcat 6mo ago
It looks like it's a fork of Django that just kinda changed a bunch of stuff arbitrarily?
- pbreit 6mo ago
  That would be good if the changes are to slim it down by 80%.
- vb-8448 6mo ago
  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.
- giancarlostoro 6mo ago
  Very likely its being changed by an AI model, driven by human prompts.
- Gooblebrai 6mo ago
  Same thoughts as soon as I saw the code in the readme
- dirkc 6mo ago
  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.
  - petcat 6mo ago
    > 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?
jacktheturtle 6mo ago
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.
- WesleyJohnson 6mo ago
  "X is just old" is a tired criticism of most things in my experience. Bloated would've sufficed, even if it's subjective.
jaredcwhite 6mo ago
So a sloppified Django spit out by Claude? Good luck with that.
durovilla 6mo ago
How does this compare to FastAPI + SQLModel?
deafpolygon 6mo ago
It’s vibe-coded, too. Pass.
- james-clef 6mo ago
  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.
- rolymath 6mo ago
  1) Good luck using anything in a few years. 2) Of course it's vibe coded, it's made for vibe coders.
donfuzius 6mo ago
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.
- stackghost 6mo ago
  >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.
awongh 6mo ago
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)
- slashdave 6mo ago
  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?
- mg794613 6mo ago
  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!
SwellJoe 6mo ago
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.
- mritchie712 6mo ago
  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.
  - SwellJoe 6mo ago
    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.
trevor-e 6mo ago
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.
nikisweeting 6mo ago
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.
- focom 6mo ago
  I agree its very good job he is doing
amanzi 6mo ago
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.
simonw 6mo ago
First time I've seen this pattern in the "getting started" guide for a project: claude "$(curl -sSf https://plainframework.com/start.md)" https://plainframework.com/start.md https://plainframework.com/start.md Looks like that usually runs: uvx plain-start . Which runs this: https://tools.simonwillison.net/zip-wheel-explorer?package=plain-start#plain/start/cli.py https://tools.simonwillison.net/zip-wheel-explorer?package=p...
- havaianaslife 6mo ago
  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.
- gavinray 6mo ago
  That is perhaps the most egregiously complicated way to run "git clone" and a post-install script I've ever seen...
dchuk 6mo ago
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
- andyfilms1 6mo ago
  You're absolutely right!
- Humphrey 6mo ago
  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.
pmarreck 6mo ago
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
decancode 6mo ago
[dead]
Humphrey 6mo ago
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.
murkt 6mo ago
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…
- drchaim 6mo ago
  that's so true, I still prefer function based views
- strogonoff 6mo ago
  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).
  - murkt 6mo ago
    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.
Clo_Claw 6mo ago
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
- R00mi 6mo ago
  [dead]
mg794613 6mo ago
1. Steal codebase of Django, and rename functions so thats hidden 2. Claim its needed for "the new AI era" 3. ? 4. Profit
- kennywinker 6mo ago
  Django is bsd licensed. This is bsd licensed. I fail to see the issue?
ardline 6mo ago
Interesting approach — curious how this scales under real load.
dirkc 6mo ago
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/ 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.
pievalentin 6mo ago
Django desperately need competition so this is a good thing.
deleted 6mo ago
[deleted]

97 points by focom 6mo ago

petcat 6mo ago

It looks like it's a fork of Django that just kinda changed a bunch of stuff arbitrarily?

pbreit 6mo ago
That would be good if the changes are to slim it down by 80%.
vb-8448 6mo ago
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.
giancarlostoro 6mo ago
Very likely its being changed by an AI model, driven by human prompts.
Gooblebrai 6mo ago
Same thoughts as soon as I saw the code in the readme
dirkc 6mo ago
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.
- petcat 6mo ago
  > 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?

jacktheturtle 6mo ago

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.

WesleyJohnson 6mo ago
"X is just old" is a tired criticism of most things in my experience. Bloated would've sufficed, even if it's subjective.

jaredcwhite 6mo ago

So a sloppified Django spit out by Claude? Good luck with that.

durovilla 6mo ago

How does this compare to FastAPI + SQLModel?

deafpolygon 6mo ago

It’s vibe-coded, too. Pass.

james-clef 6mo ago
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.
rolymath 6mo ago
1) Good luck using anything in a few years. 2) Of course it's vibe coded, it's made for vibe coders.

donfuzius 6mo ago

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.

stackghost 6mo ago
>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.

awongh 6mo ago

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)

slashdave 6mo ago
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?
mg794613 6mo ago
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!

SwellJoe 6mo ago

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.

mritchie712 6mo ago
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.
- SwellJoe 6mo ago
  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.

trevor-e 6mo ago

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.

nikisweeting 6mo ago

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.

focom 6mo ago
I agree its very good job he is doing

amanzi 6mo ago

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.

simonw 6mo ago

First time I've seen this pattern in the "getting started" guide for a project: claude "$(curl -sSf https://plainframework.com/start.md)" https://plainframework.com/start.md https://plainframework.com/start.md Looks like that usually runs: uvx plain-start . Which runs this: https://tools.simonwillison.net/zip-wheel-explorer?package=plain-start#plain/start/cli.py https://tools.simonwillison.net/zip-wheel-explorer?package=p...

havaianaslife 6mo ago
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.
gavinray 6mo ago
That is perhaps the most egregiously complicated way to run "git clone" and a post-install script I've ever seen...

dchuk 6mo ago

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

andyfilms1 6mo ago
You're absolutely right!
Humphrey 6mo ago
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.

pmarreck 6mo ago

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

decancode 6mo ago

[dead]

Humphrey 6mo ago

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.

murkt 6mo ago

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…

drchaim 6mo ago
that's so true, I still prefer function based views
strogonoff 6mo ago
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).
- murkt 6mo ago
  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.

Clo_Claw 6mo ago

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

R00mi 6mo ago
[dead]

mg794613 6mo ago

1. Steal codebase of Django, and rename functions so thats hidden 2. Claim its needed for "the new AI era" 3. ? 4. Profit

kennywinker 6mo ago
Django is bsd licensed. This is bsd licensed. I fail to see the issue?

ardline 6mo ago

Interesting approach — curious how this scales under real load.

dirkc 6mo ago

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/ 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.

pievalentin 6mo ago

Django desperately need competition so this is a good thing.

deleted 6mo ago

[deleted]