[HN Gopher] It took longer to get the API key
       ___________________________________________________________________
        
       It took longer to get the API key
        
       Author : jdalton
       Score  : 14 points
       Date   : 2025-06-12 14:24 UTC (8 hours ago)
        
 (HTM) web link (algarch.com)
 (TXT) w3m dump (algarch.com)
        
       | jdalton wrote:
       | I asked Claude to integrate Google Indexing API. 34 seconds
       | later, it was done. I hadn't even gotten the API keys by then.
       | Crazy time to be alive.
        
         | PaulHoule wrote:
         | Google is extra bad. 10+ years ago I did a shoot out of several
         | machine learning APIs. All of them were less than 20 minutes to
         | start running queries through, except for Google which took
         | upwards of an hour and trashed every Python runtime on my
         | machine.
        
         | Ronsenshi wrote:
         | Sounds like we need a Google API which would allow us to create
         | Google API keys so that we can ask LLM to do it.
         | 
         | But then again you would need key for that first API... .
        
           | jdalton wrote:
           | A centralized API key registry would be cool, but risky as
           | hell.
        
       | hooverd wrote:
       | I'll give this credit for being good FOMO content marketing.
        
         | OutOfHere wrote:
         | The article preys on the gullible who are naive enough to think
         | that AI actually writes flawless code. It doesn't.
        
           | jdalton wrote:
           | I don't think it said it wrote code flawlessly.
        
             | quectophoton wrote:
             | They might not have said it explicitly, but heavily imply
             | it with:
             | 
             | > 34 seconds later, it was done. Not just a quick
             | hack...proper production-ready code with error handling,
             | logging, environment checks, documentation, the entire
             | implementation. Working, tested, committed to git.
             | 
             | > This wasn't copy-paste from Stack Overflow. This was
             | bespoke, production-ready code tailored to my specific
             | Laravel app, following my existing patterns, with proper
             | security considerations.
             | 
             | And with their proposed "AI-Optimized Process"
             | conspicuously lacking code review, QA, manual approval.
             | Just going straight from prompt to production, with no
             | human supervision after the prompt is written. Otherwise
             | those steps would have been mentioned in the list, the same
             | way "Traditional API Integration Process" mentions them.
             | 
             | At that point might as well add a button to Jira that says
             | "Implement this".
        
               | toomuchtodo wrote:
               | > At that point might as well add a button to Jira that
               | says "Implement this".
               | 
               | And just like that, people centuries of
               | remediation/refactoring consulting work was created.
        
               | jdalton wrote:
               | I wouldn't be surprised if Jira offered that in the next
               | 6 months. Wait until AI gets deeper into PM work..scrum
               | could die and I wouldn't shed a tear.
        
       | andrewstuart wrote:
       | Big clouds - AWS,Google,Azure are so complex that even just
       | getting an API key is painful expert level project that you might
       | give up on.
       | 
       | I prefer smaller companies where you go to account settings and
       | "download API key".
       | 
       | This pain level is a genuine factor for me in using an big cloud
       | service.
        
         | jdalton wrote:
         | Oh gosh, don't me started on AWS!
        
       | OutOfHere wrote:
       | The article is complete nonsense because AI generated code is
       | often buggy, and always needs to be reviewed in detail. Also, the
       | code can only be good if the prompt is good and detailed. All of
       | this takes up a significant amount of time. It would seem that
       | the author is technically incapable of reviewing code, which is
       | why it's not even an afterthought.
        
         | jdalton wrote:
         | It would seem you're far off.
        
       | Leynos wrote:
       | This will be the next benchmark suite: how long does it take your
       | model to interactively retrieve an API key.
        
         | jdalton wrote:
         | It could possibly become that.
        
         | viraptor wrote:
         | This is going a bit in the wrong direction. You don't need to
         | do it to happen interactively. Models are fine writing
         | terraform code which could handle all of that. But your company
         | / processes have to be ready for that.
        
       | bsder wrote:
       | So ... why couldn't the AI get the API keys?
       | 
       | Now _THAT_ is a task that I would like AI to deal with for me.
        
         | viraptor wrote:
         | You don't want to expose the AI to your whole secrets store to
         | do the login. But in a way, it can automate the process itself:
         | https://registry.terraform.io/providers/hashicorp/google/lat...
         | 
         | We still need to use people who know to go that way though and
         | how to make the company enforce it.
        
         | jdalton wrote:
         | It's sure as heck would make life easier.
        
       | zerotolerance wrote:
       | The coding time is irrelevant and always has been. Time writing
       | code has never been the high cost or challenge especially so in
       | blue sky / green field development cases like those described in
       | all these articles. And as far as ops processes go, we're already
       | lightyears faster than we were even a decade ago. I could rant
       | about ITIL and these integrated flow fantasies, but even that is
       | a distraction.
       | 
       | The bulk of engineering time is spent engineering (not writing
       | code), researching the right thing to build, reviewing plans with
       | product ownership, considering operating context and constraints,
       | adjusting designs and redeveloping based on learnings. Writing
       | code is the easy part when everyone leaves you alone and you just
       | cook. Those meetings aren't going anywhere because at the end of
       | the day it takes a lot of back and forth to even come up with a
       | relatively stable spec.
       | 
       | I agree that ops automation is important, but its hard to take
       | this article seriously.
        
         | jdalton wrote:
         | I see those type of meeting just being labeled context
         | gathering in the future.
        
       | cadamsdotcom wrote:
       | Maybe what is needed is selective gating - some PRs are the type
       | you REALLY have to make sure are reviewed; others can go through
       | a barrage of AI reviews (security, code-quality etc) and the
       | author can merge.
       | 
       | Either human or AI (or both?) needs to be tagging PRs. Perhaps a
       | traffic light system is appropriate? Red - needs close human
       | review; green - AI review only; yellow - unclear / somewhere in
       | the middle.
       | 
       | Using PRs to merge features gives auditability and traceability
       | to which human merged which thing.
       | 
       | As always, it is situational. AI is exposing new shades of grey.
        
         | jdalton wrote:
         | Agreed.
        
       ___________________________________________________________________
       (page generated 2025-06-12 23:01 UTC)