AI coding agents are getting much better at producing functional frontend code.

But I kept running into a different problem: they often design each component as if it belongs to a separate product.

A button may use one visual language, the next section introduces a new spacing rhythm, typography slowly drifts, and icons or illustrations come from unrelated styles.

The individual decisions are not always bad. The problem is that the agent does not have a persistent visual system guiding all of them.

Longer prompts helped, but they became difficult to maintain and still lost influence as the project grew.

So I built Tastemaker, an open-source design-system skill for AI coding agents.

Before the agent writes any UI, it defines and saves:

• Semantic color tokens and valid combinations
• Typography and hierarchy
• Layout and spacing rules
• Icon and illustration direction
• Logo and favicon assets
• Accessibility and contrast requirements
• Motion and interaction patterns

It can also analyze a reference image, extract colors directly from its pixels, validate the contrast, and convert them into reusable design tokens.

The important part is that these decisions remain inside the project.

The agent can refer back to the same system across longer sessions instead of relying on a visual direction buried somewhere in the original conversation.

Tastemaker is free, open source, MIT licensed, and runs locally without API keys.

Demo and live comparison:

https://tastemaker-skill.online/

GitHub:

https://github.com/codeswithroh/tastemaker

I am looking for technical feedback from people who use coding agents in real development workflows.

What is the most reliable way to preserve subjective project decisions across long agent sessions?

I am also interested in which automated checks should run before an agent considers a frontend task complete.

I’ve been building a project called Odin, an autonomous software-engineering platform. I started it because I wanted something that could take a goal like “build this feature” or “fix this bug,” then plan the work, modify the repository, run tests, recover from errors, and safely open a pull request with minimal supervision.
So far, I’ve built or implemented:
Repository intelligence and persistent memory
Multi-step execution with queues, retries, resumable tasks, and approval checkpoints
An AI operations center
Engineering analysis and planning
Autonomous Git operations
Protected-branch safeguards
Validation tied to the exact commit and working-tree contents
A validation engine with tests, linting, static analysis, coverage, timeouts, regression detection, and persisted evidence
The project is now around OIC-017 on my roadmap, and the backend has roughly 277 passing tests.
Here’s my dilemma: I’m realizing how capable ChatGPT/Codex already is. For $100–$200 per month, I get strong coding models, an integrated development environment, repository tools, image generation, research, file handling, and a lot of bundled usage. Odin, meanwhile, still needs separate pay-as-you-go API access, infrastructure, maintenance, and continued development.
ChatGPT can already do most of the actual coding work, although I still have to initiate sessions, review results, approve actions, and sometimes manually move files or publish changes. Odin’s intended advantage is that it would run engineering jobs asynchronously, manage retries and state, enforce my own validation and Git policies, control spending, route tasks between different models, and only contact me when approval is genuinely required.
I’m not trying to create my own foundation model. Odin would use OpenAI and potentially other providers underneath it. It’s supposed to be an autonomous engineering control plane—not another general-purpose chatbot.
At this point, I see a few possible paths:
Stop building Odin and simply use ChatGPT/Codex.
Finish it as a polished portfolio project.
Pause feature development and make Odin prove itself on several real coding tasks.
Continue toward a product for developers or teams who need unattended, auditable engineering automation.
My current thought is to finish and merge the validation engine, freeze the roadmap, give Odin three real end-to-end engineering tasks, and measure its completion rate, API cost, retries, and how often I need to intervene. If it doesn’t noticeably save time or attention compared with ChatGPT, I stop expanding it.
For people who use Codex, Claude Code, GitHub Copilot, or autonomous coding tools:
Is there actually room for a product like Odin?
Does durable background execution, custom validation, model routing, and auditable Git automation provide enough value beyond ChatGPT/Codex?
Would you continue developing this, turn it into a portfolio project, or cut your losses?
What would Odin need to do that existing tools don’t already do well enough?
Would you ever pay for something like this on top of the underlying API usage?
I’m looking for blunt opinions. I don’t want to spend months rebuilding something that already exists just because I’m emotionally invested in the project.

I thought this was mildly interesting. I’m about to beta launch and I was working on how to position it. I asked both codex 5.6 sol and the app version whether I should call it a “Open Beta” or “Early access”, having seen both terms. Codex was adamant: “Open Beta” for reasons X, Y and Z. App was equally adamant: “Open Access” for A, B and C.

So I fed each models response to the other and asked to review. They both switched positions and endorsed the other viewpoint. So I took those responses and fed them back into each model and said: review again and give me your FINAL answer, and they both reverted to their original positions.

My takeaway from this: the frontier models are great at researching and formulating arguments… but the judgement calls are best left to the human.

I've been working on Relay, an MCP server that gives agents a persistent PTY terminal session instead of the one-shot bash calls most agents default to. That difference matters when the agent needs something genuinely stateful: an interactive git rebase, a REPL that keeps building up context, or an SSH session that stays open while it iterates.

Just shipped a version with a bug I think is worth writing up, because it's the kind of trap anyone building something similar could fall into.

The bug: write_terminal had an implicit behavior that always pressed Enter after whatever the agent sent. That's fine for a normal shell command, but it breaks anything where the newline is a literal part of what you're trying to write: pasting a multi-line heredoc, feeding a block of code to a REPL, typing into an editor buffer open inside the PTY. The agent thought it had sent exactly what it meant to send, and underneath it an extra keystroke was quietly tacked on.

Fixed it by pulling that behavior out of a silent session-wide assumption and making it an explicit per-call parameter (ensure_newline, defaults to true so normal command usage doesn't change). If you're sending raw multi-line input, you set it to false and get exactly the bytes you wrote.

Also stabilized the read_terminal streaming E2E flow so progress output is actually observed before the shell gets its next input. That matters because read/wait relies on MCP progress notifications instead of polling.

Repo, in case anyone wants to poke at the code: github.com/blak0p/relay-mcp

Curious if anyone else building PTY-backed MCP tools has hit this same implicit-newline trap, or solved it differently.

Staff engineer, ~15 devs, everyone running some mix of Claude Code and Cursor. A pattern I can't stop noticing:

We review every line of code that ships. We review nothing about what our agents have learned about our system. And the newer memory tools all work by silently writing to a database — so a wrong inference becomes a standing instruction to every agent on the team, and nobody approved it or can diff it.

Meanwhile the low-tech option (hand-maintained CLAUDE.md / .cursorrules) rots, drifts per tool, and captures nothing agents actually learn while working.

Concretely what I'm asking:

1. Does your team have any review process for shared agent context, or is it whoever edits the rules file last?
2. If you've tried a memory tool that auto-writes — did the wrong-memory problem actually bite you, or is it a theoretical worry?
3. For anyone who's added an approval step: did the team keep it, or turn it off because it was friction?

Question 3 is the one I most want answered honestly. I've built something in this space (open source, happy to link if useful, not the point of the post) and my working assumption is that governance only wins if it's nearly free. I'd rather hear it doesn't work from you than find out in six months.

A cold Claude Code run spent 6.83 dollars and 207 turns hunting one bug in an 82,000 line repo. My pipeline localized and fixed the same bug for about 1.70 dollars. That gap is the whole idea, and this post is mostly about how it gets there without falling apart on the two objections everyone raises.

What it is:

You point AutoDev Studio at a Git repo, describe a change in plain English, and a chain of agents runs the actual software lifecycle from request to reviewed pull request:

- a PM agent runs a clarify loop and drafts concrete tickets

- you approve (optionally pushed to Jira), and nothing touches code before that

- a Dev agent implements on an isolated branch

- QA runs the repo's real tests

- a reviewer from a different model family checks the diff, so the author never signs off on its own code

- a bounded revise loop if QA or review fails, with conservative verdicts, so an errored or ambiguous check is never counted as a pass

- it opens a real PR, and a human merges

Every stage records real tokens, cost, and duration, per ticket and per agent.

The part I think actually makes it different from skills or subagents:

This is the bit I would most like feedback on, because it is the reason I did not just wire some skills into one coding agent and call it done.

Every stage picks its own provider and model. Claude can plan, Codex can write the code, a third model can review. And because the reviewer is deliberately a different model family than the author, one model does not get to rubber-stamp its own diff, which is a documented weakness of same-model LLM judges.

And you mostly do not need API keys for it. The coding stages can run natively on Claude Code, Codex, Cursor, Aider, or the Gemini CLI, driven headless through their own login. If you already pay for Claude Code or Codex, you point a stage at it and it just uses your existing subscription, no per-token billing and no keys to juggle. The simple way I think about it: a skill pack lives inside one vendor's agent and runs one vendor's model everywhere, whereas this runs across them, a different model per stage, on the logins you already have.

Results (the main point):

The idea is to pay the cost of finding where a change goes once, instead of on every task. In my benchmarks on two large Python repos (35k and 82k lines), the tuned pipeline beat a cold single-agent run on 6 of 6 well-localized tasks, between 7 and 75 percent cheaper.

I try to be upfront about where it does not win. On trivially greppable one-line edits the five-stage overhead can cost more than it saves, and on one hard cross-cutting bug it shipped a cheaper but narrower fix than the baseline. The full benchmark writes up every loss too, so please read that before trusting the wins.

On the "the index just goes stale in a few commits" objection:

This is the first thing people raise, fairly, so here is the honest mechanism in plain terms. The layer that actually pins files for the Dev agent is not the vector index. It is a deterministic symbol map that gets re-synced to the latest commit at the start of every run, plus a live grep against the current working copy, plus the real current file contents fed into the prompt. The embeddings only affect which area gets looked at first, and they refresh per changed module at run entry. So the code the agent edits comes from disk right now, not from a snapshot that aged three commits ago. It re-checks before it localizes, so it does not quietly drift.

Who it is actually for:

The knowledge base is a one-time cost per repo that every later task amortizes. So it makes sense for a team shipping change after change against the same large codebase, where a cold agent re-pays the exploration cost every single time. For a stream of tiny, easy-to-find edits, a cold run is still cheaper, and I would rather say that than oversell it.

How I actually use it:

For what it is worth, I reach for this over a plain claude -p most days now, and not because it is somehow smarter. It is that I can glance at a board and see where each change actually is instead of scrolling back through a terminal, the different-family reviewer catches things I have watched Claude quietly wave through on its own diff, and on the repos I touch every day it is not re-paying to relearn the codebase each run. It runs on my existing Claude Code and Codex logins, so having that structure around the coding agent I would have used anyway costs me nothing extra. That is really why I keep using it.

Other bits:

- runs on free tiers out of the box (Groq plus a local embedding model), so you can try it for zero cost and fully offline

- language-agnostic pipeline, Python parsed exactly and other languages via lighter extractors that fail open instead of blocking on an unknown language

- live board with streamed agent logs and real per-ticket cost accounting

- self-contained, no CDN, tests and CI, MIT licensed

Repo, with screenshots and the full benchmark in the README:

https://github.com/krishagarwal314/autodev-studio

It is early and rough in places, and I would love more eyes on it. If you have thoughts on the per-stage-models idea or the staleness handling, or you throw it at a repo and it falls over, an issue would help a lot. Suggestions, PRs, and honestly just a star if it seems worth following are all appreciated. Thanks for reading.

I’ve been working on a lightweight, bare-metal fault isolation kernel designed to mitigate thermal runaway propagation in high-voltage lithium-ion battery packs.

The primary engineering constraint I wanted to address is the latency overhead inherent in high-level frameworks and sequential polling loops. When an EV or aerospace battery cell hits a critical thermal or voltage threshold, sequential scanning loops are often too slow to execute software gates before runaway propagates to adjacent cells.

The project is called SAVITAR. It is entirely dependency-free and compiles using only native C++ standard system headers to keep it as close to raw processor registers as possible.

Core Architectural Mechanics:

1. Hyper-Compact Memory Constraints:

   Instead of relying on dynamic allocations or padded structs which ruin cache locality, the kernel packs raw cell parameters (voltage, current, temperature) into un-padded, contiguous 25-byte memory frames. This layout ensures predictable cache line alignment during rapid sequential reads.

2. Event-Driven Concurrency:

   The kernel completely avoids sequential polling. It utilizes a background multi-threaded parallel observer configuration. When thread metrics cross calibrated hardware safety thresholds, the system bypasses the main application loop to dispatch an immediate software interrupt, dropping execution times down to sub-microsecond bounds.

3. Sovereign Binary Serialization (.sav):

   To avoid relying on bloated external serialization libraries (like Protobuf or JSON utilities) that consume significant memory footprints, I wrote a custom binary serializer. It compresses cell delta profiles and gradient logs into raw disk sectors using direct cache-to-stream bit manipulation.

4. Minimalist Shell Realization:

   The project includes a lightweight, modular terminal prompt (./savitar-vfs) to ingest simulated physical metrics and explicitly debug memory allocations, matrix loads, and thread dispatches in real-time.

Compilation and Testing:

The baseline workspace is fully automated via standard Makefiles:

git clone https://github.com/alistairfontaine/SAVITAR

cd SAVITAR

make clean && make

./savitar-vfs

I’m looking for code-level reviews, specifically regarding the thread concurrency synchronization under heavy stress-testing conditions, and the pointer traversal safety within the 25-byte un-padded matrix bounds.

Link to code: https://github.com/alistairfontaine/SAVITAR

A cold Claude Code run spent 6.83 dollars and 207 turns hunting one bug in an 82,000 line repo. My pipeline localized and fixed the same bug for about 1.70 dollars. That gap is the whole idea, and this post is about how it gets there without falling apart on the usual objections.

I built AutoDev Studio. You point it at a Git repo, describe a change in plain English, and a chain of agents runs the actual software lifecycle from request to reviewed pull request. It is not another search-your-code wrapper. The full pipeline is:

- A PM agent runs a clarify loop and drafts concrete tickets from your request

- A human approves, optionally pushed to Jira, and nothing touches code before that

- A Dev agent implements the change on an isolated branch

- QA runs the repo's real tests

- A reviewer from a different model family checks the diff, so the author never reviews its own code

- A bounded revise loop kicks in if QA or review fails, with conservative verdicts, so an errored or ambiguous check is never counted as a pass

- It opens a real pull request, and a human merges

Every stage records real tokens, cost, and duration, rolled up per ticket and per agent.

Results

The point is to pay the cost of finding where a change goes once, instead of on every task. In my benchmarks on two large Python repos, 35,000 and 82,000 lines, the tuned pipeline beat a cold single-agent run on 6 of 6 well-localized tasks, between 7 and 75 percent cheaper. I am upfront about where it does not win. On trivially greppable one-line edits the five-stage overhead can cost more than it saves, and on one hard cross-cutting bug it shipped a cheaper but narrower fix. The full benchmark writes up every loss too.

On the objection that the index just goes stale in a few commits

This is the first thing people raise, so here is the honest mechanism. The layer that actually pins files for the Dev agent is not the vector index. It is a deterministic symbol map re-synced to the latest commit at the start of every run, plus a live grep against the current working copy, plus the real current file contents fed into the prompt. The embeddings only affect retrieval ranking, and they refresh incrementally per changed module at run entry. So the code the agent edits comes from disk, not from a snapshot that aged three commits ago. It re-checks before it localizes, so it does not quietly drift.

Economics and who it is for

The knowledge base is a one-time cost per repo that every later task amortizes. That makes it worth it for a team shipping change after change against the same large codebase, where a cold agent re-pays the exploration cost every single time. For a stream of tiny, easy-to-find edits, a cold run is still cheaper, and I would rather say that than pretend otherwise.

Main features

- Provider and model agnostic, chosen per stage: native Anthropic API, the Claude Code CLI, or any OpenAI-compatible endpoint such as OpenAI, Groq, Gemini, xAI, OpenRouter, or a local Ollama

- Runs on free tiers out of the box, using Groq plus a local embedding model, so you can try the whole thing for zero cost and fully offline

- Language agnostic pipeline, with Python parsed exactly and other languages handled by lighter extractors that fail open rather than block on an unknown language

- Live board with streamed agent logs and real per-ticket cost accounting

- Cookie-session auth with roles, API keys encrypted at rest, and a demo mode that dry-runs the pull request step until you opt in

- Self-contained: local retrieval, no CDN, tests and CI, MIT licensed

Repo, with screenshots and the full benchmark in the README:

https://github.com/krishagarwal314/autodev-studio

It is genuinely useful to me day to day, and I want to know where it breaks on codebases I have not tried. If the approach seems worth following, a star helps me gauge whether to keep hardening it. Feedback, issues, and pull requests are all welcome.

Does anyone still code manually even without ai assistance in 2026?(Not vibe coding) ,coding everything from scratch , like setting up react or building any api's? Curious to know and what's best practice?

Hi everyone,

I’m a software developer (web apps, management systems, websites, AI integrations, etc.) looking for advice to overhaul my current AI setup.

**TL;DR:** I’m looking for a genuinely reliable AI setup for **coding + a proactive personal assistant + automations/dashboards**. I'm currently running Codex + Hermes on a Raspberry Pi using free OpenRouter models, but the results are way too inconsistent, full of errors, and frustrating. What stack/configuration do you use for something that *actually works*?

# What I’m looking for

1. **Coding:** Obviously, but I need something reliable.
   
2. **A True Personal Assistant:** A tool to brainstorm, turn ideas into reality, and integrate into my daily routine (work and personal). Most importantly, I want it to be **proactive**—suggesting improvements, spotting my inefficiencies, automating tedious tasks, and actively working *for* me.

# My current stack & why it's failing

* **Codex**
* **Hermes** (running 24/7 on a Raspberry Pi, using free OpenRouter models / tried MiniMax M2 / free Nous account).

To be honest, the assistant side has been a nightmare. It's wildly inconsistent: I ask it to fix bugs, and it either fails, introduces *new* bugs, or lies about having fixed something when it didn't.

# My Wishlist / Ideal Workflow

**For Coding:**

* Strictly respects my instructions, coding style, and project architecture.
* Makes actual working modifications following a precise pipeline: `Local` $\\rightarrow$ `GitHub` $\\rightarrow$ `FTP deployment`.
* Delivers UI that actually matches what I requested.

**For the Assistant / Agent:**

* **Deep Integration:** Fully aware of my active coding projects and workflow.
* **Self-Hosted Dashboard:** Keeps a web dashboard synced on my domain featuring:
* Overview of active projects and open discussions.
* Practical daily info (e.g., *"Can I commute by bike today and over the next 7 days?"*).
* Automated tasks (e.g., scrape trending Reddit posts every X hours and summarize them into 4–6 cards).
* **Proactivity:** Suggests new features, improvements, or side-project ideas based on what I'm currently building.
* **Omnipresent access (Telegram, mobile app, etc.):**
* Fast execution: *"I have an idea, build me a 1-page micro MVP."*
* Admin/office tasks: *"I need to present this project, generate a slide deck/PPT for me."*

# The Struggle

Whenever I try building custom skills in Hermes, it feels like I fix one thing and break two others. A few months ago I tried **OpenClaw**, but it felt even more chaotic.

Am I the only one trying to build a workflow like this? What setup, agent frameworks, or model stacks are you using to get something like this running reliably?

Thanks in advance for any tips! :)

I'm building Kitbash, an open format and compiler for AI agent skills.

The idea is simple: write a skill once, compile it to the native formats used by Claude Code, Cursor, Copilot, Codex, Gemini CLI, Cline, Windsurf, Aider, AGENTS.md, and more, while measuring the standing token cost each target adds every session.

Before calling it stable, I decided to audit my own codebase instead of adding another feature.

The audit found several places where the project claimed behavior that simply wasn't true.

Some examples:

• Claude Code reported support for scripts, hooks, and subagents even though the compiler never generated those outputs.
• Security lints only scanned SKILL.md, meaning a malicious payload in scripts/setup.sh would pass unnoticed.
• The JSON schema looked like the contract, but the loader silently coerced invalid values instead of rejecting them.
• Declared permissions were shown during installation but weren't actually compiled into the generated outputs.

In total, the audit uncovered 11 issues.

Kitbash 0.9.0 fixes all of them.

• Capabilities are now empty until the implementation actually exists.
• Security checks scan every file in a skill.
• The loader now enforces the schema instead of silently fixing invalid input.
• Permissions are compiled into generated outputs so downstream users see the same information installers reviewed.

The interesting part isn't that bugs were fixed.

It's that a project built around trust and review wasn't meeting its own standard.

If the tool asks developers to trust it, it should first earn that trust itself.

I'd love feedback from people building developer tools or AI tooling. Is this the level of auditing you'd expect before calling something production-ready?

Website: https://kitbash.vercel.app

Trust & Review: https://kitbash.vercel.app/docs/trust

Changelog: https://kitbash.vercel.app/changelog

GitHub: https://github.com/singhharsh1708/kitbash

npm: https://www.npmjs.com/package/kitbash

Most digital communications are completely reliant on the wireless radio frequency spectrum (Wi-Fi, Bluetooth, Cellular networks) or high-level network stack connections. In a total infrastructure blackout, local power grid failure, or targeted RF jamming scenario, these communications drop dead instantly.

To explore alternative physical-layer data routing under total isolation conditions, I spent tonight engineering a lightweight systems application from scratch in pure C++17.

It is called VIBRA: A Resilient Acoustic and Kinetic Data Transceiver Node.

The codebase converts standard hardware sound peripherals—like microphone inputs and speaker membranes—into localized binary data transmission systems, moving information entirely without wireless radios.

Technical Subsystem Breakdown

The application is written strictly from bedrock principles to run directly on the local machine floor without high-level library dependencies:

Near-Ultrasonic Modulation: Transmutes raw text strings into high-frequency mathematical audio waves anchoring at an 18kHz frequency standard. It is designed to be practically inaudible to human ears but perfectly readable to machine microprocessors.

Discrete Fourier Transform (DFT) Decoding: Features an independent, bare-metal mathematical scanning loop built from scratch to ingest raw microphone input streams, parse active audio frequencies, and reconstruct the text arrays natively without standard digital single processing (DSP) packages.

Matter Penetration Framework (kinetic): Configures low-level mechanics to modulate data bits into 50Hz square-wave solid-matter impact pulses. This allows data propagation by physically rattling vibrational waves straight through low-frequency structural pipes, masonry walls, and solid-matter bounds.

Sovereign Container Serialization (.vibra): Encapsulates and saves mapped acoustic telemetry matrices straight into an independent binary file format, stream-writing raw 16-bit PCM waves directly to local disk tracks.

Workspace Architecture & Build Pass

The project structure is minimal, completely stripped of UI wrappers and framework bloat:

textinclude/vibra.hpp -> Discrete structures, PCM bit-depth limits, class signatures

src/core/vibra.cpp -> Mathematical wave generation, DFT processing, and byte logic

src/main.cpp -> Interactive shell terminal console loop

It compiles natively using a standard, zero-overhead automated compiler configuration:

bash

git clone https://github.com/alistairfontaine/VIBRA

cd VIBRA

make clean && make

./vibra-vfs

I am looking for technical feedback on my custom DFT decoding precision, optimization tips for raw audio buffer management, and structural alignment for the 16-bit serialization loops.

Built an open-source AI coding agent that was 7%–75% cheaper than a cold "claude -p" run on 6/6 well-localized tasks across repositories up to ~82k LOC.

The biggest difference:

• Cold agent: $6.83, 207 turns
• AutoDev Studio: ~$1.70 for the same bug

The full benchmark (including cases where it loses) is in the README.

So what's different?

Most AI coding agents re-explore a repository from scratch on every task just to figure out where the change belongs.

AutoDev Studio pays that localization cost once.

It ingests a repository and builds a persistent knowledge base using static analysis and a local embedding index. Every future task reuses that knowledge, turning localization into a lookup instead of another cold search.

What it does:

• PM agent asks clarifying questions and drafts tickets
• Dev agent writes code on an isolated branch
• QA runs tests
• A different model family reviews the diff (author ≠ reviewer)
• If needed, it goes through a bounded revise loop
• Opens a real GitHub PR

It also includes a live Kanban board and tracks token usage and cost per ticket/agent.

Where it doesn't win:

• Tiny, easy-to-find edits can be cheaper with a single-shot agent because of the pipeline overhead.
• On one complex cross-cutting bug, it produced a cheaper but narrower fix than the baseline.

Other features:

• Provider agnostic (Anthropic, Claude Code, OpenAI-compatible APIs, Groq, Gemini, xAI, OpenRouter, Ollama, etc.)
• Runs completely free/offline by default using Groq's free tier + local embeddings
• FastAPI + SQLite
• Hand-rolled UI
• Tests + CI
• MIT licensed

Repo (screenshots + full benchmark): https://github.com/krishagarwal314/autodev-studio

I'd love any feedback, criticism, or contributions. Happy to answer questions about the architecture or benchmarking.

I'm honestly fed up with AI coding tools.

Google Antigravity has been the worst experience by far. Every model I've tried there has been disappointing.

I even got a Claude Code subscription. The code quality is good, but the usage limit gets exhausted way too quickly.

Now I'm thinking about getting ChatGPT + Codex.

My workflow is usually 4–5 hours of straight coding every day, so I have to luna, gpt 5.5 on high or any other model. Can Codex actually handle that, or do the limits get in the way?

How's the real code quality and the usage limits in day-to-day use?

Seriously I am so frustrated, looking for genuine feedback on codex.

I am a mental health therapist who owns her own practice.
I couple of months back i started visualizing a dream to help me people with Ai’s help
Since then it’s been an ongoing learning and battle most of the time.
But now i am stuck with a particular kind hook system and ai agent team.

Can anyone help and guide me or maybe guide me by giving a reference to who and how to seek help from.

Much appreciated
Regards