[sky2224]

The key is knowing when and how to use both.

If you can be twice as fast with something using AI and you're actively choosing not to use it, then yeah you're just being stubborn. Get over it or risk getting the boot.

There will be times though where you need to finish that last 10% of coding because the model just isn't refined enough for whatever task you're giving it. And from what I've experienced so far, that last 10% ends up being 70% of the work, which is where your expertise will come in.

[dakiol]

I cannot think of any environment in which getting code fast is of paramount importance (ok, maybe in hackathons and the advent of code). In work based environments, the bottleneck is not writing code is human interaction (understanding requirements, making trade offs and communicating them, listening to feedback, etc.)

[gcheong]

If you follow agile one of the tenets is getting working code to users fast in order to get feedback sooner rather than later. Yes, the things you say are where the bottlenecks typically lie, but it's a cycle so the faster you can get working code out the sooner you can enter the other parts of the cycle. In theory anyway.

[skydhash]

> If you follow agile one of the tenets is getting working code to users fast in order to get feedback sooner rather than later.

There's no mention of that anywhere in the manifesto

  Individuals and interactions over processes and tools
  Working software over comprehensive documentation
  Customer collaboration over contract negotiation
  Responding to change over following a plan

It's mostly saying to focus on active factors more than rigid rituals so that that the product evolves faster and in the right direction. There's no mention on pumping code out as fast as you can.

[gcheong]

I was going by this:

https://agilemanifesto.org/principles.html

Specifically:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

I guess there are religious texts, and then there are the interpretations of those texts.

[skydhash]

I failed to see how AI assistance can make the cycle faster. The actual writing code is a very small part after the initial cycle. The most important aspect is to have a theory of the software (or the part you own) so that you can contrast it with requirements. Such theory is hard to get without a close relationship with the code.

[ipaddr]

Teams who use agile mostly release on a set schedule not immediately. Getting that function a few minutes quicker but introducing a blackhole you don't understand but you hope works in production but can't rely on the tests AI made seems foolish.

[sky2224]

I've had instances now where the code generated by copilot has saved me roughly an hour or more without turning into a can of worms. Your mileage is going to vary depending on the language and framework you're using.

For example, one instance for me was with winforms. I wanted to know how to recursively expand a list box. It's not a hard task, but it's just something that's tedious since I need to go research the documentation to see how a list box control actually behaves and what properties I need to manipulate. This is a very solved problem. What good is there in me re-solving it when someone has already done so?

That's where using AI is helpful without it being foolish.