I feel like code review is already hard and under done the 'velocity' here is only going to make that worse.
I am also curious how this works when the new crop of junior devs do not have the experience enough to review code but are not getting the experience from writing it.
Agents can already do the review by themselves. I'd be surprised they review all of the code by hand. They probably can't mention it due to the regulatory of the field itself. But from what I have seen agentic review tools are already between 80th and 90th percentile. Out of randomly picked 10 engineers, it will provide more useful comments than most engineers.
the problem with LLM code review is that it's good at checking local consistency and minor bugs, but it generally can't tell you if you are solving the wrong problem or if your approach is a bad one for non-technical reasons.
This is an enormous drawback and makes LLM code review more akin to a linter at the moment.
I mean if the model can reason about making the changes on the large-scale repository then this implies it can also reason about the change somebody else did, no? I kinda agree and disagree with you at the same time, which is why I said most of the engineers but I believe we are heading towards the model being able to completely autonomously write and review its own changes.
There's a good chance that in the long run LLMs can become good at this, but this would require them e.g. being plugged into the meetings and so on that led to a particular feature request. To be a good software engineer, you need all the inputs that software engineers get.
If you read thoroughly through Stripe blog, you will see that they feed their model already with this or similar type of information. Being plugged into the meetings might just mean feed the model with the meeting minutes or let the model listen to the meeting and transcribe the meeting. It seems to me that both of them are possible even as of today.
Most pension funds aren't heavily invested in ETFs (or other mutual funds). They're usually large enough that it makes sense to invest directly in the underlying securities.
Everyone has a prediction about what will cause the next major financial panic. Personally I think it will be triggered by property and casualty insurers who have purchased a lot of bonds where the credit ratings don't accurately reflect the true default risk. But who knows, it could be something else.
> how do you crash an ETF? I'm talking about broad index funds. Not stuff like ARKK
Any ETF's share value can "crash" if there are not enough buyers to purchase shares when they are trading below NAV (net asset value). It's worth a quick google to see what "market makers" or "authorized participants" do, but the thing to keep in mind is: if the market is kind of exploding in some major ways (think 2008) an ETF might not have a lot of buyers, even if its market price is well below its net asset value.
But why would that happen? Let's say an ETF normally trades at 99% of it's NAV. Suddenly it "crashes" and only trades at 97.2% after some bad news. Bob in accounting embezzled millions. It's gone, Bob spent it all at the strip club. Wouldn't some investor decide to just net the approximately ~1.8% by increasing demand and buying it up? After all, Bob embezzled millions. Not the billions that larger ETFs control.
Unless you're proposing some weird industry wide boycott of Vanguard or something. In that case the only thing stock traders are going to accomplish is destruction of every publicly traded asset they hold as market confidence in retail traders slowly slips downwards.
> Wouldn't some investor decide to just net the approximately ~1.8% by increasing demand and buying it up?
When it comes to individual investors, sure, in a situation where everything is going crazy in the markets some will buy and some will be happy to sell, provided the exchange doesn't halt trading temporarily in response to an extreme drop in share prices. The problem comes when the large market makers who are meant to really be on the ball and buy large blocks of shares quickly are suddenly worried about their own survival, or at least that's the way I remember a few of the chaotic days of 2008.
I knew a few people who made money buying bond ETFs at a discount to NAV.
I have no idea how one would crash an ETF but I do wonder if someone could manipulate an index. I.e by somehow suggesting a larger fraction of free floating stock so that the index weights the stock higher than its actual share. That should create increased demand for that particular stock (fund companies buy it more) and thus raise its value over what the market would assign normally.
Index crashes have happened many times in the 20th and 21st centuries. The fact that index ETFs didn't exist for most of that period isn't relevant. If they had existed they would've crashed because they follow indices.
The point is that the ETF tracks its index, so what does it even mean to say ETF crash? Isn't that just the tracked stocks crashing? The ETF has little to do with it. But if there is some other risk that's warrants the ETF label, that's very very interesting and should be discussed! It would be little known or novel ETF mechanics.
> so what does it even mean to say ETF crash ? Isn't that just the tracked stocks crashing?
Yes. I've learned to differentiate between the words people use and what they actually mean, rather than being literal.
Since index ETFs make up a large portion of people's investments they fear the value of those ETFs tanking. Obviously this is due to the underlying stocks' prices dropping This has happened many times in the past, most (in)famously in 1929.
Well that's the crux of it, isn't it? How do you know what they really mean, if not through the words? You have to impose a mental model on the speaker, which we of course do anyways.
Saying ETF crash specifically sounds like there is an idea there, and lots of people talk about thinking that ETFs specifically have problems that owning stocks directly would not have, so in my mind the model is that the speaker has an idea about how ETFs cause the crash through hidden risk. And since hidden risk is behind most crashes, it's definitely an interesting direction to ask about.
If you own an ETF and the underlying assets crash the ETF value has gone down. Additional failure modes exist due to the mechanics of the ETF, but from context we can tell the original comment was about risks to the large amount of money invested in ETFs
A US wealth/unrealized gains tax might trigger it, because it would likely create a cascade of forced selling, with the proceeds of sales getting burned as tax revenue for entitlement programs or debt payments rather than reinvested.
I don't think that would happen for the same reason that there are income taxes and yet the government doesn't have every last dollar. Sovereign wealth funds sell assets too.
If you think sovereign wealth funds are communism, someone should tell Alaska.
I invite you to watch Mike Green videos. In short, the current market rely on inflow of money to substain itself. P/E ratio can't increase forever. There will be a tipping point and if most of the money is invested based on an algorithm, it can unravel rapidly.
The modern influencer landscape was such a boon for corporations.
For less than the cost of 1 graphics card you can get enough people going that the rest of them will hop on board for free just to try and ride the wave.
Add a little LLM generated comments that might not throw the product in your face but make sure it is always part of the conversation so someone else can do it for you for free and you are off to the races.
Even if it was a default there is so many services reaching out the non-technical user would get assaulted with requests from services which they have no idea about. Eventually people will just click ok with out reading anything which puts you back at square one with annoying friction.
I like the idea of grpc because I wanted the contract but I tried it on a small service and I think I would avoid it in the future. Too many rough edges and features I didnt really need. I was using it in Rust and python mainly (maybe it is better in Go?) but it had a whole bunch of google stuff in there I didnt need.
- Configuring the python client with a json string that did not seem to have a documented schema
- Error types that were overly general in some ways and overly specific in other ways
- HAProxy couldn't easily health check the service
There were a few others that I cant remember because it was ~5 years ago. I liked the idea of the contract and protobuf seemed easy to write but had no need for client side dns load balancing and the like and was not working in GoLang.
I think connect-rpc[0] strikes a good balance between normal http apis, and gRPC. It allows protobuf as json. So you could think of it as an opinionated http api spec. A health check would be just a call to an url /something.v1.MyService/MyMethod -d { "input": "something }.
it works really well, and the tooling is pretty good, though it isn't that widely supported yet. Rust for one doesn't have an implementation. But I've been using it at work, and we basically haven't had any issues with it (go and typescript).
But the good thing is that it can interoperate with normal grpc servers, etc. But that of course locks it into using the protobuf wireformat, which is part of the trouble ;)
He probably means when I took VC funding in 2019 and started to rip apart the framework to try build a platform and business. The 2-3 years after were very chaotic.
My goal was never to serve the community but instead leverage it to build a business. Ultimately that failed. The truth is it's very difficult to sustain open source. Go-micro was never the end goal. It was always a stepping stone to a platform e.g microservices PaaS. A lot of hard lessons learned along the way.
Now with Copilot and AI I'm able to go back and fix a lot of issues but nothing will fix trust with a community or the passage of time. People move on. It served a certain purpose at certain time.
Note: The company behind connect-rpc raised $100m but for more of a build system around protobuf as opposed to the rpc framework but this was my thinking as well. The ability to raise $10-20m would create the space to build the platform off the back of the success of the framework.
Obligatory "this is why I love HN" but even for that standard, this is is an incredibly open account, thank you for the insight and sorry it hasn't seemed to pan out quite how you hoped. Still sounds like you got your bag, built something cool, and have your "micro" share of Internet legacy, so not too bad eh?
Using connectrpc was a pretty refreshing experience for me. Implementing a client for the HTTP stuff at least is pretty easy!
I was able to implement a basic runner for forgejo using the protobuf spec for the runner + libcurl within a few days.
I've only enjoyed using Protobuf + gRPC after we've started using https://buf.build. Before that it was always a pain with Makefiles building obscure commands, then developers having different versions of the Protobuf compiler installed and all kinds of paper cuts like that.
Now it's just "buf generate", every developer has the exact same settings defined in the repo and on the frontend side we are just importing the generated Typescript client and have all the types instantly available there. Also nice to have a hosted documentation to link people to.
> - Configuring the python client with a json string that did not seem to have a documented schema
I'm far from an expert, yet I came to believe that what you've described is basically "code smell". And the smell probably comes from seemingly innocuous things like enum's.
And you wondered if the solution was using Go, but no, it isn't. I was actually Go at the time myself (this was a few years ago, and I used Twirp instead of Protobuf) - but I realised that RDBMS > "Server(Go)" layer had quirks, and then the "Server(Go)" > "API(JS)" had other quirks -- and so I realised that you may as well "splat" out every attribute/relationship. Because ultimately, that's the problem...
Eg: is it a null field, or undefined, or empty, or false, or [], or {}? ...
There has been an on-going meme around users using imessage getting messages from other imessage users which appear as one color and messages from android users(or anyone I think?) as another. So people know you are the android user in a group of apple users or whatever.
I did not think any one gave a shit outside of kids.
I have a group of adults in my social circle who won't migrate a group chat to anything other than iMessage so that I can participate. I'm genuinely angry at them for this and angry at Apple for its role in creating the situation.
Don't underestimate just how much money you can make off funneling visitors to ads at scale. It's basically Google's entire business model.
If OpenAI plays their cards right, they can definitely end up in a similar position. Yeah a lot of programmers would probably pony up for Claude, but every lazy high schooler in the world would gladly hear about Raid: Shadow Legends to have ChatGPT do their homework for them.
Don't get me wrong it's definitely sucks, but man is it ever a profitable way to suck.
This assumes that ads at google's or facebook's level would get them anywhere close to profitability. OpenAI's costs of doing business are only accelerating, all while burn rate continues to get worse. I have no doubt that selling ads will bring in a lot of revenue, but it'll be dwarfed by the numbers OpenAI needs to stop hemorrhaging cash every quarter. The great irony is that the more success OpenAI has in gaining users, the more money they lose at an ever-increasing rate. Lose on every sale, and make up for it in volume!
"LGTM..."
I feel like code review is already hard and under done the 'velocity' here is only going to make that worse.
I am also curious how this works when the new crop of junior devs do not have the experience enough to review code but are not getting the experience from writing it.
Time will tell I guess.
reply