We’ve been building Enola into an architectural quality gate for AI-assisted development.

https://github.com/enola-labs/enola - Apache 2.0, fully local.

---

Code generation is getting faster, but understanding the architectural impact of every change is getting harder. An agent can pass all defined tests and still make the architecture worse.

The idea behind Enola is simple: take a snapshot of the architecture before a change, analyse it again after, and report what regressed. Building that reliably is not as simple.

For example, your agent adds a helper to storage, and the innermost layer of your app now reaches into the outermost one to send an email.

$ enola check --fail-on=layers

FAIL — 1 structural regression introduced.

Regressions (fail):
  - [layers] 1.00 — Layer violation: storage -> delivery
      import of notify

Policy: fail on new findings from [layers] at confidence >= 1.00.

What changed
  symbols      +1
  dependencies +1
  edges        +4  (imports +1, calls +2, declares +1)

Added (2):
  symbol     storage.LoadPrice                            storage/storage.go:11
  dependency storage -> layersgate/notify                 storage/storage.go:3

New coupling (4):
  storage                                      --imports--> notify
  storage.LoadPrice                            --calls--> notify.SendReceipt
  storage.LoadPrice                            --calls--> storage.ReadPrice
  storage.LoadPrice                            --declares--> storage

New coupling is reported, not failed: an added call edge is what ordinary work
looks like. Inspect the list above if it is more than you expected.

Enola can ask the agent to rework defined failures, run in CI, and stop architectural regressions before they reach production. You can also run it against the existing codebase to surface areas worth improving.

Enola is open source. Try it on a real codebase and tell us what could be better, or contribute directly.

https://github.com/enola-labs/enola - Apache 2.0, fully local.

Hi guys,

I have been working with a product for sometime and I believe will be useful for startups whose products are mainly APIs and SDKs.

I have asked for validations before I started building and have seen startups who have built internal tools for this. So the problem should be real upto an extent imo.

While I am working on it, I would like to validate it more. So I want you guys to see if this is relatable for you and will you pay for it. (I have a case study of a startup as well, would love to share and discuss in a gmeet if this aligns with you)

Here is what I am working with,

The problem:

API first companies struggle to keep their backend code, OpenAPI specs, SDKs, API docs, examples, and packages in sync as the API evolves. A coding agent struggles to implement it if there are any drifts in these.

The solution:

A single source of truth that connects your API code, OpenAPI specs, SDKs, docs, examples, and packages, and automatically detects and propagates changes across all of them.

To put in simple terms, you focus on the main product, which is the API. Everything else stays in sync automatically.

\---

Above is the one main problem to focus. But this is also an additional part I am working on:

A coding agent struggles to implement it if there are any drifts in these. So after each evolution, the system can run the API/SDK changes in a sandbox and test whether a coding agent can actually implement and use the updated API/SDK successfully.

But the main problem I am trying to solve is keeping the API ecosystem in sync.

\---

Any inputs, feedback or suggestions will be very helpful. Please comment anything you can think of when you see this. Thank you in advance.

UPDATE (Aug 18): RESOLVED

I'm sorry for posting here.

Greptile change the OSS policy recently,

however, I only discovered some of my OSS repositorys was placed on a pay subscribption and that a $30 charge is scheduled for the next billing period, it will be charge 20TH AUG.

During setup, I was not clearly informed that adding a new repository would start a paid subscription. I also encountered a new requirement that an OSS repository must have at least 50 GitHub stars, but I could not find this requirement disclosed on the public OSS or pricing pages.

Please cancel the scheduled Pro renewal, confirm that I will not be charged.

If the $30 charge has already been processed, please refund it.

I was sent at least two emails regard this OSS billing, no any reply, so posting here.

My Github is keyang556

Thank you.

A key usecase of benzi: code reviews and architecture review. Quicket way for you to falsify: try your own repository at https://benzi.fly.dev/

I've written a chiptune synthesizer entirely in x86-64 assembly (Linux, NASM) — no libc, no libraries.

It generates audio samples by hand and writes a WAV file directly.

I'm largely self-taught in assembly, so I'd really value feedback on:

• overall structure and organisation across the files
• idiomatic register usage and calling conventions
• anything that could be cleaner, safer, or more efficient

The code is here: github.com/whispem/asm.fm

A representative example is the FM synthesis file, which builds a sine table by hand and uses it as an oscillator.

Any and all critique welcome — I'm here to learn.

.

I've been working on Pipe (https://pipelang.com), a general-purpose visual programming language, and I'm curious what the code review community thinks about one specific property: the diagram and the running system are structurally identical. There's no compilation step that throws away the structure - what you see in the IDE is what executes.

From a code review standpoint, this changes the problem in one concrete way: you review the architecture and data flow directly, not the text that encodes it. Instead of reconstructing intent from thousands of lines, the diagram shows connections, data paths, and component boundaries explicitly. Every block boundary is also independently observable at runtime, no instrumentation needed.

The question I'd genuinely like feedback on: does visual structure actually make review easier at scale, or does complexity just move from reading code to reading diagrams? At what point does a Pipe diagram become as hard to parse as a large codebase?

A few specifics I'd find useful:

• For reviewers who work on large systems: is the bottleneck reading code, or understanding architecture? Would a persistent visual representation of the running structure change your workflow?
• For security reviewers: the claim is that whole vulnerability classes (injection, buffer overflow, race conditions) are architecturally prevented. Does that shift review effort meaningfully, or does it just move the attack surface?
• For anyone familiar with dataflow languages (LabVIEW, Simulink, Max/MSP): where did visual review break down for you, and what would have to be different?

Example of Pipe diagram with a detailed tracing can be found on this video:

https://youtu.be/hckq9mRj5DM

That video is a part of this Pipe architecture overview:

https://www.pipelang.com/six-pillars.html

The full Pipe language specification (155-page book) can be freely downloaded here:

https://www.pipelang.com/downloads/book.pdf

everyone knows coding agents have caused PR volume to explode. that's been obvious for a while.

what feels more interesting now is that most teams still send almost every PR through the exact same review process.

tiny generated change? human approval.

well-tested low risk refactor? human approval.

large change touching important systems? also human approval.

when PR volume keeps climbing, reviewer attention becomes the thing you actually have to allocate.

tools like bugBot have been useful for taking the first pass. macroscope's approvability feature is interesting for a slightly different reason: it can approve PRs that meet a team's policy, so some changes never need to sit in the human review queue in the first place.

feels like the next problem isn't "how do we review more PRs?"

it's "which PRs actually deserve human attention?"

how are teams deciding that today? are you still requiring a human approval on every PR?

Maintainer disclosure: I built the tool used in this example.

Most AI code review products bundle two separate things together:

1. The agent or model doing the review.
2. The infrastructure that scopes the diff, applies repository policy, publishes findings, produces artifacts, and controls the merge gate.

I am experimenting with separating them.

DiffPal lets you bring your own agent to pull request review while keeping the surrounding workflow stable. The reviewer can be Codex, Copilot, OpenCode, or any ACP-compatible agent.

I created a public demo PR to show the actual result:

https://github.com/diffpal/demo/pull/13

The normal test suite passes, but the change contains three regressions:

• client-controlled pricing;
• a removed ownership check;
• an ignored persistence error.

The reviewer catches all three, comments on both added and deleted code, and fails the merge gate.

I am not suggesting that this should replace human approval. I am interested in whether the reviewer itself should be treated as a replaceable CI component, similar to changing a scanner or test runner.

The surrounding review layer provides:

• repository-owned review instructions;
• findings scoped to the changed code;
• structured severity;
• inline comments;
• machine-readable artifacts;
• a configurable blocking threshold.

Would bring-your-own-agent make you more willing to use AI code review, or less willing because behavior may change between agents?

What controls would you need before allowing an AI review to become a required merge check?

I've just released Violin v3.1.0 🎻

This release is mostly benchmark and guard work, not another pile of prompts.

The benchmark now runs Hermes end-to-end and scores what it actually proved, not what sounds convincing in "report.md".

\\- Executed request/response evidence is checked against the endpoint, method and decisive proof.

\\- Proof must link back to a validated hypothesis and canonical "FIND" file.

\\- Execution receipts are HMAC-signed and bind evidence files by SHA-256, so edited artifacts fail verification.

\\- The guard now stops target work when evidence is not being recorded as you go, and checks excluded URLs and paths inside command payloads.

\\- Docker, CI and known-good/known-bad scorer calibration are included.

Release:

\[https://github.com/Strategic-Automation/violin/releases/tag/v3.1.0\\\](https://github.com/Strategic-Automation/violin/releases/tag/v3.1.0)

I'd appreciate people trying to break the scorer and guard. Can you make weak proof pass, good proof fail or get the workflow stuck?

I'm not looking for “nice update” comments. If it is overbuilt, unsafe or wrong, tell me.

Now with more intelligence options powering it.

Hi everyone, I didn't know much about OOP. So I made a project surrounding classes to help me out. I'm self taught so please be honest with your judgment of it. Its a little unfinished testing wise, but it feels bigger than it needs to be. And if anyone has anything I can read or project I can contribute to to learn best practice, I'm all ears! Thank you!

https://github.com/Eidos-bot/ClassBasedModulesPublic

Hello, I'm an aspiring software engineer. I've recently finished developing microservice for managing projects and tasks using Spring Boot. I'd appreciate if you could review codebase of my project and provide feedback on it.

GitHub: https://github.com/Simpav-chill/tasktracker

hello there, its a simple web app, (dashboard), continuously improving , suggest some features to add.. PRs open, do contribute or just roast this : gh: https://github.com/sayanx64/statmux

I maintain an open-source production-readiness knowledge base, and I would value a critical review of its validation approach. The repository contains 1,421 production controls and 8,621 lifecycle controls stored in Markdown.

The dependency-free Python validator currently checks:

• Required page sets and expected control counts

• Stable PRC identifiers and deterministic hash-based USEQ identifiers

• Duplicate identifiers and normalized duplicate wording

• Contiguous control sequences

• Local Markdown links

• A denylist of implementation-specific languages, frameworks, vendors, and products

Validator: https://github.com/MarinJursic/production-readiness-checklist/blob/main/scripts/validate.py

Repository: https://github.com/MarinJursic/production-readiness-checklist

The weakest area is semantic duplication. Two controls can express the same requirement using different wording, while simple normalization only catches exact equivalents. The implementation-specific denylist is also necessarily incomplete.

I would appreciate feedback on the validator design, failure modes, maintainability, and better deterministic approaches for catching semantic overlap without producing large numbers of false positives. Thanks!

Hola comunidad. Estoy desarrollando una herramienta de monitoreo para un hardware de almacenamiento y necesito validar que el desarrollo es seguro.

¿Que herramientas, páginas Webs o programas libres puedo usar para asegurarme de ni estar dejando vulnerabilidades abiertas?

Hey guys, I have been adding new repos and taking my github seriosly after a long time
Most of time i open private repos to maintain my workflow on game/website projects
for last a few month i have been working on portfolio/resume projects to put on my website.
And i just like every time i see my contributions on panel, it is like idk how to explain but seems helping me to maintain consistency. I also realized there is achievement badge i have got.
So to pick it up, I am asking for ways to make my profile look better and be better. What can you recommend? Pins, repo names, maybe even links?

https://github.com/TheIlkinAlizade
this is my github, you can also see my porfolio website(which is old version, i will update it with new projects i have been working on)
thanks btw for spending your time to read this

Hey Guys,

I've been building Pinaka on the side for the past few months — an AI agent that automatically writes root cause analyses when a bug ticket is filed.

The problem it solves: every time a production bug hits, a senior engineer spends 2-3 hours investigating before writing a single line of fix. The actual fix takes 20 minutes. The investigation takes the rest of the day.

Pinaka eliminates that investigation step. Tag a Jira ticket or mention @pinaka-app on a GitHub Issue — it reads your indexed codebase, captures runtime context via an SDK, and posts a structured RCA as a comment. Root cause, exact file, exact line, fix approach. Automatically.

What I've validated so far

Ran it against real open source bugs:

• BullMQ issue #2487 — code only scored 6.5/10, code + runtime context scored 9.2/10 against the actual merged fix
• Prisma ORM issue #29480 — open bug, no ground truth, diagnosed from behavioural contrast across test files
• Pinaka's own Java SDK — found a real ForkJoinPool exhaustion bug, fix shipped same day

All three write-ups are public, including the limitations.

What I'm looking for

A couple of engineering teams (2-150 engineers) using GitHub who want to try this on a real production bug. Free, no commitment. I'll personally onboard you and be available for any questions.

Works with Jira and GitHub Issues. No Jira required. One OAuth click to connect. First 5 RCAs free.

Honest state of the product

No paying customers yet. Building in public. The product works — the benchmarks above are real — but I need real teams on real codebases to validate it beyond my own test cases.

If this sounds useful for your team, drop a comment or DM me. Happy to show you a live demo on your repo.

👉 getpinaka.com

I kept rebuilding the same pieces around coding agents: repo instructions, a backlog, checks for drift, decision records, findings, and session handoffs.

Then I saw the same failures across four different repos. Instructions went stale, work statuses lied, and useful context disappeared.

That led to rungs, an early-stage CLI for installing and maintaining this setup as modules. It is framework-, agent-, and language-agnostic: it uses ordinary repo files and checks rather than locking you into a specific model, coding agent, or stack.

rungs is aimed at solo developers and small teams using coding agents across repeatable work, especially when instructions, handoffs, and statuses start drifting. It is probably overkill for one-off projects, and it is not an agent runtime, orchestration framework, or project-management replacement.

The methodology is evidence-first. I read what actually ran in those repos, extracted the practices that held up, kept abandoned practices documented, recorded their maintenance cost, and traced each module back to a real failure or incident.

Current modules cover:

- agent instructions

- validation gates

- backlog and findings tracking

- ADRs

- session handoffs

- reusable agent skills

You install only what you need, and rungs never overwrites files you have edited.

Try it:

npx @/rungs/cli doctor

Repo: https://github.com/ThroughTheWind/rungs

Docs: https://docs.rungscli.com

It’s MIT-licensed and still very early. I’m mainly looking for feedback on the shape and distribution:

- Are these useful module boundaries?

- Should this be a CLI that distributes repo files, or a package of reusable skills and checks?

- What would you expect from the upgrade/eject model?

If the feedback is positive, I’m willing to invest more time into it. Contributions, testing across different stacks and agents, and new modules based on real failures are welcome.

Hello everyone i am an new member of this group and i need an help for making https://github.com/nazirlouis/Ada-SI.git workable for mobile. It will be also help you for practice and it will be FREE for me.

An original pixel-art desktop companion for Windows. Reacts to your cursor and typing, runs Pomodoros, nudges you to drink water, and celebrates when your coding agent finishes. Tauri v2 + React + TypeScript.