131 karma · joined June 2, 2020
If there is a communication between two points with ultimate low latency way with readability and threshold just enough to have the idea, MD passes that mark. As tokens needs to conserved
Sure! thanks! thats good idea, to have it clickable and true that needs needs to be easily understandable.
For the company I'm currently working I had made a VSCode extension where I can sync the task doc with clickup via frontmatter.
I decided to take it to next level as a side project. I built a CI integrated, git-native, agent template transformable syncing pipeline with git MD files to any project management tools. That means, either you can save your md files vanilla in your wiki (thus using the clickup AI search to dig up later, get insights etc) or you can use a AI agent template transformer to turn it into a task template (Background, acceptance criteria, functional requirements etc.) and update or create a task on a board.
I've been working on it now. I don't know how it will fare, but I feel like product is coming up nice.
I just threw the extreme point on the curve, to see where we can land on.
I’ve primarily used specs for two purposes.
First, for developing new features or fixing bugs. A spec becomes a development artifact where teams discuss design, trade-offs, costs, security implications, and architecture. AI agents are particularly good at exploring these aspects in depth. The entire discussion can live in one document or multiple linked documents, and when things change, agents can update the specs.
Second, for targeted analysis extracted from codebases. Sometimes you need to generate understanding for a specific audience or tool—compliance reviews, architecture analysis, cost simulations, or risk modeling. For example, I’ve built cost-simulation tools using YAML infrastructure specs derived from the codebase. The advantage is that the target audience does not need access to the entire repository—only the relevant spec.
In essence:
Specs give AI agents the structured context they need to build correctly.
They give teams clarity into why and how something was implemented.
They can be filtered and reused as inputs to other tools and analyses.
So,
MD files grows exponentially as the possibilities grow
This is where mdspec helps.
Instead of keeping specs inside every repository, teams can upload and manage their Markdown specs in mdspec, keeping repositories clean while still making specs accessible to AI agents and teams.
Your codebase stays focused on code, while mdspec becomes the structured home for specs, analysis, and cross-team collaboration.
But has any efforts made it far that is universally plug and play? Open source projects had come close. Now those OS projects used by AI coding assistants come close. But no so much plug and play. I think I know why it wasn't happened, and may be can happen.
But I think the idea of abstractions in software engineering, which has guided OOP and even the classes today, is because it was somehow pioneered and may be natural to us to think of the systems that way. Abstractions change from person to person and from teams to teams. Two fleet system components for the same purpose built by two different team will internally behave differently. So universal plug and play for same flows might not work as we think it should be.
Even a low code/no code components, which has a high reusability among completely different projects by different people may introduce overhead that will not work for a said system? because their abstraction of the system isn't the one same as the component was designed? They end up reusing the abstractions of how the system should be around what is already there.
Whats happening now with AI coding assistants, would be the reusability of components software as it should be in this engineering world. It reuses the approaches from any OS project, we can even alternate between the approaches and we get the best out of it (if you know what you're doing) from the different choices and also via our own abstractions of how software should be.
I think we are there, antifragile way of software reusability. We should embrace the choas. A universal metaphorical plug and play for software engineering.
1. Decentralized - one way 2. Wikipedia style - centralized and non profit.
With credit system, anyone can buy them in excess and utilize it for years.