That seems very dependent on which company you work for. Many would not grant you that kind of flexibility.

The majority of places I've worked don't adjust business rules on the fly because of flexibility. They do it because "we need this out the door next month". They need to ship and ship now. Asking clarifying questions at some of these dumpster fires is actually looked down upon, much less taking the time to write or even informally have a spec.

At their peril, because any set of rules, no matter how seemingly simple, has edge cases that only become apparent once we take on the task of implementing them at the code level into a functioning app. And that's assuming specs have been written up by someone who has made every effort to consider every relevant condition, which is never the case.

And in the example of "why" this 401 is happening that's another one of those. The spec might have said to return a 401 for both not being authenticated and for not having enough privileges.

But that's just plain wrong and a proper developer would be allowed to change that. If you're not authenticating properly, you get a 401. That means you can't prove you're who you say you are.

If you are past that, i.e. we know that you are who you say you are, then the proper return code is 403 for saying "You are not allowed to access what you're trying to access, given who you are".

Which funnily enough seems to be a very elusive concept to many humans as well, never mind an LLM.

...then there are the other fun ones, like not wanting to tell people things exist that they don't have access to, like Github returning 404 errors for private repositories you know exist when you aren't logged into an account that has access to them.

That one at least makes sense if you ask me. It's not just Github doing it. On the web side of things you'd return the same "no such thing here" page whether you don't have access or it really doesn't exist as well. So leaking more info than the page you return to users in the browser would show via the status code would not be good.

I.e. that would be the appropriate thing to do if you're trying to prevent leakage of information i.e. enumeration of resources. But you should not return 401 for this still. A 404 is the appropriate response for pretending that "it's just not there" if you ask me. You can't return 404 when it's not there and a 403 when you have no access if enumeration is bad.

So for example, if you don't have access to say the settings of a repo you have access to, a 403 is OK. No use pretending with a 404, because we all know the settings are just a feature of Github.

However, pretending that a repo you don't have access to but exists isn't there with a 404 is appropriate because otherwise you could prove the existence of "superSecretRepo123" simply by guessing and getting a 403 instead of a 404.

> That seems very dependent on which company you work for. Many would not grant you that kind of flexibility.

It really boils down to what scenario you have in mind. Developers do interact with product managers and discussions do involve information flowing both ways. Even if a PM ultimately decides what the product should do, you as a developer have a say in the process and outcome.

Also, there are always technological constraints, and some times even practical constraints are critical. A PM might want to push this or that feature but if it's impossible to deliver on a specific deadline they have no alternative to compromise, and the compromise is determined by what developers call out.

How does that work in an AI-supported development process? I'm a bit out of the loop since I left the industry. Usually there is a lot of back and forth over things like which fields go in a form, and whether asking for a last name will impact the conversion rate and so on.

Well the AI will just steamroll through and will therefore go out of rails just like a junior dev on a coding binge.

But all the senior business folks think AI can do no wrong and want to put it out the door anyway, assuming all the experienced engineers are just trying to get more money or something.

> adjust ... the business rules

Successful projects do this. Ideally, front loaded.

Unsuccessful projects attempt to reify the chaos.