I am #DigitalHumanities Coordinator at Max Planck Institute for #LegalHistory and #LegalTheory (#mpilhlt) #Frankfurt
Also collaborator of salamanca.school project of #adwl #Mainz
While I mostly toot about work, I do have hobbies...
#Capoeira #Stratocaster
#LawFedi #Histodons
#NLP #TEIXML #Golang #Python #Elm #XQuery
If you're reading this on bsky, follow @ap.brid.gy so i can see your replies.
| orcid | https://orcid.org/0000-0003-1835-1653 |
| hcommons | https://hcommons.org/members/anwagnerdreas/ |
| pronouns | he/him |
However, at the point I was asking I actually did not want to address these more formal considerations yet. I was trying to get a more comprehensive grasp of the subject matter and its different dimensions. To this, the conversation actually did not contribute a lot.
3/3
Helpful: merely having a sounding board was helpful. It suggested some aspects that I then excluded more consciously from my draft and brought up ways of structuring the text some of which I then adopted.
However, I am not sure how much of the "sound" of the "sounding board" I am projecting onto the bot or the dialogue. I think it was basically my own reflections of the initial text and its stakes that really improved the document. The only input that must objectively be attributed to the bot was the pointing out of aspects and structure of the document typical for the genre.
2/3
Today I figured out why I often feel uneasy with chatbot responses. They are helpful and disappointing at the same time: About some draft I asked: "did I forget an important aspect?" and when I pointed out that I considered the bot's subsequent response to be indeed covered by what I had written initially, the bot (Claude 4 Sonnet) just gave in: "Yes, now I admit that you're 100% correct etc.".
Disappointing: I think I was hoping for some friction as I would expect from a human interlocutor who would probably have had an intuition that my coverage was only partial, or bound to some unarticulated presupposition. In my experience, such a kind of friction is almost impossible to find in a conversation with a bot.
1/x
I like this take by @kentbeck on how AI-assisted programming changes the balance of which skills are most important
From this interview with @gergelyorosz https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent
@helge @kentbeck @gergelyorosz that's one of the most interesting questions right now, I think
We clearly need to reimagine aspects of how we train new software engineers
@cocoaphony @chris @simon @kentbeck @gergelyorosz I actually think it is mostly the same issue, just at a much, much lower speed. Someone who knows assembly usually writes better code (not because she is older, but has a solid understanding of how things work internally, though admittedly that may be counter today).
But AI brings that issue (not understanding what happens) from an acceptable level to 100x.
Either way, I think it can be helpful to senior devs because they can rate the output.
@helge @chris @simon @kentbeck @gergelyorosz Of course when higher level languages were first developed, senior engineers did not feel that the issue was an acceptable level :D
I'm seeing some junior devs get in way over their heads following AI advice. (I'm kind of developing a stock lecture about it…) I'm also seeing junior-to-intermediate devs use AI to explore and learn deep things they wouldn't have dared before. I'm seeing the dig into details that before they'd have left as unknowable.
@cocoaphony @helge @chris @simon @kentbeck @gergelyorosz the difference (to my mind) is that if you have a solid foundation in “how things actually work”, you can design an experiment to figure out what is really happening so you don’t get misled. Absent that foundation … all you can do is hope.
That doesn’t have to mean “writing assembly,” but “knowing that there’s an actual spec and knowing how to read one” is an _invaluable_ skill that’s severely diluted by vibe coding. Even the idea of having a spec is diluted.
@steve @helge @chris @simon @kentbeck @gergelyorosz Also true. Though time and again I discover that how I think things actually work, based on my decades of foundations, is...huh, not actually how things work (which I learn when someone like Steve explains it to me... :D)
Certainly, learning foundations will always be valuable. But I remember my mentor in 1996 fussing that I shouldn't waste so much time digging into details. I think they were wrong. But it's not like *everyone* used to care.
@helge @steve @chris @simon @kentbeck @gergelyorosz Agreed that coding assistants are definitely lowering the bar (in a good way) for non-devs to build their own tools. I've seen quite a lot of that, and it's a great thing.
I think some folks are scaling that incorrectly to "AI, build and deploy a replacement for Netflix, I'll come back in an hour." This is very related to how folks confuse prototypes with "almost ready to ship."
@simon @kentbeck @gergelyorosz I don't write code. I am more of an _idea_ person.
Good luck with that.
@jimgar @simon @kentbeck @gergelyorosz Ideas are very cheap. How 'bout a website where you can design a door? Or one that helps you find the best food for your dog? Or a site to help you fix your shoes? Or a phone app that will automatically order your lunch from the nearest fast food restaurant?
Implementation is hard. Writing a real application that can actually withstand malice is hard. Understanding the real world is hard.
@simon
I think that's extremely optimistic because the most consuming part of any creative development is specification (ie a language of description to define the operation), in ever increasing precision until the point where the machine does what you want.
You can't handwave. Anything an LLM generates has to be verified by someone or something against...what? -> against an understanding?
An LLM can help you find some steps quicker but it can't do that *work*.
Ted Underwood
Frederik Elwert
Zack Batist
Simon Willison
Anthony Cowley
Helge Heß
Chris Eidhof
Rob Napier
Steve Canon
lemgandi
Jim Gardner
DKMJ
happyborg
Kent Beck
HadrienMP