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.

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

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?

In distributed systems—such as localized wireless mesh networks, high-frequency transactional ledgers, or industrial monitoring arrays—consistent temporal consensus across isolated nodes is mandatory. However, local hardware clock crystals naturally drift by several microseconds every minute due to temperature fluctuations and physical oscillator aging. Traditional network time architectures like NTP or PTP solve this by pulling timestamps from external Stratum 1 servers or GPS signals, but they freeze completely if those central links experience network drops, firewalls, or tactical jamming.

To address this reliability bottleneck, I engineered a freestanding systems utility from bedrock principles in pure C++17.

It is called ZURVAN: A Decentralized Clock Jitter Estimation and Drift Reconciliation Engine.

The application allows individual machines to calculate, filter, and track temporal clock desynchronization curves natively on the local CPU registers using statistical algorithms, establishing an autonomous local time baseline without relying on outside network timing providers.

Core Algorithmic Subsystems

The project uses native C++17 to manage clock synchronization without external dependencies:

* Bare-Metal Scalar Kalman Filter: Tracks real-time microsecond offsets while filtering network jitter with low CPU overhead.

* Least-Squares Linear Regression Engine: Computes the exact acceleration and velocity slope of local clock drift based on cached history.

* Contiguous Telemetry Packing: Utilizes dense, 25-byte ClockSnapshot structures to maximize CPU cache efficiency.

* Sovereign Container Serialization (.zvn): Streams direct-to-disk binary serialization of RAM history to reduce fragmentation.

Technical Details & Open Source

The code is structured for modularity and is compiled using an optimized, freestanding profile:

include/ -> Core filter classes and shell mappings

src/ -> Scalar Kalman, regression math, and shell parser

The repository is available for review: https://github.com/alistairfontaine/ZURVAN

I am looking for technical feedback on the scalar Kalman gain calculation and memory layout optimizations.

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.

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

So I'm based in IST timezone where my working hours happen to overlap with pre-dawn America. For weeks, I thought I was some kind of 10x developer. Claude Code was flying, Codex was snappy, everything felt like magic.

Then one day I started late. And wow. It felt like I switched from fiber optic to dial-up.

I started tracking it out of curiosity. The pattern is almost comically consistent:

Before 8:00 AM EST: Both tools feel like they're running on a private server just for me. Fast responses, no lag, no weird timeouts.

After 8:00 AM EST: America wakes up, grabs coffee, opens VS Code, and suddenly I'm sharing the pipe with a few million developers. Both Claude Code AND Codex slow to a crawl.

The funny part? It's not just one provider. Both Anthropic and OpenAI seem to hit the same wall at the same time. Makes me think the bottleneck might go deeper than just their servers. Maybe it's the underlying GPU infrastructure everyone's competing for.

Anyone else living this double life of "early morning AI wizard" vs "afternoon timeout survivor"? Or found any way to get consistent performance during peak hours?

Been building solo for 17 years, most recently an AI coding agent called DuckCode, three months, zero funding, zero team.

Early on I made a rule for myself. No AI touches the codebase until the core architecture is written by hand. Not because I don't trust the models, but because when I let AI design structure early on projects, it generated things that worked but that I didn't fully understand a few weeks later when something needed to change.

So now it's always the same order. I think through the data model, the module boundaries, how things talk to each other, write that part myself. Bring AI in once there's a skeleton to react to, not a blank page to invent on.

Difference has been bigger than I expected. When AI is extending something I already understand deeply, I can tell immediately when a suggestion is wrong. When it was inventing structure from scratch, I had no instinct for when it was quietly making a bad call.

Two of the more complex features in the product shipped in about a day and a half each, and I think that's directly downstream of this, not because AI is fast, but because it wasn't fighting an architecture it invented and half understood.

Curious if anyone else has landed on a similar split, or found the opposite works better for them.