š From Chickens to Code
A few weeks ago, I presented a very real problem:
chickens were being unnecessarily sacrificed in the process of applying code transformations.
Fortunately, after a long and exhausting legal battle, they secured a brand new coop.
DEX artifacts, however, were not so lucky.
They still had no home.
Before Dennis, code refactoring and patch delivery lived in a strange place ā
critical, yet obscure. Necessary, yet often chaotic.
Scripts were written.
Commands were executed.
Changes happened.
And thenā¦ they disappeared.
Then came DEX.
A deterministic transformation artifact:
inspectable, transparent, reversible.
For the first time, transformations could be treated as something real ā
something you could hold, examine, verify.
Not just something you ran.
But watching the chickens win their case raised an uncomfortable question:
If chickens could get a homeā¦
why couldnāt transformations?
So I built one.
A place where DEX artifacts can live, be shared, inspected, downloaded, and trusted.
A place where transformations donāt vanish after execution.
A place where they become part of a system.
š„ Behold: Dennis The Forge
Behold Dennis The Forge.
A repository where DEX artifacts can finally live.
A place where users can upload, store, share, and inspect transformations ā
as long as they are marked public.
This is the first prototype.
It is not complete.
It is not polished.
And it is definitely missing a few important pieces ā
a proper UI diff, online editing, and other goodies that are already on the horizon.
But the foundation is there.
In The Forge, users can organize their work into Workspaces,
group related efforts into Projects,
and attach individual DEX artifacts to each of them.
Today, this structure is simple.
Tomorrow, it evolves.
Users will be able to invite collaborators ā
individuals, or entire organizations ā
and transformations will stop being a solitary act.
Because thatās the real shift:
Transformations are no longer just something you execute.
They become something you share,
something you review,
something you can trust.
The Forge is already usable.
You can explore it.
You can upload artifacts.
You can see how this idea behaves in the real world.
And yes ā it will change.
It will evolve.
It will probably break a few times along the way.
But thatās part of the point.
š§© What the Hex is a DEX?
But if you are still wondering:
āWhat the hex is a DEX?ā
I invite you to read the article with the same name.
Hereās the short version.
A DEX artifact represents a transformation.
It could be a code refactoring patch, a string translation,
or anything that modifies source code at its deepest levels.
But itās not just the change.
Itās a radiography of the change:
what will happen
where it will happen
how it will happen
and, most importantly - why
Traceability has always been a problem.
Changes happen.
Context disappears.
And eventually, nobody remembers who did what ā or why.
DEX changes that.
Each artifact carries its own lineage.
Every transformation can be traced, step by step,
back to the very first artifact in the chain.
And if something goes wrong?
You donāt guess.
You donāt patch over the patch.
You simply revert the transformation ā cleanly, in one step.
This means that any change can be:
inspected
signed
approved
and only then applied
In that sense, it may feel a bit like Git.
But while Git tracks filesā¦
DEX tracks intent.
š How to Start Using The Forge
If you want to try it out, you can already do so:
š Project homepage: https://www.dennis-forge.com/
š Forge (SaaS): https://www.dennis-forge.com/repo/
Basic flow:
Register (or enter as guest)
Create a Workspace
Create a Project
Upload a DEX artifact
Assign DEX artifact to project
Explore, inspect, and share
Thatās it.
No magic. No hidden steps.
Just transformations becoming visible.
š§ Why This Matters
DEX is, at its core, a form of quality assurance.
Not after the fact.
Not as an afterthought.
But embedded directly into the transformation itself.
It ensures:
traceability
reproducibility
and responsibility
Now imagine a different workflow.
Instead of shipping a simple link to a Git repositoryā¦
you could ship the story of the change.
A complete, inspectable narrative of what happened,
why it happened,
and how it will affect the system.
Not just code.
Intent.
DEX is not trying to replace Git.
They solve different problems.
DEX operates alongside your Git project, optionally integrating into your workflow, and focusing only on the transformations that matterāwithout getting in your way.
When used inside a Git repository, Dennis can even reuse your existing .gitignore rules to filter out irrelevant files.
But it does not depend on Git.
DEX can operate in environments where version control is absent ā or simply not allowed ā while preserving the same guarantees of traceability and reproducibility.
Together, they turn delivery into something cleaner,
more transparent,
and far less mysterious.
š Current Scope (and What Comes Next)
Right now, Dennis is implemented in Python, and the available transformation engine is focused on Python projects.
But thatās not a limitation ā itās the starting point.
The system is designed to be extensible.
Support for other ecosystems ā React, Java, C/C++, PHP, HTML/XML, Go, and more ā will come through dedicated plugins that follow the same deterministic principles.
Today, there is one plugin. Tomorrow, there will be many.
Because the goal is not to solve transformations for one language.
It is to define a model that can work across all of them.
And The Forge?
Itās where those stories begin to live.
For the first time, transformations stop being ephemeral.
Now the DEX has its own coop.
Top comments (1)
Curious to hear how people would use DEX in their workflows.
Refactors? Migrations? Something else? Any feedback will be welcome.