Everyone read today's pricing news as costs going down. On agent workloads it doesn't work like that.

A cheap model that gets something wrong rarely fails loudly. It returns something plausible, the next step eats it, and you find out four steps later. By then you've paid for the cheap call, the three calls after it, and the rerun on the expensive model. A call that errors out is nearly free by comparison, because you just retry it.

Working with enterprise tools all day means my brain is fried by the time I get home but I really don't want my Python skills to gather dust.

I tried tackling massive ML projects on the side before but I always end up quitting halfway because they're too heavy. I'm trying to find a balance maybe a lightweight automation or a simple local AI tool that I can hack away at for 30 minutes a day.

What small coding projects did you build that actually held your interest?

Feels like people are using it as a shortcut to dismiss products they don t like.

At the end of the day, devs have always relied on tools to go faster, frameworks, libraries, Stack Overflow, templates, all of it. AI is just the next step in that chain. Typing code was never the hard part anyway. Understanding what to build, making the right product calls, and handling messy edge cases is where the real work is.

AI doesn t change good vs bad builders, it just changes speed.

Had Claude Code refactor our checkout flow to add an annual billing option alongside monthly. It worked in every test I ran, annual customers got charged correctly, monthly customers got charged correctly, everything looked clean.

What I didn't catch was a specific combination, someone applying a discount code and then switching plans before completing checkout, that caused the final price to recalculate against the wrong base amount. Instead of erroring out or defaulting to full price, it just quietly landed on zero.
Nobody typed in a hack, nobody exploited anything on purpose, the flow itself just handed out free subscriptions to whoever happened to click things in that particular order.

Took six days to notice, and only because I was manually checking Stripe for an unrelated reason and saw a cluster of $0.00 charges I couldn't explain. Roughly 40 people had gotten a free year of the product by the time I found it.
Fixing the bug was fast. Deciding what to do about the 40 people who were already in, upgrade them to properly paying, quietly let them keep it, reach out and explain, was the actually hard part.

Ended up honoring it for existing users and just fixing it going forward, felt like the least damaging option even though it cost real money.

I ran the same read-only task in Claude Code twice: explain 4 source files and how they relate. Once with a single agent reading all four, once with a lead agent that launched one subagent per file and combined the answers. 3 runs each, same model, token counts from the CLI's JSON usage output (input + output + cache read + cache creation, subagents included).

Single agent: about 106k tokens, $0.14 on average. With 4 subagents: about 383k tokens, $0.41. So 3.6x tokens and 2.9x cost, and it was not faster either (about 12s vs 18s, though one run's timing looked unreliable). Cache reads dominate the token count and are billed cheaper, which is why cost grew less than tokens.

Caveats: n=3, one small task, one model. The files fit easily in one context, so subagents had no isolation benefit here. I did not test the case where each subagent would otherwise dump a huge output (big logs, large search results) into the main context.

What I'm unsure about: where is the crossover? Is it file count, size of intermediate output, or tasks that run long enough that the main context gets polluted? And do you have a rule of thumb for when you hand work to a subagent versus keeping it in the main thread? Real numbers from your own runs would be especially useful.

agents made prompt edits scary for me. tweak one system prompt and a tool call 3 steps later starts failing. what helped: prompts live in git, every change runs against a small fixed set of real traces before shipping, and the last good version is always one revert away. curious what others do here, do you run evals on every prompt change or only the big ones

Recently stumbled across this Cursor pro-tip from Ian Nuttall on X:
"1. ask it to recommend a folder structure

2. ask it to actually create the folder/files based on that this makes it 10x easier for me to get started and Cursor is more accurate using codebase cos it knows where to update files."

That got me thinking, what other pro tips are people using to generate better code, ship faster, organise your space better, etc. Drop em below:

Built my app with Lovable a few months ago. Launch went fine but since then I've had three separate production issues; auth breaking, database timeouts, a webhook that silently fails. Each one took me days to figure out and I have zero engineering background.

Curious what others are doing. Are you just patching it yourself, hiring freelancers each time, or has anyone found something more ongoing? I've been wondering if a monthly retainer for this kind of support would actually be worth it or if that's just me.

Before opening a PR, I started pasting my code into Claude for a quick review first, just to catch anything obvious before it goes to the lead.

A few times it caught things clearly worth fixing: a missed null case, a variable name that didn't match the rest of the file's convention, a catch block that swallowed the error without logging it. Stuff that, if the lead caught it instead, would've meant another round of comment - fix - push.

But there were also times it gave generic "best practice" suggestions that didn't fit our team's actual conventions, so I had to filter through what to actually apply versus ignore.

Not always a time-saver either, for small PRs, the lead's review still came back basically unchanged after I'd already run it through Claude, so that step felt redundant. The benefit was clearer on PRs with more complex logic.

Hey everyone!

I love the concept of "vibecoding", getting into the flow, using AI to build fast, and focusing purely on the product. But for a lot of developers (especially in emerging markets like Indonesia), that vibe instantly dies when it's time to deploy.

Suddenly, you are dealing with complex server setups, fighting DevOps configurations, or getting blocked because you don't have an international credit card to spin up a basic server.

Deployment shouldn't ruin the vibe. It should be just as seamless as writing the code.