Paul CantrellThis is good (from @shriramk): https://mastodon.social/@shriramk/110040524796761802
The skill of recognizing and diagnosing broken code only becomes •more• important in the face of LLM code generators.
Jesly VargheseAny experienced programmer worth their salt will tell you that •producing• code — learning syntax, finding examples, combining them, adding behaviors, adding complexity — is the •easy• part of programming.
The hard part: “How can it break? How will it surprise us? How will it change? Does it •really• accomplish our goal? What •is• our goal? Are we all even imagining the same goal? Do we understand each other? Will the next person to work on this understand it? Should we even build this?”
A thought exercise:
Which of the problems in the post above does AI code generation make easier? faster?
Which does it not help?
Which might it exacerbate?
My “hard part” list ended only because of the post size limit; it goes on, of course.
From @h_albermann: “Are we solving the right problem?” And would solving a slightly different problem simplify things? Reduce risk? Open doors? How will we measure, reflect on, reassess these answers as we build?
From @awwaiid: “How can I get rid of this?” How can I split it? Abstract it? How can we prepare for future change? But not over-prepare? What kind of flexibility should we invest in? Leave room for?
How does this software impact people? Its users? Its stakeholders? Its maintainers, current and future? Society? Especially the most vulnerable?
Yes, coders have a part in all of these questions above! We are often the first to see crucial details, often the first to have a sense of the •reality• of the whole system (as opposed to our wishful imaginings of it). There is no such thing as “just coding;” all actions have consequences.
@endocrimes sums up all the above and more quite beautifully with this post:
https://toot.cat/@endocrimes/110071997616681139
https://toot.cat/@endocrimes/110071997616681139
danielle 🏳️🌈 (@[email protected])
The hard bit of software engineering has always been "deeply understanding a problem well enough to implement a useful solution to it". The scary bit of people trying to AI away the programming part is that most rely on writing the software to understand the problem domain -- remove that part and you truly do have YOLO driven development with badly thought out questions "generating" bad and kinda broken software.
Christian Lynbech@inthehands @adamhill @endocrimes I really agree with this. Many, also programmers, see programming as puzzle solving which is a very wrong frame of mind for the activity. Programming is much better understood as a journey of learning, as Danielle is also saying.
@inthehands @adamhill @endocrimes Equally wrong, even dangerousluý so, is the idea that AI will help by taking away the boring parts of programming. First of all, that is unlikely to be true, humans will be left with the debugging, the getting the code to work, which is *not* the fun part. Secondly, I deeply believe that there is a value, even in the boring. Even the best pianist will spend hours daily, practicing scales.
@inthehands @adamhill @endocrimes And while I do understand that many programmers do not really control their tools and environments, I cannot help but thinking that if your programming language has so much bolierplate that you need an AI to help write that, perhaps you should consider using another language.
@mapcar @adamhill @endocrimes
Ha, well, •this• pianist doesn’t spend hours practicing scales — which probably explains my middling technique!
Regardless, I think you’re on the money with the last part: anything AI can automate by turning the web into boilerplate is probably ought to be a new language or library abstraction. I have longer thoughts on this I’m going to post at some point.
Stefan@inthehands Unfortunately the culture and basic models these companies operate under doesn’t allow for more than a shallow pass at these questions. At the end of the day, it’s an ARR race to the top (or bottom, depending on your point of view).
⁂ Fish Id Wardrobe@inthehands Thinking about it, I suppose one thing that bothers me about foregoing the opportunity for someone to write the initial code is – with code written by a competent person, you have a chance to divine the coder's *intent*.
Example: If I've used command pattern but there are only two commands, it's probably because I think there might be more commands added to the code in future.
With LLM-generated code, of course, there is no intent. Just code.
@fishidwardrobe Yes! Or if there is intent, the intent comes from the code the LLM is plagiarizing. If you’re lucky, that might happen to line up with the problem in front of you. If you’re lucky.
Regardless, all LLM-generated code is legacy code of suspect quality from the moment it’s created. If we’re going to let that into our dev processes, we need to think about the implications.
Janis@inthehands I bet you'd like this one, Although it's not specificallt pertinent until about halfway though: https://www.capitalisnt.com/episodes/joseph-stiglitzs-vision-of-a-new-progressive-capitalism
Joseph Stiglitz's Vision of a New Progressive Capitalism | Capitalisn't
In the last 60 years, few economists have contributed more to exposing the failures of capitalism than Joseph Stiglitz. Formerly the chief economist of the World Bank and chair of the U.S. Council of Economic Advisers under President Bill Clinton, Stiglitz won the Nobel Prize in Economics in 2001 for his work showing that the possibility of having different information can lead to inefficient market outcomes. On this episode of Capitalisn't, Stiglitz joins Bethany and Luigi to discuss his latest book, "The Road to Freedom: Economics and the Good Society" (W.W. Norton, 2024). The book, as Bethany describes it, is a "full frontal attack on neoliberalism" that provides a prospective roadmap towards a more progressive form of capitalism. Together, the three discuss the role of mis- and disinformation in producing market inefficiencies, the importance of regulation, institutional accountability, and collective action in correcting market failures, and the role of neoliberalism in today's global populist uprising. In the process, they underscore the close link between economic and political freedom.
Hans Cathcart@inthehands A machine learning algorithm to help think of ways an app could break or be abused could be quite useful, I'd imagine.
@hanscath Indeed. I can imagine carefully hand written invariants / assertions as input to a sort of ML fuzzer. Or imagine a model checker like Alloy running on ML-generated input: “Based on how you described your intent in words, could this situation that your code allows be a breakage?”
arclight@inthehands @hanscath I learned of KLEE from https://www.amazon.com/Embedded-Software-Development-Safety-Critical-Systems/dp/0367338858 (the cheaper 1st ed. is also great). The maze-solving example linked off KLEE's website is really cool, especially when it ferrets out really subtle logic bugs that "cheat" to solve the maze.
@inthehands I'm reminded of the time when I watched AlphaGo play Lee Sedol, and the commentators were trying to figure out what AlphaGo was doing. AlphaGo had started a strategy no human had ever thought of. So either white hats, or more likely black hats, will use this tech for penetration testing.
@hanscath
That seems very likely. And in general, ML seems very well suited to tasks where the reward of one successful attempt outweighs the cost 100,000 failed attempts. Automated spearphising is another example.
That seems very likely. And in general, ML seems very well suited to tasks where the reward of one successful attempt outweighs the cost 100,000 failed attempts. Automated spearphising is another example.
Word of Mouth 
@inthehands Great questions. The cargo cult is in full swing, so we should see the results within a year or two. For now, we lack data to answer. I did read that CoPilot has proven itself to be barely helpful in a limited study.
Reserving judgment but my prediction? It'll have a huge impact on SEs. And basic web dev. But engineers working on complex problems will find less utility unless we make our own tooling. If it turns out to be helpful, serious people will take it seriously.
Leon@inthehands you’ve got the wrong end of the stick there. Copilot doesn’t take out the easy parts *or* the hard parts, but the *boring parts*. The “write this line again but for the next button instead of the previous one” or “shit which arg does what in splice again, guess I need to look it up”. The little speed bumps of joyless flow-interruptions.
Shock absorbers don’t drive, navigate, or pick the destination but they make more destinations possible, desirable, enjoyable, and to more drivers.
Jesse Morris@inthehands I think the part of software development that has the biggest gains to be had from AI assist is when for some dumb reason you're stuck using an AZERTY keyboard and can't even figure out how to make a curly brace.
Gavin Chait;@inthehands There's also the conceptual stuff. Humans have to use code, so what's an intuitive API workflow that doesn't cause anguish and torn out hair. It's easy to write great balls of spaghetti, not so easy to produce something that supports & guides a user.
schrotie@inthehands Put another way: projects don't fail because of our struggles with writing code but because of our struggles with communicating with people.
@schrotie
The two hardest problems in computer science are yourself and other people.
The two hardest problems in computer science are yourself and other people.
Raul Portales@inthehands @schrotie and off by one errors
T. T. Perry
Josh Justice@inthehands @schrotie Sartre, I believe.
das-g@inthehands @schrotie Allegedly also known as "naming things" and "cache invalidation", though I'm unsure which is which and afraid of what that might imply.
Denny@das_g "The two hardest problems in computer science are cache invalidation, naming things, and off by one errors." 😄
@denny There's a whole collection of variations: https://martinfowler.com/bliki/TwoHardThings.html
Ken Anderson@schrotie @inthehands @davidjrusek That’s why I still use Fred Brooks’s book “The Mythical Man-Month” in my software engineering courses. Still good 50+ years later!
awwaiid (Brock Wilcox)@inthehands "how can I get rid of this?"
retrobungus@inthehands :o I see the same thing at library science.
well any organization will have problems in communicating decisions between spaces of time, but library (and any other science that works with taxonomies and classifications) need to convey information and knowledge to other people outside of the "institution".
many times a librarian will describe collections with their understanding of things in mind and not about the collective understanding and necessities of the user of the institution.
Zorro Notorious MEB 😡@inthehands Where I come from, what you describe as "the hard part" is called "spending too much time in the huddle" and you can get fired for it. 😈
@AlgoCompSynth
If folks are only thinking about all those things while they’re in the huddle, you’ve got problems.
If folks are only thinking about all those things while they’re in the huddle, you’ve got problems.
@inthehands If the development staff has to think about those things you've got problems anyway. "Should we build this?" should have been decided long before making other decisions. But "should we stop building this?" has to be on the table.
@AlgoCompSynth Sure, “should we build this,” “should we stop,” “should we build something different,” frame it how you want — those questions have to be on the table throughout development. It’s dangerous to imagine that product management ends when implementation begins, for the same reason that any other sort of waterfall process doesn’t work.
Ralesk@AlgoCompSynth @inthehands If someone sells a feature that's infeasible it's much worse to later say no, than to not sell it at all - so dev layer input can be important
Horst Albermann 🇪🇺🇩🇪@inthehands Are we solving the right problem?
inhuman resource@inthehands seeing these things generate boilerplate JS and other easy to check stuff - that's kinda handy, pretty energy intense for what it does
asking them to do *anything in C*, or other contexts where its easy to be wrong and important not to be - horrifying, almost every output has serious problems and if you're not personally expert-level you will probably not catch them all
@cr8
I’d argue that this rapidly becomes true even in JS. These tools seemed well-suited for exploration, discovery, and suggesting common patterns — all super helpful things! I’m highly suspicious of them generating working code in a way that actually saves time in the long run.
I’d argue that this rapidly becomes true even in JS. These tools seemed well-suited for exploration, discovery, and suggesting common patterns — all super helpful things! I’m highly suspicious of them generating working code in a way that actually saves time in the long run.
Johan Wärlander 🦀@inthehands @cr8 I definitely feel a lot safer working with generated code for Rust than I would with Python, or C 😂
Mark IJbema@inthehands but I don't mind automating the easy part. It can still take time. I can see doing TDD with me writing the tests and AI writing the code for instance.
The thing with this ChatGPT hype is that people seem to either think that it's worthless or that it's going to replace humans.
I think it might give a 10-20% speed up to senior developers, which still is very revolutionary
@mark I can see that possibility. I can also easily imagine it being a net negative: the generated code has flaws (either technical or goal-related) that are more costly to fix post hoc than to have thought through carefully from the outset. It’s going to take a lot of work to figure out how to use these tools well.
@inthehands I suspect like any new technology it will be massively overused before we learn when it is and isn't appropriate to use. Like meta-programming in ruby
DesignDamon@inthehands So true, and there's a direct parallel with design here - It's not all about the execution and how good you are at making things look good in Figma. Do I have the insight/research I need to design the Right Thing? How will people use this? How well will it translate to build? Am I serving the user needs, and not my own ego? Are business needs pushing me to do something shady? Are the aesthetics appropriate, or just what *I* like? It goes on.
@inthehands AI/LLM "Design" approaches to to be focussed on *describing how it looks*, and not understanding the job it needs to do.
@damon
This is all very well said, and everything you said applies when writing the code as well. Developers and designers alike are too much in denial about how many design decisions are actually made by the implementers. That’s why communication and shared understanding, and iterative process, are so essential.
This is all very well said, and everything you said applies when writing the code as well. Developers and designers alike are too much in denial about how many design decisions are actually made by the implementers. That’s why communication and shared understanding, and iterative process, are so essential.
EnidKapelsen@inthehands @tomster Than that’s the common ground where good developers and good designers can meet :)
Jan 
@inthehands I wholeheartedly agree!
Here is a related recent thread on that topic, if you are interested:
https://floss.social/@janriemer/110034737129225638
Especially see the post by @yuki2501
Jan :rust: :ferris: (@[email protected])
"#AI is going to make software engineers obsolete", is the most ridiculous thing I've heard in my career as a software engineer. People who say stuff like this have absolutely no idea, what software engineering is about: - Communication with people to specify requirements - Considering _A LOT OF CONTEXT_ - 95% reading existing code, 5% writing new code - Reuse existing code - Find patterns and relations - ... #ArtificialIntelligence #SoftwareEngineering
Bèr Kessels 🐝 🚐 🏄 🌱@inthehands you forgot the most difficult part, even: maintenance.
Will it keep running in ten years? Can you maintain the development pace over years? How can you build software that keeps running through decades? How do you architecture teams and software so your team keeps shipping as fast in ten years as today.
{{template.display_name}}@inthehands Love this. More software engineers need to ask themselves questions like "Should we even build this?".
Or my personal favorite: "What happens if it's wrong?", which I feel like is the key question that people building these AI chatbots *aren't* asking themselves.
Grovewest@fraterrisus @inthehands That question "What happens if it's wrong?" is actually huge. So often I have seen where the only alternative was for users to return to pen and paper. Effective work arounds need to be considered during the 'boring' part, not after it breaks.
Lorry@inthehands back in my day, writing #software was still split into two or three roles: The Systems Analyst and Designer, then the much lower ranked programmer, and lower down again, maybe a data entry person too.
Systems Analysts didn't need to be able to write code at all, they dealt with all the higher level stuff you mentioned.
I suppose in a way these days it's almost gone back full circle with product teams acting as the Systems Analysts and handing the coding to an engineering pool.
Peter Jakobs ⛵@inthehands @kentindell I said the other day:
Many people can tell you how it works, a true engineer will tell you how it will break.
Many people can tell you how it works, a true engineer will tell you how it will break.
Scott Michaud@inthehands And then making it simple. A lot of experience comes down to figuring out the smallest change (and even the correct metric for smallest) that will produce the desired result.
Jons Mostovojs@inthehands any HR worth their salt will tell you that you use the word "programmer" to address multiple professions and even roles.
That said, I'm happy when software engineers are asking themselves the latter two questions you've listed. But they don't have to, in principle.
If your coop or a company doesn't have processess that concern discoverability and understandability, then it's not software engineers' responsibility to eyeball those, nor will it end well for anyone, because they're not professional technical writers / technical HR.
wrosecrans@inthehands I've seen a fairly large team of devs burn multiple years building stuff because nobody would admit that the exec driving the project hadn't actually articulated something specific to build.
I am sure GPT could have generated 10x as much code in that time, for just as much accomplishment.
Prickly Pam (D-PA)Yes and yes!