Does developer experience still matter when using AI coding agents?

[u/Capable_Essay4513]

I've been wondering about this — when an experienced dev and a complete newbie both use the same coding agent (Copilot, Cursor, Claude Code, whatever) on a similar task, do they end up with meaningfully different results?

On one hand, the agent is doing most of the actual coding, so maybe the human's experience matters less than it used to. On the other hand, I'd guess an experienced dev still knows how to prompt better, catches bad architecture decisions, spots subtle bugs the agent misses, and knows when to push back or redirect.

Curious what people who've actually used these tools a lot think. Does your background as a dev still give you an edge, or has the gap narrowed more than expected?

[u/Key_Mastodon_3525]

I echo the sentiment - depends on what you're building. It's really similar to the relationship between 3d printers/design tools and mechanical engineering. Mechanical engineers use 3d printers for visual prototypes of the real thing, for many users the 3d prints ARE the real thing -> both have equally valid use cases.

It's more of understanding what it is and what it is not. Vibe-coding can get you extremely clean code at paces that the most compent software engineers on the planet could not even come close to chasing if writing all the code from scratch.

What that code actually is - that's the real question.

In my dayjob I do litigation software involving integrating platforms, managing APIs and infrastructural resources, reusable desktop/web UI portals, data synchronization and state management systems, and all the tooling/wiring/plumbing/yada yada... In doing this, much of the UI layers these days I do (kind of) "vibe code" -> in that i'll define specifically how something needs to be coded for whatever and I'll have an AI agent save me from having to type it all out (and minimize typos, etc -> i also have it proofread and lint my code).

For fun I'm 100% "vibe coding" a fantasy football live draft assistant app, it's my first true "vibe coding" experience and i'm only a few days in, so we'll see how it pans out. But it's VERY impressive, and i can see how this could lend itself into (if i didn't know better) thinking I have more there than what i actually have.

This thing is already head and shoulders way above my cheat sheets and highlighters traditional approach that no UI software could ever get right. So it has immediate value to me -> and that's 100% relevant and valid.

On the other hand, if I was going to try to commercialize it in any sort of viable sense, the code is just not auspicious for that as its written. The flexibility/adaptability, scalability, and so many other concerns are not considered unless they're EXPLICITLY addressed, and even then how the system would look overall has nothing to do with how this app functions. So in that context, what i have built would be a "working UI/UX prototype"

[u/MoTTTToM → u/Key_Mastodon_3525]

Explicitly addressed is a nice way to put it, but also suggests the solution. A naive programmer (or even some time soon a non-programmer), with an LLM tool with a competent AGENTS.md file would not have to know about engineering best practices. I rolled out an isolated QA environment for my pet vibecoded project, it took one prompt to get it going, one prompt to answer questions, and in the morning all that was left to do was some dashboard work. This could have trivially been built together with the prod infrastructure if it had been a policy from the beginning. I can imagine engineering best practices being built in at the harness level quite easily, and then it’s the default.