DEV Community: Rohak

Dead Creativity Theory

Rohak — Thu, 23 Jul 2026 13:13:41 +0000

It's been a few months since this happened. So, I can safely talk about it without any consequences. LinkedIn News India account put up the following year-end engagement post on, well, LinkedIn: -

Tech giants investing billions. Women's cricket blazing a trail. And making our mark even in space - it's been quite the year for India. So, what will 2026 bring?

Every December, LinkedIn News spotlights bold predictions poised to define the year ahead from our editors and experts around the world.

This year's lineup features a range of ideas - from Melinda French Gates' perspective on women's healthcare to AI's impact on performance reviews and entertainment. And not to forget, the emergence of a multipolar currency system and a one-person unicorn.

What trend do you think will have the biggest impact? Join the conversation in the comments or share your own prediction in a post or video with #Bigldeas2026.

Now, following were few of the responses (Names redacted for obvious reasons; No text is altered): -

By 2026, AI will become much more than just a tool. It will be a true partner for employees and HR teams alike. 
Imagine context-aware, autonomous AI agents that can handle everything from onboarding to learning recommendations, 
freeing up HR professionals and employees to focus on creative, strategic and people centric work. 
This shift will help workplaces become more agile and personalized, with AI acting as a digital teammate that supports both individual growth and team collaboration. 
As AI becomes more intuitive and human-like, HR will play a key role in ensuring ethical use, addressing questions of bias, privacy and fairness, 
so that technology empowers people, rather than replacing them. In short, AI will help us reimagine not just how we work, but how we support and develop each other at work.

LinkedIn News India By 2026, the biggest AI shift won't be about smarter tools, but AI becoming a true work partner. 
Instead of waiting for instructions, AI will understand context, anticipate needs, 
and quietly handle complexity in the background - from planning and analysis to decision support. 
The real breakthrough will be human impact: people spending less time managing work and more time thinking, creating, and leading. 
The companies that win won't just adopt AI fastest, but use it most thoughtfully and responsibly.

The significant shift of 2026 won't just be models getting "smarter" or "faster". 
It will be about AI moving from a reactive tool you use, to a proactive partner that works alongside you. 
Here is what that shift looks like and why it changes everything.  
1. Persistent Memory and "Hyper-Context"  
2. True Cross-Application Agency  
3. Goal-Oriented Behavior  
4. Cross-App Agency  
5. Anticipatory AI

The Rise of the "Non-Human Teammate" While 2024-2025 was about AI as a "copilot" (a tool we use), 2026 will be the year AI becomes a "teammate" (an agent we delegate to). 
We will move from prompting AI for answers to assigning AI autonomous workflows. The biggest breakthrough won't be a faster model, 
but the normalization of Agentic Workflows-where AI agents negotiate with other agents to execute complex tasks like supply chain adjustments, code deployment, or scheduling without human intervention. 
Why this matters: It fundamentally changes the organizational chart. Managers in 2026 won't just manage people; they will manage "hybrid fleets" of human talent and autonomous AI agents. 
The critical skill of 2026 will be "Agent Orchestration"- knowing how to lead a team that is 50% silicon.

Every single one said the same thing. Nobody was copying each other. That's not what happened. What happened is simpler than that.

They copied the LinkedIn post into an LLM of their choice, got back three to five bullet points, cleaned up the formatting and hit post.

Their "prediction" was whatever their model generated. In response to a prompt they didn't write. About a future they didn't think about.

The Dead Internet Theory’s Cousin

The Dead Internet Theory argues that a large chunk of internet activity is already bots. Fake engagement, synthetic content, automated interaction designed to simulate a living web.

The Dead Creativity Theory, is what I dub the following phenomenon - The humans are still there. Still typing. Still posting. And you still can't tell. Not because they're bots. Because they've opted out of the part that would make them distinguishable from one.

The Excuse: Can't Nurture Creativity

Thinking is hard. Not everyone has something original to say about every topic, all the time.

Fair. But, that's not what happened. Nobody sat down, thought carefully about the next year in technology, found themselves at their wit's end. Then concluded that they had nothing original to add.

They didn't try and fall short. They didn't try. At all

The LinkedIn post was there. The LLM was one tab over. The path from post to comment took 45 seconds and 0 original thought. That wasn't a limitation. It was the laziest alternate choice.

The result was a comment section that looks like participation but contains nothing of value.

Dozens of people performing the act of having opinions without the inconvenience of forming any.

The Question: What’s Dying

Not the internet. Not intelligence. Not even creativity in some obscure sense. Just the Habit of it.

Original thought is slower. Sitting with an incomplete idea and the uncomfortable stretch between "I think something about this" and "I know what I think about this". It takes longer than a prompt-response cycle.

Think even less and the patience for it shrinks. Do it rarely enough and the instinct to try stops showing up at all.

That's my theory. Not that creativity is impossible. That, creativity is becoming the thing that people used to do before LLMs existed.

The Answer: Here's How to Revive

The real threat of LLMs isn't that they will surpass human imagination, it's that they make opting out of it so seamless.

When we outsource the messy, uncomfortable process of forming an opinion, we forfeit the very friction that makes human thought distinct.

All that just to save time and energy, while wasting litres of water and megawatts of electricity on AI tokens churning through a GPU sat in some data centre in some corner of this spherical world.

If we keep treating original thought as a chore to be automated away, we won't end up in a world ruled by superintelligent AI. We’ll just end up in a world where everyone sounds like the same prompt response on a Friday evening.

Your OS: Designed for Many, Used by One

Rohak — Tue, 05 May 2026 13:13:15 +0000

I reinstalled Windows few months ago. Three days later, I was still not done with the Settings, Control Panel, Admin account setup and Software installations.

Uninstalling unnecessary or unused stuff is the next nightmare. APPDATA (Local, LocalLow, Roaming), Program Files (Normal and x86), ProgramData, registry, random folders buried in Documents. Don't get me started on the million cache and temp/tmp directories.

Each one is a breadcrumb left behind by an app that assumed it could scatter its files wherever it pleased and you should be fine with it. I wasn't fine with it.

Revo Uninstaller and equivalent tools exists entirely because Windows can't clean up after itself. These third-party tools' entire purpose is to fix a problem that shouldn't exist. And it's still clunky: values (set/unset) mismatch between the app and the system, updating values in the app doesn't change the system settings, etc.

Linux is better, but not solved. Dotfiles and directories in ~/.config, ~/.local, ~/.cache, package conflicts between system-wide and user-wide installs. There's an ongoing argument, that's been going on for decades, about where things should live. It hasn't produced a consensus.

Same problem. Different aesthetics.

Brief History on OS Design Choices

This isn't accidental. Blame historical tech-debt.

Modern OS architecture descends from multi-user mainframe and Unix traditions where many users shared one machine. Separating user data, system data and application data made sense when the alternative was users reading each other's files.

But that's not how most personal computers are used today. My laptop has one user. Most company devices have one owner. The multi-user security model is still there, largely intact, protecting me from... myself and making sure I don't hand over the keys to the system to a bad actor due to a misclick or not reading installation permissions.

The architecture hasn't caught up with the use case.

My 3-Pointer Design Principles

This isn't an implementation proposal and I'm not writing a kernel. These are design suggestions: a set of principles I'd want an OS to follow, IF I had a say in development. These are OS-agnostic principles, applicable to Windows or Linux equally.

1. One User, One Pseudo-Sudo

A personal OS should have exactly two privilege levels:

The user: you, for everything you do day to day.
A pseudo-sudo account: for installs, system changes and anything that touches the OS itself.

The critical distinction: the pseudo-sudo account has a separate password from your sign-in password, and it has no home directory, no user data, no persistent session. It exists only to authorise privileged actions. It is not a person, it is ONLY a key.

No root with a home directory. No administrator account you accidentally leave logged in. No sudo that remembers your password for five minutes and quietly lets the next command through.

Two clear levels with a hard boundary between them.

2. App-Local Everything

Every installed application should own its own config, cache and data, stored within its own directory. Not in %APPDATA%. Not in ~/.config/appname. In the app directory itself.

The benefits are obvious once you say them out loud:

Uninstalling an app means deleting its folder. Nothing left behind.
Moving an app means moving its folder. Config comes with it.
Auditing what an app stores means looking in one place.

The default should be: your files live with you, the app's files live with the app.

3. One Global Config SEAN File

System settings: display, network, audio, locale, power, etc., should live in a single, human-readable global config file. One file, I dub as global-conf.sean.

SEAN (pronounced as "Shaun", a nod to JSON file type and Heavy Rain, the game) stands for: System Entity Attribute Notation file. Format or nomenclature is less important than the principle though.

Template global-conf.sean: -

# global-conf.sean
# System Entity Attribute Notation
# Version: 1.0.0

[system]
system-name     = my-machine
architecture    = x86_64

-> [display]
# Display nested inside system and can be called as display.resolution alternatively
resolution      = 2560x1440
refresh_rate    = 144
scaling         = 125%

-> [audio]
# alternate nesting method
output.device   = default
output.volume   = 25
input.device    = default
input.volume    = 100

--> [headphones]
# Headphones settings nestes inside audio, which in turn is, inside system

[power]
sleep.on_battery     = 15min
sleep.on_ac          = 30min
fast_boot            = false

[network]
hostname        = my-machine
dns.primary     = 1.1.1.1
dns.secondary   = 8.8.8.8
ipv6            = true
firewall.mode   = strict

[security]
screen_lock          = true
screen_lock.timeout  = 5min
encrypt_storage      = true
pseudo_sudo.timeout  = 0

This is better than settings scattered across a registry with 200,000 keys, or being split between /etc, /usr/share, and a dozen other locations, or requiring a GUI to change a setting that is, fundamentally, just a key-value pair.

One file. Version-controllable. Readable without a special tool. Transferable to a new machine without hassle.

The Benefits

If these three principles were the default, a few things become possible that currently aren't.

Reproducible setups: If your system config lives in one file and apps are self-contained, your entire OS setup becomes version-controllable. Fresh install means cloning a repo and running a script. Your global-conf.sean is your IaC.
Automated CI/CD: System changes go through a pipeline, not a manual click-through. Roll back a bad config change the same way you'd roll back a bad deploy. This exists for servers. It should exist for personal machines too.
Pre-hardened images: One can easily build and distribute a baseline image as an add-on. For e.g., a hardened Windows or a Windows-like Linux distro becomes easier to build, maintain and distribute when the architecture supports it.
True portability: New machine, same environment. No dotfile managers, backup tools or manual reinstallation. Just the file and the app folders.

Already Available Alternatives

I'm not claiming these ideas are new. I'm claiming they're not the default and they should be, at least for power users, developers or even in a singly owned system.

NixOS comes closest to my principle 3. Its declarative configuration.nix is similar to the kind of global config I'm describing. The trade-off is complexity. NixOS has a steep learning curve that makes it inaccessible to most users.
Flatpak and Snap move toward my principle 2. Containerised apps with sandboxed storage. But they layer on top of existing systems rather than replacing the underlying model, and config portability is still limited. macOS app bundles gets it right for most apps. But ~/Library still exists, still accumulates and still requires manual archaeology to clean.
ChromeOS implements principle 1 in spirit. It's a single-user OS with a simple privilege model. The trade-off is that it's also a locked-down, cloud-dependent system that trades local control for simplicity.

None of them implement all three. None of them make these principles the default, out of the box, for a general-purpose OS.

The Current Blockers

I've been arguing one side. Here's the other.

Shared state is a real problem. If every app owns its config locally, what happens when two apps need to communicate? A global config for system settings is clean, but apps interact with each other as much as the system. Some shared state is necessary or maybe a non-conventional way of thinking and implementation.
The pseudo-sudo model has edge cases. What happens with background services that always need admin access? Daemons, update managers, antivirus. These don't fit neatly into "user action requiring a one-time key". The model works for interactive installs. It gets complicated for persistent system processes. App/process level elevation can be a thing, but that opens another can of security worms.
Backwards compatibility. Any OS that wanted to implement this would be breaking decades of software assumptions. Apps expect %APPDATA% to exist. They expect to write to /etc. Path migrations are hard.

These aren't reasons not to try. They're reasons the design is harder than it looks.

Final Notes

I want to reinstall my OS and be productive in the matter of hours, not days.
I want to uninstall an app and have it actually be gone.
I want to understand what my system is doing by reading a file, not running a registry editor with seemingly random numbers treated as flag/conditional values/parameters.
Personal computers are personal. The OS should be designed like it knows that.

PS: This is a design opinion piece, not an implementation proposal. If you disagree with the trade-offs or think I've missed something, let's chat. I'd genuinely like to hear more on this.

Technical Write-up: Comparing CMS Architectures

Rohak — Fri, 01 May 2026 11:56:08 +0000

I had a question I couldn't answer from documentation alone: how different does it actually feel to build similar systems in Django vs Express.js?

Similar features and scope, but two different stacks: built in parallel so the comparison would be honest. This post is the pseudo-technical summary of what I observed.

The Project

A Blog/CMS with standard requirements: user authentication, post creation and management, media uploads, role-based access (User and Admin) and a templated frontend (nothing exotic). The kind of system where framework and architecture matter more than LAF (Look and Feel).

Component	Express.js	Django
Runtime	Node.js (JavaScript)	Python 3.13
Database	MongoDB via Mongoose	SQLite via Django ORM
Authentication	Manual JWT + cookie-parser	Django Built-in Auth
Media Handling	multer (server-side storage)	FileField / ImageField
Templating	EJS + Bootstrap 5	Django Templates + Bootstrap 5

Both implementations are in separate repositories. The goal was functional parity, not just similar features, but equivalent behaviour so the comparison would be meaningful and as fair and impartial as possible.

Both repositories are linked in the README file if you want to look at the full implementations.

Authentication: Visible Contrast

This is where the difference between the two frameworks is most visible. Not in logic flow but its implementation.

Express.js: You Own Everything

In Express, authentication doesn't exist until you build it. Here's the user model handling password hashing and login validation:

// Pre-save: salt generation and hashing
userSchema.pre("save", function (next) {
  const user = this;
  if (!user.isModified("password")) return next();

  const salt = randomBytes(64).toString();
  const passwordHash = createHmac("sha256", salt)
    .update(user.password)
    .digest("hex");

  this.salt = salt;
  this.password = passwordHash;
  next();
});

// Login: validate credentials and return token
userSchema.static("userValidatorandTokenise", async function (email, password) {
  const user = await this.findOne({ email });
  if (!user) throw new Error("User Not Found");

  const hashChk = createHmac("sha256", user.salt)
    .update(password)
    .digest("hex");

  if (hashChk !== user.password) throw new Error("Incorrect Password");

  return createUserToken(user);
});

This is before touching JWT issuance, cookie management or route protection middleware, all of which live in separate files that you have to write as well.

The upside: you understand exactly what's happening at every step.
The downside: every step is a surface area for mistakes.

Django: The Framework Handles It

The Django equivalent for user profiles is this:

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    image = models.ImageField(default="default.jpg", upload_to="profile_pics")

    def __str__(self):
        return f"{self.user.username}'s Profile"

    def save(self, *args, **kwargs):
        super().save(*args, **kwargs)
        img = Image.open(self.image.path)
        if img.height > 480 or img.width > 480:
            op_size = (480, 480)
            img.thumbnail(op_size)
            img.save(self.image.path)

The Profile model handles the custom parts: profile photo with auto-resizing.

Password hashing, session management, login/logout views, CSRF protection, the admin interface, all of that comes from django.contrib.auth, which you import in one line.

The upside: The entire custom auth logic is roughly zero lines in Django.
The downside: Sometimes it may feel rigid to the 'tinkerers'.

Data Modelling: Flexibility vs. Integrity

MongoDB with Mongoose gave you schema flexibility and document structure could evolve without migrations. For a project where post metadata might change frequently, that's an advantage.

Django's ORM enforced relational integrity from the start. Every schema change goes through a migration. That may seem like a time-loss during development, but it is this friction that prevents bugs where your data structure and application logic drift apart.

Neither is universally better.

The answer: if your data structure is uncertain, MongoDB's flexibility is worth having.
If your data structure is known upfront, Django's migrations give you a paper trail and consistency guarantees that are hard to replicate manually.

Developer Velocity: Whatcha Ya Building

Django won on features that map directly to what the framework provides out-of-the-box. The admin interface appears in about 10 lines of configuration. User management, permissions, CRUD scaffolding, placeholder/fake data, all faster.
Express.js won on understanding. Building the middleware pipeline manually meant you could debug it precisely, extend it without fighting the framework and understand exactly what each request was doing at every point in its lifecycle.

The pattern I noticed: Django is faster when the framework has already solved your problem. Express is faster when it hasn't, because you're not working around someone else's abstractions.

Security Posture

This is where I'd push back against the framing that custom implementations are inherently more flexible or powerful.

Django's session management, CSRF protection and password hashing are production-hardened defaults. They're not configurable because the correct configuration is already in place.
Express implementation requires you to make explicit decisions about salt length, hash algorithm, cookie configuration and token expiry. I feel like I made reasonable choices, but they were my choices, made at implementation time and they're only as good as my knowledge at that moment.

For security-sensitive logic specifically, "batteries included" maybe is better if you're not deep in security engineering. If you know what you're doing and aren't bothered by time constraints, you can try custom auth.

Takeaway: Stop thinking about food

Building both taught me something the documentation doesn't say directly: the choice between Express.js vs Django isn't just about JavaScript vs Python. It's about how much of the stack you want to own. Apart from that, if you're a working professional, you also have to take into consideration, the leadership and the existing tech that might give you nightmares during integration testing if you chose incompatible stack.

Express is like an empty house with just walls where you can design your interior while Django is like moving into a fully furnished house.

On the reference projects, both implementations were built with reference to these two tutorial series:

The implementations follow both references closely with minor tweaks. Comments functionality was intentionally excluded from both to keep the scope focused on the architectural comparison rather than feature completeness.

What's worth noting: the tutorials reflect their frameworks' philosophies as much as the frameworks themselves do. Corey's series is methodical and production-minded, it teaches you Django the way Django wants to be used. Piyush's series is fast and mechanical, it prioritises understanding what's actually happening under the hood over getting to a finished product quickly. The code difference and the teaching difference point in the same direction.