2,890 karma · joined June 7, 2012
This is a gripe I've had with AI tools for a while now. Though it's gotten somewhat better in time, but we don't really know what to expect from the tool in terms of quality. Ex. I'd expect a human engineer to probably not use a brand new assertion library for a new test when there are 200 tests using an existing one. But Claude has done this to me multiple times. So I have to add yet another item to the list, like you have, and tell it to look for testing conventions before writing. But, there is plenty we don't have to tell it, like what a function is or a test should probably cover the change in the diff. But we don't really have a list of what things are on each side so we're just left to sort of hunt and peck to build a viable solution.
I think this isn't being discussed enough in the SWE world. It wasn't too long ago that engineers on HN would describe a line of code as "not an asset but a liability". Now that code is "free" though, I'm seeing more excessively verbose PRs at work. I'm trying to call it out and rein it in a bit but until engineers on average believe there is inherent risk here, the behavior will continue.
>Freezing Russian reserves in 2022 introduced confiscation risk to assets previously considered risk-free
Is this actually new? Didn't we freeze Iranian assets back in 1979? Wouldn't be surprised if there were other examples.
This is the challenge I also face, it's not always obvious when a change I want will be properly understood by the LLM. Sometimes it one shots it, then others I go back and forth until I could have just done it myself. If we have to get super detailed in our descriptions, at what point are we just writing in some ad-hoc "programming language" that then transpiles to the actual program?
Not disagreeing that this is happening in the industry but it still feels like a missed opportunity to not hire juniors. Not only do you have the upcoming skill gap as you mention, but someone needs to instruct AI to do these menial/easy tasks. Perhaps it's only my opinion but I think it would be prudent to instead see this as just having junior engineers who can get more menial tasks done, instead of expecting to add it to the senior dev workflow at zero cost to output.
https://www.latimes.com/archives/blogs/company-town-blog/sto...
[1]: or so it seems, I tried to figure this out earlier in the year and the data is just lacking in order to make a perfect decision.
Wow that's a great deal MSFT made, not sure what it cost them. Better than say a stock dividend which would pay out of net income (if any), even better than a bond payment probably, this is straight off the top of revenue.