They openly talk about it here https://www.mvp.express/philosophy/ in section " AI-Assisted Development".

Okay, but is that a bad thing?

[dead]

Apologies! It's a long read and was the only time I did not want to use AI to summarize for a purpose :) ---- So Yes, a lot of the code has been written using AI. I have also been transparent about it on https://www.mvp.express/philosophy/ in the section "AI-Assisted Development".

However, that does not mean that I as the author do not understand the code/concepts :) I also don't deny the fact that I might not have gone through the entire codebase till now.

For some background: 1. I have been working in Capital Markets-Trading, basically FIX (https://www.fixtrading.org/what-is-fix/) systems since a few years now and have been using QuickFIX/J at my job. 2. At the same time, I have been intrigued with Java FFM especially after seeing huge performance gain over idiomatic Java code for a (~500 MB market data) file processing job which I had written a few months back at my regular work. 3. Fellow FIX developers from JVM world would know that there are other Java FIX systems that achieve "extra/huge performance boost" by using "Java's sun.misc.Unsafe" in several parts of the FIX system and OMS.

Reflecting on above 3 points, I had envisioned writing a modern Java FIX engine with 1. 0.0% usage of sun.misc.Unsafe in the entire codebase, 2. achieve close(-enough) performance to market leading C/C++ FIX engines. This was somewhat in the beginning of this year-2025. However, a month or two into this effort I realized 2 key essential ingredients which will dictate performance, latency, & throughput of the entire system - 1. Serialization & 2. Transport. By then, I had already written quite a few tests and benchmarks and was amazed by the performance boost solely relying on FFM; also no unsafe, zero copy, zero allocations are the benefits as byproduct & ofcourse extremely low GC pauses comparatively.

Since I had already started using FFM MemorySegment et al to build the key infra parts of the system - I was of the opinion that restricting these only within a FIX system alone would be a crime. Hence, MYRA & MVP.Express were incubated as an idea overnight - modern, safe, lightweight, modular, FFM oriented high-performant Java infra libs.

Well, I have been posting only on Reddit's Java sub till now to get some initial feedback. However, I just noticed today a sudden huge inflow of traffic and that's how I realized its coming from a post by mands on HN. Thanks mands! I had no intention of posting to HN (yet). No complaints :) I'm glad it made here and also appreciate all the feedback.

A note on why the extensive (un)checked usage of AI to build this - I would like to go breadth first rapidly i.e. expanding the ecosystem to let others tinker with. Work in pipeline - 1. JIA Cache - build a modern JVM based off-heap & safe distributed caching using the MYRA libs as infra. 2. MVP.Express - a light-weight Java only RPC system focusing on performance, type-safety, schema-driven, high throughput & low latency by leveraging MYRA libs & JIA-Cache as building blocks. Side note: I am currently on a vacation. Once back; I plan to start integrating XDP/eBPF as another backend for myra-transport.

Agree or not - That's a hell lot of work! And that's the reason I am using AI extensively. To quickly build modern FFM based solutions and validate the existence/purpose - through performance and other metrics. Ideally, they should be real good candidates to perhaps displace incumbent similar systems which have a lot of legacy pre Java 8 code; meaning even if such existing systems need to be modernized they would potentially have to be re-written from scratch using modern Java paradigms. Well that's what MYRA & MVP.Express is trying to do now as Stage 0 at a rapid pace - to see a market fit!

Having said that, I am very cautious about the design and guard-rails which is evident from the extensive test suite & benchmark every MYRA lib has and will have. Trying to follow a close TTD loop here.

Next stages: If the MYRA libs and related ecosystem seems to be a good fit for modern Java projects, then I and others (its OSS for a purpose) can contribute also by manually reading (human verification) certain parts of the code in which they are experts at. This way we/us as a Java community can build modern forward-looking libs & solutions to power the enterprises for the next decade or two. It may sound silly but I believe in this philosophy and I hope you will too!

Let's look at it from another (realistic) perspective - I have been working on this since a few months (2 to 3 give or take) along with my current 9-5; have been possible only due to AI. TBH if there was no AI, most probably I would not even have thought of starting this myriad task - since I know practically I would never have been able to finish ever or would have taken an enormous timeline and perhaps might have abandoned it half-way!

Hope, this clears some air and brings some honest clarity about the goals & philosophy of MYRA (& myself seconded). Also, I am not a io_uring/XDP expert and AI has been really helpful to bring my vision into reality. Although, I am in parallel trying to grow my knowledge into the technical nitty-gritties of these tools/technologies. However solely due to AI, I was able to rapidly build something and hence, prove that using io_uring has substantial benefit - evident from benchmarks against Java Netty. That's what I meant earlier by rapidly expanding on the breadth of the ecosystem first and warranting every solution's purpose thru benchmarks and other metrics; not to forget NO unsafe and NO JNI as well are also golden nuggets.

Last but not the least, I am excited by the response here on HN and will stay close here going forward; will be sharing updates here as well. I would also appreciate all kind of concerns/feedback/suggestion.

Thanks -RR