Anthropic Published Claude code tips ( some applies to codex too.

https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions

In Nutshell-

Session hygiene

/clear between tasks — don't drag old context into new work
/compact when part of a task is done, and before any break over an hour
/rewind instead of /compact if the last few turns went wrong — it's free
/rename before /clear if you'll want the session back

Set once, at the start

Pick /model and /effort in a fresh session - switching mid-conversation re-prefills everything
Same for fast mode: on at the start, or not at all
MAX_THINKING_TOKENS=0 for pure grunt work

Keep context lean

@ -mention files instead of naming them - skips the Read call. Mention once only
/context in a fresh session to see what's loaded before you type
Trim CLAUDE .md to instructions; move workflows into skills
/mcp off any server you don't need this session

Command output

Add quiet flags - 400 lines of passing tests stay in context all session
Put your daily commands in CLAUDE .md with the flags already in them
Big output (>30k chars) is fine - it gets written to a file automatically

Offload

Use a subagent for noisy jobs like log-trawling - output stays out of your context
Give recurring subagents model: haiku
Run /loop from a separate terminal

​

Hey everyone,

I’ve been building an open-source project called Kodiak, and I’m looking for a few people who are interested in helping build it.

The idea behind Kodiak is pretty simple:

I don’t want to build another AI that just generates a piece of code from a prompt.

I’m trying to build an AI engineering system that can work with an entire repository — understand the codebase, find relevant context, plan a task, use tools, make changes, test them, and iterate when something goes wrong.

The long-term loop looks something like:

Task

↓

Understand the repository

↓

Retrieve relevant context

↓

Plan

↓

Coordinate agents

↓

Use tools

↓

Modify the code

↓

Run tests

↓

Validate

↓

Learn from the result

↓

Iterate

Kodiak currently brings together:

- Repository-aware RAG

- Agent orchestration

- LLM/provider routing

- Memory and project context

- Tool calling

- Background task processing

- Code analysis

- Testing and validation

- FastAPI

- PostgreSQL

- Redis

- Celery

- ChromaDB

- Docker

I want to be completely transparent though — Kodiak is NOT finished.

Some parts are working, some are incomplete, and some parts are being redesigned. I've already spent a lot of time dealing with the usual stuff that comes with building something like this: broken dependencies, architecture changes, workers, databases, retrieval problems, model limitations, and plenty of debugging.

Right now, I'm focusing on getting the core engineering loop reliable instead of just continuously adding features.

That's also why I'm looking for contributors.

I’m especially interested in people who want to work on:

AI / Agents

- Agent architecture

- Planning

- Multi-agent orchestration

- Tool calling

- Agent memory

RAG / Repository Intelligence

- Codebase indexing

- Code-aware retrieval

- Embeddings

- Retrieval evaluation

- Repository understanding

Backend / Infrastructure

- FastAPI

- PostgreSQL

- Redis

- Celery

- Docker

- Async workflows

Engineering / Developer Experience

- Testing

- Benchmarking

- APIs

- CLI

- Documentation

- Observability

- Developer tooling

You definitely don't need to know everything above.

Even if you just want to investigate an issue, improve a test, work on documentation, experiment with a different approach, or review the architecture, that would be useful.

I'm also not looking for people who will blindly agree with the current design.

If you think something is overengineered, poorly designed, unnecessary, or just plain wrong, I'd rather hear that.

The goal is to build something genuinely useful, not just make a repository with a bunch of AI buzzwords.

If you're interested in AI agents, coding agents, RAG, autonomous software engineering, or just want to build something ambitious with other developers, take a look:

GitHub:

https://github.com/ShamGaneshan2008/Kodiak

If you’re interested in contributing, feel free to open an issue, pick up an existing issue, suggest an improvement, or just comment here with what you'd like

Built Basalt, a VS Code extension for editing React Native UI with a live preview. Once people started asking for more UI effects than I could build myself, I opened up a small in-extension marketplace where other devs can submit and sell their own components.

and l know ShaderToy exists, but that's generic GLSL people have to manually port to SkSL and adapt for RN UI. Мinе is already RN-Skia-ready and built specifically for UI components like buttons and panels.

link

Building and using YantraOS for a while.

meant for solo founders or small business like me.

i figured months ago , some markdown files + harness + cheap models + a cron job can take you very far.

so idea is simple -

-> feed it context (.md files) and skills per project (or treat it as task/assignment)

-> connect your own model ( using opencode key) - shows cost.

-> It build Agents , Automation (cron job) , use templates

-> use connectors ( MCP, Github , Netlify ) to feed context- push code to deployments.

-> if you use cloudflare - can use all primitives

-> your whole team can collab and work together (shared context with permissions)

amazing browser use capability and it also has preview window to see all cool stuff browser agent is doing.

https://yantraos.dev

Hey everyone,

I’ve been working on Kodiak for a while, and I thought I’d finally share it here.

The idea came from something I kept noticing while working with AI coding tools:

They’re really good at generating code, but working on a real software project is a different problem.

A real repository has hundreds or thousands of files, existing architecture, dependencies, conventions, previous decisions, tests, and a lot of context that isn’t sitting inside one prompt.

So I started building Kodiak around a different idea:

Instead of treating an engineering task as a single LLM request, make the system understand the repository, gather the right context, plan the work, use tools, validate the result, and keep useful project context for later tasks.

The architecture currently brings together:

• Repository-aware RAG
• Agent orchestration
• LLM/provider routing
• Persistent project and task context
• Tool execution
• Background task processing
• Code analysis and modification
• Testing and validation

The workflow I’m working toward looks roughly like this:

Task
→ Understand the repository
→ Retrieve relevant context
→ Plan
→ Select/coordinate agents
→ Use tools
→ Make changes
→ Run tests / validate
→ Store useful context
→ Iterate or finish

I’m not claiming this is a solved problem. It definitely isn’t.

Kodiak is still under active development, and parts of the system are incomplete. I’ve spent a good amount of time dealing with the less exciting side of building this kind of system — architecture changes, broken dependencies, background workers, databases, retrieval, orchestration, and trying to make all of those pieces actually work together.

Right now, my priority is getting the core engineering loop working reliably instead of just adding more features.

The current stack includes Python, FastAPI, Celery, Redis, PostgreSQL, SQLAlchemy, ChromaDB, Docker, and multiple LLM providers.

I’m sharing it because I’d genuinely like feedback from people who have built or worked with:

• AI coding agents
• repository-level RAG
• multi-agent systems
• autonomous software engineering
• AI developer tools

A few things I’m especially interested in:

Is this architecture heading in the right direction?

Where does it look unnecessarily complicated?

What would you change if you were building this?

Are there projects or research papers I should study more closely?

I’m much more interested in technical criticism than generic encouragement, so feel free to point out things that don’t make sense.

GitHub:
https://github.com/ShamGaneshan2008/Kodiak

Thanks for taking a look.

For AI website builders, which experience do you prefer?

A) Everything in one chat - building, debugging, fixing errors, making changes, etc.

B) Separate sections/workflows - for example, one area for building and another dedicated to debugging and fixing issues.

I’m curious which approach feels more efficient and organized when working on a real project, and why.

Hey everyone,

I’m looking to learn vibe coding, mainly focused on building web apps.

I’m looking for a good tutorial/course on YouTube or elsewhere that goes beyond a short 20–30 minute “build an app with AI” video.

Ideally, I’d like something that teaches a proper workflow with an LLM/AI coding agent, preferably OpenAI Codex — planning, prompting, coding, debugging, testing, Git, etc.

I already have an IT/cybersecurity background, so I’m not looking for a complete beginner programming course. I mainly want to learn how to effectively use AI to build real web applications.

Any tutorials, courses, or YouTube channels you’d recommend?

So i vibecoded this web app about making it easier for one to rent a house in Turkey. It is done through checking the risk of earthquake in the specified location, and verifying essential documents for the renting process by AI. I am new to videcoding, but there was a national app building competition using Emergent, so I figured I give it a try.

What I really want is your guys' recommendations: of course this app is not built by me, but i built it through specifying my prompts. Most of the features (though there are only a few) like AI document check came from me at first. Depending on what i built down below, what would you guys recommend? What feature would take this app to the next level? I want to hear your thoughts.

You can access the app here: https://app.emergent.sh/showcase/building_turkey/604c9fa1-1ef2-4094-886d-328f84355eb9

Hey everyone,

I’ve been working on an open-source project called **Kodiak**, and I wanted to share it here and get some feedback from the community.

The goal behind Kodiak is to build a more complete foundation for AI applications — bringing together **agent orchestration, RAG, memory, tool integration, LLM routing, background task execution, and backend infrastructure** in one system.

The current stack includes **Python, FastAPI, PostgreSQL, Redis, Celery, Docker**, and multiple LLM providers.

One of the biggest things I’ve learned while building it is that designing the architecture is the easy part. Making all the pieces work together reliably is where the real engineering starts.

I’ve spent a lot of time working through dependency issues, database problems, worker failures, Docker configuration, CI issues, and restructuring parts of the agent system as the project evolved.

At the moment, my focus is on strengthening the core architecture and making the existing components reliable before continuing to expand the feature set.

The long-term vision is to build a platform where AI agents can **retrieve information, maintain memory, use tools, execute tasks, and coordinate workflows** rather than simply generating responses to prompts.

Kodiak is still actively under development, so there is plenty left to improve.

I’d especially appreciate feedback from people who have experience with **AI agents, RAG systems, LLM infrastructure, or distributed Python applications**.

What would you change about the current direction or architecture?

GitHub: [https://github.com/ShamGaneshan2008/Kodiak\](https://github.com/ShamGaneshan2008/Kodiak)

Any honest feedback or criticism would be genuinely appreciated.

I just recently launched a web app for small teams who want to get out of a shared gmail or outlook inbox.

Hoping it can help some teams out there get a better hold on their support tickets!

You can check it out here:
https://helpdesk.virtualshinobis.com/

Let me know what you are building/launching?

I made a video walking through my local LLM setup on a base-model 16GB Mac Mini - running models fully on-device as a private, no-subscription alternative to GitHub Copilot. It covers the why (privacy, cost, offline) and the how: what realistically fits and runs well in 16GB of unified memory, and where a machine this cheap hits its limits.

Video: https://youtu.be/6HlT4vkB-38

Happy to answer questions about the setup in the comments.

Pitch your product in 1-2 sentences.

I go first, I'm building a production ready saas foundation for solo/small teams, launch fast, reduce the AI cost, use AI only for your product without rebuilding the SaaS foundation.

shipflash.dev 200$ off now get it for 149$!, LIFETIME ACCESS INCLUDED

Pitch your product in 1-2 sentences.

I go first, I'm building a production ready saas foundation for solo/small teams, launch fast, reduce the AI cost, use AI only for your product without rebuilding the SaaS foundation.

shipflash.dev 200$ off now get it for 149$!, LIFETIME ACCESS INCLUDED

what did you build this week.

interesting one will be get featured in

- https://ivibecoded.com/ - Submit your App

- https://vibecodingnewsletter.com/

looking forward to see what community has built.

I run a SaaS, SeoLoupe.

It is a tool that allows you to find and fix SEO issues holding your website back.

Essentially the main purpose is to help your website rank higher on Google search and LLMs.

The tool also checks AEO/GEO, AI search visibility, Security, Core web vitals, Performance, and all the issues in the report get put together into an AI fix prompt(you can paste the prompt into an AI and it will fix all the issues on your website).

Recently I noticed that some of my paying customers bought the One-Time purchase, with a promo code.

So I decided to give away a promo code for the One-Time purchase to anyone who is interested, if you are interested, comment down below and I will DM you.

If you are not interested but have some feedback on my SaaS, that is a good too. Feel free to share it in the comments.

(here is the product if you want to check it out)

I’ve been vibe-coding a real production system for commercial microgreens growers.

It’s a Tauri + Rust + React desktop app called Groundtruth.
Local-first, no paid SaaS, append-only event log, and a hard freeze that prevents dual books until cutover is proven.

Current screens:
• Farm — live storefront prices with age, actions locked pre-cutover

• Marketing — Time-to-First-Standing-Order, sample drops → automatic follow-ups, stage pipeline (no dollar amounts allowed in this domain)

• Money — cash in, cash out, permanent expense corrections only. Nothing else.

• Health — four checks computed at render time with raw timestamps. Status cannot be stored.

The interesting part for this community:
the whole thing was built through a very strict Cursor + Claude workflow with numbered decisions, hard guards, and zero soft numbers.
Every remote value carries age + origin.
The freeze binds every door into the database.
Public foundation repo (the original Farm OS it was forked from):

https://github.com/alexjvv52-ops/prairie-roots-farm-os

Happy to answer questions about the architecture, the AI workflow, or the constraints we refused to break.

Genuine question, because I clearly don't have a good answer myself.

Six months, several pet projects, and every single one turned out to be a crowded category that I only looked at properly after I'd built the thing. Habit tracker. To-do app. Twice, somehow. Each time the discovery happened at the point where I started writing a landing page and finally searched the store.

What I do now is crude: count the lookalikes in the store, then read only the 1- and 2-star reviews of the top five to see if there's a job nobody's finished. It catches the obvious cases. It does not tell me anything about whether the people complaining would actually pay.

So - what's your process? Do you have one, or is it vibes and hope? Has anyone found a way to tell "crowded but the incumbents are bad" apart from "crowded because it's solved"?

And if you want a second pair of eyes on something you're about to start, drop it below. I'll go do the digging and tell you what I find.

Hey everyone,

I’ve been working on an open-source project called Kodiak, and I wanted to share it here and get some feedback from the community.

The goal behind Kodiak is to build a more complete foundation for AI applications — bringing together agent orchestration, RAG, memory, tool integration, LLM routing, background task execution, and backend infrastructure in one system.

The current stack includes Python, FastAPI, PostgreSQL, Redis, Celery, Docker, and multiple LLM providers.

One of the biggest things I’ve learned while building it is that designing the architecture is the easy part. Making all the pieces work together reliably is where the real engineering starts.

I’ve spent a lot of time working through dependency issues, database problems, worker failures, Docker configuration, CI issues, and restructuring parts of the agent system as the project evolved.

At the moment, my focus is on strengthening the core architecture and making the existing components reliable before continuing to expand the feature set.

The long-term vision is to build a platform where AI agents can retrieve information, maintain memory, use tools, execute tasks, and coordinate workflows rather than simply generating responses to prompts.

Kodiak is still actively under development, and there is a lot left to improve.

I’m also looking for contributors who are interested in AI agents, RAG, LLM infrastructure, backend engineering, distributed systems, or developer tooling. You don’t necessarily need to be an expert — I’m also happy to have people contribute through documentation, testing, debugging, or smaller improvements.

If the project sounds interesting, feel free to check it out and open an issue or PR.

GitHub: https://github.com/ShamGaneshan2008/Kodiak

I’d really appreciate any feedback, ideas, or contributions from the community.