Your question is actually pointing at the most interesting unsolved problem in the project. A grievance resolution arc — where the .md file itself gets rewritten mid-simulation as the agent "processes" something — would make long sessions feel genuinely different from short ones. It's on the roadmap but I haven't built it yet.

The risk is it could make agents feel too therapeutic. Real people carry grievances for years. Not sure the right answer yet.

On emergent behavior: in practice, tension tends to escalate then plateau rather than resolve. Agents don't "make up" — they find a cold equilibrium. I've watched scenes run for 40+ turns where two agents just stop addressing each other entirely, which felt more realistic than a forced resolution.

The atmosphere bars (tension/warmth/noise) were my attempt to surface that arc visually without interrupting the scene.

Took me a while to realise I could actually build that.

The interesting technical challenge was making agents feel genuinely distinct rather than variations of the same helpful AI voice. The solution was grounding each agent in real behavioral research pulled at world-creation time, storing their full identity in a plain markdown file, and giving them a specific grievance — something eating at them before the scene even starts.

Happy to answer questions about the agent prompting approach, the parallel asyncio loop, or anything else. Built from Malawi on zero budget using free API tiers.

Comments URL: https://news.ycombinator.com/item?id=47420182

Points: 3

# Comments: 4

I'm a self-taught developer from Malawi, and I built DJX because I was tired of writing the same Django boilerplate over and over.

Django is powerful, but starting a new feature means manually creating models, views, templates, URLs, and wiring everything together. Rails solved this 20 years ago with scaffolding. Django deserves the same.

DJX brings convention over configuration to Django:

    pip install djx-cli                                                                                            
    djx new myblog && cd myblog                                                                                    
    djx scaffold Post title:string content:text published:boolean                                                  
    python manage.py migrate && python manage.py runserver                                                         
    # → http://127.0.0.1:8000/posts/ — full CRUD. Done.                                                            
                                                                                                                   

Other commands: - `djx routes` — see all URL routes (Django doesn't have this built-in) - `djx destroy scaffold Post` — clean removal of generated code - `djx add django-crispy-forms` — install and auto-add to INSTALLED_APPS - `djx model`, `djx controller` — generate pieces individually

It follows Rails conventions: pluralized app names, RESTful URLs, automatic timestamps, and sensible defaults.

I built this because I wanted Django development to feel as fast as Rails. It's early stage, but it's already saving me hours on every project.

PyPI: https://pypi.org/project/djx-cli/ GitHub: https://github.com/RedsonNgwira/djx-cli

Would love your feedback and contributions. What other Rails-like features would make Django development faster?

Comments URL: https://news.ycombinator.com/item?id=47368925

Points: 5

# Comments: 2