zameermfm

wondering the same today

Stop the qtip when there's resistance

True, they fill a beautiful gap

True, Machine to machine is interesting to think about

Yeah, Reading it clearly in the editor - Probably MD to HTML happens in the editor anyway. So what we are dealing with here are a battle between ease of writing, readability and various cost dimensions.

May be they should coexist for utilities they provide

Agent to human?

If cost of showing HTML and MD are same in the CPU level for UI, but generation of them costs uneven at AI level (as it should be mathematically), shouldn't the equation be what is the lowest cost to represent something considering the token usage

A) Enterprises for one, e.g Rendering of an HTML page vs MD in an AI IDE or even tokens (compounding costs for a communication doc may be billions in a year) B) True, its a subset, nobody is arguing against it. HTML has overheads in terms of stylings. MD in essence is just a straight arrow.

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

Thats a complete reductive idea of MDs. MD was long spawn before LLMs as a need for light weight formatting and easy conversion to different formats. No one used at that scale doesnt mean the absence of the utility for it, as the primary adopters were tech community and that was a layer below the consumer market. Utility obviously stands, the question is, can HTML supersede on that utility side of it in all developer work components.

Great idea you got, what would be a classic use case? We have a data source and we can define the API structure to get them?

Sure! thanks! thats good idea, to have it clickable and true that needs needs to be easily understandable.

With AI IDEs, Personally I had to generate a tons of md files for planning a task, analysis on the code for something or other, a task doc for a feature - a summary to paste into the clickup ... and I saw many devs keeps on generating them, and all tucked away into folders. Good, okay.

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.

https://mdspec.dev

Ah its a reader, okay, great tool!

There was a plug of smalldocs intro in that post, regarding that, Dont we need the md files on the wikis and documentations in the central project management tools, instead of client side anything?

Yes, In my experience with it, AI agentic syntaxes were few notches above what human would do, where in humans quality can fluctuate, and as creatures of habit we all tend to develop some patterns that can be read by our reviewers intuitively when our name is on it. AI can consistently get the right patterns if we can keep a tight rule/skill/checks on them, but thats mean they would conform to one pattern.

imo, unless you can quickly read off the approach the AI has taken, If you haven't got the experience for it, it can be a minefield. Because by agentic coding, we have moved beyond syntaxes into the ideas and approaches. Agent gives an approach, we should know if its the efficient one. But if you got that reading hook, its really fast and I dont see why it should not be production code.

true, yeah thats right, But my larger point is we are operating many levels above than we can with JS. Like C, C++/Rust is the closest as LLMs would be trained on that.

I just threw the extreme point on the curve, to see where we can land on.

Great points and thats true, may be the line is somewhere between readability and most efficiency.

"Any idea"

Yes, front end is indeed in the automation territory. Artisanal works aside, common patterns usually serves peoples needs, so vibe coded front end will in fact work.

True, but in a longer term? where the curve filters out the side projects which arent viable and others will make it to a inevitable point of scaling?

As we build software with AI agents—through tools like Cursor, VS Code, or Antigravity—Markdown files (often called specs in software development) are rapidly becoming part of the AI infrastructure layer. They act as a communication interface between humans, teams, and AI systems.

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.

I've seen this reusable assembly of software components again and again in the discussions for decades as well as in some older research papers. One side it's good that we check periodically if it can be done with any new tech that is available.

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.

Curious, We need more info :)

Natural disasters and wars, each seemingly more devastating than the last. Are we becoming desensitized to this constant stream of bad news? And could that actually be necessary to help us stay functional amid global conflict and the climate crisis?

Barrier to entry, true. Building website network is also a problem, but they do have incentive as even all posts becomes a source of revenue, not just the ones behind paywall.

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.

Love the idea! Awesome execution, I just want to see it in a future evolution of twitter like UI, so it becomes easy in my head to keep, access and listen. Keep building what you love.

Awesome effort, always wanted to see our colombo on a game! It's really extensive and seems to be made towards public policy, Thanks Yudanjaya and Nimesha!

I won't be having pricing tiers as such, this will be completely free app ads running later this year and remove-ads annual pricing will be less than or around $20.

Yeah it was bit costly for me to rely on it and I wanted more flexibility (by many folds) than eraser.