Good instinct to judge for yourself, because the login answer misunderstands the vulnerability. What it actually is, in one honest example, then the protections that count:

The vulnerability is user input becoming code: an application building queries by gluing strings, a search box feeding WHERE name = '" + userInput + "', lets input containing a quote character escape the data role and continue the statement as SQL. The textbook input of a single quote followed by OR 1=1 turns a login check into a condition true for every row, and the same mechanics escalate to reading other tables, changing data or worse, limited only by what the application's database account may do. The requires login defense fails twice over: injection frequently attacks the login itself, and every authenticated user, plus every attacker holding any stolen credential, faces the same gluing code behind the login, internal applications historically being where injection lives longest precisely because that assurance kept reviews away.

Real protection is one primary discipline with supporting layers. The discipline, parameterized queries: statements written with placeholders, WHERE name = @name, the input bound as a parameter, so the database receives code and data as separate things and no content of the input can change what the statement does. Every language and framework the application could be written in supports this natively, ORMs do it by default until someone concatenates inside a raw query escape hatch and the review your developers owe you is a search of the codebase for string built SQL, each hit either converted or explained. Stored procedures inherit the protection when called with parameters and lose it the moment they build dynamic SQL by concatenation internally, sp_executesql with parameters being the safe dynamic form.

The supporting layers assume the discipline fails somewhere and cap the damage: the application's database account granted only what the application does, no sysadmin connection strings, so an injection that lands reads what the app reads rather than owning the server, errors returned to users kept generic since detailed database errors are the attacker's map, and input validation as the outer moat, valuable against many things while never sufficient alone against this one, because clever encoding slips validation while parameterization holds regardless. OWASP's injection material makes the fine reference for the review, and the one sentence version for judging your developers' answer: protection lives in how queries are built, and nowhere else.