[wiradikusuma]

Maybe I'm old, but I only recently started using Gemini to assist me in coding. Now it seems everyone is heading to giving agents to do the full-blown coding. I guess if the result code is good, it doesn't matter who's coding (me or AI).

But are they affordable already for developers who don't earn a Silicon Valley salary? Developers in 3rd world countries?

[seamossfet]

I'm not convinced people who are doing real work on production applications with any sizable user base is writing code through only agents. There's no way to get acceptable code from these models without really knowing your code base well and basically doing all the systems thinking for the model.

Your workflow is probably closer to what most SWEs are actually doing.

[ryandrake]

You really need to keep them on a tight leash, stop and correct them when they start screwing up, and then the remaining 90% of the work starts after they say their done, where you need to review/refactor/replace a lot of what they produced.

The only way you're going to let an agent go off on its own to one-shot a patch is if your quality bar is merely "the code works."

[nprateem]

Not true. As long as you don't blindly accept their garbage and keep things behind sensible interfaces so you can reimplement if necessary, and have good tests you're fine

[simplyluke]

This, at least for me, has changed in the past six months. Which is the same thing people were saying in the months prior to that, so I will accept some eye rolls. But at least for our pretty large monorepo opus + a lot of engineering work on context got us to a point where a large portion of our engineers are doing most of their work with agents first and a lot of back and forth + smaller hand edits.

[kypro]

Agreed. The size of the repo isn't a limiting factor anymore. It's more about the type of change.

Agents today can generate solid code even for relatively complex requirements. However, they don't always make the right trade-offs.

Just because something works doesn't mean it scales. It doesn't mean it can handle unexpected user input. It doesn't mean it's easily extensible.

Today engineers really just need to define those high-level technical requirements.

[simplyluke]

> Today engineers really just need to define those high-level technical requirements.

At least within our company, this is quickly becoming what it means to be a software engineer.