Whatever the logs indicate is the issue? How can there be a fixed response to this?
You should definitely use your builder container to run your tests locally before pushing changes though. That’s one of the advantages of containers - a consistent environment.
deleted by creator
OMG.
https://en.wikipedia.org/wiki/Security_through_obscurity
In security engineering, security through obscurity is the practice of concealing the details or mechanisms of a system to enhance its security. This approach relies on the principle of hiding something in plain sight, akin to a magician’s sleight of hand or the use of camouflage. It diverges from traditional security methods, such as physical locks, and is more about obscuring information or characteristics to deter potential threats. Examples of this practice include disguising sensitive information within commonplace items, like a piece of paper in a book, or altering digital footprints, such as spoofing a web browser’s version number. While not a standalone solution, security through obscurity can complement other security measures in certain scenarios.
You don’t know what you’re talking about - please stop. It’s embarrassing. It’s a long-standing industry term not some weird phrase I just made up. Nobody is saying “Linux is obscure”.
Enjoy your “security”. 🙄
Sorry - which part of your comment added anything of value? “can help to minimize the attack surface”? 99% of the time a proxy just passes traffic through. Unless you’re talking about a WAF which is a) a different thing and b) NOT what any home gamers are talking about when they recommend nginx, traefik, etc. to newbs.
Just google the term next time rather than embarrassing yourself.
See what I mean?
As if a proxy blindly passing traffic directly to a backend server “reduces attack surface” in any meaningful way. 🙄
Edit: Guy edits his post with a bunch of stuff and assumes I’ve read it later. I can’t eyeroll enough…
The self-hosted crowd thinks reverse proxies protect you from the Internet. Don’t expect too much of them.
You could have just said that you don’t know what “security through obscurity” is.
It goes right to the top!
It’s on the “electromagnet spectrum” but “radio” is defined as a range on that spectrum.
But you are correct that they’re the same type of thing.
which is a bipartisan board
*was
These have always been terrible.
Yeah - I’m not a fan of low-code stuff either.
Anyway, my point here was, obviously, that producing larger and larger volumes of code faster, isn’t something desirable, and it has never been. You took this out of context, with the added injury of commenting on the follow up sentence… but I’m glad you did, because it clarified your position a lot.
I’m not saying you want tools to produce “large volumes of code faster” though. Just that they do code faster. Sometimes that’s deletion.
You took this out of context
Apologies - not my intent.
You would leave a poorly written and unnecessary larger piece of code in your code base, which would increase development time as reviews would take longer, which was precisely the reason why you would want a human in the software engineering loop in the first place.
We all make this trade-off. “Do I refactor this now and introduce risk and take more time, or do I leave it for now to be done later?” The LLM helps with the “take more time” component.
You claim that the LLM would refactor the code for you, but LLMs, in general, are designed with the implied requirement of maximizing token usage.
I… What? This isn’t even wrong it’s just weird. To begin with “token usage” has nothing to do with the amount of code in our code base, removing and modifying code also uses tokens. Secondly this just sounds far to “conspiracy theory” for me to entertain.
Later in your comment, you said that you don’t care about losing skills that “aren’t needed anymore”, but I wonder, isn’t this the kind of skill, i.e. refactoring inefficiently written code, that you would want a senior developer to maintain? Even more, in the long term, how would you guarantee that you could tell a good refactor from a bad one?
That’s fair - better developers do and will continue to understand these things. Most developers, however, aren’t “better” developers. But it’s not a barrier to entry was my primary point.
In short, I think you are wrong, but I don’t think you would know why until it bites you.
I’m curious - what is it you think I’m wrong about?
In theory, people ought to check every LLM output. This collides with reality in different points;
people are lazy and being diligent just passively checking results is hard - and can be very tiring people are under pressure to work faster if they really check everything, the result is often slower.As a result, careful checks of each result won’t happen.
I know that by experience because I have a coworker who uses LLMs heavily. I am relying on interfaces he should provide and he is often not able to describe them in an usable way. Thinks that should take a day or two often take many weeks.
God yes I can relate to that. I have a similar “full vibe-coder” coworker who sent me a PR for something that amounted to 1,000’s of lines of code changes. I rejected it out-of-hand. We had a long conversation about readable PRs, breaking work up into chunks, etc. Of course he had Claude do all that for him but… at least the PR was “better”.
And the same trouble with him not having any clue what he just produced actually did. I 100% agree that’s a problem. But it’s kinda the same problem we had before LLM, though maybe a bit super-charged. That fella’s code before Claude was terrible as well. So technically the code itself is better now so… I guess that’s a win?
You could argue it is a competence problem, so maybe yes but LLMs apparently augment such problems.
Yeah - give bad drivers faster cars and people will die faster. I hear that. We do need to train people better on how to use these tools. It’s definitely NOT “go vibe code a thing into existence and then drop it on others to maintain”. But I don’t think “bury your head in the sand and hope it goes away” is the right approach either.
We evaluate suggestions from people differently. For example, we use cues like use of language, certificates, reputation, personality, prior experience with them, and insitutions to evaluate their competence - and we trust then, with a reason. You won’t go to a barber shop and ask a random person working there for a stomach surgery.
Sure. But you can do that with LLMs too. They have strengths and weaknesses as well. But to understand how to use these tools appropriately you need to gain experience with them. To know when they tend to produce good results (well known and well documented languages and libraries) and when to be more “sus” about them (obscure libraries, poorly documented applications (coughOraclecough)).
The more you use them the more you get to see when it’s struggling.
I don’t think you understood my point.
Maybe.
Writing code faster was never something anyone with any real knowledge of their domain would think is desirable.
Sorry - that’s bullshit. IDEs, code completion, syntax highlighting, editor macros, incremental compiling, editor syntax checking, debuggers, integrated debuggers in IDEs, code generators, RAD and “low code” tools, etc. The list goes on for tools we’ve created to do that exact thing. You’re probably using many of the ones I’ve listed.
I don’t care if more code is written faster, because that has never been a good indicator of productivity. In fact, I would argue that less code is better.
Okay. I’ve had an LLM help simplify some logic by refactoring a bunch of things before. The sort of thing that isn’t “hard” but is time consuming. I know you don’t care about “speed” but it did this work much faster than I would have taken. And it also resulted in “less code”.
It’s also the sort of work that I may not have done because “man that’s gonna bit a bit of work.” But since it was easier to do, I did it. So the LLM helped me cleanup our source.
And that’s another thing here. I can spend 15-30 mins writing a small script to fetch data from an AWS API, parsing the results, using those results to fetch yet other resources, format the output, etc. Most of which is going to require me to dig through the AWS docs and read a lot of JSON responses, or I can have Claude do it in <3 mins and it just works. I’ll throw it away in a few days once I’m done with that task so it doesn’t need to be perfect. You needed to hit some threshold of “utility” vs. “time to write the script” to do things like that and being able to do it faster means more utility scripts so I don’t have to dig through the aweful AWS console looking for when a scheduled job last ran.
Anyway, it’s funny that you mention, in a somewhat patronising tone by the way, that we need to adapt and not be wary of AI because we have “other skills”.
Patronizing? I was being sincere.
If you want to keep a human in the loop, then fine. Now you have a choke point in your otherwise faster machine. A human who now needs to understand code they haven’t written
You already had that choke-point with code review. I review code I haven’t written all the time - have for decades. As a result I’ve gotten very good at it. If you haven’t been then maybe that’s a skill you need to focus on since it sounds like you find reading code to be quite difficult (I only say that because you keep bringing it up).
with more and more datapoints coming up suggesting that LLM usage leads to skill atrophy, an eventually more fallible human at that.
Skill atrophy is only bad if that skill is needed. How’re your assembly skills these days? I could do it but I haven’t in decades. Most developers have very little knowledge about how their computer even works. Ask your average dev what L1, L2 and L3 cache are. They don’t care and don’t need to. Even memory allocation is something you don’t need to care about unless you’re writing in C still. And frankly that’s a good thing. So a lost skill - but good riddance.
Use of so-called Artificial Intelligence (AI) is allowed only if it is explicitly mentioned.
I wonder if they mail the scarlet “AI” or if you need to order one yourself?
An experienced programmer who could actually review the code produced by a LLM, won’t be able to do so at the speed the LLM writes it.
You’re going to need to review any code you and other members of your team write anyway. Or are you just skipping code review? If so then you’re already vibe-coding old-school. Reviewing others code and soliciting feedback on your own is an integral part of software development.
And I dispute the whole “it’s harder to read code than to write it” thing. It’s a helpful aphorism to get Jr. devs to write good code because you can certainly make your life a lot harder by writing bad code (hint: an LLM can help you understand that 15-yr old code that some apprentice wrote).
But code review doesn’t generally take twice as long as it took the developer to create the PR to begin with. Why is that? Because the developer who worked on the code had to solve a bunch of problems, fix bugs they wrote, etc. as you pointed out. The LLM helps with all that as well and the “code, test, fix” loop is a lot shorter. Finding “all those places where I need to make this change” is a lot easier. Refactoring code is a lot easier. Debugging code is easier. Looking up documentation is easier.
I do understand your frustration though - I really do. I’ve been a developer for, well, a long time and I’ve honed my craft over those decades. To see it commoditized like this is…difficult. But we have other skills besides just writing code. The technical knowledge of what that code should look like, how it should work, security best practices, etc.
What’s your solution to avoid slop in this scenario?
Keeping the human in the loop. Using AI as a tool but not abandoning software development best practices. If you’re doing those then the source of the code kinda doesn’t matter. Open source projects accept PRs from random sources on the internet for example. They already have processes in place to review code and apply it. It’s already part of the system.
Because you hate yourself?
You can’t use AI for things you do not know well.
This is a talking point. You’re falling back on the nirvana fallacy.
It will happily suggest total bullshit in the most confident tone.
Yes - absolutely nobody is recommending you do everything the LLM says. You still need to have critical thinking when using an LLM. I still use my many years of experience to gauge the quality of the responses. But it definitely has recommended solutions that I found to be quite good and better than what I was thinking of implementing. Do you think you can’t recognize whether a solution would be a better or worse fit when recommended by either an LLM or a person if done “confidently”?
But even for “just coding” - I offer an example. It will happily convert an old Apache Tiles application to using Apache Thymeleaf (the former being unsupported). And it does it very well, and much faster than people can. The solution is very cookie cutter and we’ve established a pattern. It’s very easy to recognize the changes being made are following the pattern and QA is testing all of the changes. What was going to take nearly a year will take weeks. It’s an absolute win here.
You can tell yourself whatever you need to make yourself feel better, but there are real benefits to LLMs in software development.
Round 1 goes to the people this is excellent.