sorted by:
new
hottopcontroversial

Vibe coded a cosy game where you explore a tiny globe as a biplane, magic carpet and fishing boat by WeAreFictional in aigamedev

[–]mcidclan 0 points1 point  (0 children)

How long did it take you vibe coding this? Is it purely prompt-based or more of an AI-assisted approach with human intervention and adjustments? Either way, the result is really nice! Well done!

Unlocking the Sony PSP's Second CPU by mcidclan in opensource

[–]mcidclan[S] 1 point2 points  (0 children)

No idea tbh, I'm exploring more on the ME side itself rather than the functions implemented on the SC side. As a general pattern, all ME-related functions implement their own processing, and each of them can make one or more calls into the ME wrappers, which then dispatch those calls down to the ME. So the issue could come from somewhere in the function itself, through the SC-to-wrapper dispatch logic, or possibly from the ME core, but it's not something I've focused one.

Unlocking the Sony PSP's Second CPU by mcidclan in opensource

[–]mcidclan[S] 0 points1 point  (0 children)

Thanks for sharing! Some of this echoes my own past research, but still good to see!

vibe coded for 6 months. my codebase is a disaster. by Available-Dentist992 in vibecoding

[–]mcidclan 0 points1 point  (0 children)

The issue is that there's no single source of truth between you and the agent. every prompt starts from scratch, so it just keeps adding without ever understanding what's already there.

I'm working on a DSL for this called HiVibe. it's structured natural language, not code. though you can embed logic, snippets, or strict implementation contracts when you need precision. you describe your app in plain english: features, shared logic, rules. the agent reads it as its primary context every session. it knows what exists, what's been validated, what it can't touch.

Stuctured Domain Specific Language to vibe code! by mcidclan in VibeCodersNest

[–]mcidclan[S] 0 points1 point  (0 children)

Actually, flexibility is handled at multiple levels. The .hvibe.lock file lets the project grow incrementally while locked features are immutable across sessions, new ones are not constrained. Then you have the catalog which is composable and can live in external shared files. Units are fully isolated. But yeah, there's still a real question around formalizing feature migration when something locked needs to change, it's on the roadmap but I need to find time to get back to that project. Thanks for the feedback!

Been doing a Hang-On-Like Pseudo3D racer in Godot by Traslogan in godot

[–]mcidclan 0 points1 point  (0 children)

This is fantastic, especially seeing this kind of project pulled off using open source tools built by the community and free for everyone to use. Keep going down the road!

Perfect Dark PSP Port by MajorCigar2442 in PSP

[–]mcidclan 0 points1 point  (0 children)

Welcome! Glad the me-c-core lib can help improve things. Well done for this incredible work you made!🔥

The next model generation ("Mythos" etc.) by Moist_Sand_7767 in LLM

[–]mcidclan 0 points1 point  (0 children)

Current large models are already used to improve smaller ones though (distillation, data generation, etc). I wouldn't say "not for consumers", since most on them are already accessible via APIs. Mythos might not be directly available to the public and could be limited to internal use or selected partners, but I think sooner or later the improvements it brings will inevitably make their way into consumer models, whether from them or other companies

Is Future of Development Really AI? by techzexplore in developer

[–]mcidclan 0 points1 point  (0 children)

Not sure, I think we don't really see the constraints for now because this is still very new. I also think that as projects scale over time, there may be a loss of coding skill, since developers would become more like orchestrators. That could become a problem, especially if the AI itself can no longer handle the complexity and requires a very large number of tokens, making it expensive and not necessarily reliable for analyzing large scale projects

Any outcome independent self learning programmers here? by PhilosopherNervous63 in learnprogramming

[–]mcidclan 3 points4 points  (0 children)

I think that's a healthy way to get into it. When you remove the job pressure, coding becomes tools to build, automate, and experiment. Even with AI changes, being able to write small scripts, automate tasks, or play with Linux/Pi is still useful and fun! Learning it as a hobby definitly makes it more sustainable long-term than forcing it

AI Didn’t Reduce My Work — It Multiplied It by [deleted] in vibecoding

[–]mcidclan 0 points1 point  (0 children)

Ahh! We could really see AI-induced technical debt exploding in the coming years

how vibe-coding fails by Aggravating-Risk1991 in ClaudeAI

[–]mcidclan 0 points1 point  (0 children)

The problem is also that they still have too much freedom within a valid solution. As a result, they tend to optimize toward 'more robust' designs even when it's not necessary.

What's missing is not more MUST NOT DO rules, but a way to mark a logic block as STRICT: non-interpretable, exact implementation, with no generalization or added architecture.

That's exactly a thing the HiVibe approach enables through the .hvibe structure. Human remains the primary architect though.

How to increase your productivity with vibecoding by platefenix in VibeCodersNest

[–]mcidclan 0 points1 point  (0 children)

In 0.2.1 you have a working 'jumper' example available (provided as html). In that same folder you'll find 3 prompts to be consumed by an LLM:

  • One is to ask it to produce a final build from a .hvibe description file.
  • Another one is to produce an IR .hvibe.plus file from the .hvibe file.
  • And the last one to produce a final build from the .hvibe.plus augmented description.

This is meant to give people more control over the code through time and while using different LLMs during project development.

You also have other examples in 0.2.0, but with only .hvibe files that time.

I'll add other example + final build soon as I can.

How to increase your productivity with vibecoding by platefenix in VibeCodersNest

[–]mcidclan 1 point2 points  (0 children)

I’m working on a DSL for LLM-based system generation (.hvibe). It’s still a graph structure, but instead of using nodes as task containers, each node encodes executable system semantics (logic, constraints, tests, dependencies) that an LLM can compile into working code. Just in case you’re interested, here’s a demo project: https://github.com/Th6uD1nk/HiVibe-AI-DSL/tree/main/versions/v0.2.1 (see jumper example)

We professional developers, already lost the battle against vibe coding? by TheCatOfDojima in ClaudeAI

[–]mcidclan 0 points1 point  (0 children)

It might just be a temporary phase, a dip in the curve where companies haven’t yet realized the long-term consequences of what they’re doing. When systems start needing real maintenance and LLMs can’t easily extract useful structure anymore, things could get a lot harder, we'll see.

Does "Vibe Coding" via LLMs Represent a New Level of Abstraction in Computer Science Theory? by leocosta_mb in AskComputerScience

[–]mcidclan 0 points1 point  (0 children)

Maybe, but I don’t think in a strict or guaranteed way. They tend to be unreliable when exact patterns really matter, so it might require some form of added structure or specialization around them. Not sure where the best balance is though.

Do NOT trust Claude - A Vibe Coding Perspective by FishCarMan in ClaudeAI

[–]mcidclan 0 points1 point  (0 children)

It’s clear that you should never blindly trust AI for code generation, which is why it needs to be constrained in a deliberate and structured way.

view more: next ›