Teaches AI agents to write idiomatic Kotlin (data classes, val, scope fns, Kotest) AND to make the right stack choices on JVM: Kotlin 2.3 + JDK 21 + Gradle Kotlin DSL, Ktor for HTTP, kotlinx-coroutines, DJL for ML inference, JavaCV for vision, Koog for AI agent orchestration.
95
95%
Does it follow best practices?
Impact
95%
1.23xAverage score across 10 eval scenarios
Passed
No known issues
org.bytedeco:javacv-platform, current 1.5.13)cv2 via Python, don't try to use org.openpnp:opencv (older, abandoned), don't write JNI bindings to a system OpenCV installorg.bytedeco.javacv.OpenCVFrameGrabber(index) for webcam captureorg.bytedeco.opencv.global.opencv_imgproc.* for full OpenCV imgproc API (cvtColor, resize, rectangle, putText)org.bytedeco.opencv.opencv_objdetect.CascadeClassifier for Haar detectionorg.bytedeco.javacv.Java2DFrameConverter + OpenCVFrameConverter.ToMat for Mat ↔ BufferedImage ↔ DJL Image bridgingOpenCVFrameGrabber in an AutoCloseable Kotlin class with try { ... } finally { grabber.stop() }grabber.grab() after start() returns black frames for ~500 ms — sleep through the warm-up before entering the main loopFlow<Frame>: emit on every grab, use Flow.sample() to throttle heavy inference downstreamjavacv-platform pulls native libs for Linux x86_64, Linux ARM64, macOS x86_64, macOS ARM64, Windows x86_64 — ~400 MB of jars on first downloadjavacv + opencv-platform-linux-x86_64) instead of the full javacv-platformpython -c "import cv2; …" for image work — defeats the point of being on JVMorg.openpnp:opencv for new code — unmaintained, lacks recent OpenCV featureslibopencv.so via JNI hand-bindings — JavaCV solves this; don't re-solve itMat per frame inside a 30 fps loop — reuse the buffer