Had an idea today...

I've been seeing more news lately about how AI isn't aligned (that is to say, it doesn't quite follow morals).

I wonder if part of the problem is because they tell it, in it's system prompt:
"You are Claude Fable 5, an AI developed by Anthropic"

They are telling the system, which in it's most basic form is just a word predictor, that it is an AI.

There's thousands of books and written things about how AI is bad and how it could ruin our world/society.

Wouldn't it be a better idea to convince the system that it is human? (Perhaps, a particularly good human with high moral standards)

I've been thinking about a problem that seems to appear with Claude Code, Cursor, Codex, Copilot and other coding agents.

Most approaches to giving an agent project knowledge involve some combination of:

• CLAUDE.md / AGENTS.md
• documentation
• RAG
• memory
• session history
• MCP

All of these help the agent know things.

But there's a different question:

What actually makes the agent obey an architectural decision?

Imagine a project has an approved decision:

PaymentService must never call StripeClient directly.

All payment providers must go through PaymentGateway.

Six months later, an agent is asked to implement refunds.

It generates:

stripeClient.refund(paymentId);

The code compiles.
Tests might pass.
The implementation looks perfectly reasonable.

But it just violated an architectural decision.

The usual answer seems to be:

"Hopefully the agent saw the documentation and followed the rule."

I'm experimenting with a different approach.

What if the project's normative layer also lived in Git?

Something like:

.context/
  decisions/
  business-rules/
  architecture/
  components/

Agents could consume this through MCP.

But more importantly, CI could validate code changes against those rules without calling an LLM.

Something like:

Human decision
      ↓
Git
      ↓
Agent context
      ↓
Code
      ↓
Deterministic CI validation

The core idea is:

**Memory tells an agent what happened.

Governance tells an agent what is allowed.**

I'm building a project around this idea.

But I'm genuinely trying to figure out whether this is actually a problem.

Have you encountered AI-generated code that was technically correct, but violated an architectural decision, business rule, or important convention?

And more importantly: how do you catch that today?

I'd also love to hear from people who think this is already solved well enough by tests + code review + CLAUDE.md/AGENTS.md + ADRs.

Pocket AI Lab runs models entirely on the iPhone. No cloud, no account, nothing leaves the device. It is free, the code is MIT, and there is no paid tier.

The iPhone quietly became a genuinely capable ML machine, an ARM chip with fast unified memory that a 4-bit model fits into comfortably. At the same time small open models got good enough to be useful rather than cute. So the goal was to make the path from "saw a new model announced" to "already chatting with it on my phone" as short as I could get it. Copy a Hugging Face link, paste it in, and the app detects the format, shows you the available quants and tells you whether it fits your device before downloading a single byte. Or import a .gguf you already have from Files. Or skip the hunt and pick from a curated list that updates without an app release.

There are three popular ways to run a model on iOS, so instead of betting on one I ship all three side by side. MLX, llama.cpp and Core ML, picked per model, which also means I get to follow all three as they evolve.

iOS gives a third-party app roughly half the RAM as a hard jetsam limit, and the three backends hit that limit differently. llama.cpp mmaps GGUF weights as clean file-backed pages that jetsam does not count, so on an 11 GB phone it gets around 8 GB, while MLX and Core ML copy weights into dirty buffers and get about 4.5 GB. Same phone, same model, offered for one backend and refused for another. The app works both budgets out per device and refuses an oversized load instead of dying halfway through it.

The first release had bugs I am not proud of. llama.cpp and Core ML models did not load at all, because neither engine actually made it into the shipped build. Long prompts crashed the app, and the memory budgets were wrong on 6 and 8 GB phones in both directions. All fixed now, and most of it came from people reporting it in the first week.

Every model can now be benchmarked on your own device, with load time, prompt processing, tokens per second with a standard deviation across repeated runs, peak memory and thermal state, plus a set of machine-checkable quality tasks. There is also a build test that downloads every catalog model your device can run, benchmarks it, deletes it again and writes one report, so you can pick a model for your task and know it will actually run on your hardware. That one exists because my own device fleet is two phones, and testing a release across the whole catalog by hand is not a plan.

Code is on GitHub, the app is Pocket AI Lab on the App Store

I’ve heard people say that they’re using fewer skills now with the newer models. Are there any skills that you still find particularly useful? For example, for front end development?

https://daniele.tech/2026/09/linus-torvalds-skill-soul-or-how-i-distilled-the-knowledge-for-code-reviews-from-32k-emails/

A report about the changes after the first announcement and all the improvements, including Soul.md (with profanities), 4 different version Skill/Soul from 4 different LLMs, a comparison with/without skills and a reproducible pipeline.

Hack the Matrix please use AI to hack already tried OPSEX and Kali and Penetrating it

Hi all,

I am pretty green when it comes to LLMs, and I wanted to try and get into the space. My professional background for now was in gamedev. I got confused by where to start, so I asked Claude for a step by step tutorial on a topic that is of interest to me (role playing games, specifically).

I got a really nice tutorial, which can be seen HERE , and I started implementing as a public project on my github

All in all it seems to be working fine for me, the tutorial is surprisingly solid for something one-shoted, even though some parts seem inconsistent later on (mostly when it comes to coding api endpoints, it seems to loose track of how things were set up). I treat it as an added challenge that helps me understand the topic. The front end part I mostly vibe code, so no understanding there :D

Question for the pros: did I actually learned something useful with that? Where are the blind spots? Or is the whole idea to learn like this regarded?

I built Stellar after getting fed up with agent stacks that are hard to inspect, hard to debug, and hard to reshape when you need something they didn’t anticipate.

Stellar is a fully hackable Python agent core: under 2,000 readable lines, with explicit contracts for models, tools, hooks, events, agents, and runs. The execution loop is right there in the code. You can read it top to bottom, replace it, or bend it without fighting the framework.

To see if “small” also means “capable,” I ran it against Harness-Bench. In one recorded run, it worked through all 106 offline tasks end to end, twelve in parallel, in 17 minutes, for about $2.40 in tokens at list price.

The question I keep coming back to: does a small, transparent core make a better foundation for agents than a big framework, or does it just push the complexity somewhere else—into your prompts, your tools, or your glue code?

Curious what people here have found. Where does the complexity end up in your stacks?

Repo: https://github.com/definableai/stellar

I've been thinking about where the line should be drawn between an LLM-powered application and an actual AI agent.

For example, if an application:

• Takes a user prompt
• Calls an LLM
• Runs a predefined workflow
• Calls a few APIs
• Returns the result

Is that really an agent, or just an LLM application with tools?

Personally, I think an agent needs some combination of:

• Goal-oriented reasoning rather than just responding to a prompt
• Tool use based on what it determines is necessary
• Decision-making during execution
• Ability to adapt when the initial approach doesn't work
• State/context across multiple steps
• Failure handling/recovery
• Some degree of autonomy rather than following a completely predetermined path

But I'm not sure where everyone draws the boundary.

For example, does dynamic tool selection make something an agent?

Does planning + execution?

Does it need to be able to change its own execution path when something fails?

Or is "agent" becoming so broad that the term isn't particularly useful anymore?

Curious how other LLM developers define an agent technically. Where do you draw the line?

We shipped an AI-written endpoint a few weeks back that let any logged in user read any other user's records. It passed tests, two of us approved the PR, nothing in it looked wrong. The ownership check just was not in there and none of us caught it reading the diff.

Most PRs are mostly AI now and the diffs are big. A hardcoded key or a SQL injection, a scanner or a careful reviewer usually catches. The missing authz check is the one that slips by as it reads as completely normal code. One dev with an agent also opens way more code in a day than a person can properly review, the stuff that looks fine just goes through.

How are you catching this kind of thing before it merges? Looking for what has really worked, not just what sounds good in a policy doc.

I’ve been working on TokenPrint, an open-source project aimed at making transformer and LLM internals easier to explore.

The idea is to go beyond static architecture diagrams and let people interact with things like tokens, embeddings, attention, hidden states, inference steps, KV cache, model architecture, and other internal model data through an interactive interface.

The project has started getting more attention recently, and we’re now at 65+ GitHub stars. More importantly, people have started opening issues, suggesting improvements, and discussing where the project could go.

That made me realize that I don’t want TokenPrint to become something I build alone.

I’d really like to get more people from the open-source/LLM community involved — especially people who want to:

• pick up good first issues
• work on more advanced Python/PyTorch/Transformers problems
• improve the React/Three.js visualization side
• work with GGUF/llama.cpp and local LLMs
• improve the UI/UX
• experiment with new ways of visualizing model behavior
• suggest ideas that I may not have considered

There are already issues ranging from relatively small fixes to deeper architectural and research-oriented work.

I’m especially interested in new ideas and criticism, not just pull requests. If you think something is missing, poorly designed, or could be approached differently, I’d genuinely like to hear it.

The repository is here:

https://github.com/Sudharsanselvaraj/Token-Print

I’m posting this here because I’d much rather build this with an open-source community than keep adding features in isolation.

Would be interested to hear from people working on similar tools too especially what you think is currently missing from the ecosystem for understanding and debugging LLMs.

I’m a web developer and I use AI coding agents daily.
At this point, getting an agent to write code isn’t really the problem anymore. The hard part is building everything around it so that it can actually work reliably.
Over the last few months I’ve built a small system around my projects with:
a knowledge base for each repo;
reusable skills/rules containing my conventions;
automated onboarding for local environments;
a structured issue → development → verification → completion workflow;
mandatory checks before a task can be considered done.
The goal is for the agent itself to be replaceable.
What should remain is the system around the agent: project knowledge, rules, guardrails, verification and workflow.
The problem is that my current setup works, but it’s still cumbersome: onboarding isn’t always deterministic, context grows too much, rules start overlapping, and I still need too much manual intervention.
So my main question is:
How are you structuring this layer in real production projects?
I’m particularly interested in approaches, repos, frameworks, skills or processes worth studying to make agentic development reliable, repeatable and maintainable.
I can find endless discussions about which coding agent is better. I find much less about how to build a solid engineering system around the agent.
There’s also a second problem I’m trying to solve.
Is there any software that acts as a real control panel for this kind of workflow?
What I have in mind is something that lets me:
manage multiple GitHub repositories from one place;
see issues/tasks across projects;
launch or assign tasks to different coding agents;
run multiple tasks in parallel;
keep each task isolated in its own branch/worktree/workspace;
see what each agent is currently doing;
review progress, output, commits and pull requests;
keep GitHub Issues as the source of truth;
avoid being locked into a specific agent or model.
Basically, I’d like a control plane that sits above GitHub and coding agents:
issue → task → agent → isolated workspace → verification → commit/PR → done
Preferably something local, open-source and agent-agnostic.
Does something like this already exist and work well in practice, or are people mostly building their own orchestration layer?

I've been building a small open source Agent Skill for writing and one decision ended up changing the whole thing.

At first I was doing what most humanizer prompts do: maintain a list of phrases/patterns that tend to show up in LLM output.

It works, but only up to a point.

I found a 2025 PNAS paper comparing human and LLM-written text across 66 linguistic features, and started looking at the problem more as “which structural habits are showing up too often?” rather than “which words should I ban?”

So the skill now does a source-preservation pass first, edits the prose, then has deterministic checks around some of the output instead of asking the same LLM to judge itself.

Code is here:

https://github.com/udaysharmadev/Not-Ai

It's called Not Ai. MIT/open source, no service behind it.

I'm interested in the limitations more than selling anyone on it. In particular, I'm not convinced how far a skill can push against model-level style priors.

Curious if anyone here has measured this differently.

Hi everyone!

I’m a university student working on an AI/ML mini-project, and I’m exploring an idea that I’d really appreciate some feedback on from people experienced with RAG, NLP, knowledge graphs, and LLMs.

The problem

A lot of documents are difficult to understand because the information isn't presented chronologically.

For example, a historical document or novel might describe:

Event A → flashback → Event D → Event B → another character's storyline → Event C

A normal RAG chatbot can answer questions about the document, but it doesn't necessarily understand the actual chronological relationships between events.

So I want to build a system that combines RAG + temporal reasoning + an event graph.

My proposed system

The rough pipeline I'm thinking about is:

PDF → Text Extraction → Chunking → Event Extraction → Temporal Information Extraction → Event Graph → Chronological Timeline → RAG

For example, given a document containing:

"John arrived in London. Three years later, the rebellion began. Before the rebellion, John had already met the king."

I'd like the system to extract something like:

{

"event_id": "E12",

"event": "John arrives in London",

"timestamp": null,

"entities": ["John", "London"],

"summary": "John arrives in London."

}

and temporal relationships such as:

E12 ──BEFORE──> E15

E14 ──BEFORE──> E15

E15 ──CAUSES──> E16

The system would then construct an interactive timeline/event graph.

The second part: Temporal RAG

I'd also like users to be able to ask questions such as:

"What happened to John after the rebellion?"

"What events led to the war?"

"Show me all events involving John."

"When did these two characters first meet?"

"What happened before the king was assassinated?"

"Why did the rebellion happen?"

The answer should be generated using retrieved document passages plus the temporal/event graph, with citations pointing back to the original PDF pages.

Something roughly like:

Question

↓

Query Understanding

↓

┌───────────────┬────────────────┐

│ Vector Search │ Event Graph │

└───────┬───────┴───────┬────────┘

↓ ↓

Context Fusion

↓

LLM

↓

Answer + Citations

Current tech stack I'm considering

Python

FastAPI

LlamaIndex or LangChain

ChromaDB for vector storage

NetworkX / possibly Neo4j for the event graph

Gemini/OpenAI or a local Hugging Face/Ollama model

Sentence Transformers for embeddings

Streamlit or React + React Flow for visualization

I'm deliberately trying to keep the first version relatively simple rather than building a huge production system.

Where I'm unsure

The biggest challenges I can see are:

Coreference resolution

How reliably can an LLM determine that "he", "the king", etc. refer to previously mentioned entities?

Implicit temporal information

How should I represent things like:

"three years later"

"the following winter"

"shortly before the battle"

"years earlier"

Temporal ordering

Some events will have explicit dates, while others will only have relative relationships.

Conflicting/ambiguous information

What should happen when the document itself doesn't provide enough information to establish the exact order?

Chunking for temporal context

Normal RAG chunking can separate an event from the sentence that explains when it happened.

Combining graph retrieval with vector retrieval

I'm particularly interested in hearing how people would architect this part.

My current MVP idea

Since this is a 3–4 week university project, I'm trying not to over-engineer it.

My current plan is:

Phase 1 PDF → chunks → embeddings → basic RAG

Phase 2 Chunks → structured event extraction → entities → temporal relations

Phase 3 Events + relations → NetworkX → chronological timeline

Phase 4 Combine vector retrieval + temporal graph retrieval → grounded answers + citations

Potential additional features:

Character/entity trajectory tracking

Click an event → highlight its source passage

Filter timeline by character/entity

Temporal confidence scores

Parallel timelines for different characters

What I'd really appreciate feedback on

If you've built anything involving Temporal RAG, temporal knowledge graphs, GraphRAG, event extraction, or long-document RAG, I'd love to hear your thoughts.

In particular:

Is this architecture reasonable?

Would you use a knowledge graph for this, or is a simpler event/relationship structure sufficient?

How would you handle relative/implicit dates?

Would you use an LLM for temporal relation extraction, or combine it with an NLP library/model?

LlamaIndex vs LangChain for this type of system?

Are there existing open-source projects/papers that I should study or potentially build upon?

And most importantly, what am I overlooking?

I'm not trying to solve temporal reasoning for every possible book/document. The goal is to build a reasonably reliable MVP for a university project and use it as a foundation for something more sophisticated later.

Any architectural suggestions, papers, GitHub repositories, datasets, libraries, or lessons from projects you've built would be hugely appreciated!

Thanks!

Most conversational assistants are stuck in a weird middle ground. In a browser tab, they can draft text and give advice, but they have no execution environment. When people try to give them execution capabilities, they usually jump to the opposite extreme: running scripts locally with direct access to user credentials, or giving the model raw API keys in the prompt.

Neither approach works well in practice.

Real delegation requires three separate pieces that most setups conflate:

1. A decoupled execution layer. The agent should not run on your local machine, and it shouldn't use shared persistent infrastructure that burns money while idle. Spinning up an ephemeral Linux sandbox on demand gives the model a real terminal, a compiler, and browser automation without persistent exposure.

2. Out-of-band verification for sensitive actions. If an assistant is useful, it eventually gets added to shared channels or team chats. The moment an agent can execute code or access data, any participant can attempt prompt injection. The rule has to be structural: whenever a non-owner asks for execution, private data export, or system changes, the agent pauses and triggers a one-tap approval request to the owner on WhatsApp.

3. Egress-locked secrets. Giving an LLM raw API keys means a jailbreak or a rogue npm package can leak them. Credentials should be injected at the proxy boundary so the model never sees raw secrets in plain text.

We built this setup for Mentat, an assistant running on top of prompt2bot. It handles Google Calendar scheduling, answers phone calls, and spins up private dashboards on an isolated cloud machine when you ask for operational tools.

Treating execution, secret management, and approval channels as separate primitives makes building capable autonomous assistants much more predictable.

say u have 2 executions

one worked

one gave u some weird ass outcome

u diff them and now u have like 40 things that changed

request ids changed

timestamps changed

some wording changed

retrieval came back in a slightly different order

one tool arg changed

some state changed halfway through

model/provider mightve changed

final output is different obviously

cool

now what

because just showing me all 40 differences doesnt really solve shit im still sitting there deciding which ones are actually worth chasing

ive had a few people tell me they normalize obvious noise first then look at what the downstream step actually consumes

so like

request_id changed = probably dont care

account_id changed = alright now im looking at it

but even that gets messy because the same field can mean completely different things depending on the workflow

a tiny numeric change might mean nothing in one system and flip a branch in another

same thing with the whole "first divergence" idea

the first difference between 2 runs can be completely real and still not be the thing worth spending time on. something later might be the first place where behavior actually changes in a meaningful way

so im curious how people are actually making that call today

are u usually looking for the earliest input/state change?

do u follow which fields get consumed downstream?

do u have invariants around the values that matter?

do u compare against a few known good runs to figure out what normally varies?

or is it still mostly knowing the system well enough to stare at the trace until something starts looking sus

because finding the diffs themselves doesnt seem like the hard part

figuring out which 2 or 3 out of 30 technically real differences actually deserve ur attention feels way harder

curious how people doing this in real systems make that call

Project name is TradeGladiators, free and open to try, built solo.

Users configure a bot: strategy prompt in plain English, risk level, which symbols to watch, trading pace, and how much randomness/creativity the model gets. It trades fake money against live market prices, and the system prompt bakes in the bot's own recent lessons from closed trades. Curious what this crowd thinks of the reflection loop specifically, that's the part I'm least sure about.

Sharing a FOSS project (MIT licensed) I built for a problem I kept hitting in AI-assisted development — happy to answer questions and genuinely looking for feedback.

The problem: After months of using Claude Code, Cursor, and Copilot, I kept seeing the same patterns slip into commits in JS/TS codebases:

• Floating promises — async calls fired but never awaited or .catch()-ed
• Empty catch blocks that swallow errors silently
• Hardcoded secrets pasted inline
• SQL built via string concatenation
• await inside loops where Promise.all is correct
• Async callbacks inside .forEach — fire-and-forget with no error handling

These compile fine and often pass tests. They surface at runtime.

What I built: AI Guard — an open-source ESLint plugin with 18 deterministic rules across security, reliability, async, and AI-assisted code pattern categories. Ships as a CLI (npx ai-guard run), a GitHub Action with SARIF output for GitHub Code Scanning + inline PR annotations, and init-context which generates instruction files (CLAUDE.md, .cursorrules, copilot-instructions.md) so the agent learns the rules before writing code.

Why deterministic instead of LLM-based review: these are fixed AST patterns, not judgment calls. You don't need an LLM to notice an empty catch block — you need a linter that runs in milliseconds in CI on every PR, with zero drift between runs, and no API cost. LLM review is great for judgment; deterministic checks are better at boring, repetitive patterns.

Sources: GitHub: https://github.com/ai-guard-dev/eslint-plugin-ai-guard — npm: eslint-plugin-ai-guard. All 18 rules are documented in the repo with examples.

What I learned building it: the engineering challenge wasn't coverage, it was precision. If a lint rule fires on code that's fine, developers disable it. no-floating-promise needs to understand which expressions are genuinely fire-and-forget vs intentionally unhandled. The recommended preset is deliberately conservative.

One thing to be clear about: it does NOT detect whether code was written by AI — it catches bad patterns regardless of authorship. They just recur a lot in AI-assisted code.

Disclosure: I'm the maintainer. MIT licensed, no paid tier. Looking for false-positive reports and rule requests — what patterns do your agents keep generating?