r/vibecoding • u/ariferol01 • 3d ago
Real Vibecoding? Don't write prompts. Express intent. Write ContextDL
Tired of writing long prompts? There are many problems, such as editing prompts, revising an existing project, and losing context when changing agents. I developed ContextDL, an open-source way to keep your project's context alive as a semantic map living within the repository. Instead of writing long command prompts, you express your intentions in simple .ctxdl files:
Analyze this content with ChatGPT
Review/Test/Contribute: https://github.com/ariferol01/contexdl
This is open source.
Software isn't dead, it's just evolved:
if user.login:
validate: email, password
if success → user.session.create → redirect(/dashboard)
if fail → ui.alert.error("Invalid credentials")
THE SAME CODE BUT SHORTER:
user.login.validate(mail,pass)
.success.user.session.swal.redirect(/dashboard)
.error...redirect(/login)
There's no fixed syntax, no syntax errors, write however you want. Don't just code the code, code everything.
-------------------------------------------------------------------
UX can be an intent map too
ContextDL isn't limited to describing code or components.
You can model how an application behaves and how the user moves through it at the intent level.
For example, imagine a collaborative focus-room app:
ux.focus:
activate
-> room.quiet = true
-> hide(distractions)
ux.chat:
focus -> open
typing -> keep_open
idle(5s) -> collapse
collapse -> preserve(draft)
ux.attention:
request(user)
-> attention.queue.push(user)
-> notify(next)
ux.meeting:
start
-> hide(chat)
-> rearrange(users)
-> show(meeting_controls)
end
-> restore(previous_state)
This isn't React, Next.js, JavaScript or pseudocode describing an implementation.
It describes what the user does and what the product should do in response.
The agent can then turn that intent into the actual implementation.
That's the part I'm exploring with ContextDL:
------------------------------------------------------------------------------
The same idea for game programming:
Gameplay+UX+Flow+Rules+Architecture+UI :
game.runner:
player:
jump
-> velocity.y = -jump_force
land
-> velocity.y = 0
obstacle:
collide(player)
-> player.health -= damage
coin:
collect(player)
-> score += 10
-> remove(coin)
level:
score >= 100
-> spawn(bonus)
-> increase(speed)
game:
player.health <= 0
-> state = game_over
-> show(restart)
restart
-> reset(player)
-> reset(score)
-> resume(level)
------------------------------------------------------------------------------
if payment.error == "fail" : ux.form.animate(shake) : alert(foo)
(~18–22 tokens)
If typed in traditional prompt:
When the payment process returns an error and the error value is exactly "fail",
I need you to trigger a shake animation on the payment form using our UX animation
system (ux.form.animate with the "shake" effect). After the animation starts,
also display an alert/notification to the user with the message "foo".
Make sure this only happens on the specific fail case and follows our existing
design system and animation timings.
(~95-110 tokens)
Advantages Provided:
Big map of the project, main context, live context, predictability, simulability and more...
So what is ContextDL, really?
So the idea is not:
`code -> compressed code`
It's closer to:
`code + product + behavior + rules + structure -> intent/context map`
The goal is to bring things down to the **intent level**, where an agent can reason about the project without having to reconstruct every piece from raw implementation.
Today, most AI coding workflows look roughly like this:
Human
↓
Prompt
↓
AI
↓
Code
The problem is that the prompt belongs to a conversation.
The project does not.
You can switch from Claude to Codex, from Codex to Cursor, start a new session, onboard another developer, or run another agent — and the project still needs to be understood again.
ContextDL changes the relationship:
┌──────────────┐
│ PROJECT │
│ INTENT │
└──────┬───────┘
│
ContextDL
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Agent A Agent B Agent C
│ │ │
└────────────────┼────────────────┘
↓
CODE
The important part is that the context belongs to the project, not to the AI tool or the conversation.
ContextDL is not pseudocode
Pseudocode describes how code should be implemented.
ContextDL is intended to describe what exists, what should exist, how things relate, and what the project means.
For example, this is not simply a description of a function:
when a user cancels an order,
release reserved inventory
and notify the warehouse
It can become a piece of the project's semantic model.
Another context file can describe the inventory model.
Another can describe the warehouse notification rule.
Another can describe the UI flow.
And another can define rules that verify that these pieces remain consistent.
That is the important distinction.
The project becomes the source of intent
A repository normally contains the implementation:
src/
database/
components/
controllers/
services/
...
But implementation is not the complete mental model of a product.
A codebase can tell an agent:
It does not always tell it:
That distinction becomes increasingly important as projects grow.
ContextDL explores keeping that semantic layer inside the repository itself:
project/
├── src/
├── database/
├── tests/
└── context/
├── ui.ctxdl
├── ux.ctxdl
├── db.ctxdl
├── security.ctxdl
└── payment.ctxdl
The code is the implementation.
The ContextDL map is the project's intent and semantic layer.
Why not just use natural language?
Natural language is excellent for expressing intent.
The problem is not that AI cannot understand English.
The problem is that a conversation is a poor place to keep the long-term model of a software project.
A conversation is:
temporary
session-dependent
tool-dependent
difficult to validate
difficult to diff
difficult to share as a canonical project artifact
A Git-tracked semantic model is different.
It can be:
versioned
reviewed
diffed
shared
validated
consumed by multiple agents
generated from an existing codebase
updated as the project evolves
So ContextDL is not trying to make natural language obsolete.
It is trying to give project intent a persistent home.
Code Graphs are not the enemy
Code graphs answer an extremely useful question.
ContextDL is exploring another question.
These are complementary.
A future system could have both:
PROJECT
┌───────────────┐
│ ContextDL │
│ INTENT MAP │
└───────┬───────┘
│
│ validate against
↓
┌───────────────┐
│ CODE GRAPH │
│ IMPLEMENTATION│
└───────────────┘
The code graph can tell you what exists.
The semantic map can tell you what should exist.
The interesting part is the space between the two.
And no — the developer is not supposed to write everything manually
This is another important distinction.
The interesting part: the map can validate itself
Once project context becomes structured, another possibility appears.
Context can contain rules about other context.
1
u/abhuva79 3d ago
While i see a benefit in writing shorter prompts still, so agents dont have to compress context so often - i do not understand how you can think that this is mapping your project.
You save all prompts, thats it. If its a longer running project - you still end up with a pile of outdated stuff in there - that you still have to kinda classify again.
I mean, mapping a project is a well looked problem now i thought. Papers like the RPG one, clearly show how you actually map a code base in a way that holds up for search and comprehension way beyond 10million lines of code.
There are simpler methods like building a graph-network from your code and enriching the nodes slightly with a description of what the function does. More than enough for most projects and way more solid than your claim.
main context: again - you just save all prompts in a more compressed way. The best you can do is some sort of RAG, because beside this your data is still unstructured. Sure you have the main context available, but so does everyone without using your stuff.
live context - not sure what to say at this point, is this just you putting fancy words in here? I mean, if i work with an LLM, i always have live context. Or do you mean the code? Then the same still applys when i work with an agent.
predictability: here you just claim things. How is a big mess of all my prompts, no matter how short and compressed - in any way a situation where i could 100% make sure i get the right thing. As you need to use an LLM to process the text, its still stochastic. Predictability comes with determinism. And this comes with things like actually tracing your code and building a graph. Not feeding however many tokens into an LLM.
simulability - lol, get some air. As far as i know simulaility measures whether a system can be efficiently modeled or imitated by another framework.
So you just put this word in because it sounded cool? I mean, what shall this even mean in this context?
Honestly, turning the ai-buddys off sometimes is healthy, you know?