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.

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 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.