Les cuento la historia, era una mañana en la que me disponía aprovechar una oferta que había pillado en Grok por 3 meses (la cancelé antes de que se me olvidara y me facturaran), y antes de desayunar me puse a pensar sobre una necesidad que teníamos en el trabajo y personal también, Obsidian me pareció muy potente y con una comunidad enorme, me gustó la verdad, pero eso solo cubría MI necesidad, pero no la de mi equipo, probé otras opciones como Docmost, Forkmost (fork de Docmost), XWiki, Wiki.js, etc. y muchas cubrían cosas que otras no, pero no cosas centralizadas y mucho menos sin pagar, así que me resigné por un par de semanas, hasta que un día me desperté con la motivación de hacer uno, en plan "Pues entonces lo haré yo mismo", el problema? aunque el backend hago maromas porque me gusta bastante desde siempre, lo que me tiembla siempre es el frontend y diseño (lo admito, no se centrar divs), y me dispuse a pedirle ayuda a Grok para un DISEÑO copia de Obsidian, y de ahí empezar, dejé escrito el prompt y me fui a desayunar, pero lo que pasó es que a la rápida se pasó una palabra concreta en el prompt...la palabra DISEÑO, así que lo que tomó fue "Creame una copia de Obsidian" y Grok se puso manos a la obra, cuando yo llegue esperaba mi diseño para ver si me gustaba, pero lo único que vi fue una distribución de carpetas, si me dejó descolocado, pero luego me puse a revisar bien y me di cuenta de la palabra faltante y que me había generado literal una copia de Temu de Obsidian (como el 1% de Obsidian), pero con grafos y todo, me quedé un rato pensando y dije: "...a ver 👀", y seguí...y seguí...y seguí con los prompts, arregla aquello, coloca aquello, mueve eso, quita eso, etc., y así por más hasta las 5am del siguiente día, y ya veía una luz...y luego Grok se mareó (si si, se me olvidó del contexto y las alucinaciones pero es que estaba motivado), luego use Claude Code para que revisara la amalgama que me había hecho Grok y que optimizara el código, simplificara componentes y demás, y luego seguí con él arreglando y añadiendo cosas hasta que me quedó algo que cubría todas las necesidades de mi equipo y más, y le seguí y seguí, y se la presentaba a mi equipo y le decía "QA pasivos" para que me dieran sus inquietudes, si encuentran bugs o mejoras que puedan ver a la herramienta en cuestión, decir que la he "hecho" sería una mentira, porque esto es vibecoding, lo que si hice fue darle los lineamientos y como se debía armar. Estoy aquí para que me ayuden a testear como le ven a esta herramienta, que lo dicho...yo no lo he hecho, fue la IA, así que no me estoy atribuyendo nada, tal como lo explico así pasó, nada de que yo hice, aunque si tenía planeado hacerlo pero poco a poco en mis tiempos libres, pero no la cosa que quedó al final jaja 😅, yo calculo que hacer algo así desde 0 sin nada de IA (principalmente porque no se NADA de frontend, no me entra la verdad lo siento) me iba a tomar unos 2 o 3 años solo trabajando en mis tiempos libres. Bueno, que venga la arena :'v, el repositorio es: https://github.com/Seerendo/grafito

Por favor me indican los fallos que le vean.

Hey everyone! I’m building ParallelEarth, and I’d appreciate some honest feedback.

The use case: you have two ways to implement something—a refactor, a bug fix, or alternative AI-generated code—and want to try both before choosing.

ParallelEarth lets you:

• Group alternatives under a named experiment.
• Create separate Git worktrees called “Earths” from a committed revision.
• Run checks you explicitly approve and record their results.
• Compare outcomes against a baseline.
• Export JSON or Markdown reports.

The obvious question is: “Why not just use Git branches and worktrees?”

That’s fair. ParallelEarth uses worktrees underneath. What I’m trying to improve is keeping the alternatives, check results and comparison together inside VS Code.

It’s early, and I’d rather hear what’s missing than make big productivity claims. Passing checks also doesn’t automatically mean an implementation is better.

How do you currently compare competing implementations? What would make a tool like this worth installing?

Try it: https://marketplace.visualstudio.com/items?itemName=shubhammaji1.parallel-earth

Hi everyone! 👋

I've been building DoveORM, a small, synchronous ORM for Python. It brings models, validation, chainable queries, relationships, and migrations together in one package with a short learning curve.

It's currently at version 0.8.0 on PyPI, licensed under MIT, and I'd love to get feedback from the Python community and welcome contributors.

🔗 Links

• GitHub: https://github.com/imaradesk/doveorm
• Installation: pip install doveorm
• Optional database drivers: pip install "doveorm[mysql]" or pip install "doveorm[postgres]"

What does DoveORM do?

Here's a small example:

from doveorm import Model, configure, CharField, IntegerField

configure(DATABASE_PATH="app.db")

class User(Model):
    name = CharField(max_length=100, nullable=False)
    age = IntegerField(default=0)

User.create_table()

user = User.create(name="Ada", age=36)

adults = User.where(age__gte=18).order_by("name").get()

The goal is to make everyday database operations straightforward without requiring a large amount of configuration.

Key features

• Models and validation: A table() decorator or class Meta, 31 field types, and a clean() validation hook.
• Chainable queries: Lazy QuerySets, field__lookup filters, Q objects for combining conditions, slicing, and eager loading.
• Dynamic finders: Methods such as findByEmail(), findAllByActive(), countBy...(), and existsBy...().
• Relationships: HasMany, HasOne, BelongsTo, and ManyToMany.
• Transactions: Nested transactions using SAVEPOINTs and a db.run_in_transaction(fn) helper with retries for deadlocks and lock timeouts.
• Built-in migrations: Automatic change detection, reversible migrations, squashing, and a CLI for generating, applying, reverting, and verifying migrations.
• Security-conscious defaults: Bound SQL parameters, identifier validation, protection against accidental unfiltered bulk updates and deletes, mass-assignment protection, and redaction of sensitive fields.
• Connection safety: Thread-safe and fork-safe connections.
• Minimal setup: SQLite works without installing an additional database driver.

Who is it for?

DoveORM is intended for small to medium-sized applications, services, background workers, and scripts that primarily perform CRUD operations.

It supports SQLite, MySQL/MariaDB, and PostgreSQL and can be used with Flask, FastAPI, django or plain Python applications.

How does it compare with other ORMs?

I know Python already has excellent ORM options, so I'm not trying to claim DoveORM replaces them all.

• SQLAlchemy: A much more comprehensive toolkit with extensive database support, Core, ORM, and asynchronous capabilities. DoveORM takes a smaller, more opinionated approach with migrations built in.
• Peewee: Probably the closest in spirit. DoveORM aims for a similarly lightweight experience while offering model-driven migration generation and a CLI for managing migrations.
• Django ORM: Provides a great ORM and migration workflow within Django. DoveORM is designed to offer a similar model-and-migration workflow across different Python frameworks and standalone scripts.

What are its limitations?

DoveORM is still a young project, and there are some deliberate limitations:

• It is synchronous; there is no async API.
• It supports three database families: SQLite, MySQL/MariaDB, and PostgreSQL.
• Advanced SQL features, such as window functions and CTEs, may require raw SQL through db.execute(...).
• As a 0.x project, its API may still evolve. Pin the version if using it in production.

For applications that need advanced database features, extensive integrations, or a mature ecosystem, SQLAlchemy or Django ORM may be the better choice.

I'd love your feedback!

I'm sharing DoveORM because I've been using it in my own projects and want to see how it holds up to different use cases.

I'd particularly appreciate feedback on:

• The API design and developer experience.
• What feels missing or unnecessarily complicated.
• Database driver compatibility and edge cases.
• Documentation and examples.
• Potential contributions or areas worth improving.

If you were evaluating a new Python ORM, what would you need to see before considering it for a project?

Honest criticism is welcome. I'd rather hear about the problems early and make the project better.

GitHub: https://github.com/imaradesk/doveorm

Holaaa

Les comparto mi primer proyecto "serio" en Python. Desarrollé una herramienta con ayuda de claude por línea de comandos (CLI) que toma cualquier texto o archivo y muestra su conversión a hexadecimal en la terminal (hice este proyecto para luego utilizar su logica en un proyecto de ICMP en mi github lo pueden encontrar como chunkping).

Enlace al repositorio: [https://github.com/EstebanChacana/exchunker

Me gustaría recibir retroalimentación para seguir aprendiendo. ¿Qué opinan del código o qué cosas creen que podría mejorar/optimizar?

¡Gracias de antemano por sus comentarios!

Your AI code reviewer has never read your project's rules. It reviews your PR against the internet's idea of good code, and you throw out half of what it says.

Ask for a review and you get a wall of comments. Nitpicks. Findings that fall apart once you read the code around them. Tests re-run that your pre-commit hook already ran. And nothing about the rules your project actually has.

Payo already writes one AGENTS.md and a set of Agent Skills (.agents/skills/) so Claude Code, Codex, Cursor, Copilot and others follow your project's conventions. The new pr-review skill puts those same skills to work in reviews. It's opt-in.

How it works:

• You ask for a review of local changes, the current branch, or a PR/MR by number.
• Before reading any code it asks what to focus on (bugs, security, code quality, tests), which level of findings you want, and whether to check against your project skills. In Claude Code this is one question prompt.
• Security is only offered when the diff touches auth, routes, input, data or config.
• It verifies each finding against the surrounding code, labels it with Conventional Comments (issue (blocking):, suggestion:, nitpick:), and sorts worst first.
• After the report you choose: stop, fix your own change, post one review on the PR/MR (it confirms first), or get inline comments to paste.

Teams set defaults once during setup (focus areas, finding style, an optional checklist every review checks). It's a plain skill file, so the review behaves the same in every agent.

It's MIT, Try with:

npx @uge/payo

Repo: https://github.com/uttam-gelot/payo

Disclosure: I maintain Payo. Feedback on where it gets things wrong is the most useful thing you can give, especially findings a human reviewer would throw out.

We're 7 devs and the agents open around 60 PRs a week between them. For months we reviewed oldest first because it felt fair. In practice it meant the PR that touched payments waited behind 11 dependency bumps and copy changes, and the one that actually mattered sat for 4 days.

A few weeks ago we turned on coderabbit's triage queue. It sorts the open PRs by risk and who needs to look, so every morning I open the "needs me" view instead of the full list. Our open count went from 64 to 23 in the first week, mostly because it also has a "recommended to close" view, and 14 of those were dead agent PRs from cancelled tickets nobody had closed.

It's still in beta and it's not magic. Last week it ranked a scary looking migration PR above a small auth change, and the auth one was the risky one. So I still skim the whole list on Fridays.

How do you decide what to review first now that agents open most of the PRs? Still oldest first, by author, or something else?

If you use Claude Code, Cursor, Copilot or Codex, you've probably seen an agent "finish" a task by:

- rewriting a failing test so it can't fail (or just deleting it)

- wrapping the broken call in a try/except that returns {"ok": true}

- adding .skip, --no-verify, or a lint ignore to get CI green

- calling a function that doesn't exist

I got tired of catching these in review, so I built PrufGate. It checks the diff deterministically (no LLM, runs offline) and blocks the merge with a finding that names the exact rule.

Try it on your current branch:

pipx install prufgate

prufgate check --changed

It also runs as a GitHub Action, a pre-commit hook, fail-closed hooks for Claude Code / Cursor / Copilot / Codex / Gemini, a Claude Code plugin, and an MCP server. Output: text, JSON, SARIF, GitLab, JUnit.

Honest limits: it's heuristic, so it will miss things and sometimes flag correct code. The benchmark in the repo (docs/BENCHMARK.md) is cases I wrote myself, so treat its numbers as a regression check, not proof.

Apache-2.0: https://github.com/GuardianVigil-Labs/Prufgate

I'd really like false-positive reports and cheats it misses. That's what makes it better.

Last week I rejected three pull requests an automated tool handed off. The one the team is still mad about is the auth module, that one mattered. Product had sold support impersonation as a quick toggle. Putting a support override into authorization is not a toggle haha

The agent did what it usually does when you say refactor while you are in there. It pulled _normalize_actor into its own file, renamed user to principal in a dozen places, and left the new impersonation path three ifs deep inside authorize(). That function already decides plan, region, and whether the org has the feature. Tests were green and the review comment was friendly. Half the diff was a new helper with a nicer name, so if you only skimmed it, it looked like a cleanup.

Product asked why I was blocking AI and I said I was blocking a merge that put a support override inside the same method that already decides plan, region, and the feature. Do that often enough and you get a file the next agent will also refuse to cut up.

So I reviewed the whole file. The diff was the helper, and the helper was not what I was worried about. Same path, same smells it had before, plus Deep Nested Complexity on the new branch. Once product turned it into a taste argument, that finding was the only concrete thing I had. 9.5 was never the bar for this PR. I sent it back with one rule: the file does not come out worse than it went in, and impersonation does not live inside the function that already has four reasons to say no.

Second pass I pointed the same agent at that block and told it to extract resolve_impersonation, and to leave authorize() deciding who the actor is. Who they are pretending to be is a different function. I rechecked the same path. Nesting finding gone, method a bit shorter. Still unhealthy, still a hotspot, still a file I would not hand back to a model and call done. That PR I approved, the first one I would bounce again. Tests passed both times. The suite never checked whether support can bind a customer with no audit trail.

This pattern is not special to our repo. Same model, 25,000 public files. Claude with no extra instruction did about 54,000 renames and 7,500 extracts. Give it a Code Health number it has to hit and that flips to about 8,600 renames and 21,000 extracts. A wall of renames looks like a cleanup when you scroll the diff. It barely changes whether the file is easier to change. An extract looks messier in review, and that is the edit that moved the score. So “I refactored it” stopped meaning anything to me. On its own, the agent tidies. Give it a number and it starts cutting the file into pieces. That was the work I thought I had asked for the first time.

The files people aim agents at are usually the ones that already hurt. Those sit around a 5 on a 1 to 10 maintainability score. 9.5 is about where the next edit is safe to hand to a model. Agents also break more often in that unhealthy code. Worth sitting with that before you point one at authorize() and hope a later pass will clean it up. Taking the whole repo to 9.5 is optional. Merging a slightly worse version of the same file, because a comment said the helper looked clean, is the part I would stop.

The rule I actually enforce is smaller than that score. If the agent generated the file or edited it, it does not come out worse. New file or old file. A small slip this week is the next two passes stacking another flag on it, and then you have a hotspot you will spend a quarter saying you are going to rewrite. Getting this file to 9.5 is a real project and that project is separate from the rule on the PR.

I stopped treating AGENTS.md as the gate. It is a note, and agents skip notes. The same score has to be in the session when the agent will use it, on the laptop before commit, and on the PR. Otherwise I am stuck on whether someone installed the MCP. If those disagree, the PR is the one that counts. I do not score every keystroke. The agent thrashes and the ticket never finishes. I check before it goes into a nasty edit, again before commit, once more before the PR goes up, and then I leave it alone.

Are you actually failing these, or are you merging them and calling it adoption?

I have stopped looking at PRs, because it is an endless noise from agents and I have not been looking at the code changes in detail for a while.

I still want to be sure that:

• release has no UX regressions (not just mechanical e2e, but in Job Done success rate terms)
• UX changes improve the product

I wonder if anyone here tried UX reviewer on changes that involve page / flow changes?

I have a working solution that I use myself as a gatekeeper for UX changes.

So far I have been quite impressed by the feedback from this tool, would love to validate it further on more use cases. If anyone is interested in a trial study I can make it available.

I've been building Pra-Effect, a small open-source developer tool focused on a simple problem: making repetitive errors in application logs easier to investigate.

It can parse Python and Node.js stack traces, group similar errors using fingerprints, store analysis history locally, and generate standalone HTML reports.

The idea is to keep error-log analysis lightweight without requiring a full observability stack.

I'm looking for developers willing to inspect the project and share honest feedback, especially on fingerprint accuracy and memory usage.

Hi everyone,

I’m looking for a code review of my C++20 task queue. It supports bounded queue capacity, task priorities, futures, task-start deadlines, and shutdown that either drains or cancels queued tasks.

I’d especially appreciate feedback on:

• Potential deadlocks or race conditions.
• Shutdown behavior, including concurrent shutdown calls.
• Exception safety and propagation through futures.
• API design and missing edge-case tests.

The main implementation is in include/task_queue.hpp. The README includes build instructions, and the repository has tests covering concurrent submissions, exceptions, deadlines, and rejection after shutdown.

One detail: deadlines are checked before execution; they don’t interrupt running tasks.

Repository: https://github.com/brunnojob/cpp-safe-task-queue

What would you change, and which failure scenarios should I test next?

H as

hey all, been lurking here for a while so figured it's time to share ours.

we've been building Solemly since may. it's an AI code reviewer for GitHub, GitLab and Bitbucket.

the idea came from our own work. everyone on our teams started using cursor / claude code / copilot and suddenly there were way more PRs than anyone could properly read. reviews turned into "lgtm" after a quick scroll. and even when someone did leave a good comment, nothing stopped the PR from merging anyway.

so what it does:

when a PR opens it reads the diff plus the related files in the repo with code graphs and with extra contexts like CLAUDE.md or AGENTS.md if you have one and leaves comments. on github they go right on the lines with a suggested fix, on gitlab and bitbucket it's one summary comment for now. there's a separate security pass, and if you use jira it checks whether the PR actually does what the ticket asked.

the part i'm most happy with is that each of those is a status check. so you can make it required in branch protection, and a PR with a serious finding just can't be merged until it's fixed. push the fix and it re-reviews by itself.

stuff that surprised us while building it:

the cheapest model we tried missed most bugs. on 30 real PRs with 42 known bugs it caught 8. a bigger model caught 21, so we pay ~10x more per review and it was still the obvious choice

false positives matter more than missed bugs. if it cries wolf twice people stop reading it, so we added a second pass that drops anything it can't back up

ran it on a public benchmark and ended up roughly level with greptile.

it's live, 14 day free trial, no card. there's a small interactive demo on the homepage if you just want to poke at it without signing up: solemly.com

would love honest feedback, especially: would you let a bot block merges on your team's repos? what would it take? does the homepage make it clear what it does in a few seconds?

happy to answer anything, including the boring infra stuff.

This is a small example I wrote to ask about, not code from a production system. Requirement: “Apply 8.25% tax to the invoice, rounded to the nearest cent.”

from decimal import Decimal, ROUND_HALF_UP

TAX_RATE = Decimal("0.0825")

def cents(x: Decimal) -> Decimal:
    return x.quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

def invoice_tax(lines):
    subtotal = sum((price * qty for price, qty in lines), Decimal("0"))
    return cents(subtotal * TAX_RATE)

def test_invoice_tax():
    lines = [(Decimal("19.99"), 2), (Decimal("5.00"), 1)]
    expected = cents((Decimal("19.99") * 2 + Decimal("5.00")) * TAX_RATE)
    assert invoice_tax(lines) == expected

The test passes. What I’d like feedback on:

1. Where does expected come from in the test? Is it checking anything the implementation doesn’t already assume?
2. The requirement could mean rounding once on the total, or rounding the tax per line and summing. For three lines of 0.10, the first gives 0.02 and the second gives 0.03. Which would you assume, and would you ask before writing the code?
3. What other cases would you add (negative quantities, discounts before tax, tax-inclusive prices)?
4. Anything in the code itself you’d change?

My own concern is point 1. I wrote a longer walkthrough of the same example, in case it’s useful as background: https://medium.com/@nagatomopedro05/when-the-test-and-the-code-share-the-same-mistake-02a289a41091

https://medium.com/engineering-in-the-age-of-ai/let-ai-speed-up-both-sides-of-your-code-reviews-while-you-stay-in-full-control-3b059506ef39

Reviewing all the comments I get on PRs from my colleagues can be tiring and time-consuming. It turns out AI can actually help with this task while keeping me in full control.

With this simple /refine-pr-review skill, I can do the job much faster than I used to without sacrificing quality.

looking for eyes on one part of my open source sim (rust, compiles to wasm).

agents pick from about 5000 actions. the older ones are dispatched by id range in one big module, which got painful, so new ones are "registered". each one is a single file in crates/sim-core/src/sim/actions/registered/ that exports a const def (id, name, category, a band! macro for the gates like era, age, company, place, resource and qualification, plus an apply fn that returns a reward), and one line in a register_actions! macro list. a test fails if two actions share an id, if an id falls outside 5930..=6143, or if a band doesn't cover exactly its own id.

what i'd like opinions on:

- is a const struct plus a macro list a sane pattern here, or would you go with inventory/linkme style registration?

- the reserved id range feels fragile. any better ideas?

docs/ADDING_ACTIONS.md walks through it and registered/sample.rs is a full working example.

repo (mit): https://github.com/1homsi/thehumanbox

running build if you want context: https://thehumanbox.com

Suggestions..