> And now that they have the tedium wrangled, they are freed from all of these arguments that start: we can't do that because it would take forever.
I'm strongly skeptical of this argument, as there's only a few things you can not build a rough version and get something to ideate upon. Even with 3d games you can do design with blocks and buy models to have something to pinpoint the design.
This is still an incomplete model, in my opinion. You're still holding up what is possible as a non ai assisted developer as equal to the assisted one in the abstract, before adding in real world things like tedium, boredom, distraction, the ephemeral nature of novelty, frustration, and everything else that has derailed human software development, but inference engines are perfectly impervious to.
I can give you a concrete example: this week at work, it occurred to me that the 16 channels of expected and measured binary on or off test data I need to collect could benefit from a visualization because matching expectations will have visual properties that failures will not. So I had my AI agent create a script that encodes 16 channels of expected and measured binary wave forms over time, as a 32 channel 1Hz sampling frequency wav file, which I can view with audacity, which also has the necessary controls to measure time between transitions in the waveformms.
From hindsight, one could argue that since all of that solution consisted of rudiments of perfectly normal software that didnt need AI to be written or integrated, it was equally possible to create without AI. But knowing that could do it with the greatest of ease, for the total price of naming it, converted this from a project that required the motivation to figure out all of the necessary steps to one that just needed a good description.
I do get your point about speeds and ease of producing working code. This kind of quick win can be a good example of AI assisted tooling. But I don't generate scripts that way as I prefer to have composable blocks that I can reuse later. AI is not great at reusable code.
Another things I noticed with AI assisted programming is the one track thinking. Someone has an idea, generate a working sample and then it becomes like a sunk-cost fallacy where they don't envision any other implementation choice or design. It's about adding more feature without taking a step back and assessing the overall goal of the project and if that feature is really needed.
Antoine de Saint-Exupéry has said it best:
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
This kind of cohesiveness is often missed in projects that are AI assisted because there's no refinement step. The product and the efforts are not tempered by real world usage.
But what about compositions of your reusable blocks an order of magnitude larger than you were ordinarily willing to manually compose? A lot of this misnaming Im circling around comes down to demanding that the ai user must be giving up their agency. Whatever you can name as a good practice you don't think an AI agent is a capable of employing on its own, I can retort that a human can demand the agent employ it, along with all of its other capabilities that outstrip the human typist.
Theoretically they can. There are people that use Paint to draw masterpieces. But your argument is only true if they’re willing to do so. AI is a slop enabler, having the discipline to funnel the slop into something concise and useful is not a given.
Sudoku’s constraints are knownn and easy to build an harness for. Software has a more malleable structure. An harness is hard to build and the tests cases for the constraints can be a lot.
As soon as you’re specifying instructions for the computer to do a task automatically, you’re programming it. It can be recording a macro, writing a script, describing it in something like Shortcuts,… The core thing is automation.
Copy-pasting is not programming, no more than clicking the save button is. But text expansion may be seen as such, especially when it involves dynamic elements (like current date and time). It may not be a clean delineation but, IMO, it's the difference between writing a recipe and doing the dish. Copy-pasting twice is making a dish. Creating a button that let the computer do it is writing a recipe.
Why are you looking to contribute to open source projects? If you have a fix or a new feature, you can share the diff in variety of ways. The maintainers are not obligated to review, discuss, and accept your changes.
I’m not entirely following you. I generally don’t contribute anymore, but in the past I’ve found a lot of maintainers are not actually looking for collaboration, rather free labor.
I certainly understand things are different nowadays, I’m talking pre-LLM proliferation.
> I’ve found a lot of maintainers are not actually looking for collaboration, rather free labor.
Do you think that maintainers lack domain expertise? A nice bug report is way more helpful than a random pull request. A patch, even when correct, can be counterproductive, if it conflicts with the roadmap and goal of the project.
The goal of open source is to give you freedom in maintaining your own version and extending it. Collaboration is not a requirement.
Well--well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
Code architecture and technical design. You can have a solution that works fine, but are too complex or will impede future changes. Maybe you have code that has already been solved or your variables’ name are too generic. Maybe your modules are messy and your data structures are not modeled well.
No need to pair program, you can always send a message to your colleague about the design of the upcoming code, especially if it’s going to impact them or if it’s an area that they’re more familiar with. Waiting till a PR for feedback is wrong IMO.
Code review is not for feedback, it’s for ensuring quality (many eyes on the output) and have a shared involvement in the evolution of the code. The time for feedback is earlier, once you have an idea of the solution.
Writing and reading design documentation can be slower than pair programming. On the other hand, info about code design also belongs into inline documentation or commit messages (in this order of preference), so the effort might not be wasted.
I don't think so. There can be a lot of shared context within the team which can make prose shorter than writing code. And written words last longer than verbal exchange.
I think of a PR as something akin to a lab report. I put myself in the shoes of the reviewer and everything not immediately clear from the title and the diff, I would write an explanation in the description of the PR. That reduces the need for back and forth.
> So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common.
I want my commits to reflect the evolution of the theory of the program, not a chronological log of my reflection and attempts. In my local branches I snapshot things that only matters to my working process. And before sharing, I make sure that the commits are atomic with a proper description.
When sending a report, do you also send all the post-it, the notebook with your notes, the books with the highlights , your conversation with your colleagues, your web history? I don’t think you do. My local history have commits that reflect my working process which can be messy. Before sharing I tidy them, so that the changes are easily understood.
> entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling
A PR is supposed to be atomic if you’re using squash and merge. Bundling different changes is the antipattern here, not the squash and merge.
I'm strongly skeptical of this argument, as there's only a few things you can not build a rough version and get something to ideate upon. Even with 3d games you can do design with blocks and buy models to have something to pinpoint the design.
reply