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

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.

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.

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.

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

That would be good if the changes are to slim it down by 80%.

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.

Very likely its being changed by an AI model, driven by human prompts.

Same thoughts as soon as I saw the code in the readme

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.

You're absolutely right!

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.

Django is bsd licensed. This is bsd licensed. I fail to see the issue?

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

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.

that's so true, I still prefer function based views

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

I agree its very good job he is doing

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

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!