171–180 of 409 posts
Earlier quoted context omitted.
Cool cool cool. So if you use LLMs as junior devs, let me ask you how future awesome senior devs like you will come around? From WHAT job experience? From what coding struggle?
How do you get junior devs if your concept of the LLM is that it's "a principal engineer" that "do[es] not ask [you] any questions"? Also, I'm pretty sure junior devs can use directing a LLM to learn from mistakes faster. Let them play. Soon enough they're going to be better than all of us anyway. The same way widespread access to strong chess computers raised the bar at chess clubs.
Earlier quoted context omitted.
That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and reviewing the outputs. It does the boring stuff of actually writing the code. I am phenomenally productive this way, I am happier at my job, and its quality of work is extremely high as long as I occasionally have it stop and self-review it's progress against the…
I think we have different opinions on what's fun and what's boring!
Having said that I used to be deep into coding and back then I am quite sure that I would hate AI coding for me. I think for me it comes down to – when I was learning about coding and stretching my personal knowledge in the area, the coding part was the fun part because I was learning. Now that I am past that part I really just want to solve problems, and coding is the means to that end. AI is now freeing because where I would have been reluctant to start a project, I am more likely to give it a go.
I think it is similar to when I used to play games a lot. When I would play a game where you would discover new items regularly, I would go at it hard and heavy up until the point where I determined there was either no new items to be found or it was just "more of the same". When I got to that point it was like a switch would flip and I would lose interest in the game almost immediately.
Earlier quoted context omitted.
I have mentored and worked with a junior dev. And the only way to get her to do anything useful and productive was to spell things out. Otherwise she got wrapped around the axle trying to figure out the complex things and was constantly asking for my help with basic design-level tasks. Doing the grunt work is how you learn the higher-level stuff. When I was a junior, that's how it was for me. The senior gave me somet…
I have never worked with junior devs as incompetent as you describe, having worked at AWS, Splunk/Cisco, among others. At AWS even interns essentially got assigned a full project for their term and were just told to go build it. Does your company just have an absurdly low hiring bar for juniors? > Giving juniors full autonomy is a great way to end up with an unmaintainable mess that is a nightmare to work with withou…
It's an entirely different world in small businesses that aren't primarily tech.
Or I should say, they kept hiring the humans who needed something to do, and basically did what this AI did.
Earlier quoted context omitted.
Maybe I didn't make it clear, but I didn't build the software in my comment. A clanker did. Vibe-coding is a claude code QA loop on the end result that anyone can do (the non-experts in his claim). An example of a cycle looks like "now add an Options tab that let's me customize the global hotkey" where I'm only an end-user. Once again, where do my 20 years of software experience come up in a process where I don't eve…
> An example of a cycle looks like "now add an Options tab that let's me customize the global hotkey" where I'm only an end-user Which is a prompt that someone with experience would write. Your average, non-technical person isn't going to prompt something like that, they are going to say "make it so I can change the settings" or something else super vague and struggle. We all know how difficult it is to define softwa…
The LLM prompt space is an ND space where you can start at any point, and then the LLM carves a path through the space for so many tokens using the instructions you provided, until it stops and asks for another direction. This frames LLM prompt coding as a sort of navigation task.
The problem is difficult because at every decision point, there's an infinite number of things you could say that could lead to better or worse results in the future.
Think of a robot going down the sidewalk. It controls itself autonomously, but it stops at every intersection and asks "where to next boss?" You can tell it either to cross the street, or drive directly into traffic, or do any number of other things that could cause it to get closer to its destination, further away, or even to obliterate itself.
In the concrete world, it's easy to direct this robot, and to direct it such that it avoids bad outcomes, and to see that it's achieving good outcomes -- it's physically getting closer to the destination.
But when prompting in an abstract sense, its hard to see where the robot is going unless you're an expert in that abstract field. As an expert, you know the right way to go is across the street. As a novice, you might tell the LLM to just drive into traffic, and it will happily oblige.
The other problem is feedback. When you direct the physical robot to drive into traffic, you witness its demise, its fate is catastrophic, and if you didn't realize it before, you'd see the danger then. The robot also becomes incapacitated, and it can't report falsely about its continued progress.
But in the abstract case, the LLM isn't obliterated, it continues to report on progress that isn't real, and as a non expert, you can't tell its been flattened into a pancake. The whole output chain is now completely and thoroughly off the rails, but you can't see the smoldering ruins of your navigation instructions because it's told you "Exactly, you're absolutely right!"
Earlier quoted context omitted.
Cool cool cool. So if you use LLMs as junior devs, let me ask you how future awesome senior devs like you will come around? From WHAT job experience? From what coding struggle?
My last job there was effectively a gun held to the back of my head, ordering me to use this stuff. And this started about a year ago, when the tooling for agentic dev was absolutely atrocious, because we had a CTO who had the biggest most raging boner for anything that offered even a whiff of "AI". Unfortunately the bar is being raised on us. If you can't hang with the new order you are out of a job. I promise I was…
I don't think we'll be out of jobs. Maybe temporarily. But those jobs come back. The energy and money drain that LLMs are, are just not sustainable.
I mean, it's cool that you got the project knocked out in a month or two, but if you'd sit down now without an LLM and try to measure the quality of that codebase, would you be 100% content? Speed is not always a good metric. Sure, 1 -2 months for a project is nice, but isn't especially a personal project more about the fun of doing the project and learning something from it and sharpening your skills?
Earlier quoted context omitted.
Cool cool cool. So if you use LLMs as junior devs, let me ask you how future awesome senior devs like you will come around? From WHAT job experience? From what coding struggle?
Why is that a developer's problem? If anything, they are incentivized to avoid creating future competition in the job market.
Seriously, long term thinking went out the window long time ago, didn't it?
Earlier quoted context omitted.
“I want my AI to do laundry and dishes so I can code, not for my AI to code so I can do laundry and dishes”
Claude is very good at unfun-but-necessary coding tasks such as writing docstrings and type hints, which is a prominent instance of "laundry and dishes" for a dev.
Disagree. Claude makes the same garbage worthless comments as a Freshman CS student. Things like:
// Frobbing the bazz
res = util.frob(bazz);
Or
// If bif is True here then blorg
if (bif){ blorg; }
Like wow, so insightful
And it will ceaselessly try to auto complete your comments with utter nonsense that is mostly grammatically correct.
The most success I have had is using claude to help with Spring Boot annotations and config processing (Because documentation is just not direct enough IMO) and to rubber duck debug with, where claude just barely edges out the rubber duck.
Earlier quoted context omitted.
Or “can you prototype doing A via approaches X, Y, and Z, and show me what each looks like?” I love to prototype various approaches. Sometimes I just want to see which one feels like the most natural fit. The LLM can do this in a tenth of the time I can, and I just need to get a general idea of how each approach would feel in practice.
> Sometimes I just want to see which one feels like the most natural fit. This sentence alone is a huge red flag in my books. Either you know the problem domain and can argue about which solution is better and why. Or you don't and what you're doing are experiment to learn the domain. There's a reason the field is called Software Engineering and not Software Art. Words like "feels" does not belongs. It would be like…