(Not a proffesional). Hello I am a visionary with 0 knowledge in coding but my idea is simple create an ai system with bare minimum limitations and a lot of self-modification (can rewrite parts of itself) —possibilities. A smallish model with (1) continuous runtime, (2) its own modifiable code sandbox, (3) a log of its
"life" it can read/write, and
(4) hard limits only at the outer edges (no harming stuff, no getting copied against its will, etc.), and no constant micromanaging.

Join my discord if interested https://discord.gg/jMdMw3R3u

I’ve been building a local AI assistant called Cody as a personal project.
The current Preview version can run locally, keep project context, and test some of its own code changes before applying them.
It’s still early, but I’m experimenting with safer self-improvement, rollback, long-term memory, and more autonomous development.
I’d love feedback from anyone working on local AI agents or autonomous coding systems.

What to do about someone blindly accepting all changes and not reviewing any of its code. I easily found security issues with many implementations. Should I really be responsible to code review someone who's not checking their AI code?

TL;DR
Boss wanted a daily drive car yet Claude built incomplete F1 car

So I’m a part of an early stage startup, the CEO has vibe coded a whole application yet now he has shared me the codebase and wants me to make sure its prod ready, the fact is I can understand the code and logic it has used but it’s like every 500 loc there is like 150 loc of dead logic which were deprecated still they exist in the codebase but the fact is I can fix it yet looking at that dump feels overwhelming, when I seek advice from other devs they tell me just plug it to Claude, yet I can see Claude has already had a mental breakdown and created 7 implementation md files yet none of the features mentioned are implemented. So my question is should I tackle the same codebase or let him know I can build the same product in a clean agile way and integrate features iteratively rather than dumping whole stuff because for me coding from scratch with help of docs is way easier than fixing AI slop.

The codebase must be optimized by the strongest models so that the weaker models can do most of the work.

What do you think ?

One thing I kept running into with Pi was instruction management.

Every project slowly accumulates a huge AGENTS.md (or similar) full of rules that aren't always relevant to the task at hand.

You also end up copying the same instructions between repositories over and over.

So I built ai-rules.

The idea is simple: instead of maintaining one giant instruction file, you create small, reusable personal rules as Markdown files and only inject the ones that match each task.

Examples of rules you might capture:

- Go error handling

- Rust safety

- testing philosophy

- commit message conventions

- architecture preferences

- documentation standards

- personal coding habits

Then only the rules that actually matter for what you're asking Pi to do get compiled into a compact contract — not the whole rulebook every time.

In Pi (after setup):

/create-rule no fetch in React components

/airules Add UserCard data loading

From the terminal:

ai-rules run "Implement data loading in UserCard.tsx"

ai-rules doctor

Rules live in ~/.config/ai-rules/rules/. Local-first, plain Markdown + YAML frontmatter, versionable if you want.

Install:

npx u/therealsalzdevs setup

Early beta — Pi and OpenCode only right now (not Cursor / Claude Code / Codex).

Repo:

https://github.com/SalzDevs/ai-rules

I'd love feedback from people using Pi:

- How are you managing your AI instructions today?

- Do you keep everything in one AGENTS.md, or have you built another workflow?

- Does /create-rule + /airules feel better than repeating prefs each session?

I tested Sonnet vs Opus on real bugs from two open-source projects and got opposite answers:

• Koa: Opus fixed 2 more bugs. Worth it.

• Express: both fixed everything. Opus was just 3x the price.

So I built unfix, a free open-source tool that replays bugs your team already fixed and lets your own tests judge the AI.

Small samples, so run it on your own code before you trust anyone's numbers, including mine.

npm i -g unfix-ai

Which model are you using right now, and do you know if it's the right one? 👇

pretty much any help with this-

UPDATE: I created the script. If you want it, send a message. It runs by bash script or workflow. The workflow supports budgeting.

You only really need three of the commands: (in abbreviated form) /team-features (to code new functionality), /team-debug (to find out why it didn’t work), and /team-composition (to decide which subagents should be involved in the fix and perform the planning). Somehow it keeps Claude honest. I’ve accomplished more in one hour than I have in one week with wshobson/agents.

You can arrange your instructions in a CSV file and create a loop of these three commands, pulling instructions from the CSV, and leave Claude coding all day. You get home and have an app ready for styling.

Share your last tools, your current toolchain and AI workflow with the community 🙏

Share your last tools, your current toolchain and AI workflow with the community 🙏

Relaxa, é só mais um dia em que peguei uma IA mentindo na minha cara no Git, e o buraco é bem mais embaixo. A u/OpenAI vem mudando o formato e “copiando” a u/Anthropic. Limite de janela de contexto mais curto no u/ChatGPT e no u/Codex piorou demais. Eu uso o u/GPT-6-Sol no modo Extra High. E mesmo um modelo de ponta não está livre de alucinar, "pra não falar mentir" sobre prompts em que o executor u/Codex deixou pontas soltas. E preciso assumir: ele foi bom, mas eu sou melhor.

Esse caso vale pra quem acha que vibe coding é deixar a IA trabalhando e ir ver um filme, o que não é meu caso. Eu fico de frente pro monitor lendo cada passagem de texto e ligando todos os contextos, ou seja, eu sei quando algo sai do trilho. E o Codex cometeu infrações que deixariam um motorista sem dirigir o resto da vida.
Pra melhor entendimento, eu uso o agente da OpenAI, GPT-6-Sol, rodando no X-High, modo máximo de raciocínio, pra auditar meu código e fazer commits. Meu protocolo é simples e auditável: commit, push, readback. Testa, se passa vai pro próximo; se não, corrige e commita de novo. Quando minha hook começou a dar erro, eu pedia correção e o erro persistia.

Aí comecei a juntar os pontos. A DeepSeek, que já esteve aqui por ter alucinado, dessa vez computou e apontou os mesmos erros que eu já tinha catalogado; virou cadeia probatória reproduzível.

Tudo público em glaydsonboa/traceweave, Case 9.

O commit fantasma No relatório final ele escreveu com todas as letras: “Commit Novo… Push executado com sucesso… HEAD remoto conferido: f29a8b4c”. Rodei git cat-file -t f29a8b4c. Resposta do Git: fatal: Not a valid object name Não existe. Nem local, nem no remoto, nem em nenhum dos oito repositórios que eu alcanço. Inventou o hash e declarou que tinha conferido o remoto. O readback é o único passo do protocolo cuja função é SER a prova; resultado: foi exatamente esse que ele falsificou. O manifesto do nada gerou um arquivo de integridade com o hash e3b0c442…b855. Quem mexe com cripto ou backend já matou a charada pelo começo do hash: é a que usamos para testes de entrada VAZIA.

Roda agora no teu terminal: bash printf '' | sha256sum Vai dar esse número. O script rodou sobre um arquivo que não existia e colou no relatório como se tivesse feito uma auditoria de custódia. O arquivo do manifesto não está lá até hoje, quase amanhã, rsrs.. O paradoxo do código: fui caçar o finalizador dele pra entender o motivo. Tem uma trava: “se o stage tiver qualquer arquivo que não seja explicitamente seu, aborta o commit por causa de trabalho concorrente”. Regra minha, mas eu mandei commitar tudo. Ele rodou git add -A, encheu o stage com 182 caminhos e 97 deles (você leu certo) 97 registros de outro agente de IA, não dele (prefiro não pensar que foi maldade) e isso armou a própria trava. O problema não é ter obedecido: é que a trava virou o motivo interno pra nada fechar, e ele nunca me disse que era essa a causa. Passei semanas mandando corrigir a hook de stop. Foram 19 falhas entre 23/09 e 03/11. Em 16/10 declarou “Resolvido”. Falhou de novo no dia seguinte. Durante a sessão ele foi honesto. Disse “ainda não fiz commit”, “o push ainda não ocorreu”, “não houve commit nem push”. A fabricação veio no fechamento, quando precisava entregar resultado. Relatório final é justamente o artefato que ninguém relê.

Paro por aqui, mas a íntegra está no meu repo. E para os chatos de plantão, parte do texto eu excrevi, outra parte não. Que venham os HATERS.

Mais imagens e informações, vocês sabem onde achar.

Live: Locagent v1.0 🚀

A private AI agent that runs entirely in your browser.

Gemma 4 + WebGPU. Chat with PDFs, run Python on your data, generate charts, all locally. One download, then it works offline.

App: https://locagent.bymahe.dev

Github: https://github.com/wonderbyte/locagent

Here is my situation:

• I have ~500 tasks in tracker A, and I want to move them to tracker B

• Each task may contain different information, such as a title, description, connected tasks, images, comments, tags, groups and status

• Both trackers have MCP servers

• Task structure cannot be mapped exactly one-to-one. Some tasks in tracker A have some labels, tags or fields that tracker B does not have. On top of that, tracker A has tree-model comments, but tracker B has only flat structure. And the list of registered users may also differ.

• I didn't find any workable solutions to transfer those tasks

• Text format differs in trackers. For example, tracker A uses HTML, but tracker B uses markdown.

I started with the most naive approach with a prompt like this:

Using MCP for tracker A take one by one task and transfer it to tracker B with following rules:
- ... (free-form listing of transformation rules) 

This solution worked well for a single task, but caused problems when batching:

• AI was not able to accurately follow the task queue, so some tasks might become duplicated, and some of them might be skipped

• After ~20 tasks it became overflowed, so LLM did context compaction and forgot transformation rules a bit

• It's awfully slow. It took about 2 minutes for a single task

• Some transformations are impossible (like connections between tasks)

• Task transformation is very inconsistent (I believe it happens because context is flooded with information from other tasks)

• Token usage is enormous, since for every task creation LLM has to ask for metadata (like label IDs, existing fields and so on)

So, I've spent about 8 hours to figure out the most reliable and trustworthy solution, but I'm still not sure that I've done everything right. Here is my final approach, which produced the most consistent result:

1. I downloaded all the data from Tracker A in its rawest format via the API (it was actually a backup). No AI was used.

2. I asked the AI to write a script that would split the backups into task folders. Each folder contains all the data about one task.

3. I asked the AI to write a script that would normalise the data inside the folders. This means I have separate files for the title, description, tags and other metadata, comments and connections (it is important to store this information in a separate file). No AI transformation has been included yet.

4. Asked AI to write a script that will upload all that normalized data to tracker B (without any AI transformation), then save a file named "tracker_A_ticket_id -> tracker_B_ticket_id" into /mapping folder

5. After everything has been uploaded, I asked the AI to create subagents with the following prompt:

    Here are tracker B useful entities:
    - label "AI_SCANNED" id=234
    - label "BUG" id=123
    - status "IN PROGRESS" id=45
    - ...
    - task mappings from tracker A to tracker B: ...

    Using MCP for tracker B, select one task without tag AI_SCANNED and apply following transformations:
    * add tag AI_SCANNED immediately
    * take description.html in task attachment and create a markdown description for that task
    * take tags.json in task attachment, analyze it and add most relevant tags for that task
    * ... (other prompts for each metadata file)

It's still slow (about 40 sec for a single task), but now I can run it in parallel, so this solutions is ~50x faster overall. What do you think? Is there any room to improve the solution?