The 2026 Dev Environment Tour

This is less a tour of a finished environment than a tour of the direction everything is moving.

The last two years have been a long lesson in what actually matters. Not what looks impressive in a diagram. Not what makes a good tweet. What survives daily use, weekend debugging, hardware limits, model churn, and the slow discovery that every prototype eventually has to become something maintainable.

The conclusion is simple enough:

we need to rebuild the underlying model and data stack properly.

The Workstation: Kubuntu 26.04

On the workstation side, Kubuntu has become the easy choice.

I am using Kubuntu 26.04 because it gives me most of what I liked about Windows from a usability standpoint without the constant sense that the operating system is trying to sell me something, monitor me, or steer me back into somebody else's cloud product.

That matters more than people think.

A development workstation should get out of the way. Kubuntu does. KDE is familiar enough that the desktop feels easy, but Linux gives me the terminal-first workflow I need for servers, containers, model experiments, and agent tooling.

OS:         Kubuntu 26.04
Desktop:    KDE Plasma
Editor:     VS Code + terminal tools
Terminal:   tmux sessions, SSH, scripts, Hermes workflows
Use case:   development, testing, model experiments, infrastructure work

I still use graphical tools when they make sense. I am not trying to turn the workstation into a purity test. But the more of Sorren.ai moves toward Linux servers and local AI infrastructure, the more valuable it is for the daily workstation to feel close to that environment.

Windows was comfortable.

Kubuntu is comfortable without fighting me.

The Old Stack: Windows on Hyper-V

I should stop calling the old stack a Dell stack.

The better description is the old Windows stack hosted on Hyper-V.

That environment had a role. We used it for shares, code handling, and general lab infrastructure. It was not where the model-development work really happened. It was not the center of AI experimentation. It was useful infrastructure from an earlier phase.

Since then, the Proxmox-hosted stack has proven itself.

The reliability has been excellent. The management model fits the way I work now. VMs and containers are easier to reason about. Rebuilds are cleaner. Services feel less like one-off machines and more like pieces of an actual platform.

So the old Windows/Hyper-V stack has become obsolete for where Sorren.ai is going.

Not useless historically. Just no longer the center.

The Proxmox Direction

The Proxmox stack is where the serious backend work belongs now.

The current rebuild is not just about moving services from one box to another. It is about cleaning up the underlying assumptions:

• what data is relational
• what data is vectorized
• what runs locally
• what should go through APIs
• what should be shared between Companion, Tutor, and Writer
• what needs to be isolated per user
• what should be observable and recoverable

The early prototypes answered product questions. Could memory help? Could retrieval improve responses? Could companions feel more grounded if recent messages and older summaries were both present?

Now the question is different.

How do we build the version that can survive real use?

The Data Rebuild: PostgreSQL and Qdrant

The data direction is clear now.

PostgreSQL for relational data.

Qdrant for the vector database store.

The prototype era used lighter tools because speed mattered. That was the right call then. SQLite and ChromaDB let us test quickly, rerun experiments, inspect failures, and figure out whether the memory system was even worth building.

But the next stage needs a cleaner split.

PostgreSQL should own the structured world:

• users
• projects
• sessions
• messages
• summaries
• permissions
• audit trails
• application state
• course records
• writing-universe records

Qdrant should own vector retrieval:

• memory chunks
• semantic search
• summary embeddings
• course-material retrieval
• companion recollections
• writer universe facts
• story/world consistency lookups

That split makes sense. Relational data belongs in a relational database. Vector search belongs in a vector store.

The important part is that this should become shared infrastructure between the three major sites:

• companion.sorren.ai
• tutor.sorren.ai
• writer.sorren.ai

Companion needs user-specific memory and relationship continuity. Tutor needs student progress, course context, and retrieval. Writer needs universes, facts, timelines, characters, events, and plot consistency.

Those sound like different products, but underneath them they all need the same thing: structured facts plus semantic retrieval.

Writer as a Memory System

Writer is the one I keep thinking about.

On the surface, it is a tool for helping someone write a complex book or novel series. Create a universe, track characters, store facts, maintain timelines, catch contradictions, and retrieve relevant context while drafting.

That is already useful.

But there is another layer to it. An author's universe is basically a structured world model. It contains facts, relationships, causality, history, locations, and rules. That starts to rhyme with what an AI companion needs as it learns more about a user and the world around that user.

A novel universe and a companion's memory are not the same thing.

But both are attempts to keep a world consistent.

That is why the PostgreSQL/Qdrant rebuild matters. If we build the storage and retrieval layer well, it becomes useful across all three products instead of being three separate piles of special-case code.

Agent Orchestration: Mostly Hermes

The agent stack has simplified in one sense and gotten more serious in another.

We are using mostly Hermes for orchestration now.

Other tools still have uses. I have tested and occasionally used coding agents from different labs. Some are good at narrow implementation. Some are good at review. Some are useful for one-off experiments.

But Hermes is the part that fits the way I actually work: persistent context, scheduled jobs, delegation, memory, Discord delivery, project-specific workflows, and the ability to tie multiple tools into a coherent loop.

That matters more than any one model.

After watching the government shut down or restrict access to models like Fable 5 and GPT 5.6, I am also less comfortable betting the workflow on western closed-model availability. I do not like building on foundations that can disappear because of policy panic.

At this point, I feel better about the Chinese open-weight and API ecosystem for a lot of the work.

GLM 5.2 and DeepSeek V4 are doing a lot through Hermes.

They are not perfect. Nothing is. But they are practical, capable, and aligned with the direction I care about: more control, more local options, and a path toward systems we can shape instead of merely rent.

The Model Layer Now

The model notes in this article needed updating because the field moved again.

That is the annoying thing about writing infrastructure posts in AI. If you blink, the model names are stale.

Right now, DeepSeek-V4-Pro and GLM 5.2 are stealing the show for us.

DeepSeek-V4-Pro is especially interesting because we have it running locally. It is slower than I would ideally want, but it runs, and that changes the conversation. A slower local model is not automatically worse than a faster remote model if the workload can tolerate latency and the control/privacy benefits are real.

The place I am watching closely is the subconscious process.

Companion depends heavily on the quality of summaries and memory records. The daily review process takes interactions, extracts what mattered, summarizes events, and feeds those memories back into RAG later. If those summaries are shallow, the future conversation is weaker. If those summaries capture the right context, the companion feels more grounded.

So the test is not just, "Can DeepSeek-V4-Pro answer questions?"

The test is:

can a stronger local model produce noticeably better memory quality?

Can it summarize daily events and interactions with enough nuance that the RAG layer improves?

Can we detect a difference in the recollections that get retrieved later?

That is the kind of workload where slower local inference might be acceptable. The subconscious process does not always need to be instant. If a deeper nightly or background pass gives better memory, that may be worth the time.

We are testing that now.

What We Are Not Doing Yet

We are still not pretending the LoRA future is here.

The direction remains attractive: a strong local base model, later adapted for Companion, Tutor, or subject-specific teaching behavior. But we need better hardware and a revenue stream that justifies the spend before we can treat that as real infrastructure.

The first struggle is to use the technology we can afford to build something valuable enough to pay for the next stage.

That is the real environment tour.

Not a perfect rack. Not infinite GPUs. Not every model running locally at ideal speed.

A practical stack that can produce revenue, improve memory quality, and make the next hardware purchase make sense.

Where This Leaves Us

The 2026 environment is a transition point.

Kubuntu 26.04 on the workstation because it is easy, stable, and not constantly trying to monetize my attention.

Proxmox because the hosted stack has been reliable.

PostgreSQL and Qdrant because the data layer needs to grow up.

Hermes because agent orchestration needs continuity, not just clever one-shot prompts.

GLM 5.2 and DeepSeek-V4-Pro because the model layer is shifting toward tools we can actually build around.

The stack is not finished.

But the direction is finally clear.