Yeah, I have never understood the over reliance on AI. Writing the code is not the challenge. The time it takes to push a new feature and test it out is often trivial, maybe a few hours.
The real challenge is forming the new ideas in the first place and most of those new ideas coming either from using the code as a product or time spent maintaining and refactoring large code.
Anyways, if you want to continue on the path towards regaining control and take it to the next level I wrote something similar here: <a href="https://blog.sharefile.systems/be-brave-go-low/" rel="nofollow">https://blog.sharefile.systems/be-brave-go-low/
Wriring the code is not the challenge, but it's what was taking up most of the time. Not the typing itself, but also because I had to think of how to implement it.
Now I can just say "add 2FA" and in 5 minutes, while I test something else, it is done.
It also made iterations a lot faster, you can try something out, see how it feels, if it doesn't work, you can just trash all the code and start again.
I don't know what it built for you in 5 minutes, probably something that "works".
I have spent two weeks using opus just to write a plan/design for 2FA and iron it out until review (about 7 of them) doesn't flag it with 20+ problems (with security holes of various sizes), for which I had to guide it through to not turn it into a mess and whac-a-mole.
It's just a secret key that an autheticator uses to generate a time-based code, which the app can validate before completing a normal log-in flow.
What model did you use?
Astra xhigh on fast mode can probably indeed one-shot that in 5 minutes.
Plus optionally QR image generator to easily add that key to the authenticator app.
There are already many libraries doing 2FA, but implementing it in any language is quite trivial, right
Aside from the fact that the implementation must be secure, you want for example to:
- handle accounts that have lost their second factor in an way appropriate for your business
- decide what to do with accounts who don't configure it. If e.g. you want to send them authentication codes via email or SMS that's another can of worms.
Let alone the simple things such as making sure that your implementation works with the various TOTP apps
Any of the latest models can one shot a modern 2FA workflow given the right context in a sane codebase.
The critical part is providing it a way to validate its work end to end. Without that, it's similar to asking a human to implement a feature with pen and paper.
> The critical part is providing it a way to validate its work end to end.
Yes! Part of implementing it "one-shot" is actually a loop of planning, implementing, testing e2e on various devices and various edge-cases. It's not just writing the code, and this is not how "vibe-coding" works nowadays. It's not just writing code anymore, this is why most providers worked on their computer-use support too, not only for doing tasks, but also for being able to check and test the work they do e2e.
If you're not doing anything that matters, 2FA is easy. If you're doing something people actually care about, you're going to have to answer real world questions like "how do we provide support for this", "do we force certain roles to set up 2fa", "what if someone loses their phone", etc
I just asked the model to implement 2FA and it did address all the points you've mentioned.
EDIT: Support was not the case, because the app is self-hosted, but the docs should indeed provide instructions for recovery if both authenticator and recovery codes are lost.
Well yeah, and it wasn't, most of the pain was around rate limiting, lockouts and preventing exploits and making it work with this specific codebase.
I agree that with a clean codebase it will be simpler, maybe couple of days, just running code review workflow takes 15-30 minutes and then decisions llm makes for each problem is often not good and lead it into overengineering rabbit hole, which means I have to think about each problem and prevent it from escalating.
But yeah if "look, it sends the code and I can enter it to login" is enough validation then it can be made in 5 minutes, sure.
austin-cheney · · focus · HN ↗
The real challenge is forming the new ideas in the first place and most of those new ideas coming either from using the code as a product or time spent maintaining and refactoring large code.
Anyways, if you want to continue on the path towards regaining control and take it to the next level I wrote something similar here: <a href="https://blog.sharefile.systems/be-brave-go-low/" rel="nofollow">https://blog.sharefile.systems/be-brave-go-low/
XCSme · · focus · HN ↗
Now I can just say "add 2FA" and in 5 minutes, while I test something else, it is done.
It also made iterations a lot faster, you can try something out, see how it feels, if it doesn't work, you can just trash all the code and start again.
aytigra · · focus · HN ↗
I have spent two weeks using opus just to write a plan/design for 2FA and iron it out until review (about 7 of them) doesn't flag it with 20+ problems (with security holes of various sizes), for which I had to guide it through to not turn it into a mess and whac-a-mole.
XCSme · · focus · HN ↗
It's just a secret key that an autheticator uses to generate a time-based code, which the app can validate before completing a normal log-in flow.
What model did you use?
Astra xhigh on fast mode can probably indeed one-shot that in 5 minutes.
Plus optionally QR image generator to easily add that key to the authenticator app.
There are already many libraries doing 2FA, but implementing it in any language is quite trivial, right
n_e · · focus · HN ↗
No?
Aside from the fact that the implementation must be secure, you want for example to:
- handle accounts that have lost their second factor in an way appropriate for your business - decide what to do with accounts who don't configure it. If e.g. you want to send them authentication codes via email or SMS that's another can of worms.
Let alone the simple things such as making sure that your implementation works with the various TOTP apps
XCSme · · focus · HN ↗
One-time displayed recovery codes are a standard practice, and most good LLMs will add it by default without even asking for it.
And yeah, I am talking about TOTP apps, I think sms/email is not as secure.
sampullman · · focus · HN ↗
The critical part is providing it a way to validate its work end to end. Without that, it's similar to asking a human to implement a feature with pen and paper.
XCSme · · focus · HN ↗
Yes! Part of implementing it "one-shot" is actually a loop of planning, implementing, testing e2e on various devices and various edge-cases. It's not just writing the code, and this is not how "vibe-coding" works nowadays. It's not just writing code anymore, this is why most providers worked on their computer-use support too, not only for doing tasks, but also for being able to check and test the work they do e2e.
thunderfork · · focus · HN ↗
XCSme · · focus · HN ↗
EDIT: Support was not the case, because the app is self-hosted, but the docs should indeed provide instructions for recovery if both authenticator and recovery codes are lost.
aytigra · · focus · HN ↗
I agree that with a clean codebase it will be simpler, maybe couple of days, just running code review workflow takes 15-30 minutes and then decisions llm makes for each problem is often not good and lead it into overengineering rabbit hole, which means I have to think about each problem and prevent it from escalating.
But yeah if "look, it sends the code and I can enter it to login" is enough validation then it can be made in 5 minutes, sure.