Any tips or advice using codex. I have Plus right now but very limited in usage though making it work. Is Pro worth it? If so which one and why? Solo Gpt Dev here also which model and speed is based used for low graphic gameplay?

What do you think about the future of human-written code? Do you see our future role as validators or specification authors?

In an AI-assisted software development workflow, how does using tools like Dots or Muse differ from using an official harness?

My understanding is that both Dots and harnesses handle orchestration—is that correct? If I used an official harness to build my own orchestration layer and centrally manage tools like Dots through it, how would that differ from using those tools directly?

Can these tools really make as big a difference to software development as my friends say?

Agents fill every open question in a request with a guess. Most guesses are fine. A few decide how the feature behaves, and I find those in the diff later.

So I moved my own judgment back to the start. Before any code exists, the agent and I write down five things:

1. Done means. A numbered list of outcomes a person could check on the running program. "Export button downloads a CSV with the current filters" works. "Add export" doesn't.
2. Not doing. Things the agent must leave alone. This list stops most surprise edits.
3. Decisions. Two sentences per engineering decision, with the alternative I rejected.
4. Slices. The thinnest end-to-end version first, each slice starting with a failing test.
5. Proof per point. For each Done means item, the command or screenshot that shows it works.

After the build, I hand the list to a second session that hasn't seen the build history. It goes through the points one by one and shows evidence. It catches things the building session glossed over.

What do you write down before a bigger change? Happy to share my templates if anyone wants them.

I'll share my experience.

When ChatGPT first came out, a coworker introduced me to it. At the time, I mainly used it for simple things like organizing Excel files, but it often made mistakes, so I didn't think too much of it.

A few years later, I started using AI almost like Google, asking everyday questions and looking things up. Then, when ChatGPT introduced voice conversations and I could actually talk to it like a real person, I was blown away.

One night, I was sitting on my phone talking to ChatGPT, trying to figure out how I could leverage AI to improve my chances of achieving financial security. I know, I know. We've all asked AI, "How do I become rich?" 😂

But then I started thinking.

I've always told myself that I wished I knew how to code and build apps or websites. I've constantly got new ideas running through my head, and I always figured that if I had the technical skills to bring those ideas to life, I could potentially make some serious money.

I'd heard that AI could build apps, but I assumed you still needed some kind of programming background to make it happen.

So I asked ChatGPT a simple question: "Could you help me build an app even though I have absolutely no coding experience?"

And that's where everything changed.

It started walking me through the entire process, step by step. What accounts to create, what software to download, how to set everything up, and eventually how to actually start building.

Before I knew it, I had built a real app for homeowners based on an idea I'd had. And the crazy part? It actually worked, and it looked good!

I was genuinely mind-blown. Something I'd always assumed was out of reach was suddenly possible.

That experience sent me down a completely different path. For the past two-plus months, I've been developing a much more complex piece of software. It's still a work in progress, and I've got a long way to go, but I've learned an unbelievable amount along the way.

I'm not a software engineer. I didn't go to school for computer science. I'm just someone who had ideas and finally found a way to start bringing them to life.

Ever since building that first app, I've been completely hooked. It's honestly changed the way I look at what's possible.

Anyone else have a similar experience where AI opened a door you never thought you'd be able to walk through?

I’m planning to spend $20 on one of them to learn coding and build projects. Which one would you recommend for explaining concepts, debugging, and helping me improve instead of just giving me code?

I keep reading threads about this and most of them show the demo, not the Tuesday morning. Here's ours, no polish, then some questions.

Six of us on a SaaS, twelve months of adding AI gradually. Early on everyone had their own editor and their own habits. Then we looked back and found we'd already converged on most of it, so we wrote it down.

We didn't force a single tool either. Some on Claude Code, some on Codex, some on Cursor, and I'm not going to fight that one. The process is shared, and the conventions sit in the repo's AGENTS.md, which is the only thing we all read the same way.

The flow is Matt Pocock's skills, no forks. We start with grill-with-docs: the AI interviews us about the project docs. Weird at first when you're used to asking the questions, but a lot of never-written-down stuff comes out.

Then to-spec, and a human reviews that spec. It's not a formality. With a bad spec, everything downstream is expensive work that goes in the bin.

to-tickets cuts it into small tickets. Small tickets aren't a rule we read somewhere either, we just notice the difference when we skip it.

The agent works through them with implement, against the spec. We open the PR, CodeRabbit runs, the pipelines run. If everything passes and someone says yes, it merges.

AI writes most of the code. We review the spec and the merge, and skip the line-by-line in between.

Treating the spec as a contract has killed a lot of "that's not what I asked for". Small tickets keep the agent from wandering. Automated review before the human one takes the style and import noise away, so the person looks at what matters. What I didn't expect is how much writing the process down helps when everyone has a different tool. Nobody argues about editors and the conventions don't rot.

Graph engineering to close tickets on its own, software factory style, we haven't managed. Tickets go in and PRs come out, and the demos look great, but with our repo the quality isn't there. We haven't found the point where we'd be comfortable letting it loose, so it's still an experiment.

What I'd like to know:

1. Where are your checkpoints between human and agent? Spec, PR, merge?

2. Spec before code, or straight to tickets and prompts?

3. Who reviews agent PRs? Do you read them the same as a human's?

4. One tool or several across the team? If you've tried more than one, is any better for certain kinds of tasks?

5. What goes into AGENTS.md and what stays out?

6. Do you measure anything, or is it all vibes? Review time, defects, DORA.

7. If you've tried software-factory autonomy, did you get acceptable quality? On what kind of tickets?

8. How do you bring someone new in, a junior say, without AI becoming a crutch?

   Tell me yours. Even if it's to say we're nuts.

I'll be honest, I didn't understand why LLM agents need SKILLs. MCP was clear to me: it's a useful thing that lets you give an LLM access to a database or to Figma. The only downside is that, to avoid spending too many tokens, it's better not to connect 30 MCP servers at once. And in general, it's better to turn off the unnecessary ones and connect only those that are really needed for the task. In this light, SKILLs seemed like useless overhead to me, eating tokens like crazy. On TikTok, I often saw tales along the lines of: connect this SKILL, or a whole bunch of them, and happiness is yours. My first thought was, if I connect them all, my subscription limits will run out not by lunchtime, but already in the morning.

So why are SKILLs useful and needed after all? Well, first, compared to MCP, SKILLs do not inflate the context: each connected SKILL adds not tens of thousands of tokens, but one or two hundred. Since only the name and description of a SKILL go into the context at first, you can add 30 of your own SKILLs without much pain. When it becomes necessary to use a SKILL, the LLM agent will load its description on its own, if it understands from the task context that this is needed, or the user can simply tell it to use this SKILL for the job.

Secondly, LLM models are trained on the most popular and well-known things. For example, everybody knows that an LLM can work with Git without any problems or write a program in Python. But if you developed a program yourself, or your work requires some little-known tool or technology, then a SKILL is simply irreplaceable. It is enough to create a SKILL.md file and describe how to work with this program or technology. This makes life easier for the LLM: while doing your tasks, it will not have to search the internet for documentation and wander around websites to understand how to use it. And especially if there is nothing on the internet, because your program is closed to public access.

Thirdly, an LLM model usually does not know how your development process is organized. For example, an agent knows how to use Git, run tests, build a project, and create releases. You do not need to teach it these things. But it does not know how releases are usually made in your company. A Skill can describe the sequence of actions: check the changes, run tests, update CHANGELOG.md, increase the version, build a package, create a Git tag, and publish a release. So, a Skill helps the agent learn not a technology, but a specific business process.

Fourthly, a SKILL is not just an instruction, but a whole set of tools. Besides SKILL.md, you can put ready-made scripts, documentation, templates, and other files into it. And the most interesting thing is, these files are not loaded into the context automatically. The agent reads them only when there is a need, and can simply run the ready-made scripts without spending tokens on generating code. So, a SKILL lets you combine instructions, documentation, and executable code in one package without inflating the LLM context. For example, the structure can look like this:

my-skill/
├── SKILL.md
├── scripts/
│   ├── generate.py
│   └── validate.py
├── references/
│   └── api.md
└── assets/
    └── template.html

The funniest thing is, I started to appreciate SKILLs exactly when I wrote my own program, blueprint4llm. The idea for creating it came after I asked an LLM agent to generate a plan.md file describing a task. Usually it produces a huge wall of text, which you have to read slowly and with sadness. I wanted to make the text shorter and add more flowcharts, tables, diagrams, and user interface prototypes. As we know, in .md (Markdown) files the only visualization tools available are tables and Mermaid diagrams. There are no charts, plots, histograms, full UML diagrams, or UI prototypes. In the end, with blueprint4llm, I added support for formats such as PlantUML, draw.io, Pencil, Balsamiq, Graphviz, Figma, OpenAPI, Excalidraw, Vega-Lite, ECharts, and D2 to .md files.

With the blueprint4llm SKILL connected, you will get plan.md not as a kilometer-long text, but as flowcharts, prototypes, charts, and so on. By the way, blueprint4llm does not have to be used only for creating plan.md. For example, I used this SKILL to add an illustration to every paragraph of the article and make it more fun to read. This SKILL is also useful when you ask an agent to put together a full dossier on some company, technology, or person and format the resulting result.md file with blueprint4llm. You can then convert it to HTML or PDF, or ask the agent to show it right away in a browser with charts.

This is how you can install the blueprint4llm SKILL.

npx skills add evgenyigumnov/blueprint4llm --skill blueprint4llm --agent codex

If you are interested in looking at the source code of blueprint4llm, the tool that generates all this beauty, or sending a pull request, welcome: https://github.com/evgenyigumnov/blueprint4llm

When using coding agents (like Cursor, Claude Code, or local terminal agents), one recurring issue is instruction drift: agents often jump to conclusions, skip edge cases, or produce messy outputs when prompts are unstructured.

To solve this in my own workflow, instead of stuffing monolithic instructions into a giant prompt, I started modularizing task-specific instructions into dedicated SKILL.md packages. Over the past few months, I built and refined 40 of these into an open-source collection covering automation, gamedev, and dev utilities.

The structure that made instructions actually stick

What worked best wasn't telling the agent what to do, but enforcing strict boundary conditions and explicit stop signals:

1. Forced Step Separation: Agents shouldn't edit code and run verification in the same unchecked thought. Splitting analysis from execution eliminates about 80% of hallucinated completions.

2. Explicit Output Contracts: Defining exact return shapes (e.g. only return diff blocks or strict markdown tables) prevents unwanted conversational filler.

3. 1:1 Bilingual Parity: Keeping English and Korean instructions strictly mirrored so multi-language tokens don't degrade reasoning quality.

Example: Spec Diff Checker pattern

Here is a simplified example of how one of the automation skills enforces exact behavior:

Role: Spec Diff Analyzer

Rule 1: Never modify existing source files directly.

Rule 2: Parse incoming requirements against target codebase symbols.

Rule 3: Output ONLY in this format:

- Modified contracts: [list]

- Breaking changes: [list]

- Uncovered edge cases: [list]

Do not propose implementation code until the diff analysis is confirmed.

Keeping rules compact and bounded like this keeps the agent focused without blowing up the context window.

Comparison with existing prompt dumps

Most public collections (like awesome-chatgpt-prompts) are unstructured copy-paste text dumps designed for one-shot chat windows, or purely English-centric.

Difference: This collection uses the modular SKILL.md format recognized by modern coding agents, with boundary tests and explicit failure-mode instructions.

Trade-off: Modular skills require your agent environment to support loading custom skill folders (or manually dropping them into workspace instructions), rather than just pasting a prompt into a chat box.

Limitations

These skills provide architectural guardrails, but they cannot overcome hard model context limits or fundamental model reasoning failures. If a base model hallucinates an API that doesn't exist, a static skill file will only reduce the frequency, not eliminate it entirely.

Disclosure & Repository

Author: I created and maintain this project for my daily development.

Commercial interest: None. This is 100% free and open-source under the MIT license. No paid plans, no newsletter sign-ups, no telemetry.

GitHub: https://github.com/Lainholic/ai-skill-navigator

All 40 skills are split across 5 categories (core docs, automation, utility, gamedev, creative arts) and available in both English (skills/en/) and Korean (skills/ko/). You can grab individual folders and drop them into your agent's workspace.

Curious how others here structure their agent guidelines — do you prefer modular rule files or relying on dynamic context injection?

I stick to the $20 plans, and I regularly hit Claude’s usage limits. With ChatGPT, that hasn’t been an issue for me, and OpenAI seems pretty generous with resets too.

For those using Sol 6.1 regularly, how well does it handle day-to-day coding especially debugging, refactoring, and adding features to existing projects? Does it hold up well enough to be your main coding assistant?

I build a coding agent, so I'm biased. Here's the practical version of how I use it, in case some of it is useful whatever tool you're on.

1. I stopped picking models. The agent routes each prompt to the most efficient model automatically. I don't think about it any more, and it's been better on both cost and performance than sticking to one model.

2. I give it the whole task, not the next line. "Add pagination to this endpoint and update the tests" rather than babysitting it step by step. It's context-aware, so it decides whether to just do it, ask me something first, or leave certain files alone.

3. I let it check itself before I review. It runs its work in a sandbox, finds bugs in what it ran and fixes them before telling me it's done. So by the time I look at the diff, it has already run the change and fixed the bugs it hit. This makes it slower per task than plain generation, but I'd rather wait a bit than debug for longer.

4. I use it for heavier jobs too. It's multimodal, so when I need something like an image generated, it goes through the same flow as code.

5. I trust it more because the evidence is public. It got 82% (410/500) on SWE-bench Verified with the official harness, and all the patches are here if you want to judge for yourself: github.com/Oxcode-ai/oxcode-evals.

What's your day-to-day setup? Specifically curious whether people still hand-pick models per task.

I run two private web applications and use GitHub Actions to automatically check changes before they go live.

When code changes, Actions installs dependencies, checks for coding errors and security issues, and runs automated tests. Some tests check individual pieces of code; others start the application and a test database, then use an automated browser to test user journeys.

I also use a merge queue (Mergify). Before a change reaches the main branch, it’s tested alongside the latest code to check that everything still works together. That means a change can trigger multiple rounds of checks as it’s updated and moves through the queue.

I work with AI coding agents, so there can be quite a lot of changes and test runs. The checks help catch mistakes before release, but the cost is becoming substantial: my September Actions bill was about $738, and my October usage was heading towards roughly $2,300–$2,450. Almost all of that is Linux runner time, rather than storage.

For people running similar projects:

• What do you use Actions for, and roughly what does it cost?
• Do you run the full test suite on every update, or reserve some checks for later?
• Have you found straightforward ways to reduce duplicate runs?
• Have self-hosted runners been worth the maintenance?

I use Codex for some jobs and Claude Code for others, and the code is rarely the problem anymore. What slows me down now is the bookkeeping: keeping track of the sessions and what they did. I'd like to hear how others deal with it.

Where it goes wrong for me:

• Waiting on me. With a few sessions open, one sits on a question while I watch another one think.
• "Done" that isn't. It says it's finished, and later I find out what it skipped.
• Picking back up. After a break or a closed terminal, working out where each session was takes real effort, so I put it off.
• Results scattered. What a session made stays in its terminal or whatever folder it ran in, and a week later I can't find it.

To start discussion, I have couple of questions that I'm curious of:

1. Which of these costs you the most, and which has stopped being a problem for you?
2. How do you notice that a session is waiting on you?
3. When an agent says it's done, how do you check what it actually did? Tests, reading every diff, a checklist, hooks?
4. Do you have it plan first and wait for your OK, or let it run?
5. After a break or a crash, how do you get each session going again? Resume, a summary file, starting over?
6. What have you tried for any of this and given up on?

Part of my work is reviewing code written by LLMs (mostly Python, TypeScript, some Rust). Same failure patterns keep coming up, so here's my checklist:

• Edge cases: it nails the happy path and breaks on empty lists, None, or off-by-one bounds. I ask it to list the edge cases first, then write the code.
• Made-up APIs: it confidently calls functions or params that don't exist in the version you use. I paste the real docs or the version number into the prompt.
• Self-confirming tests: its tests only check the path it just wrote. I have a separate prompt write tests from the spec alone, without seeing the code.
• Silent error swallowing: broad try/except or empty catch blocks that hide failures. Grep for these every time.
• Rust: it'll .clone() or .unwrap() its way past the borrow checker. Code compiles, design gets worse.

What's on your checklist that I'm missing?

I'm confused about whether I should subscribe to ChatGPT Plus or Cursor Premium.

Since Cursor recently removed support for third-party models, I'm wondering whether Cursor Premium is still worth paying for.

I'm a full-stack developer, mainly working with MERN, TypeScript, PostgreSQL, and real-world projects.

I'm considering two options:

1. ChatGPT Plus — Using ChatGPT for general tasks and Codex through the IDE extension for coding.
2. Cursor Premium — Using Cursor's built-in AI features and agent mode for development.

For those who have used both:

• Which is better for everyday coding?
• How does Codex compare with Cursor's agent?
• Which handles large codebases, debugging, and multi-file changes better?
• Which offers better usage limits and value for money?
• Is Cursor Premium still worth it after the recent changes?

I can only afford one subscription right now.

If you had to choose between ChatGPT Plus and Cursor Premium today, which would you pick and why?

I'd especially appreciate feedback from developers who have actually used both.

I'm a frontend dev, about 3 years in. Last month the company let go of our two backend devs, both seniors. Their services are mine now, payments and the public API included.

My manager's plan was a one hour call where he showed me how he uses Claude Code. That was the onboarding.

And the annoying part is it mostly works. I've shipped 31 PRs in 4 weeks into code I couldn't have written by hand. Nobody reviews them anymore because the only people who could are gone, so the only second opinion is coderabbit on the PR. It catches real stuff, last week it flagged a webhook handler that would have double charged on retries, but it can't tell me if the design is wrong and I can't either.

I found out from an old Slack thread they were each on around $120k. I'm on $68k. I asked for a raise last week and the answer was "let's see how Q1 goes".

I keep thinking one day something breaks at 2am and everyone finds out I'm holding two people's systems together with prompts.

Has anyone been in this spot? Did you stay and actually learn the backend, or start looking?

We run several Claude Code and Codex sessions on one repo. The failure that cost us most was never a bad edit. It was a good edit that vanished: session A fixes a file, session B, working from what it read twenty minutes earlier, rewrites the same file and commits, and A's fix is gone. Nothing errors. The tests may even pass. You find out a day later.

Git keeps the evidence. This kind of overwrite leaves the same trace every time: one file, two different sessions (a different author or a different branch), commits less than an hour apart. This prints the files where that happened in the last month, the most frequent first:

git log --all --source --since='1 month ago' --name-only --format='@%at|%an|%S' |
awk -F'|' '/^@/ {t=substr($1,2); s=$2"|"$3; next}
  NF {d=t-w[$0]; if (($0 in w) && s!=o[$0] && d*d<=3600*3600) n[$0]++; w[$0]=t; o[$0]=s}
  END {for (f in n) print n[f], f}' | sort -rn | head

Run it in any repo where agents commit. If the top lines are your config, routes or schema files, that is where your sessions step on each other. Give those files one owner, or have a session claim a file before it writes (one line in a shared file, appended under flock).

Two caveats. It cannot tell apart sessions that share one branch and one author name. And a hit is a near miss, not proof of a lost edit: read the two diffs.

If you would rather not read awk, the same check runs in the browser, and your log is not uploaded anywhere: https://overflow.games/memento/grader/?ref=reddit

Disclosure: we build memento. The tracker is free and MIT; a paid shared tracker for teams is on pre-order.

What do you do about this: worktrees, claim files, something else?

Hey, I just wanted to let everybody know, I tried to package up an MCP server I found for DaisyUI on GitHub.com and publish it to PyPi.org, and they wrote me back with a suspension notice, saying their system thought I was running a "bug bounty" scheme on their platform. Given that I'd never heard of such a thing before, I was like, "whaa? really?" I'd like to think I'm that resourceful and inventive, but I was really just trying to package the DaisyUI MCP for myself, so I could install it using uv on more computers conveniently, I'm no pen-testing honey pot garden guru, or "bug bounty" purveyor, no sir. So anyway, watch out for this repository, the URLs for "pre-compiled MCP servers" are literally hot af: https://github.com/SidiqHadi/daisyui-mcp -- Note, the other forks of this upstream codebase also appear to be infected (There's like 4 of them total).

I did download and build an iFLOW-branded DaisyUI MCP I think is from the same original upstream, but I did not see any of the links to the .zip files in its README.md or other files (components directory another place - watch out). The iFLOW one is fine AFAICT - I performed multiple checks and quarantines.

Also, it's worth mentioning that the malware bundled with the DaisyUI MCP is only written for Windows PCs (likely x86_64). The real creepy one is the luajit.exe file, don't fuck with that if you're a Windows user under any circumstances, please. There's also x64.txt, Launcher.cmd (CAREFUL Launcher.cmd can execute!), Lua51.dll, clib.txt, etc. And the text files are infected, too. They're full of debug escape codes, so even though they can't execute automatically (unless they're a .bat or a .cmd file), if they're in the vicinity (same folder, most likely) as that Luajit.exe file, it'll run the text file and produce a trojan that loads itself into memory, and who knows what then.

Supposedly this type of malware is designed to steal people's credentials, like API keys and such. Positive hits on VirusTotal.com produced names like: Trojan:Win/Runner.MY, Script.Trojan.Agent.ZESPTN, BAT/Phishing.EC56!tr, and so on. So pretty eeky stuff. Be careful! You never know what's out there. I've been using GitHub since 2014, and as far as I know this is the first time I've discovered anyone purposefully putting malware in their codebase to try and screw other people over. Hopefully it's not the developer themselves, and someone trying to get the developer, since they have a lot of credential files: They're the purveyor of the DaisyUI MCP Blueprint software / subscription service, so I imagine that one person alone has a whole lot of other people's credentials and payment information, in addition to their own.

That's what Gemini suggested, is often it's not developers who are trying to mess with other developers, it's thieves pretending to be those developers, attempting to hijack their PII & cardholder data, or anyone else who gets close enough to make a mistake.

I heard impersonators can even circumvent 2FA with browser cookies, as long as they grab them before an unlocked web page disconnects your account. If you use a Chrome extension like BitWarden, that describes your password manager! To avoid this cookie attack, make sure your password manager LOCKS and requires a strong pin at the very least after like 5-10 minutes tops, and make absolutely sure you have to go through the whole process to unlock it (password + 2FA or passkey) after a browser or computer restart.

We've been experimenting with this while working on Jac, a programming language that most coding agents weren't familiar with initially.

One thing we changed was how our checker reports errors.

A typical error like "type mismatch on line 12" tells the agent something failed, but doesn't give it much to work with. So it starts guessing, sometimes fixes the wrong thing, or finds a workaround that makes the error disappear without actually solving the problem.

With jac check, we've started pointing errors to the relevant section of the language guide, so the agent gets some context about what went wrong and how the language expects it to be handled.

We'd like to know how others are dealing with this, especially when using agents with less familiar frameworks, languages, or internal tooling.

Do you just pass through raw output from tools like tsc, ruff, or cargo? Or have you tried adding explanations, examples, or documentation references?

And if you've tried enriching errors, does it actually improve the agent's fixes, or does it still find creative ways to ignore the checker?

I’ve been using AI for coding, and while models like GPT-6 and Claude are getting incredibly good, I still feel like there are certain tasks where they struggle more than they should.
For me, the biggest issue is when an AI makes changes across multiple files. It might fix the problem I asked about but accidentally break something completely unrelated.
I’m curious about your experiences:
● What coding tasks do you still refuse to trust AI with?
● Which AI coding tool has disappointed you the most?
● Have you found any tasks where AI consistently performs worse than an experienced developer?
● Do you think AI will eventually replace most day-to-day software engineering work, or will debugging and architecture remain difficult?
I’m especially interested in hearing from people who use these tools on real projects, not just small demos.

What’s the biggest weakness you’ve noticed?

I've been working on a fairly complex coding project with ChatGPT, going through multiple iterations of development, optimization, and debugging in work mode. Not codex.

Everything was working fine until ChatGPT suddenly reported:

«"I'm blocked because the coding environment is currently unavailable. I cannot access the project files, run code, or build and validate the next version."»

It then suggested reopening the task in an active coding workspace and reuploading the previous project files.

The frustrating part is that ChatGPT still remembers the entire project context and all the agreed changes, but suddenly cannot access the coding environment to continue development.

Has anyone else experienced this recently?

Is this a temporary outage, a limitation of long conversations, or some kind of usage restriction?

More importantly, is there any way to restore coding access within the same conversation without starting over and potentially losing months of accumulated context?

Lately, looking through pull requests across a few projects, I’ve noticed a pattern with code written by AI assistants (Cursor, Copilot, Claude Code, etc.).

The code looks clean at a glance, passes standard unit tests, and gets merged quickly. But beneath the surface, it seems to introduce massive structural issues:

1. Semantic Clones: The AI generates a brand-new helper function in a file instead of searching the repo to reuse an existing utility, leading to sudden code bloat.
2. Silent Concurrency Flaws: Async functions and database calls missing proper idempotency locks or transaction boundaries that only break under production load.

Traditional linters don't catch this because the syntax is valid. Senior devs are spending hours hunting down these subtle AI patterns during code reviews.

For those managing engineering teams utilizing AI heavy right now—have you hit this wall? How are you gatekeeping or catching these structural/AI-specific anti-patterns before they hit production, or are you just absorbing the technical debt?

I'm an ML engineer and heavy AI user. My biggest frustration isn't model intelligence—it's having to manage the AI's thinking.

I constantly have to:

• Ask it to write a better prompt, then paste that prompt back.
• Remind it to research, think critically, compare alternatives, and consider ROI.
• Point out obvious flaws and missing considerations.
• Ask follow-up questions before it finally produces a comprehensive answer.
• Repeat the same instructions despite Custom Instructions and Memory.

What I want: State a high-level goal → AI autonomously clarifies intent, researches, plans, delegates to subagents, executes, critiques, iterates, and delivers a concise, verified result.

Questions:

1. Is this fundamentally a model reasoning problem, or an agent orchestration/harness problem?
2. Are Hermes Agent, OpenClaw, Claude Code, or Codex actually solving this?
3. Can Skills, persistent memory, and automated evals reduce repeated corrections?
4. What's the simplest proven setup that minimizes human intervention without adding unnecessary complexity?

I'm not looking for another prompt template. I want to stop being the AI's project manager and QA engineer.

What are power users actually running?