Posted by javaeeeee 6 hours ago
async fn watch_item(&self, item_id: &str, user_id: &str) -> Result<()> async fn unwatch_item(&self, item_id: &str, user_id: &str) -> Result<()> async fn watched_items_for_user(&self, user_id: &str) -> Result<Vec<String>>
This shows the limitations of vibe coding. It takes someone with a long history of software development to prompt for something like this.
Even though the model is writing 100% of the code, still needed someone with a lot of programming knowledge to write the prompt.
Most of software development is looking at some process and then decomposing it recursively until you get to those molecules/atoms of the computing world. Coding them is trivial, and while you can gain a certain boost from the AI, after a while you no longer have to write that much code. It will turn into a balancing act where the introduction of a new concept has to be done carefully.
- the code is essentially good but all is in one file, you split it up, lines of code stay the same
- the code is essentially good but lacks some structure, for a function that does five things directly, you extract the functionality into five functions and call them from the original function, lines of code goes very slightly up
But once the code is actually bad - code duplication, bad abstractions, inefficient language use, ... - I would generally expect the lines of code to significantly drop. What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code? It is certainly possible but at moment I am having a hard time comming up with a good example.
IMX: the scenarios where people hold higher standards than what you describe :) (i.e. such that "the function does five things" is deemed "actually bad". Of course, that does depend on the refactoring not causing an unacceptable performance hit, which can happen depending on the environment.)
What I really want to get at is the distinction between leaving the actual code untouched and just moving it a bit around - to other functions, other classes, other files - and having to change the code - from deduplicating to completely rewritting it.
Taking a component and turning it from 7K lines to 3K lines and maintaining functionality obviously means there’s less complexity introduced, less to go wrong now, and less overhead to modify in the future.
Sure it can go the other way, the component needs to support something it might need, we need to adjust larger patterns, this function needs to be refactored into something more robust.
But lines of code is a pretty decent metric of success for “trimming down and cleaning up” style refactoring, to me at least. It’s not everything of course, but it’s definitely an indicator.
Total LOC is a garbage metric. Things like reducing line count in specific files or components is a big benefit, but those lines are often moved, not dropped.
Since LLMs are word generators, and have a propensity to generating words, they need to be shaped to understand simplest is best, more isn't more, and less isn't more always.
Trimming down and cleaning up could be formatting, standardization, commenting, or even some basic re-architecting that was overdue.
One of the biggest benefits of llms for refactoring I'm finding is reducing technical debt.
There’s further work to do to understand exactly what’s going on here.
In some projects, the code might not have much, or enough testing, or documentation/commenting.
Code is largely for others and the future if the creators of it want to move onto other projects.
Still a nice writeup and love how these meta analysises (presumeably) done via AI can now easily capture metrics that inform your workflow.
> Claude is unable to look at code, look at refactorings in general and work out which are suitable to apply: a human needs to actively guide it.
Claude is happy to produce a very large Rust file. But you need human guidance to make it smaller.
I am just sitting here waiting for Grady Booch to write "Architecture!"