Code review can go much deeper now if you use AI to aggressively attack a PR combined with your human insight. Same for planning a feature:
Can I consolidate this logic to a shared function? Does the error surface to the user and are there any gaps? What preexisting functionality is affected by this PR? Can this query be made more efficient?
LLMs are great with focused questions, up and down abstraction layers and across all kinds of concerns. Stack up these focused concerns into a rich understanding of what you are doing or writing.
Understanding is the real output, code is the byproduct.
I agree. This is much better advice than what the article tries to do, which is to give best practices around how to use or not use AI to code.
Do I understand when I just let AI regurgitate the function and behavior of the code?
> You code and you have the AI check your work. Treat it like a reviewer. That’s my advice in a sentence.
Bro you're giving the same advice as the article
Well, I can't ask it for an overview of a system it can't see.
also
> I don’t follow all these religiously.
So if you need an overview of a system, you can and should provide access to the entire codebase. Even the rule itself says "preferably", not "don't ever". If you have different needs, you can always just look at it as a useful guideline. It's just a blog post by some rando on the internet, not the epiphany of AI coding's Ten Commandments.
Core modules: Coded by myself, AI reviews and AI to discover/learn.
Stuff I don't care about Craft: API layer, CLI layer, Smoke tests, Integ tests - Dial AI heavy, and lighter human reviews accordingly
Obviously takes a lot of patience and very easy to sin, but on good days, its doable.If students of the 70s or today pretended they didn’t exist up to a certain point when they needed them to move forward, like bioinformatics or something, they 100% would be better off. There is plenty of research on off loading thinning providing a worse understanding of the material - eg side rules proving a better understanding than calculators.
I think AI might be more of a problem, at least for some skills because it is not just doing a small unit of work. its more like the problem of doing more complex calculations. An example I have come across with calculators is students learning statistics without knowing how to calculate a variance, because they just put the numbers into a calculator. There is a failure there to learn the concept - they do not really know what a variance or SD is. I can imagine AI doing a lot of that.
You learn stuff by heart, so that when you mess up with the calculator you have a feel that stuff has gone wrong
> the term “vibe-coding” suggests a kind of laissez-faire attitude where you don’t really care about the outcome and you’re just having fun. That’s what the phrase meant when it was coined, but the world has moved on. In many companies professional programmers are using AI in such a way that it’s impossible to imagine that they are also reading the resulting code in detail. This is what modern vibe-coding is. Deferring to the AI, not worrying about the individual lines of code, and keeping an eye on whether the code passes its tests and throws up any problems in production.
This way of working is the only one that justifies the trillion-dollar bet on the AI industry. I agree, this method should be called vibe-coding.
I don't care which words we use, but they should separate this sort of empirically-minded work (versus the rationalism of typical development) from just dropping a few sentences into the prompt and crossing your fingers.
Yeah, I understand that this testing-oriented constraint method is what AI coding enthusiasts are pitching. Sure, it's different from pure vibe-coding as originally defined, but nobody is seriously suggesting professionals should do pure vibe-coding anyway. It's a strawman. The word fits.
I wonder if that trick about prompting it to write like a 5th grader* would help here. Keep it simple!
*A trick which allows it to pass for human 70% of the time...
My current approach is "ask for very small diffs" + "review them very carefully".
I'm not working a job though, I'm working on a multiplayer game.
Main findings: The frontier models can't reliably modify Pong without breaking it, so their skill appears to be quite domain-specific. (OK, to be fair, neither can I half the time!) This is probably because they are "time blind". I had one model try to test a game by running it at 0.1 frames per second and shoving each frame in the vision API...
If you leave any room for a misunderstanding, they will laser in on do it and do the stupidest thing possible. If you're not checking everything carefully, you will discover this later, and you will cry.
Formal proofs, oddly enough, do not improve the situation: they will simply prove mathematically that the absurd and pointless and backwards implementation is completely without defects. (It obviously does help within an implementation, though.)
They can't formally prove what the hell you meant when you told them to build something. That job remains frustratingly human!
Current dissatisfaction: (1) Harnesses are designed for super bloated codebases (i.e. designed to load as little context as possible) which make them pretty clunky for small repos and small edits. (I had a Surgical Edit Tool I need to bring back...), (2) Current LLMs are anal about verifying the most trivial change, even without prompting, even if it's impossible for them to verify it because they're blind so they start measuring pixel data in Python... Both of which eat up Speed and Cost, taking the work even further from Realtime/Interactive to Tedious/Sad.