Comment by nyrikki | Hacker News Reader

Comment by nyrikki | Hacker News Reader

Parent Full thread

It is a bit more complicated, as it can be harmful for experts also, and the more reliable it gets the more problematic it becomes.

Humans suffer from automation bias and other cognitive biases.

Anything that causes disengagement from a process can be challenging, especially with long term maintainability and architectural erosion, which is mostly what I actively search for to try and avoid complacency with these tools.

But it takes active effort to avoid for all humans.

IMHO, writing the actual code has always been less of an issue than focusing on domain needs, details, and maintainability.

As distrusting automation is unfortunately one of the best methods of fighting automation bias I do try to balance encouraging junior individuals to use tools that boost productivity while making sure they still maintain ownership of the delivered product.

If you use the red-green refactor method, avoiding generative tools for the test and refactor steps seems to work.

But selling TDD in general can be challenging especially with Holmström's theorem, and the tendency of people to write implementation tests vs focusing on domain needs.

It is a bit of a paradox that the better the tools become, the higher the risk is, but I would encourage people to try the above, just don't make the mistake of copying the prompts required to get from red to green as the domain tests, there is a serious risk of coupling to the prompts.

We will see if this works for me long term, but I do think beginners manually refactoring with though could be an accelerator.

But only with intentionally focusing on learning why over time.

I completely reject this way of thinking. I remember when I was starting out it was popular to say you learn less by using an IDE and you should just use a text editor because you never learn how the system works if you rely on a run button or debug button or a WYSIWYG editor.

Well in modern software we stand on the shoulders of many many giants, you have to start somewhere. Some things you may never need to learn (like say learning git at a deep level when learning the concept of add, commit, rebase, pull, push, cherry pick and reset are enough even if you use a GUI to do it) and some thins you might invest in over time (like learning things about your OS so you can optimize performance).

The way you use automation effectively is to automate the things you don’t want to learn about and work on the things you do want to learn about. If you’re a backend dev who wants to learn how to write an API in Actix go ahead and copy paste some ChatGPT code, you just need to learn the shape of the API and the language first. If you’re a rust dev who wants to learn how Actix works don’t just copy and paste the code, get ChatGPT to give you a tutorial and then your write your API and use the docs yourself.

Using an IDE does stunt learning though. Whether that’s a problem is up for debate. But relying on the run button, or auto completion does offload the need to remember how the cli fits together or learn library apis .

Do you have any evidence of that?

From personal experience and from the popularity of rstudio, jupyter etc. the evidence points in the other direction.

It’s because when you start out you just need to learn what code looks like, how does it run (do all the lines execute at once or sequentially), that you have these boxes that can hold values etc.

Given that form most of my projects, the run button is a convenient wrapper over “cargo run” or “cargo test — test-name”, or “python file.py” not super convinced of the argument.

Maybe in C/C++ where build systems are some kind of lovecraftian nightmare?

Some Makefile knowledge does not hurt much, but other than that it starts to become a nightmare.

Another big difference is the size of the standard library. One can hold on his brain all the information needed to program in C, but I would argue that for C++ or Java it would be too taxing and an IDE is almost a requirement, the alternative being consulting the documentation often.

It's actually this language-specific packaging ghettos that exist precisely in order to hide the grotesque reality of how difficult it is to directly use third party code in these languages.

People making new languages should resist this trend. Do not implement another damn package manager. Think about the problem and make it easy for people to just use someone's tarball of code.

> If you’re a rust dev who wants to learn how Actix works don’t just copy and paste the code, get ChatGPT to give you a tutorial

But if you don't know how Actix works, how can you be sure that the ChatGPT-generated tutorial is going to be particularly good? It might spit out non-idiomatic, unnecessarily arcane, or even flat-out wrong information, asserted confidently, and you may not have any good way of determining that. Wouldn't you be better off "using the docs yourself" in the first place, assuming they have a halfway decent "Getting Started" section?

I know it's easy to draw an analogy between "AI-assisted coding" and autocompleting IDEs, but under the hood they're really not the same thing. Simpler autocompletion systems offer completions based on the text you've already typed in your project and/or a list of keywords for the current language; smarter ones, like LSP-driven ones, perform some level of introspection of the code. Neither of those pretend to be a replacement for understanding "how the system works." Just because my editor is limiting its autocomplete suggestions to things that make sense at a given cursor position doesn't mean I don't have to learn what those methods actually do. An LLM offering to write a function for you based on, say, the function signature and a docstring does let you skip the whole "learn what the methods actually do" part, and certainly lets you skip things like "what's idiomatic and elegant code for this language". And I think that's what the OP is actually getting at here: you can shortcut yourself out of understanding what you're writing far more easily with an LLM than with even the best non-LLM-based IDE.

Strawman on the WYSIWIG editor vs text editor question. That is not an "automated decision-making system"

> Automation bias is the propensity for humans to favor suggestions from automated decision-making systems and to ignore contradictory information made without automation, even if it is correct.

Note this 1998 NASA paper to further refute the IDE/WYSIWYG editor claims.

https://ntrs.nasa.gov/citations/19980048379

> This study clarified that automation bias is something unique to automated decision making contexts, and is not the result of a general tendency toward complacency.

The problems with automation bias has been known for decades and the studies in the human factors field is quite robust.

While we are still way to early in the code assistant world to have much data IMHO, there is evidence called out even in studies that edge towards positive results in coding assistants that point out issues with complacency and automation bias.

https://arxiv.org/abs/2208.14613

> On the other hand, our eye tracking results of RQ2 suggest that programmers make fewer fixations and spend less time reading code during the Copilot trial. This might be an indicator of less inspection or over-reliance on AI (automation bias), as we have observed some participants accept Copilot suggestions with little to no inspection. This has been reported by another paper that studied Copilot [24].

Some decisions like “how do I mock a default export in jest again?” are low stakes. While other decisions like “how should I modify our legacy codebase to use the new grant type” are high stakes.

Deciding what parts of your workflow to automate is whats important.

WYSIWYG editing in software development, for actual code and not just documentation, is in the lunatic fringe.

Specifically re: git, I think a more fair comparison (than deep git vs. shallow git knowledge) is about learning how to use automation tools vs understanding the processes that they automate.

Case in point, there is an employee in my office who, after attaining a 4-year CS degree, was unaware that "git" wasn't "GitHub". GitHub is so aggressively pushed on new programmers that they don't even need to know that git exists, much less how it works. Actions that don't have a large colorful button may as well be impossible for someone so thoroughly dependent on tools-in-the-middle.

> It is a bit of a paradox that the better the tools become, the higher the risk is

  "C makes it easy to shoot yourself in the foot; C++ makes it harder,
   but when you do it blows your whole leg off". -- Bjarne Stroustrup

Reply on news.ycombinator.com