A few months ago, I started building a terminal app with vibe coding.

I spent a week giving AI instructions, asking it to implement features, fix bugs, and keep going. The codebase grew quickly. There were thousands of lines of code, a UI, and what looked like a working application.

Except the terminal barely worked.

The first Electron version wouldn't even launch properly. I moved to Tauri, tried replacing xterm.js with a custom terminal renderer, and ended up dealing with ANSI parsing, screen buffers, Unicode widths, and Vim rendering bugs.

We've got 111 one click apps in Arteza across six studios. Building them was the easy part. With an agent you can take a prompt template to a shipped, working app in an afternoon, so adding one feels free and you stop asking whether it earns its place.

The bill arrives later. A menu nobody can scan. Support load for things almost nobody opens. And every model swap underneath means retesting all of it, because 111 apps sitting on 30+ models is a test matrix, not a feature list.

The mistake wasn't building them. It was not writing the kill rule first. If I'd set a number up front, opened by this many distinct people in 30 days or it goes, removal would be a rule instead of an argument. Now every deletion is a conversation with someone who liked that one.

Vibe coding collapsed the build cost and did nothing to the maintenance cost, so the ratio is worse than it has ever been. Most of the feature bloat I see right now isn't ambition, it's just that saying no got expensive relative to saying yes.

There is a massive trap in expecting an AI to reliably output matching JSON schemas or proper frontmatter without breaking formatting under the hood.

We finally cut out model generated paths and dates entirely handing those chores over to a simple local hook that feeds exact parameters before every request.

The model only focuses on narrative text now and validation errors dropped to zero. How do you handle strict data formatting in your agent workflows without constantly dealing with broken syntax?

Most of us have a line. mine is anything that changes what the agent is allowed to do next.. new tools, new permissions, a new API key. the agent can do the work, but the yes has to come from me at the keyboard.

someone in my last thread locks test files so the grader sits outside what the agent can touch. same idea.

Where's your line, and is it enforced or just a habit?

I used to assign implementation tasks to teammates. Over the last months I've moved most of that to coding agents: once the requirements are confirmed, I press Enter and the agent implements it and runs the e2e tests. If I need proof, I tell it to capture screenshots as evidence and write a short report.

For me, explaining a task to an agent is easier than explaining it to a person and then re-checking the result. I used to think "one person, one project". Now one person can run several, as long as the requirements are written down clearly before anything is handed over.

What I keep doing myself: collecting incomplete requirements (meeting notes, client questions) as requests, and only handing one to the agent when it is complete. When the client changes something later, I add it as a change request on the same item so the agent gets the original context. The screenshot is my own list of such requests (sample data).

What I'm unsure about: this is my own opinion, not something I measured. Where do you draw the line? Which parts do you still give to a human (reviewing e2e results, client-facing decisions, ambiguous specs), and which do you trust an agent with end to end? Disclosure: I'm the maker of PMDesk, so I'm biased toward this workflow.

There's a specific moment that happens with almost every project: the agent produces code, it passes your tests, everything's green, and there's a real pull to just move on to the next thing. Totally understandable, the whole appeal of this workflow is speed.

But there's a gap between "this works" and "I understand why this works," and that gap is where the real risk hides. Not because the code is wrong, most of the time it isn't, but because the next time something breaks nearby, you're debugging code you never actually read closely the first time.

during the BC (before ChatGPT) era, this gap barely existed. You wrote it, so you understood it, mostly by necessity. Now understanding is a separate step you have to choose to take, not something that comes free with writing the code yourself.

One habit that closes that gap fast: before merging anything non-trivial, ask the agent to explain its own implementation back to you, line by line, in plain language. Not as a formality, actually read the explanation. Two things tend to happen. Either it confirms your understanding and takes thirty seconds, or it surfaces an assumption you didn't know was baked in, which is usually the more valuable outcome.

I've been a professional developer for 10+ years (WordPress ecosystem, and React, TypeScript, Node, the whole stack).

Now I'm building my own SaaS and I'm genuinely torn.

reading the end of software engineering paper (arxiv 2606.05608). its own benchmark has agents above 80% on one-off tasks and at most 38% when they maintain a codebase over time, because early mistakes carry forward. writing code got cheap, keeping a system correct didnt. feels like the real job is now writing intent down clearly and checking agent output with a different method than the one that wrote it. are you spending more time writing code or reviewing what agents wrote?

Hey PH family.

Been part of this community for years now, and if there's one place to talk with builders, this is it.

I ve been spending more time vibe coding recently, and I ve started to question something I initially took for granted. Most of the conversation around vibe coding is about speed. Like how quickly you can go from idea to prototype, or how fast you can iterate. And to be fair, that part is real. The barrier to building has clearly dropped.

But the more I use these tools, the more it feels like speed isn t the limiting factor anymore.

The real constraint seems to be taste.

• what do you choose to build?

• what do you keep vs discard?

• what actually feels right vs just working ?

• what is genuinely useful vs just impressive in a demo?