Live data from Hacker News

We should be more tired than the model

vickiboykis.com

51–60 of 168 posts

Re: We should be more tired than the model

#51
post #46

I don't know. I find that I'm moving up a level and improving my product-management skills while delegating most of the code to the agents. I'm still very much hands-on with the design and requirements, and I'm asking questions like, "What's our security story for XYZ?", "Are we accounting for colour-blindness?", etc. Not being down in the code allows me to prairie-dog a bit more and see the landscape better.

I'm about 50% that way. However when the AI is done coding I then step back and review to find places the code quality is unacceptable. I also have to stop the AI once in a while because it forgets the point and does something stupid. Junior engineer learn, AI does not.

> Junior engineer learn, AI does not.

This is technically true, but lets not act like we haven't seen immense improvement of both models are harnesses for these models in the past years. They may not be learning, but they are getting better

Re: We should be more tired than the model

#52

> We should be more tired than the model I understand the rationale behind this, but can't help feeling that this is a downward spiral. The software industry has always been a hard place to build and sustain a career because of the pace of change. With these tools, the pressure to increase output is going to grow, jobs are going to be axed - so software devs need to work harder to stay relevant. Weren't these tools s…

I'm not convinced jobs will be axed in the long-term - All the big tech companies frequently staff teams on projects that basically go nowhere to spread bets on multiple projects in case one has legs. Once LLMs reach the point of commoditization and drop in price, it seems like the natural next step is more teams with smaller structures to spread bets even more. A 5 person team that is LLM-assisted is going to move faster and be more cohesive than an 10 person team that ends up stepping all over each other.

Re: We should be more tired than the model

#54
post #38

So many efforts out there to alter the usage of the tool to regain control, when it's clear to me that the tool is the problem? By which I mean, we should -- as software engineers -- be insisting on tools that put us in the driver's seat more. Instead we're letting the agent drive. (I'm as guilty as this as anybody). But really we're letting Dario, Sam, Boris, etc. drive. And it should be clear from their public pron…

> By which I mean, we should -- as software engineers -- be insisting on tools that put us in the driver's seat more. And the company says "fuck you then, I'll fire you, and keep fewer coders, willing to keep the AI dance". The role of AI as a tech is to put you out of the drivers seat as much as possible. All the way to job elimination. Solution?

And by doing that said companies are devaluing their own IP and creating an organizational knowledge debt. Companies that work that way will in long run get outcompeted by shops that figure out (I don't know how) how to manage this better.

Re: We should be more tired than the model

#55
post #35

Earlier quoted context omitted.

>Prompts like "move the code relating to SQL query analysis into a new file", "look for opportunities to use pytest parametrize to remove duplication in that test", "rename method X to Y". There’s a lot of overlap there with the sorts of things traditional automated refactoring tools can do approximately instantly, locally, and for free.

What are some traditional automated refactoring tools that can do stuff like those tasks from the example?

???

Mature workflows for those kinds of tasks have been mostly ubiquitous across professional-grade engineering tools like those from JetBrains or Visual Studio itself for longee than many people here have even been working in the trade.

It's clearly not the case for simonw, but much of what many people task AI tools to do foe them are only a novelty for the "VS Code"-type users who stubbornly refused to explore more professional-grade paid tools in the past.

Yet for many tasks, those mature paid tools provided reliable and efficient features that make the AI approach look like an expensive, slow, and dangerously nondeterministic regression.

Re: We should be more tired than the model

#56
post #35
post #14

Something I've been trying recently for non-throwaway code is extensive refactoring, without typing any code myself but by closely directing the coding agent. Prompts like "move the code relating to SQL query analysis into a new file", "look for opportunities to use pytest parametrize to remove duplication in that test", "rename method X to Y". Early indications are that this is helping a lot with the problem where i…

>Prompts like "move the code relating to SQL query analysis into a new file", "look for opportunities to use pytest parametrize to remove duplication in that test", "rename method X to Y". There’s a lot of overlap there with the sorts of things traditional automated refactoring tools can do approximately instantly, locally, and for free.

You just went too far. Go back to the subscription.

Re: We should be more tired than the model

#57
post #35

Earlier quoted context omitted.

>Prompts like "move the code relating to SQL query analysis into a new file", "look for opportunities to use pytest parametrize to remove duplication in that test", "rename method X to Y". There’s a lot of overlap there with the sorts of things traditional automated refactoring tools can do approximately instantly, locally, and for free.

What are some traditional automated refactoring tools that can do stuff like those tasks from the example?

Eclipse IDE since like 2001

Re: We should be more tired than the model

#58
post #46

Earlier quoted context omitted.

I'm about 50% that way. However when the AI is done coding I then step back and review to find places the code quality is unacceptable. I also have to stop the AI once in a while because it forgets the point and does something stupid. Junior engineer learn, AI does not.

Unless you log its mistakes and how they were solved in decisions.log

[deleted]

Re: We should be more tired than the model

#59
post #35
post #14

Something I've been trying recently for non-throwaway code is extensive refactoring, without typing any code myself but by closely directing the coding agent. Prompts like "move the code relating to SQL query analysis into a new file", "look for opportunities to use pytest parametrize to remove duplication in that test", "rename method X to Y". Early indications are that this is helping a lot with the problem where i…

>Prompts like "move the code relating to SQL query analysis into a new file", "look for opportunities to use pytest parametrize to remove duplication in that test", "rename method X to Y". There’s a lot of overlap there with the sorts of things traditional automated refactoring tools can do approximately instantly, locally, and for free.

Yea, when I read about people using AI with prompts like that, my first thought is, "Wow, that's like copy/paste, but instead of Ctrl-C/Ctrl-V, it's round-tripping to a server and using GPUs to do it." What's next? "Claude, rename the function doFoo() to performBar()"?

Re: We should be more tired than the model

#60
post #46

Earlier quoted context omitted.

I'm about 50% that way. However when the AI is done coding I then step back and review to find places the code quality is unacceptable. I also have to stop the AI once in a while because it forgets the point and does something stupid. Junior engineer learn, AI does not.

> Junior engineer learn, AI does not. This is technically true, but lets not act like we haven't seen immense improvement of both models are harnesses for these models in the past years. They may not be learning , but they are getting better

They are getting better at historical data, not at the fundamental issue.

As a recent example, I recently had to abandon the multiple LLM reviewer/verifier model I was using because zig 0.16 was released with major changes.

I actually reverted back to full self hosted because the foundation models we’re trying too hard to revert to the older versions of the language.

It is going to be a balancing act and there is fundamentally no way for LLMs to get around this.

We will have to develop methods to do so, most likely by focusing agents on problems that are more static.

Post reply on HN