You must log in or register to comment.
What quality writing! With such takes as “ooh wittle AI scwipt kiddie never gonna be a weal progwammer” and “Using genAI is like paying the Google App Store”.
I don’t need AI to make me a bad programmer.
Reading code is harder than writing code. The author acknowledges this and pretends it means the opposite of that.
He then suggests a world where any idiot can describe a thing into existence means less individual control than scrolling through the app store and hoping someone’s done what you want. Like doing a thing on your own computer means someone else gets all the money. My guy - what money?
Listen. I taught myself QBASIC using the help file. I majored in computer engineering. I’ve done some esoteric shit, both high-level and low-level. Fuck anyone scoffing at people making their own programs, without jumping through those hoops. These stupid objects are supposed to be a bicycle for the mind. Even children should be able to use them to the fullest possible extent.
These stupid chatbots are the closest we’ve come to a computer that does what you tell it to.
Haven’t read the article, but can anyone with more software experience let me know how you’re supposed to collaborate with someone who uses AI to code? I’m working with a vibe coder for the first time. As far as I can tell, his code is all great, but the dude checks in like 3,000 lines at a time. How am I supposed to have any understanding of a codebase that grows and changes that quickly?
Reject their patches.
Literally “this is a small, simple feature. It should take something like 200 (or 10, or 50) lines to implement. 3000 tells me you didn’t think carefully enough”
Or “you have a bug here, a bug here, another here. This is where I stopped. Ask me back when it’s ready for review”
I promise you that their code is not all great. It takes an order of magnitude more effort to refute bullshit than produce it. Refute part, then don’t engage with the rest. They’ll get the message.
Not sure how much experience you have, but I’m 25+ years at this point.
Just make sure the project is well structured and things are put in the right place so you can at least get the gist of a chunk of code’s purpose. Then drill down as needed adding fidelity to your understanding. There is no secret sauce here other than practicing reading lots of code.
For very large change sets (because your coworker is a lazy fuck), mentally pick out the automated shit like variable/function/class renames, function/interface abstraction, basically whatever your IDE can do and discard them. That is just noise. For the rest, start with their commit message that should describe the change in sufficient detail and look specifically to validate its claim. It can help to ignore the diff and instead just checkout their branch and read through the finished code with all the nice things your IDE provides to follow calls, look up definitions, etc. and mentally/actually run the code to see evidence of the expected change.
The other thing you can/should do is tell him to break up his commits and direct the agent in smaller steps. I’ve legit done this in the before days to prolific peeps I’ve worked with. Believe it or not, the introduction of agile/sprints and all that nonsense helped to keep commits smaller simply because you don’t have time to keep a long lived branch. It was (and still is) good kata to layer your changes in commit-by-commit such that the mutation is a smooth, deployable gradient of incremental changes.
TL;DR: Tell him to quit being fuckin lazy.
For the rest, start with their commit message
Heh, that’s another can of worms. The project is in a “get a bunch of stuff quickly” mode at the moment, and he’s taken to treating main like his personal codebase. Pushing to main, no comments. Even our Linear tasks he just marks as “complete” with no comments or context.
But yeah, I think the rest of your advice would work well if he was a bit more of a team player.
You need to isolate his work behind a well-defined interface and then ask yourself if Conway’s law works in both directions.
Seriously though, an interface is easier to test than a mess of spaghetti code, and also easier to replace the implementation when you eventually realise that vibe coders are a net-negative to any project.
Every advancement in technology resulted in the same conversation. What ends up happening is the energy we put into one thing is now put into something else and our productivity goes up.
I guess the real danger with AI if it meets its potential is we may not have a place to put our energy that AI isn’t already better at.
deleted by creator
Exactly! People like to hate ai without looking at the changes already happening in the market ad in people’s life. All the time and energy we once took into doing a lot of demanding things like coding and writing will now be used for fixing the mistakes done by ai intead.
Lol, true. But significantly less energy put into that. I love writing SQL, but some things are tedious. And I also don’t know by heart. I can get AI to write most of the query for me, then I need to review it and fix issues, but in the end it is saving me like 20-30 minutes having to google and figure out syntax.
Am I worse off at writing SQL? Maybe, but I’m putting that energy into reviewing the results of the query quicker.
I use SQL as an example cause I just did exactly this. My energy is being used now to write a comment on the internet :)