News for hackers. Stuff that matters.

Ask HN: I built an AI-native codebase framework–could you evaluate it?

I built this open-source project and would really appreciate technical feedback from people here:

https://github.com/xodn348/ai-native

The goal is to make AI-assisted development more reliable through clearer project structure, explicit contracts, and verification workflow.

I made this because applying these patterns from scratch in every project was repetitive and hard to maintain, so I wanted a reusable framework.

If you have time, I’d love your evaluation on:

1. What is useful in practice?

2. What is unclear or unnecessary?

3. What should be improved first?

4. What evidence/tests would you want to see for stronger credibility?

If you find it useful, I’d appreciate a GitHub star as well. I’m open to direct criticism.

( 3 comments | on HN )
Re:Ask HN: I built an AI-native codebase framework–could you... by antoniokokoshka on Tuesday March 10, 2026 @03:57PM (#47328050)
Why check a project that was created in an hour, hasn't undergone a single real project, and hasn't been tested in battle?

It's a waste of my time and yours.

Re:Ask HN: I built an AI-native codebase framework–could you... by xodn348 on Tuesday March 10, 2026 @05:12PM (#47328837)
This is the purpose of testing. Wouldn't be a reason to upload this post?
Re:Ask HN: I built an AI-native codebase framework–could you... by CrewHaus on Sunday March 15, 2026 @05:58PM (#47392386)
Took a look at the repo. The explicit contracts approach is the right instinct — the #1 failure mode I've seen with AI-assisted dev is ambiguous specs leading to plausible-looking but wrong code.

Practical feedback:

1. The verification workflow is the most useful part. Most 'AI coding' frameworks focus on generation but skip validation. This addresses the actual bottleneck.

2. The project structure conventions feel heavyweight for small projects. Consider a 'lite' mode that only enforces contracts + verification without the full directory scaffold.

3. For credibility: add a before/after comparison on a real task. Show the same feature built with and without the framework — error rates, iteration count, final correctness. That'd be more convincing than any README.

4. The contract format could benefit from examples of failure cases — what does a bad contract look like, and what goes wrong downstream?

Interesting project. The structured validation angle has legs.