Serious question - what do you do for fun? I find fishing with friends enjoyable, and using my hands tidying up the old place I bought. It’s not innovating software I’ll never use but I’ll never tire of writing the same old ASP that delivers my clients the results they’re after.
> I like to think of training and improving AIs as bringing freedom to the world.
Yes, when I think of OpenAI and Anthrophic and Google and Meta and any AI labs and their intentions, i cry a single tear for how these great instituitions are working so hard to bring freedom for humanity.
AI owned by a few companies is more likely to put the majority right back to serfdom. You're a privileged fool to believe that freedom is the likely outcome of the current stampede.
With a username that appears to cheer for a sociopath¹, I doubt reason will convince you.
It was obviously a sarcastic joke. I get it if you didn't catch that, but do you think my username glorifies Sam Altman? And is that a reason to talk negatively about me? You doubt reason will convince me? And at the end, you call *me* a privileged fool. Wow, just wow.
The comment and username in isolation probably wouldn't have elicited that response from me. In combination, I took you for a delusional ultra-fan.
I think anyone who genuinely thinks AI is a wonderful thing for everyone probably enjoys the privilege of its use, reducing their own workload, without it (yet) affecting their employment, or their local environment, and possibly even lacks the empathy to comprehend negative affects on others. Obviously I was mistaken for thinking you were as such.
Putting words in others' mouths doesn't give credence to your points, the only homophobia here is coming from you. Straw men are not your friends.
Sociopathy in the context of running a powerful organisation is entirely relevant because making decisions that affect many, without really caring about the consequences for them, is generally regarded as a bad thing.
How is homophobia coming from me? Also yes, sociopathy in a powerful organization is bad okay but you are not attacking sociopathy, you are attacking Sam Altman personally and claiming its bad because he's a sociopath (without any medical basis just circumstancial subjective opinion). Lets say fine, we remove him and every other bad CEO, what now? Do you think the system we have built will not put these type of people in power? Shouldn't our focus be on the actual issue, i.e. the factors that make these powerful companies do such awful things to actually change things? We can complain about the symptom (Altman) and blame them morally or because of personal reasons. But that doesn't heal the sickness. Just like murdering a CEO doesn't change healthcare in the US, calling a CEO sociopath undermines the actual wrong their organisation does.
I think (this is subjective opinion from my experience so take it as such and not something objective) but a lot of your want for a better world is also linked with your desire to shame and ridicule people. That is not a healthy outlook towards life imo. Not that what you think is wrong morally (i am on your side actually as you realised) but rather the relationship with the moral values. And its bad not because your outrage is fake or stupid but because that relationship is not good for the self eventually. I can think OpenAI is doing a lot of wrong things, I think Sam Altman is sketchy person who is definitely not a morally good agent but I don't need to hate him or get triggered by him. I also think if he just disappears tomorrow, there will no hit to the broader forces which we should actually protest against imo.
People sure are different. Your heart must be in the right place. The kind of post that includes:
> that relationship is not good for the self
I’d expect to come across, or read in my eyes, differently. Maybe more sympathetic, gracious, or kind, or I can’t think of the right word. Guess I see some bones one could throw to the interlocutor considering you probably share much of the same worldview.
Thanks for provoking some thought! I’ll come back to this one for another read and reconsider outrage & healthy outlooks on life.
I share the sentiment but the question here is how long can we maintain the balance point where the human in the agentic loop is required. It might be a window lasting only a few years, or for the foreseeable future; I think the answer lies the opaque compute economics of the frontier lab: how well models keep scaling and how economically sustainable is serving those models under the current market conditions.
If my job gets automated, I'll find something else to do. I wouldn't have wanted lamplighters to succeed in preventing electrification, so it would be unfair for me to prevent the automation of my job if it can be done.
That's life. I'm lucky to be interested in and also good at a profession that pays well. If I lose that and in exchange everyone gets to be good at making software, then that's a sacrifice I feel obligated to make for the benefit of humanity, and I'll still have more savings than someone not in this profession.
I use Astra to drive Fable; I drivel into my phone while walking in the forest and it builds. I don’t need to check; I do as clients need to pay, but it always is great. And it surprises me with things I did not know were possible even (never encountered them before so why would I know). We are at the point where our clients send voice messages and they get what they want without humans basically. This costs 10+10 max2 subs but that’s nothing compared to hiring people. We didn’t fire anyone; we just have 100+ more clients and make almost 50x more money. It’s boring but great as long as it lasts, we are already where you say for what enterprises generally need for the boring parts. That’s 99%.
Giant corpos hold every sliver of your so called freedom, you dont innovate, you repeat what others created before you. You use a tool that shackles your thoughts and creativity in a never before seen way, what you perceive is an illusion of liberty that is no present. Without others you are nothing and they can take it away any seconds, you are an addict, not an innovator.
I can see where you're coming from, and I share the sentiment and resentment to a large degree, but I think you might be not doing reality justice.
It is true that closed weights models are a big issue. It is also true that LLM-generated solutions usually drift towards a median.
But that is not the dead end you think it might be.
Most coding work is repetitive boilerplate, and most typing is just.. well.. typing. Miserable work I too did not really enjoy. What I did enjoy were the end results, and that was just a necessary step to get there.
Now that's less the case than it was before we had LLMs, and for that I too am glad.
___
I think the article headline might've primed you (and me, fwiw) to reading the comment you're replying to as passive. But if you just look at the words of it, that might not actually be the case.
For me code still is the reward; I made and make my fortunes with boring code people on HN say no one needs or wants, my hobby is, and has been for 45 years, writing, perfecting and optimizing code manually until I find it perfect. I have been working for 10 years on a programming language and OS (with niche 2 dbs that are now prod quality and we use) and those are the best moment of my day, I couldn’t care less what anyone thinks of it or ever uses it. But the lessons learned do flow into LLMs to write the boring code and I can say that our million$ paying LoB code can handle 100s req/s on shite hardware and even if the LLM did a crap job. Which is almost 100s times more than the client will ever needs.
I think that the difficulty is that the difficulty is what results in software developers being paid a decent salary. If anyone can do it or if it only requires a few developers, then why would they pay us that much?
What about cases where a bug is only obvious in motion? Or where you're working with a SBC and the bug is that you forgot a cable? Screenshots alone aren't enough. The authors point stands.
I completely understand this. I’ve worked on robot hands and 5.6/Fable 5 were practically useless at helping me debug anything visually.
What I have found super useful actually is having models make a interactive 3d viewer in which I use move / highlight / paint (soft body painting directly onto the geometry for issues and different colors mean different failures). This gives a much better way to communicate the physical relationships and positions that are hard to get across in a labeled screenshot.
Its for sure still a lot of manual work so the "seeing-eye dog" description definitely holds. But I have found that after a couple of examples with the extra context the model gets much better at handling the problem and becomes useful.
> All that’s left is the dumbest workflow possible: I fire up the debug viewer myself, look around for weird mistakes, then take a screenshot and tell the language model how badly it messed up this time. Eventually I just decided to do all the debugging work myself, so I would at least get to do the fun part too.
I call this "thanoscoding" for two reasons:
1. "Fine, I'll do it myself"
2. In the past I found I have to "snap away" the mess the LLM made in order to start afresh from a known good state (generally with git reset).
I mean there's a reason why we're doing MoCap for video games.
If computers were good at this, we wouldn't be needing that. But actual motion and all seems to be much more complex than the systems can predict, apparently.
Also.. uh.. isn't this.. good? I thought AI was to steal all our jobs.
___
Beside that, kinda weird self-description.
Isn't the computer executing your commands and you're just filling in where it cannot do that?
Being that dog implies that the computer is in the driver seat.
>Also.. uh.. isn't this.. good? I thought AI was to steal all our jobs.
the problem is, the CEOs still think AI solves their problems ie minimize paid jobs
It is weird if you think about it this way: it is AI that waits for you, its ‘eyes’, to provide a feedback so it can continue working. It literally uses you as its organ.
<!!spoiler ahead!!>There is a TV show called Person of Interest <!!spoiler ahead!!>, where Machine (AI connected to Internet and CCTV networks) has no legs or eyes, so when it needs to go and check something not covered by CCTV feeds, it gives instructions to a real person. In the show it is called an ‘analog interface.’
If intern is making a breakfast, and boss is the one who suddenly runs to the grocery store, is boss still the one in a driver’s seat?
From the original goal point of view yes, as it was boss who has initiated whole breakfast procedure. But from an execution standpoint it is intern who gives its boss a job of grocery store run. He could give same job to anyone else, boss as a persona is irrelevant here.
One of the first things I tell the junior/mid-level developers I mentor is "You can't debug something just by reading the code." We all have a mental model of how our code works, and it's usually a bit wrong. Bugs are the real world manifestations of those mistakes. When you read the code it's all filtered through your model, and that makes you blind to seeing why something unexpected happened. In order to debug something you have to be able to put the system in the state where the bug happens to see why it occurred.
LLMs generally only debug systems by reading the code with whatever information you give them in a prompt. The image in the article is meta-prompt - the prompt is whatever comes from the vision model the AI happens to use to 'understand' the red circle annotation. That won't work. To successfully debug what's going on it will need much better state information. Has the 'shelf' been explained to is? Is the contrast and lack of shadows in the image messing up the vision model? Why isn't the 'lid' in the image? And so on.
LLMs are clever but they're not magical. Treat them like a naive junior dev. Give them enough data about the state of something to understand it properly.
I call this a tautological mental model. You can read the code over and over again, but your second reading will be mostly an echo of the mental model you built up in your first.
Hmmm, I don't think that's necessarily true. Often times once I have witnessed a bug, I have found it just by reading through the code with the behaviour of the bug in mind.
For LLMs, this is likely to be disproportionately effective as well: especially because they don't really build up a persistent view of the codebase, they're generally re-reading it each session, and they tend to be surprisingly good at predicting the behaviour of code.
(That said, knowing where and how to gather more evidence to make things clearer is a pretty core skill in troubleshooting, so it's generally good advice anyhow)
That's AI getting an example of replicating the state that shows the bug which is exactly what I'm talking about. It does that far more than humans do, and it's ace. That's how you should be debugging a system - replicate the issue, understand why it breaks in that given state, and then make a code change to fix it.
Sometimes you can do that mentally and fix the code. Often your fix will be right especially in a relatively simple part of the code. However, equally often you'll fix a different problem (or something that wasn't a problem at all), and the original bug will remain but you'll believe you corrected the issue. This is why you should always replicate a bug to understand it, and why you should always add a test whenever you fix a bug to prove you actually fixed it as well as preventing future regressions.
> "You can't debug something just by reading the code."
This is exactly how I debug things. When I first started working I was forbidden from using the debugger “you won’t have a debugger in the field”. Being able to read the code, spot the bug and tie it to the symptoms; that’s a skill. A damned important skill.
> You can't debug something just by reading the code.
You are doing those junior engineers a disservice with this message.
I'm usually trying to go in the other direction with them - you don't need to be able to reproduce it yourself or see the log files to narrow down or find the cause of an issue.
Logs/etc are just additional tool that make it easier.
Lost track of how many juniors I've seen throw their hands up and say they can't progress because they don't have logs/clean repro
> Lost track of how many juniors I've seen throw their hands up and say they can't progress because they don't have logs/clean repro
Not the parent, but I think their approach is the correct one even though their line that you quote "You can't debug something..." should be everything instead of something.
The issue with your juniors is them throwing their hands in the air without actually reading the code when they hit a wall, and not them trying to reproduce and inspect the bug first.
What's the issue with telling them, "Obviously if you can't reproduce it and inspect it with dev tools, read the code."?
I've won bets off devs who blamed me cause they said they couldn't reproduce the bug consistently when the tried but it would happen randomly in production. Mind you, the bet wasn't even about who was at fault. The bet was that I could reproduce it if I actually tried.
You are complaining about juniors in a role that's known for the motto "it works on my machine" of course they're going to whine the moment it takes some effort to reproduce something.
At the end of the day, how are you going to claim you fixed an issue if you can't reproduce it to begin with? The senior has to now read the code more carefully cause there is no proof the junior actually fixed anything.
I'm actually not complaining. I coach them through it, but the primary help I give is showing them how to walk through the code, and break the dependency on logs/repro scenarios.[1]
In addition, if you find the issue in the code -- unless it's a really unusual race condition -- you have what you need to construct a reproduction scenario. That's also part of the coaching.
[1] At least, I did until the place I work switched everyone to vibe coding. Now I give terse responses to their LLM-generated PRs -- which usually misses the forest for the trees -- since I know that they're just going to feed my words back into the machine.
It's a good approach if every run of your code is very slow or very expensive, but if you can iterate quickly by running the code it's way more effective to try to reproduce and narrow it down that way
I think you've been doing your juniors a disservice
Logs are great. Interactive debugging is great. Both of these can also help build an understanding of the code and systems involved. But they're just debugging tools, and they should rarely be /required/ to find a bug.
The skill I'm teaching is how to think through the problems and the systems in a way that lets log files be a useful tool instead of the only option.
> LLMs generally only debug systems by reading the code with whatever information you give them in a prompt.
Oh, I wish. "This call doesn't return, how strange! Let me fire off a bunch of small test script one after another, with a timeout of 10 minutes each, to narrow down where the error might be!" In terms of tokens, it's maybe even efficient. In terms of time it isn't!
A bit off topic, but I absolutely love the little robot on the author's main project's landing page (https://rerun.io/).
I normally condemn mouse hijacking, but this implementation will be allowed.
Rerun is pretty dope, but I'm not sure how you came to the conclusion that it's the "author's main project"? There is a whole company backing it, with no affiliation that I could find, apart from the author being an occasional contributor?
They mentioned "... and my visualizer tool comes with an MCP server ...", with a link to the rerun project. I guess it makes more sense that his visualizer tool uses rerun...Sorry for the confusion from my side.
> I used to argue with people on the internet, after about six replies, you realize that you’re speaking to someone incapable of thought
He realises the current woe of things but doesn't realise he's been arguing with bot farms and teams of people hired just for this reason - to sow doom, arguments and engagement.
Around 10 years ago I noticed this happening on trending topics of Twitter - it wasn't that the opponents were stupid because they disagreed, it was that they were simultaneously intelligent and stupid in the way they spoke in a way that I realised I'd never seen in genuine people, making me realise it was probably different people or bots under one account.
If I realised it 10 years ago it was probably happening for at least 15. He wasn't better than these people he was falling into their trap
Haha it’s just a foolish move made by those from the ‘90s. We all internalized a different lesson. The younger generations have learned to brush it off and stop responding. Even if the person is human, when you fail to move toward Aumann Agreement, there is no point in persisting.
Us older ones are still fighting the last war. If only we explain it properly, maybe the bots will understand!
Haha, it’s figurative and requires squinting. “rational actors with common axioms will reach shared conclusions through repeated exchange of information”.
So if you’re not reaching a shared conclusion then you’re not exchanging information, you don’t have shared axioms, or one of you isn’t rational.
If it didn’t land with you, it was just a poor choice of phrase and while I care to attempt to explain it, I don’t care to attempt to defend it.
Have you heard about the free energy principle and free energy model of emotions? In this model, all brain does is minimize the prediction error, so all values and beliefs are bayesian priors by necessity.
I justify it to myself by saying that even if I'm arguing with a bot, I want to have a counterargument posted for the benefit of the people who are reading the comments
I used to think that the people who could not apply any semblance of logical reasoning online were just bots or trolls, but then I started meeting them in real life.
>it wasn't that the opponents were stupid because they disagreed, it was that they were simultaneously intelligent and stupid in the way they spoke in a way that I realised I'd never seen in genuine people, making me realise it was probably different people or bots under one account.
I believed they were all bots until I actually interacted with such a person in real life. It's terrifying.
> People you interact with online almost certainly aren't bots or paid.
Not all of them, and I'm not saying they target me. I noticed it more in popular engagement sinks - comments on popular instagram videos, replies on trending topics on Twitter, the main subs on Reddit.
There absolutely are engagement farms doing this for multiple reasons, and it at least seemed to me that most of the interactions in those places were not genuine.
> He realises the current woe of things but doesn't realise he's been arguing with bot farms and teams of people hired just for this reason - to sow doom, arguments and engagement.
I've had the same kind of argument you'd swear was a bot with real people I know offline. The best explanation I could come up with was that they got radicalized online, was shameless about arguing in bad faith, and was willing to say heinous things in a group text, but refused to continue the discussion when I challenged them to do so IRL when I next met them - their electronic words towards me were particularly foul. Polarization, online echo-chambers, lack of consequences, and shamelessness have conspired to crater the quality of discourse and provide plenty of fuel for bots and psy-ops operators to fan the flames.
In 2006 i was arguing in barrens chat with someone spouting racist nazi bullshit, 3 days of this they sent me /t saying i couldnt stop them shaping the minds of young men. Shaping the minds of young men, an exact quote i would hear being used by steve bannon many years later. This.. thing.. has been active for much longer then 10 years.
LM still can not see and understand the desktop app UI on a level that is acceptable for testing.
All the advances in coding are from web dev and thanks to the nature of html UIs.
Try to develop a desktop app and it’s like working with a legally blind person who can see some part of the screen is they squint in a certain way but surely will miss all minor details.
> I often handwrite the code myself, but I’ve found that LLM coding assistants’ limitless patience ameliorates the drudgiest work of coding.
I've been using a few different "smart" LLM to work on an analysis, parsing, search and correlation tool that ultimately deals with a 5.5GB on disk (with indexes) mariadb database that has its origin as a federal government department's 905,000 row plain text CSV file.
There are a ridiculous number of data entry errors and just plain weird fuckups in the data origin that don't seem they will be ameliorated any time soon, so automating the drudge work of cleaning it up and rectifying it into something usable is a textbook case for this. Very pleased with the results so far.
I've found that LLMs are specifically bad at a certain kind of debugging, though I can't quite put my finger on what that is.
"Spot the bug in this code" when the code can be looked at and pattern-matched against bugginess is something they seem really good at.
Some parts of debugging, like "Here is this logfile, what do you think is going on?" are also surprisingly good.
It's that thing kind of in the middle -- I know it when I see it honestly is the best way I can put it into words. An example from recently, I'm receiving some bad data on a network message parser. Immediately I don't know whether it's a my-side or their-side thing, but I know if I try and just vaguely describe the behaviour to the LLM it will start churning tokens.
My current approach to problems like this is -- I need to tell the LLM what it needs to do to give itself the data it needs to solve the problem. My first reaction now isn't "It's not working, there's a bug, it's not doing X". It's "Okay, this isn't quite working properly; I need you to add some debug logging around X, Y and Z so we can figure this out". That tends to avoid spirals and get me out of the situation much more quickly.
The seeing eye dog analogy is pretty apt actually. I would love to see some transcripts from the author if they are able.
Edit to add: I think the 'thing' I'm alluding to might be -- if I have trouble expressing the buggy behaviour clearly in words, then I know it's probably going to be a fair few back-and-forths with the LLM to get something; the harder I find it to concisely describe, the more risk that it'll fall into a pit. Doubly so if I offer up a hypothesis which turns out to be wrong.
74 comments
[ 0.22 ms ] story [ 13.5 ms ] threadSerious question - what do you do for fun? I find fishing with friends enjoyable, and using my hands tidying up the old place I bought. It’s not innovating software I’ll never use but I’ll never tire of writing the same old ASP that delivers my clients the results they’re after.
Yes, when I think of OpenAI and Anthrophic and Google and Meta and any AI labs and their intentions, i cry a single tear for how these great instituitions are working so hard to bring freedom for humanity.
AI owned by a few companies is more likely to put the majority right back to serfdom. You're a privileged fool to believe that freedom is the likely outcome of the current stampede.
With a username that appears to cheer for a sociopath¹, I doubt reason will convince you.
¹ https://futurism.com/artificial-intelligence/sources-sam-alt...
I think anyone who genuinely thinks AI is a wonderful thing for everyone probably enjoys the privilege of its use, reducing their own workload, without it (yet) affecting their employment, or their local environment, and possibly even lacks the empathy to comprehend negative affects on others. Obviously I was mistaken for thinking you were as such.
Putting words in others' mouths doesn't give credence to your points, the only homophobia here is coming from you. Straw men are not your friends.
Sociopathy in the context of running a powerful organisation is entirely relevant because making decisions that affect many, without really caring about the consequences for them, is generally regarded as a bad thing.
I think (this is subjective opinion from my experience so take it as such and not something objective) but a lot of your want for a better world is also linked with your desire to shame and ridicule people. That is not a healthy outlook towards life imo. Not that what you think is wrong morally (i am on your side actually as you realised) but rather the relationship with the moral values. And its bad not because your outrage is fake or stupid but because that relationship is not good for the self eventually. I can think OpenAI is doing a lot of wrong things, I think Sam Altman is sketchy person who is definitely not a morally good agent but I don't need to hate him or get triggered by him. I also think if he just disappears tomorrow, there will no hit to the broader forces which we should actually protest against imo.
> that relationship is not good for the self
I’d expect to come across, or read in my eyes, differently. Maybe more sympathetic, gracious, or kind, or I can’t think of the right word. Guess I see some bones one could throw to the interlocutor considering you probably share much of the same worldview.
Thanks for provoking some thought! I’ll come back to this one for another read and reconsider outrage & healthy outlooks on life.
Giant corpos hold every sliver of your so called freedom, you dont innovate, you repeat what others created before you. You use a tool that shackles your thoughts and creativity in a never before seen way, what you perceive is an illusion of liberty that is no present. Without others you are nothing and they can take it away any seconds, you are an addict, not an innovator.
It is true that closed weights models are a big issue. It is also true that LLM-generated solutions usually drift towards a median.
But that is not the dead end you think it might be.
Most coding work is repetitive boilerplate, and most typing is just.. well.. typing. Miserable work I too did not really enjoy. What I did enjoy were the end results, and that was just a necessary step to get there.
Now that's less the case than it was before we had LLMs, and for that I too am glad.
___
I think the article headline might've primed you (and me, fwiw) to reading the comment you're replying to as passive. But if you just look at the words of it, that might not actually be the case.
Astra is already good at taking screenshots and acting on it (part of the agi claims).
What I have found super useful actually is having models make a interactive 3d viewer in which I use move / highlight / paint (soft body painting directly onto the geometry for issues and different colors mean different failures). This gives a much better way to communicate the physical relationships and positions that are hard to get across in a labeled screenshot.
Its for sure still a lot of manual work so the "seeing-eye dog" description definitely holds. But I have found that after a couple of examples with the extra context the model gets much better at handling the problem and becomes useful.
I call this "thanoscoding" for two reasons:
1. "Fine, I'll do it myself"
2. In the past I found I have to "snap away" the mess the LLM made in order to start afresh from a known good state (generally with git reset).
Also.. uh.. isn't this.. good? I thought AI was to steal all our jobs.
___
Beside that, kinda weird self-description.
Isn't the computer executing your commands and you're just filling in where it cannot do that?
Being that dog implies that the computer is in the driver seat.
<!!spoiler ahead!!>There is a TV show called Person of Interest <!!spoiler ahead!!>, where Machine (AI connected to Internet and CCTV networks) has no legs or eyes, so when it needs to go and check something not covered by CCTV feeds, it gives instructions to a real person. In the show it is called an ‘analog interface.’
But it isn't. That's my point.
I told the clanker "hey do that", and like the intern/junior it emulates, it eventually says "boss! Help! I can't do this alone".
It is I who is in the driver seat.
From the original goal point of view yes, as it was boss who has initiated whole breakfast procedure. But from an execution standpoint it is intern who gives its boss a job of grocery store run. He could give same job to anyone else, boss as a persona is irrelevant here.
LLMs generally only debug systems by reading the code with whatever information you give them in a prompt. The image in the article is meta-prompt - the prompt is whatever comes from the vision model the AI happens to use to 'understand' the red circle annotation. That won't work. To successfully debug what's going on it will need much better state information. Has the 'shelf' been explained to is? Is the contrast and lack of shadows in the image messing up the vision model? Why isn't the 'lid' in the image? And so on.
LLMs are clever but they're not magical. Treat them like a naive junior dev. Give them enough data about the state of something to understand it properly.
For LLMs, this is likely to be disproportionately effective as well: especially because they don't really build up a persistent view of the codebase, they're generally re-reading it each session, and they tend to be surprisingly good at predicting the behaviour of code.
(That said, knowing where and how to gather more evidence to make things clearer is a pretty core skill in troubleshooting, so it's generally good advice anyhow)
Sometimes you can do that mentally and fix the code. Often your fix will be right especially in a relatively simple part of the code. However, equally often you'll fix a different problem (or something that wasn't a problem at all), and the original bug will remain but you'll believe you corrected the issue. This is why you should always replicate a bug to understand it, and why you should always add a test whenever you fix a bug to prove you actually fixed it as well as preventing future regressions.
This is exactly how I debug things. When I first started working I was forbidden from using the debugger “you won’t have a debugger in the field”. Being able to read the code, spot the bug and tie it to the symptoms; that’s a skill. A damned important skill.
But lots of bugs can and should be found and fixed by inspection of the code, inspired by a reasonable observation.
Depending on your process needs, maybe write a test to confirm the fix.
You are doing those junior engineers a disservice with this message.
I'm usually trying to go in the other direction with them - you don't need to be able to reproduce it yourself or see the log files to narrow down or find the cause of an issue.
Logs/etc are just additional tool that make it easier.
Lost track of how many juniors I've seen throw their hands up and say they can't progress because they don't have logs/clean repro
Not the parent, but I think their approach is the correct one even though their line that you quote "You can't debug something..." should be everything instead of something.
The issue with your juniors is them throwing their hands in the air without actually reading the code when they hit a wall, and not them trying to reproduce and inspect the bug first.
What's the issue with telling them, "Obviously if you can't reproduce it and inspect it with dev tools, read the code."?
I've won bets off devs who blamed me cause they said they couldn't reproduce the bug consistently when the tried but it would happen randomly in production. Mind you, the bet wasn't even about who was at fault. The bet was that I could reproduce it if I actually tried.
You are complaining about juniors in a role that's known for the motto "it works on my machine" of course they're going to whine the moment it takes some effort to reproduce something.
At the end of the day, how are you going to claim you fixed an issue if you can't reproduce it to begin with? The senior has to now read the code more carefully cause there is no proof the junior actually fixed anything.
In addition, if you find the issue in the code -- unless it's a really unusual race condition -- you have what you need to construct a reproduction scenario. That's also part of the coaching.
[1] At least, I did until the place I work switched everyone to vibe coding. Now I give terse responses to their LLM-generated PRs -- which usually misses the forest for the trees -- since I know that they're just going to feed my words back into the machine.
It's a good approach if every run of your code is very slow or very expensive, but if you can iterate quickly by running the code it's way more effective to try to reproduce and narrow it down that way
I think you've been doing your juniors a disservice
The skill I'm teaching is how to think through the problems and the systems in a way that lets log files be a useful tool instead of the only option.
Oh, I wish. "This call doesn't return, how strange! Let me fire off a bunch of small test script one after another, with a timeout of 10 minutes each, to narrow down where the error might be!" In terms of tokens, it's maybe even efficient. In terms of time it isn't!
He realises the current woe of things but doesn't realise he's been arguing with bot farms and teams of people hired just for this reason - to sow doom, arguments and engagement.
Around 10 years ago I noticed this happening on trending topics of Twitter - it wasn't that the opponents were stupid because they disagreed, it was that they were simultaneously intelligent and stupid in the way they spoke in a way that I realised I'd never seen in genuine people, making me realise it was probably different people or bots under one account.
If I realised it 10 years ago it was probably happening for at least 15. He wasn't better than these people he was falling into their trap
Us older ones are still fighting the last war. If only we explain it properly, maybe the bots will understand!
I don’t understand your point at all in this context. What’s “Aumann Agreement” in the context of a discussion about values?
So if you’re not reaching a shared conclusion then you’re not exchanging information, you don’t have shared axioms, or one of you isn’t rational.
If it didn’t land with you, it was just a poor choice of phrase and while I care to attempt to explain it, I don’t care to attempt to defend it.
I believed they were all bots until I actually interacted with such a person in real life. It's terrifying.
Not all of them, and I'm not saying they target me. I noticed it more in popular engagement sinks - comments on popular instagram videos, replies on trending topics on Twitter, the main subs on Reddit.
There absolutely are engagement farms doing this for multiple reasons, and it at least seemed to me that most of the interactions in those places were not genuine.
I've had the same kind of argument you'd swear was a bot with real people I know offline. The best explanation I could come up with was that they got radicalized online, was shameless about arguing in bad faith, and was willing to say heinous things in a group text, but refused to continue the discussion when I challenged them to do so IRL when I next met them - their electronic words towards me were particularly foul. Polarization, online echo-chambers, lack of consequences, and shamelessness have conspired to crater the quality of discourse and provide plenty of fuel for bots and psy-ops operators to fan the flames.
I've been using a few different "smart" LLM to work on an analysis, parsing, search and correlation tool that ultimately deals with a 5.5GB on disk (with indexes) mariadb database that has its origin as a federal government department's 905,000 row plain text CSV file.
There are a ridiculous number of data entry errors and just plain weird fuckups in the data origin that don't seem they will be ameliorated any time soon, so automating the drudge work of cleaning it up and rectifying it into something usable is a textbook case for this. Very pleased with the results so far.
"Spot the bug in this code" when the code can be looked at and pattern-matched against bugginess is something they seem really good at.
Some parts of debugging, like "Here is this logfile, what do you think is going on?" are also surprisingly good.
It's that thing kind of in the middle -- I know it when I see it honestly is the best way I can put it into words. An example from recently, I'm receiving some bad data on a network message parser. Immediately I don't know whether it's a my-side or their-side thing, but I know if I try and just vaguely describe the behaviour to the LLM it will start churning tokens.
My current approach to problems like this is -- I need to tell the LLM what it needs to do to give itself the data it needs to solve the problem. My first reaction now isn't "It's not working, there's a bug, it's not doing X". It's "Okay, this isn't quite working properly; I need you to add some debug logging around X, Y and Z so we can figure this out". That tends to avoid spirals and get me out of the situation much more quickly.
The seeing eye dog analogy is pretty apt actually. I would love to see some transcripts from the author if they are able.
Edit to add: I think the 'thing' I'm alluding to might be -- if I have trouble expressing the buggy behaviour clearly in words, then I know it's probably going to be a fair few back-and-forths with the LLM to get something; the harder I find it to concisely describe, the more risk that it'll fall into a pit. Doubly so if I offer up a hypothesis which turns out to be wrong.