31–34 of 34 posts
> So if copying a useful piece of code from Stack Overflow has always been acceptable This has not "always been acceptable"; copy-pasta was a pejorative not that long ago, and people have been fired for simply copying code from SO and using it without understanding it.
In your closing thoughts, you don't mention what is this staying firmly in control? how do you stay firmly in control while reaping the benefit of the model while being more productive? because if you start a curriculum over what the model wrote then, one can argue, you are better off writing it yourself in the first place.
One concrete answer from my own small tool: move the things you must stay in control of out of your head and into tests. Our privacy rules (drafts never stored or logged) are executable, so any patch that quietly violates them fails the suite whether or not I reviewed that diff carefully that day. I still read the code, but the invariants no longer depend on my attention holding.
I realized recently the LLMs are calling bullshit on the moniker of engineer or programmer that I've bestowed on myself over the course of my career. The current LLMs are making it quite easy to seperate software design from implementation. I used to be firmly in the camp that one really needed to roll up their sleves, sit down with an editor and start banging away until the software evolved and coalesced around a so…
>The current LLMs are making it quite easy to seperate software design from implementation. I don't really agree. This kind of division of labor has always been possible, with architects doing the design and engineers/programmers doing the implementation. Architects who design systems with lofty requirements with no regard for the cost of their decisions are kind of a meme in the industry. I don't believe it's really…
Earlier quoted context omitted.
>The current LLMs are making it quite easy to seperate software design from implementation. I don't really agree. This kind of division of labor has always been possible, with architects doing the design and engineers/programmers doing the implementation. Architects who design systems with lofty requirements with no regard for the cost of their decisions are kind of a meme in the industry. I don't believe it's really…
The Architects you're describing aren't reviewing the code and making suggestions for changes so your comparing apples and oranges. What I'm describing is more of a team lead to team members relationship.