281–290 of 378 posts
Wasn't that the idea? Withe cars on roads, didn't we literally lose the touch with the ground? I guess the desire was to "lose" touch with all dirty and hard work areas.
Earlier quoted context omitted.
Yeah I get that. But having been both it doesn’t advocate for better treatment for any of them. Also as far as I’m aware the pay for programmers in the US has always been an isolated thing with the rest of the world ranging from normal to “literal sweatshop”.
What do you mean, "advocating for better treatment"? They're not describing an abuse of tradespeople and professionals. They're adults doing a job.
That makes no sense. You seem to understand that he was being snarky, so why do you not understand that that snark and desire to see “others” brought down to a lower level just because some were already there doesn’t help anyone? Actually, that division does help people, those people that are putting people there in the first place.
Let’s be clear: for context I’ve been out of the programming game for more than 10 years at this point. I have my own business that I’m set to sell soon and then retire to something more entrepreneurial. But I still don’t desire to see my younger employees suffer any more than the tradesmen I used to work with.
Earlier quoted context omitted.
So how do you build competence in a world where AI is preached to be the most reasonable way to solve problems because it's supposed to be faster than humans?
Have a single human AI chef. Everyone else has to write an engineering statement and submit it to the AI chef. All that interaction is outside the codebase. Engineers will take turns - perhaps 1 month stints - being the AI chef. I guarantee you'll spend less on tokens, have better documentation, better code, and most importantly more competent engineers.
On the other hand, I think this denies the reality (in my experience anyway but I think enough people will agree) that one often solves a problem as they are working on it.
This method seems to presume that a good engineer will submit a well thought-out solution or direction giving the AI an extremely good overview of each problem and enough of a description of what to do that it will do things as expected and they can just review the result.
In my experience it just doesn't work that way in practice. One learns the problem and even the domain while developing the solution. So one would have to submit at least a half developed solution not just "instructions", for there to even be coherent instructions in the first place. And one needs that experience working on the problem to be able to properly evaluate a separately proposed solution.
All in all for me this leads more towards using AI as a co-developer than using it to just implement some fully thought out idea and then check what it did.
Earlier quoted context omitted.
> and it's quite enjoyable Used to be somewhat enjoyable. Nothing pleasant about digging around codebase that was heavily affected by the last 12-18 months of AI-ing.
We have a tool at work that was entirely spun out of a prototype that itself was entirely driven by a single guy with an unlimited Claude budget. I only touch it on the edges, where I need to integrate it every so slightly into one of my systems. It's a crucial piece of software for the team, though. I've looked over the source, the thing that strikes me the most is the verbosity. Human software engineers would've be…
A natural evolution of engineers losing touch with the customers and users. I'm noticing some of the concern play out regarding AI weakening the capabilities of software people. I gave the team an exact solution on a silver platter and they still failed to identify how to go about it after 3 days slamming it into Claude. The resolution is literally 1 line of code that could be arrived at in about 30 minutes of patien…
What is your relationship to this team? Their manager? A senior colleague? Something about this sounds like a failure of communication or leadership. Why are you stand offish from them? Why are you treating them like children? If they don't know what they're doing why did you hire them? Now that you did why are you treating them like a burden and not an opportunity to mentor, teach, and uplift?
It used to be that when someone else at your company was asking for something that wasn't a priority, you would erect bureaucratic roadblocks to protect your time. Now, the new normal is to just forward their questions to AI and sling the slop back over to them.
Earlier quoted context omitted.
I don't think it's generalizable. The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. It's more compelling, and we probably see more of them because of it, but it's the same general thing. The kind of person who insists on understanding things and working through the problem has always been rarer. It's not "humble", it's "inquisitive" and "persistent".
The difference between the two is that friction is learning. the less friction the less growth. So even if they copied from SO they would have better knowledge than an Ai user. This isn’t speculation either, theres an MIT study which this is based on. https://www.media.mit.edu/publications/your-brain-on-chatgpt...
Earlier quoted context omitted.
I was investigating an ansible playbook yesterday that had a 45 line comment to explain a single apt install command, completely and utterly useless. I am updating my neovim to just collapse all comments, the noise is unbearable.
I've seen people report cleaner code by forbidding agents from writing comments. Anecdotal, but interesting.
Limit the amount of comments you put in the code to a strict minimum. You should almost never add comments, except sometimes on non-trivial code, function definitions if the arguments aren't self-explanatory, and class definitions and their members.
Do not remove existing comments unless they are directly related to what you are changing.
Earlier quoted context omitted.
You are advocating for the kind of compartmentalization that got us here in the first place.
Nothing wrong with compartmentalization. Some people like it, some people don’t. Just different ways to live your life.
I've always worked in high-trust organizations where we depended on each other operating on the diligent side of things, making conservative choices to never wander into the murky area in between. It is horrifying to me how many people seem complacent about or even complicit in a different objective, which seems hell bent on wandering as far into the murk as one can without being caught.
When the person who has a duty of diligence starts rubber-stamping AI outputs, they're veering off into that same murk. They accidentally or wantonly trust the agent as if they have delegated their duty of care. But the AI tool has no such duty and no capacity to care.
I think this worker who has turned themselves into an outsourcing middleman needs to treat the results just like "found code" in a USB drive they found in the parking lot. Its origins and purpose are unclear. It could be flawed or obscurely inappropriate for the intended application, it could have legal entanglements, or it could even be subtly adversarial. The review task to figure this out is not simple. It is not something you do by skimming the result, or worse, asking some other AI tool to review and summarize.
The person importing such code to a project needs a different kind of diligence to try to screen it. For a lot of people, I think this review may be impossible or at least no less laborious than doing the original work themselves with the required diligence.
And, I think this importer needs to be fully liable and responsible for the outcome. But, instead, I think we're seeing frequent appeals to blame the machine and act like it is an honest mistake to let things pass because they've been rubber-stamping the imports. A lazy desire to claim credit for appearance of success, but shirk responsibility for detected failures.
A natural evolution of engineers losing touch with the customers and users. I'm noticing some of the concern play out regarding AI weakening the capabilities of software people. I gave the team an exact solution on a silver platter and they still failed to identify how to go about it after 3 days slamming it into Claude. The resolution is literally 1 line of code that could be arrived at in about 30 minutes of patien…
What is your relationship to this team? Their manager? A senior colleague? Something about this sounds like a failure of communication or leadership. Why are you stand offish from them? Why are you treating them like children? If they don't know what they're doing why did you hire them? Now that you did why are you treating them like a burden and not an opportunity to mentor, teach, and uplift?