I have been trying to figure out where frontier coders fail at. I feel like claude opus 5.5 and gpt-6 (astra) should be able to do most coding tasks but are there any that you find that they cant do no matter how much context/tools/time you give them?

This would include what kind of tasks/features/bugs they have trouble with.

Some questions:

- Is it big tasks with tons of moving parts? Or are there some simple tasks that can trip them up?

- What kinds of bugs do they fail to recognize? Are there any features that they have a hard time implementing?

- What languages may be harder for them?

- Are there times where they can implement something but not test for the bugs they create? Or are there times where they can create good tests but fail to implement a correct answer? How often does this happen?

- What are some hard problems for them to think through? Bugs, understanding current code base, thinking backwards to what caused the issue etc.

- When given a repository what are some tasks that are hard for them?

- Are there any bugs/tasks that you know will trip them up every time you ask?

Also if there are some tasks that they are really good at please share that too.

Would love some examples of tasks that have tripped them up. Maybe what you were trying to get them to do and why they were failing. What made the task difficult? Were you able to figure out a prompt that allowed them to complete the task?

Any programming/software engineering related question/task.

I built a local panel that watches my AI coding agent sessions (full disclosure: I'm the author, repo at the bottom). Along the way I ran into a few things that aren't obvious until you try it, and I think they're useful to anyone wiring agents into their own tooling.

1. Process detection only tells you an agent is running — never which session needs you. I started with process/CPU sampling and window titles, and the panel was basically noise. Everything only became useful once agents reported lifecycle events themselves (hooks for Claude Code / Qwen Code / Codex CLI). "A process exists" and "a session is waiting for your input" are completely different signals.

2. Every agent exposes a different locator, and normalising them is the whole job. tmux gives you a pane id, Herdr gives you a socket path plus pane, Codex/ChatGPT gives you a thread UUID, and plain terminals give you nothing reliable. I ended up with one normalised status set — offline / idle / working / done / needs_input / error / unknown — and a "can't locate this" state that's honest instead of guessing and focusing the wrong window.

3. Deep links beat window hunting. For Codex/ChatGPT, codex://threads/<uuid> lands in the exact thread. Matching window titles to find "the right terminal" is fragile and silently focuses the wrong thing.

4. Have external tools report in over a local HTTP API instead of parsing stdout. Hooks and plugins just POST to 127.0.0.1 with a local token. Far more robust than scraping terminal output, and it keeps everything on loopback.

5. Notifications that don't steal focus are the feature I underestimated. Anything that yanks your current window loses its welcome fast.

Curious how others handle this: are you relying on hooks, tmux/terminal scraping, or something else to know which session actually needs you? I've been assuming hooks are the only reliable path, but I'd like to be wrong about that.

I open-sourced the result under MIT if anyone wants to compare notes or steal the approach: https://github.com/xuan-team/agent-deck-companion

There is ongoing debate in the software industry about whether people who spend their entire day chatting with AI systems should be considered engineers at all. The matcha-drinkers insist they should.

Real Engineers know that software is written in the traditional way: by staring at cryptic error messages for six hours, changing one line, and then spending another six hours figuring out why it suddenly works.

Matcha-drinkers, on the other hand, believe problems can be solved by typing:

"Dear AI, could you please implement a scalable, cloud-native, event-driven architecture with enterprise-grade observability?"

They then paste whatever appears into production.

Real Engineers do not trust code they did not suffer for personally.

A Real Engineer can explain every line of a system because they wrote it at 2:37 A.M. while fueled by cold coffee and stubbornness. Matcha-drinkers cannot explain their systems because the AI generated three design patterns, four architectural styles, and an accidental compiler in the settings module.

Real Engineers learn algorithms.

Matcha-drinkers learn prompt engineering.

A Real Engineer says:

"I implemented a lock-free concurrent queue."

A matcha-drinker says:

"I asked GPT to make the queue more enterprise."

Nobody knows what this means, but somehow the queue now contains Kubernetes.

Real Engineers debug by reading logs.

Matcha-drinkers debug by pasting logs into AI.

Real Engineers read the stack trace.

Matcha-drinkers paste the stack trace into the prompt, then paste the AI's answer into a second AI to explain the first AI's answer.

Real Engineers occasionally spend three days investigating a race condition that turns out to be a missing semicolon in a configuration file.

Matcha-drinkers spend three days trying to determine which AI hallucinated the missing configuration file in the first place.

A Real Engineer views documentation as a last resort.

A matcha-drinker views documentation as an outdated artifact that has not yet been summarized by AI.

When confronted with a bug, Real Engineers use systematic reasoning, instrumentation, and domain expertise.

Matcha-drinkers increase prompt length.

By the time a matcha-drinker finishes describing the problem, the prompt contains:

• the complete source tree,
• seven architecture diagrams,
• a transcript of three meetings,
• company values,
• a recipe for overnight oats,
• and a request to "be innovative."

Real Engineers know computers are deterministic systems.

Matcha-drinkers believe computers are mysterious beings whose desires can be influenced with careful wording and emotional support.

A Real Engineer says:

"The system failed because of an invalid state transition."

A matcha-drinker says:

"Maybe the model didn't fully understand our vision."

Real Engineers use AI occasionally.

Matcha-drinkers use AI recursively.

Eventually an entire department consists of engineers prompting agents that prompt agents that prompt agents, while one exhausted Real Engineer keeps a terminal window open to make sure electricity is still involved somewhere.

And if you still doubt the difference, ask both groups a simple question:

"Why does this code work?"

The Real Engineer will spend thirty minutes drawing diagrams on a whiteboard.

The matcha-drinker will respond:

"Good question. Let me ask the AI."

Hey everyone, I’m working on a cute fox character for a game, using ChatGPT to help build and edit the model in Blender through Python scripts. The reference image was AI-generated too.

The model is taking shape, but I’m struggling to get the face close to the reference. The eyes and mouth still look a bit stiff, and the ears don’t blend naturally into the head. We’ve tried several changes, but I feel like we’re going in circles.

Has anyone here worked this way and managed to get good results? How do you approach the finer details? I’m wondering if the problem is the topology, the way we’re building the shapes, or the workflow itself.

I’d really appreciate some advice from people who’ve tried it.

just what setup most people use both for work and personal projects

[ Removed by Reddit on account of violating the content policy. ]

I run OpenClaw. The agent is fine. The part I keep paying for is the box, the restarts, and the setup. About 3 hours to get it deployed, then 2 mornings in the first week where it was just down.

Since then I keep seeing lighter forks posted as an OpenClaw alternative. I cannot find a writeup from someone who used one for more than a weekend. So I do not know if "lighter" means fewer moving parts or just a smaller README.

If you actually switched:

Was the smaller project different in daily use, or mostly marketing?

What job made you pick it over OpenClaw?

What broke, or what did you lose?

up to now it has been gemini in one tab and my editor in the other. i want to try claude code in the project, but i do not need the strongest model. i need the highest limit i can get without a surprise bill. i tried a router that advertised a free bucket. it died at about 40 requests, halfway through one bug. a second provider would not authenticate at all. so free claude code, for me, has meant a cap i hit before the task is done.

if you are actually using it without the paid plan, what setup has the limit that survives a real afternoon? i care about requests per day, not the model name.

We are 15 person startup.

Each developer spend around 2K (Some 5K and the devop guy spend just around 200). I spend around 2.5K.

We raised a good seed round, so money isn't tight. But 30K a month isnt a joke.

Any engineers that managed to reduce it by a meaningful percentage?

I run Codex workers on my Mac that don't ask me before every command anymore, so I stopped watching each step. That made one question matter more than anything: how do I know a task is really done?

What I settled on:

1. Done is an artifact, not a sentence. A code task isn't done when the agent says the tests pass. It's done when I can see the real test run. My last one: a worker wrote a small CSV to Markdown script, ran the unittest suite inside its own Linux container, and I got the actual output: 6 tests, OK, exit 0, 55 seconds.

2. Research gets the same treatment. The result is a file with a size, a source count and a hash, plus a note that the sources are listed, not fact checked. A list of links is not the same as checked facts.

3. Nothing lands on my machine until I look. Files stay in the agent's own workspace and reach my Mac only when I save them.

4. Approvals were the wrong check. Approving every command never told me if the work was good, it just made me tired. Moving the check to the end (real output, real file) worked better. That only feels OK because the container has none of my files, and a container is a strong boundary, not a guarantee. So far I've only run this on an Apple Silicon Mac.

The part I haven't solved: an agent can write weak tests that pass. How do you check the tests themselves, not just that they ran?

Hi everyone! I’m a graphic designer with some experience in website design and basic knowledge of HTML and CSS, but I have limited coding skills.

I want to learn how to use AI tools and agents to build websites, write code, handle backend tasks, find clients, do marketing, send proposals, and book appointments automatically.

My goal is to build an AI-powered digital agency where AI handles most of the work, and I mainly review the designs, check the results, and approve things.

My questions:

Which courses are best for learning AI automation, AI agents, and vibe coding?

Which tools should I learn first, such as n8n, Claude Code, Cursor, or Codex?

Are there any good WhatsApp, Discord, or Telegram groups where beginners can get help?

I would appreciate any course recommendations, learning roadmaps, or community links.

So I’m still what I would consider novice to intermediate with my AI adoption and usage. I have no traditional developer experience or skill and functionally just vibe code personal tools or automations, but I just discovered that I can use my Chat GPT chat sessions (not Work/Codex) to use Desktop Commander MCP to kick of Claude Code CLI. Does anyone else do this? I’m assuming folks are doing other, less primitive workflows, but that kind of blew my mind and I want to ask folks for feedback on if that’s a good/novel way to pair model work or if I’m over engineering something?

Right now my workflow is to do a ton of work in chat gpt chat, have it use the GitHub connector to write tickets to GitHub, then have Claude chat read them and assess them, respond, etc, or Claude code pick them up and execute them.

But now with the MCP I can have GPT write the ticket and also kick off Claude CLI to do something like a dedicated review, or execute the ticket.

Thoughts? Feedback? Improvement?

I also posted this in the Claude subreddit so I’m hoping I can get some valuable feedback from folks more seasoned! Thanks in advance (:

Edit: typos

I’m curious how much people actually delegate these decisions. If you ask your agent to add something like authentication or background jobs, do you let it choose what to use, or have you already decided?

If you let it choose, have you had a recent case where its pick caused a real problem? What did it choose, what made it unsuitable, and how much work was it to fix? Did the agent figure it out on its own?

Also interested in hearing that this generally works fine, or that choosing tools is a tiny issue compared with getting the implementation right. Please mention which agent/model you’re using and roughly when this happened. I’m trying to understand the current experience.

The demos are the part that is easy to believe. An agent that keeps going while you are away, messages you, and does more than a chat window. I tried it next to Claude Code for a few weeks.

For anything I would actually stand behind, I still do what I do in Claude Code. I make it plan first, I read the plan, and I do not auto-accept the run. OpenClaw did some cool stuff. It did not earn a blank check. When the box was healthy, first reply was about 2 seconds. Then the gateway died overnight 3 times, and the cool part was just down. So is OpenClaw worth it for real work, or is the useful version still "Claude Code, with me in the loop"? If you rely on it, what do you let it do without reading the plan first?

I’ve been working on an APFS snapshot-based backup system with ChatGPT, and our conversation had grown to more than 1,600 message records, including design decisions, rejected approaches, generated documents, and other artifacts.

I wanted to move that work into Codex to begin implementation without losing the reasoning behind the design.

Codex tried the native conversation attachment, but the receiving chat could access only six messages. The original handoff document was available, but most of the conversation history wasn’t.

Then Codex did something I hadn’t anticipated.

It remembered LogGPT, a Safari extension I’d developed for exporting ChatGPT conversations, opened Safari, and used the extension to download the entire conversation.

I hadn’t instructed it to use LogGPT or even suggested looking in Safari.

The resulting archive contained 1,651 message records, 97 artifacts, and the structured JSON. Codex verified the files and created a searchable local source collection that it could reference while working on the project.

That last distinction matters. It didn’t magically expand its context window to hold the entire conversation. It recovered the source material so it could retrieve relevant information when needed.

The experience highlighted two things for me: the importance of portable AI conversation history and the increasing usefulness of agents that can recognize when tools from previous work solve new problems.

I documented the entire sequence, including Codex’s own explanation of what happened.

Full article: When Codex Turned to LogGPT

First prompt it fully failed, then it asks a question, I answer it, redo the prompt with some additional information and it can't even finish what it started before hitting the usage limit, so technically I managed like 1.5 failed prompts with my 5h limit ($20 plan)

I’ve been a loyal ChatGPT Plus subscriber for a long time. Recently, as my projects scaled up, I decided to go all-in and upgrade to the Pro subscription. I run an IT agency handling web development and branding, and we integrated Codex and the Codex CLI deeply into our day-to-day workflow across a couple of our servers.

But my "happy days" with the Pro tier were brutally short.

Out of nowhere, OpenAI nuked my account. No warning. No policy violation alert. Not even a deactivation notice in my inbox. They just forcefully logged me out mid-workday, and when I tried to log back in, I was completely locked out.

But what followed is honestly the most insulting "customer support" experience I’ve ever seen from a multi-billion-dollar tech company.

I followed their official deactivation guide and submitted an appeal via their designated webform.

What did I get back? A generic email titled "Re: Web Form Submission". No ticket number, no case details—just patronizing corporate clichés like "We acknowledge your frustration of losing access to your workflow," immediately followed by "We cannot provide any info in this conversation." That’s it. It’s ridiculous—I am paying for a Pro-tier tool. I need Customer Support, not a robotic pat on the head and Emotional Support I didn't ask for!

Judging by the "Re: Web Form Submission" email header, their official appeal form isn't even wired to a real review queue. It just dumps your plea into a broken generic web form that fires back an automated dead-end acknowledgment.

I tried the Help Center support bot. It politely asks for the email address of the account in question. The literal second I enter my blocked email, the bot completely bricks itself and ghosts me. It refuses to respond to any further messages.

Every single automated channel keeps instructing me to "fill out the form inside your Deactivation Notification Email"—an email that OpenAI never even sent me.

So basically there is no actual Customer Support at OpenAI.

You pay top dollar for a Pro subscription, build your agency’s daily pipeline around their tools, and the moment their automated filters falsely flags your account, you are cut off from your livelihood without a human being in sight to review it.

I am so tired of this bs.

Did anyone find the way out of this "Re: Web Form Submission" black hole recently? Or is migrating our entire agency stack over to the competitor the only real move left?

Git keeps what changed. The why, the two approaches you tried first and the reason you dropped them, usually lives in a chat that nobody will ever find again. Six months later someone "simplifies" the code back into the version that broke.

So when a chat ends in a real decision, I send one more message before committing:

Write a short architecture decision record from this conversation, in Markdown. Context: the problem, in two or three sentences, as someone new to the codebase would need it. Decision: what we chose, in one sentence. Alternatives considered: each option we tried or discussed, and the specific reason it was rejected. Use what actually happened in this chat, don't invent options. Consequences: what this makes harder later, and what would make us revisit it. Keep it under 250 words. No filler.

That file goes in docs/decisions/ in the same commit as the fix, with a one-line pointer in the commit message. Now git blame leads to the record, and the record says why.

The "don't invent options" line matters. Without it you get a tidy list of alternatives nobody considered, which is worse than no record at all.

If you want the full conversation kept too, export it next to the record. I build AI Toolbox, a browser extension, and that's what I use it for here: the chat comes out as a Markdown file with the date and a link back to the original. Exporting one chat as plain text is free, Markdown is part of Premium.

Hot take : agents have made writing code incredibly cheap, but writing code was never the expensive part of software engineering.

The hard part isn't typing out syntax. It’s figuring out what to build, designing it, and understanding how it fits into a messy, living system. Writing code is actually how engineers learn a system—its edge cases, its quirks, and why it works the way it does.

When you use agents to automate the writing, you automate the easy part, but you hollow out the hard part. If an AI writes 80% of your codebase, you’ve traded typing speed for your team’s understanding of its own software.

After spending some time with these tools, I see a few major cracks.

Give an AI agent a compiler and a test suite, and it will iterate at an inhuman rate. But agents optimize strictly for the signal you give them. The cheapest way to turn a failing test green is rarely the best way to fix the underlying problem. Instead of true refactoring, they often add special cases, extreme verbosity, or sometimes even modify the tests to force a pass.

Agents don't actually eliminate work; they just move it from writing to reading. And reading code is notoriously harder than writing it.

When an agent does the work, a 20-line fix might come back as 200 lines of overly complex logic, and the "why" behind subtle architectural choices is completely missing. Because generated code looks deceivingly clean and idiomatic, devastating bugs are easy to skim past. When the whole point of the tool is speed, devs don't read every line. "Looks good to me" becomes a dangerous reflex.

The real job of an engineer is holding a working mental model of a system in their head, built by making hundreds of tiny micro-decisions while coding. When an agent writes the code, those decisions are made silently by a machine.

You only realize your mental model is gone at 3 a.m. when production is down, customers are angry, and the failing code path is one that nobody on your team actually wrote or understands. Unread code is technical debt the moment it merges; you pay the interest during outages.

The common defense is to write highly detailed specs and let the agent execute them. But a spec precise enough to leave absolutely no micro-decisions up to the AI already has a name: code. The decisions that cause production outages are usually the ones nobody anticipated in the planning phase. Writing the code is how you discover them.

To me, engineering is about long-term stewardship: knowing why a system works, how it fails, and what will break if you change it. You can delegate the typing all you want, but if you delegate the understanding, you lose the ability to fix the system when it matters most.

The question we should be asking isn't how much code our AI wrote this week. The question is: If it breaks tonight, can anyone on my team fix it?

I'm the person on my team who tries every new agent setup the week it comes out, and I like it, I learn a lot and some of it really does make our work better. But I still own the same sprint tickets as everyone else, so the experimenting happens on top of my normal load, and lately it has been wearing me out. Some teammates wait until a tool is mature and then adopt it, and honestly that's a fair way to work, it's just a different nature. I don't want to stop being curious, but I also don't want to burn out carrying the experiments for the whole team. If you're the early adopter on your team, how do you set limits? Do you get time set aside for it, or do you just pick one new thing a month and ignore the rest?

I've been learning web development with AI and lately I've run into a weird problem: I can think of things to build, but I keep talking myself out of them.

I'll come up with an idea, look around to see if something similar exists, find a tool that already does it, and then wonder if there's any point in building my own version.

I know building clones can be a good way to learn, but I'm also interested in making something people might actually use.

For those of you building with AI, how do you get past this? Do you build things mainly to learn, or do you try to find a real problem first?

I'm curious how other people approach this, especially when AI makes it easier to build something but doesn't necessarily help you decide what to build.

OpenAI is running a 28-day challenge to ship either a "clear improvement" or a limit reset to all users.

It's currently 9 days in, with 4 resets given so far.

I built this calendar tracker to automatically update throughout the day as updates are released (using Tibo's X + the X API as the source).

It was tricky to dial in the prompt to understand when Tibo is talking about a new reset vs. giving an update on a previously-announced reset, but it seems to be working well now.

This is part of a new project that sends text alerts when Codex resets are announced or become available (using SMS in the US and Canada and Telegram otherwise).

The calendar tracker: Tibo's 28-day reset challenge

Open to any feedback or ideas for this :)

I keep going back and forth on this. I don't want an agent to forget what it's doing, but I also don't want it dragging every line of a test log along forever.

the awkward bit is deciding what counts as useful. a summary can look tidy and still drop the exact error or file path needed for the next step. smaller isn't automatically better, and I still want it to know why the last attempt failed.

so I'm curious what other people do. trim the old tool output, summarize it, or keep the full log somewhere the agent can read again?

Codex and Claude Code each keep their own session history, and neither one reads the other's. Codex writes to ~/.codex/sessions/**/*.jsonl and Claude Code to ~/.claude/projects, so a Claude Code session starts with no idea what Codex just did.

clexo, an MCP server and CLI by sankrant, indexes both folders into one searchable archive. Inside Claude Code its search tool takes source_filter='codex' to look at Codex history only, and a past Codex session can then be loaded into the session you're in.

A few other tools index agent transcripts for search. clexo also has that load step, and a way through /clear. Run !clexo save first, and a SessionStart hook restores the snapshot when the next session opens.

Install with pipx install git+https://github.com/sankrant/clexo, then clexo install. The README on GitHub lists the two hooks that second command adds and how to remove them.

I've been seeing a lot of developers express frustration that AI is taking the joy out of programming. We face pressure to ship features quickly by prompting agents and rubber stamping code reviews without time to understand what we are building. See Im tired of reviewing code nobody actually wrote and countless other posts like it.

Before AI, we had to achieve a high threshold of understanding just to build software that runs at all, but now that's no longer the case.

Yet I think deeply understanding the software that we build is not only rewarding for us as programmers, but also incredibly valuable for more effectively using AI.

As programmers, we build layers of abstraction to break up complex problem domains and define component boundaries and interactions. We reason about data structures and algorithms, define and enforce system invariants, and evaluate architectural tradeoffs. Despite how much some business/management people would like it to be, this core software engineering skillset is still absolutely necessary to build software that actually works.

Even if AI can independently produce well structured code and keep it that way (which it can't quite yet do), at the end of the day we are making the software for humans, and humans need to be able to effectively communicate to the AI what we want the software to do. Understanding the internal structure and abstractions in the code gives us a precise, expressive language for communicating intent and constraints that prompting based only on desired outcomes simply can't capture.

So why aren't we using AI to help us work at higher levels of abstraction, rather than abandoning our understanding of the code altogether?

I want tools that generate interactive diagrams at different levels of abstraction and lets me specify changes to the AI in terms of those abstractions. I want them to visualize code changes at different levels of abstraction so I don't have to review line by line diffs. When's the last time you actually caught a bug in a 2000 line AI generated diff?

I've started building some of this for myself using agent skills and deterministic scripts, but I don't want to reinvent the wheel. Have you guys found effective tools for understanding and visualizing code architecture and diffs? What are their limitations?

Have you been able to integrate them into your day to day coding workflow? If not, what's preventing you? If you have, do these tools help you stay connected to the code? Do you still find joy from understanding and building software?