The REPL in (Lisp) driven development is generally attached to your editor, not like irb or ipython or whatever: so the thing you're building is either the resulting function, or something that mostly looks like a test already anyway and is easy to copy into a test module.

Jeremy Howard developed the fastai library using Jupyter Notebooks and his nbdev tool[1]. I'm not saying that to disagree with your claim - I don't have enough experience with Jupyter Notebooks yet to have much of a strong opinion on whether or not it discourages modularity. Just that folks who want to have the best of both worlds might be interested in how it can be done. My first thought is that it looks like Donald Knuth's literate programming ideas put to practice, and it has me excited about programming again.

[1] https://github.com/fastai/nbdev

Not sure it really discourages modular code. I usually write code modularly in Notebooks as well, but not sure how this is for most people.

I suspect the problem is less that it discourages than that it does not encourage.

Which gets back to the posted article. REPL-driven development permitted him to feel confident without doing his usual process, it didn't discourage decoupling, but it didn't encourage decoupling either. TDD, to be done well, almost requires decoupling your code to make it more testable.

The same may (I'm not sure I agree, but I've never used Jupyter notebooks) be true of using notebook-styled development approaches and modularity. If the workflow permits relatively easy (and mostly safe) development without encouraging modularity, then it's incumbent on the developer to bring that discipline into the workflow.

And unfortunately, most of the new crop of programmers don't have that discipline. I tell them to write tests and they eyeroll when they think I'm not looking.