Yeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or…
New career path unlocked — reverse prompt engineering — trying to determine what someone prompted the AI given the slop they put into a ticket
I think you’re kidding but some LinkedIn influencer will come across this and preach that it’s serious
Yeah, the terminal level, whatever the title (they are just words) need to be the point at which you can handle moderately complex (multi-week) tasks with no supervision. And honestly, this will depend on the environment and kind of work being done.
If that's what you're looking for you can find it in academia. Universities have no problem paying people to stay around forever without promotion. Of course the pay won't be great, but the benefits are decent, PTO is usually excellent, and the work environment usually very low stress.
In my experience, people who say this kind of thing about either industry or academia have usually worked in one, but not both.
I'd go further and say vibe coding it up, testing the green case, and deploying it straight into the testing environment is good enough. The rest we can figure out during testing, or maybe you even have users willing to beta-test for you. This way, while you're still on the understanding part and reasoning over the code, your competitor already shipped ten features, most of them working. Ok, that was a provocative sc…
How often do you buy stuff that doesn't work, and you are OK with the provider telling you "we had a reasonable belief that it worked"? How are we supposed to use software in healthcare, defense, transportation if that's the bar?
There's a lot of functionality in the frontend that I am building that I did not review. If it worked in testing, that's good enough.
You're free to review every line the model produces. Not every project is in healthcare or defense, and sometimes different standards apply.
> I'd add a link to where I copied it from LLMs can't do this. Your code is unambiguously better than any LLM code if you can comment a link to the stackoverflow post you copied it from.
> Your code is unambiguously better than any LLM code if you can comment a link to the stackoverflow post you copied it from. This is not a truism. "My" code might come from an LLM and that's fine if I can be reasonably confident it works. I might try to gain that confidence by testing the code and reading it to understand what it's doing. It is also true of blog post code, regardless of how I refer to the code; if I…
Believing you know how it works and why it works is not the same as that actually being the case. If the code has no author (in that it's been plagiarised by a statistical process that introduces errors), there's nowhere to go if you realise "oops, I didn't understand that as well as I had thought!".
Okay, then software engineers are not engineers. The whole reliability, etc. to many is not of much priority. Things got an absolutely shitshow and still everyone buys it. In other words the only outcome will be that people don't have or don't want to have engineers anymore. Companies are very much not interested in someone who does the above, but at most someone who sells or cosplays these things - if even. Cause th…
> I believe what we need to wake up to or come to terms with is that our industry (everything that would go into NASDAQ) is a farce. the thing is, with software development, it's always been this way. Developers have just had tunnel vision for decades because they stare into an editor all day long instead trying to actually sell a product. If selling wasn't the top priority then what do you think would happen to your…
Technology has absolute qualities. Not a fantasy.
Are you being paid to browse hacker news? Probl not, but here you are.
Maybe you never considered this, but programming for other reasons other than a salary is a possibility.
If those pesky programmers gave it all away, for free, what would be left for you to sell? In this case, would you leave technology? Would you go somewhere else and practice your selling there?
Can't we defend building for the sake of building?
Doing for the sake of having fun?
Maybe you would be left with nothing to sell, I understand, but that's fine for me. Sorry.
Okay. Go write an operating system and suite of apps with global memory and no protections. Why are we wasting so much time on abstractions like processes and objects? Just let let everyone read and write from the giant turing machine.
DOS, early Windows, and early MacOS worked more or less exactly that way. Somehow, we all survived.
Apple nearly didn't survive until they bought a company that made an OS that didn't work that way.
For what it's worth, writing good PRs applies in more cases than just AI generated contributions. In my PR descriptions, I usually start by describing how things currently work, then a summary of what needs to change, and why. Then I go on to describe what exactly is changing with the PR. This high level summary serves to educate the reviewer, and acts as a historical record in the git log for the benefit of those wh…
Also, take a moment to review your own change before asking someone else to. You can save them the trouble of finding your typos or that test logging that you meant to remove before pushing. To be fair, copilot review is actually alright at catching these sorts of things. It remains a nice courtesy to extend to your reviewer.
The Draft feature is amazing for this.
I’ll put up a draft early and use it as a place to write and refine the PR details as I wrap up, make adjustments, add a few more tests, etc.
there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. Is anyone else seeing this in their orgs? I'm not...
I’ve been seeing obviously LLM generated PRs, but not huge ones.
I am currently going through this with someone in our organization. Unfortunately, this person is vibe coding completely, and even the PR process is painful: * The coding agent reverts previously applied feedback * Coding agent not following standards throughout the code base * Coding agent re-inventing solutions that already exist * PR feedback is being responded to with agent output * 50k line PRs that required a 1…
Fire them?
This is not really an option for your standard IC.
How often do you buy stuff that doesn't work, and you are OK with the provider telling you "we had a reasonable belief that it worked"? How are we supposed to use software in healthcare, defense, transportation if that's the bar?
There's a lot of functionality in the frontend that I am building that I did not review. If it worked in testing, that's good enough. You're free to review every line the model produces. Not every project is in healthcare or defense, and sometimes different standards apply.
I’m assuming you work in a setting where there is a QA team?
I haven’t been in such a setting in 2008 so you can ignore everything I said.
But I wouldn’t want to be somewhere where people don’t test their code, and I have to write code that doesn’t break the code that was never tested until the QA cycle?