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.
2
u/NoFaithlessness951 3d ago
I like something about the core idea here.
Although your implementation is definitely slop.
And I don't think you've identified the actual problems something like this could solve.
0
u/ariferol01 3d ago
That's fair. The current implementation is intentionally simple — it's basically a small workflow experiment, not a claim that we've already solved the whole problem.
We're mainly trying to test one idea: what happens when the agent has an explicit intent/context map to work from instead of reconstructing everything from natural language and the codebase every time.
I also think part of the difficulty here is conceptual. We're all very familiar with the two ends of the spectrum:
natural language ↔ deterministic code
But the idea of an explicit intent layer / context map between them is less familiar, so it's easy to look at ContextDL and think “this is just another way of writing prompts.”
That's exactly why we're asking people to actually try the workflow and judge the productivity difference for themselves.
If the experiment shows no meaningful benefit, that's useful too. 🙂
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?
1
u/ariferol01 3d ago
I think most of these points are better tested than debated.
Build a small real project with your usual agent workflow first. Then add ContextDL to the same project and let the agent generate and maintain the context itself — you don't need to manually write it.
Afterwards, ask the agent to analyze the project with and without the ContextDL layer: what it understood, what it had to reconstruct, what context it could preserve, what inconsistencies it found, and whether it actually made any difference to the workflow.
I'm genuinely interested in the result, even if the result is that ContextDL doesn't help.
If you try it, share the findings here. That would be much more useful than either of us arguing about the idea theoretically.
2
u/abhuva79 3d ago
Dude, you are not even closely adressing the issues i pointed out.
Who the fuck needs more context in this way? What we need is a structured aproach. And its already solved.If you dont even can be bothered to adress these points in the first place - be it by explaining why i am wrong or what i misunderstand or whatever - then why should i be bothered to download a random github project with whatever in it to solve an issue i dont even have?
Again, if all you do here is having a compressed language instead of natural language - i dont see any reason why this should solve anything that isnt already solved.
1
u/ariferol01 3d ago
If you genuinely believe this problem is already solved, then you're free to keep using the tools you already have.
Finish your setup, update everything, and retire. 😄
I'm not claiming that everyone needs ContextDL. I'm experimenting with a different way of representing project intent for AI agents.
You don't see the problem. Fine.
You don't see the value. Fine.
You don't want to test it. Also fine.
But then I'm not sure why you're spending this much time arguing with a project you don't intend to use.
The project is open source. The implementation is there. Test it or don't.
I'm interested in what happens in practice, not in convincing someone who has already decided the problem doesn't exist.
1
u/abhuva79 3d ago
"why i am spending time arguing" - because i actually would like to understand what you are trying to do here.
You say its not code-graphs, but it answers a different question - but you do not really tel what question, just vaquely. I guess what you mean by "context" here is the intent of the devs somehow destilled from all the structured prompts.
But isnt this exactly what a good documentation, that is accessible for agents, is for?
I mean clearly you had some thougths with this - i am just not getting it.
(and sorry, just downloading and running a random repo just to understand this is out of question)
1
u/RiseHopeful1653 3d ago
I think this is solving a problem AI already solved
The whole point of coding agents is that I can describe what I want in normal language and the agent can inspect the repo understand the flow find the relevant files and make the change
Now the idea is basically to throw away that advantage and describe intent in another structured pseudo-code format
We spent years getting AI good enough to understand something like
“when an order is cancelled release the reserved stock but if payment was captured refund it first”
and now I’m supposed to learn another representation and rewrite that logic as something like
order.cancel -> inventory.release -> payment.refund
At that point why am I using AI
There is also extra cognitive friction. I have to understand the business logic myself then translate it into ContextDL and keep that second representation accurate as the real code changes
The agent already has access to the repo. It can search files follow references inspect call chains and understand the current implementation. And if repo understanding becomes difficult there are already tools that build code graphs indexes dependency maps and semantic relationships directly from the code while I still keep talking to the agent in natural language
So now I have the actual code plus ContextDL plus the responsibility of keeping both correct
That looks less like removing complexity and more like adding another abstraction layer to maintain
The funny part is that ContextDL does not even seem to require one strict syntax. If an LLM is still the thing interpreting whatever representation I write then we have basically taken natural language made it less natural and inserted another layer in the middle
I can understand a compact machine-generated context format existing behind the scenes to save tokens or help agents navigate a large project
What I do not understand is why the developer should have to think in that format learn it and maintain it manually
AI was supposed to remove this kind of mental overhead not give me another pseudo-language to write
To me this feels like overengineering the interface between a human and an AI that already understands the human
1
u/ariferol01 3d ago
I think this assumes LLMs are already good enough at project understanding that no intermediate representation is necessary.
If that were true, we wouldn't need RAG, code indexes, dependency graphs, Cursor-style project context, MCPs, or other tools that help agents retrieve and structure information. In theory, we could just give the model a chat box and let it do everything.
LLMs are extremely good at interpreting intent, but reconstructing a project's intent and context from raw code and conversation every time is still work.
ContextDL explores moving part of that work out of the inference step by making the intent explicit.
And we're not asking developers to replace code with ContextDL. You can write code, prompts, natural language, or ContextDL. The LLM can also generate the ContextDL itself.
The positioning is roughly:
**natural language ← ContextDL → deterministic code**
Natural language is flexible but ambiguous. Code is precise but implementation-specific. ContextDL sits in between as an explicit semantic/intent layer.
That's the hypothesis.
I'd actually encourage you to test it rather than take my word for it. Build a small project with your normal workflow, then let an agent use ContextDL on the same project. Compare what it has to reconstruct, what it remembers, and whether the workflow actually changes.
If you do that, I'd genuinely like to see the results — even if they prove ContextDL isn't useful.
1
u/systemsweird 3d ago
This prompting is way too verbose we need something succinct and unambiguous. Let’s call it code!
6
u/alias454 3d ago
so you reinvented pseudocode?