Generalized version: Using tool to do thing makes you bad at doing thing without tool.

I get where this is coming from and it is true sometimes (e.g. my favorite example is Google maps). But it’s quite silly to assume this for all tools and all skill sets, especially with more creative and complex skills like programming.

Wise and experienced practitioners will stay grounded in the fundamentals while judiciously adding new tools to their kit. This requires experimentation and continual learning.

The people whose skills will be impacted the most are those who didn’t have strong fundamentals in the first place, and only know the craft through that tool.

Edit: forgive my frequent edits in the 10 minutes since after initially posting

To me the issue with AI generated code, and what is different than prior innovations in software development, is that it is the the wrong abstraction (or one could argue not even an abstraction anymore).

Most of SWE (and much of engineering in general) is built on abstractions -- I use a Numpy to do math for me, React to build a UI, or Moment to do date operations. All of these libraries offer abstractions that give me high leverage on a problem in a reliable way.

The issue with the current state of AI tools for code generation is that they don't offer a reliable abstraction, instead the abstraction is the prompt/context, and the reliability can vary quite a bit.

I would feel like one hand it tied behind my back without LLM tools (I use both co-pilot and Gemini daily), however the amount of code I allow these tools to write _for_ me is quite limited. I use these tools to automate small snippets (co-pilot) or help me ideate (Gemini). I wouldn't trust them to write more than a contained function as I don't trust that it'll do what I intend.

So while I think these tools are amazing for increasing productivity, I'm still skeptical of using them at scale to write reliable software, and I'm not sure if the path we are on with them is the right one to get there.

Right, but having used assembler and C/C++ before has made me a better programmer, even if I choose to work with a more high level language day to day so I'm more productive.

>1972: Using Anything Other Than Assembly Will Make You a Bad Programmer 1995: Using a Language with a Garbage Collector Will Make You a Bad Programmer

Both of these remain true to today, which is why we always interview people at one layer below the requirement of the job so they know what they’re doing.

Writing C/C++ - know how the output looks like. Using GC-based languages? Know the cleanup cycle (if any).

I would wager the third also holds true.

You forgot:

- using a debugger will make you a bad programmer

- using an IDE will make you a bad programmer

- using Google will make you a bad programmer

- using StackOverflow will make you a bad programmer

Hint: It's not the tools, it's how you use them.

Plato: Writing will make people forgetful.

2035: Using simplified english will make you a bad prompt engineer.

I can trust that a higher level language will produce the correct assembly code.

I can trust that a garbage collector will allocate and cleanup memory correctly.

I cannot trust that an AI will generate quality code. I have to review its output. As someone who has been stuck doing nothing but review other people's code for the last few months, I can confidently say it would take me less time to code the solution myself than to read, digest, provide feedback for, and review changes for someone else's code. If I cannot write the code myself, I cannot accurately review its output. If I can write the code myself, it would be faster (and more fulfilling) to do that than review output from an AI.

2044: "What's a programmer?" the child asks his father innocently. "Well you see son, humans used to be needed to instruct the machines on what to do..."

> Using a Language with a Garbage Collector Will Make You a Bad Programmer

If garbage collectors only did the correct thing 90% of the time, and non-deterministically did something stupid the other 10%, then, er, yeah, it very much would!

There's a reason that conservative GCs for C didn't _really_ catch on... (It would be unfair to describe them as as broken as an LLM, but they certainly have their... downsides.)

And we evidently have a fantastic software landscape with very few buggy products/features being introduced, superb security and transparent interoperability across diverse software domains nowadays.

Don’t forget copy and pasting from stack overflow! I have to do it every time matplotlib cuts off part of my saved figure when using tight layout.

2 out of 3 of those maxims are Reasonably Correct?

Haha, so funny

> and forget how to write the most basic stuff without needing those tools again

This is a reality for some of us already - but it's not about tools. I'm working with 5+ different languages and likely between 20+ projects. I had to lookup in the docs how to (for example) lowercase a string every single time, because every language has to invent their own name/case for it. Now I'm free - just write tolower() and it gets fixed. New string array - ["foo"] and it gets fixed. etc. etc.

There's a huge number of things that are not necessary to remember, but you just do if you see them consistently every day. But now I'm free. If I ever need to do them manually again, I'll check the docs. But today I'm enjoying the time saving.

You might want to try Claude 3.5 Sonnet instead of Chat GPT. Claude 3.5 Sonnet seems to be a generational advance over earlier AIs like Chat GPT. I find that I can reliably uses it in cases where Chat GPT produces pure hallucinatory nonsense. I've only seen Claude hallucinate once, and that after I had incorrectly told it that its answer was wrong. It's not the only AI that does code well, but at this particular snapshot in time (Oct 2024), general concensus seems to be that it is currently the best.

It has fundamentally changed the way I write code. And I'm still exploring the boundaries of what kinds of tasks I can feed it. (45 year veteran senior programmer).

Sorry for the TLDR post, but I find it difficult to briefly make the case for why Claude 3.5 Sonnet (and other similarly modern and capable AIs) are fundamentally different from smaller and older AIs when it comes to use as a coding assistant.

I do use it for simple tedious things like "Convert an ISO date string in GMT to a std::chrono::systemclock::timepoint" (requires use of 3 generations of C/C++/Posix library functions that would take about 15 minutes of wading through bad documentation and several false starts to get right).

But have also had success with larger fragments ranging up to 100 or 200 lines of code. It still has distinct limitations (bizarre choices of functional composition, and an unpleasant predilection for hard-coded integer constants, which can be overcome with supplementary prompts. Seems to be brilliant tactically, and shows a terrifyingly broad knowledge of APIs and libraries across the the three platforms I use (android/javascript, typescript/React/MUI, C++/linux). But doesn't yet have a good sense of strategic coding (functional and class decomposition &c).And usually requires three or four supplementary prompts to get code into a state that's ready to copy and paste (and refactor some more). e.g. "Wrap that up in a class; use CamelCase for classnames, and camelCase for member names. ... &c &c.

And have also used it help me find solutions to problems that I've spent months on ("android, java: unable to connect to an IoT wi-fi hotspot without internet access when the data connection is active"; Claude:" blah blah ... use connectivityManager.bindProcessToNetwork()"!!!).

Or "C++/linux/asound library: why does this {3000 lines of code} fail to reliably recover from audio underruns".

And had some success with "find the wild memory write in this 900 line code fragment". Doesn't always work, but I've had success with it often enough that I'm going to use it lot more often.

And used it to write some substantial bash scripts that I just don't have the skills or literacy to deal with myself (long time Windows programmer, relative newcomer to linux).

  //Converting an ISO date string in GMT to a  std::chrono::systemclock::timepoint 

I agree with that entirely. Using the current tools available to make your life easier while picking up a decent pay check is a no brainer. I probably expect my next job is using said tools primarily followed by complete redundancy.

By that point, having never used any of the tools makes you almost no different from anyone off the street.

In a way I welcome it. Writing the same menial code as everyone else slightly differently becomes a pretty stale existence.

This sucks so absolutely bad because even a shitty demo or POC sticks, and now you’re stuck with that, when it would’ve been faster and easier to just rewrite from scratch.

Also exacerbates the problem of A teams that get assigned to greenfield work and B teams that thanklessly maintain and actually productionise said greenfield work

They do, but very few people are good enough to either write a pull request or review one well. I wouldn’t put myself in the really good category for either.

Most people write pull requests that are scoped too poorly to tell what they’re doing. Like I get a single function with unit tests, so the best I can do for a review is check whether there are any obvious missed edge cases for a function whose purpose I don’t understand.

On the review side, most people review by doing basically what a linter does. I joke with people that if they want to nitpick my variable names then I’ll start DMing them to ask what name they want every time I need a variable. A meaningful review would analyze whether abstractions are good, whether there is behavior that relies on an unspecified part of an abstraction (timing), etc. Nobody does those.

Some care but most don't or cannot care as talking code quality means to managers that you could be doing more, faster and cheaper that is relevant to the bottom line. In large corps, everything is slow and expensive as it is, so 'wasting time' on things that are hard/impossible to measure is not something that is a great sell.

I have 23 years,and I'm convinced too.

Yeah, no, things have changed in the last 30 years...

For the record, some of us have tools which comprehensively solve all of your concerns (even #1). Generating 100% reliable self-analyzing deterministic code is already possible and will become mainstream within the next two months. When you see how it’s done, you’re going to smack yourself in the forehead. Programmers in particular seem extremely vulnerable to dismissing technology that they are not intimately familiar with.