1. Compare the code against production data with MCP.
We use a read only platform called Metabase which reads one of the MySQL replicas. I tell the agent to fetch production data and make a static pass (it doesn't run the code) in which it compares shapes and inputs, and oh boy it has caught a few misnomers.
2. To debug production data and create graphs. It connects to datadog (where we store the logs), checks the history of the commits, and many times suggest fixes. These are for low-medium impact like validations that didn't need to go through, or a step check that it was missing
3. Creating tickets on the board (we use linear). Now PRs are more detailed and can be understood.
And for coding? I've been spending the last 4 weeks scrutinizing EVERY output and decision from frontier models, and pushed back in many decisions.
It won’t because universities, national labs and non profits are exempt from the fee.
Under the proposed rule, the additional fee would not apply to H-1B petitions that are not subject to the cap, such as petitions filed by certain nonprofit research organizations, governmental research organizations, and institutions of higher education.
https://www.uscis.gov/newsroom/news-releases/dhs-proposes-ad...
I do believe it’s going to push a lot of jobs offshore though. I have already seen it at my job.
That's an insufficiently granular question. How much of the talent in frontier labs has an H1B rather than an O visa? Out of the people who have an H1B, how many employers would be willing to eat the $100k fee because those employees are so valuable?
On the degree the software evolves and will be used.
The reason we've spent years discovering patterns, creating special syntaxes has been to tackle certain domain problems more efficiently and to have systems that can evolve through time.
The only constant is change.
Albeit LLMs chunk out code (and with great know how impressive output), the developer must have the know how to pass a certain threshold.
Writing in unknown languages may seem fine at first. But once you go to the edge, you'll be finding certain quirks, inefficiencies along the way that the LLM may work around it instead of removing it from root.
For example, I've been learning Effect.ts for some weeks now. I've used LLMs extensively, but before that there were a series of manual coding rounds first.
To understand composability, the nitty gritty, where things break, how, how the syntax is formed, and how could I structure some observability challenges I had around the library.
If I hadn't gone through that process, the code quality would be subpar. It wouldn't have been evident at first, but once the system would begin to evolve and adapt to feedback, things would be brittle, existing customers would be affected, and more.
I guess the decoder is more than the 208 bytes that this page uses..
But maybe you can misuse this and store a session ID / cookie in a favicon (give everyone a unique one) and survive some cookie cleanup and evade privacy restrictions?
Maybe you can still make it that the favicon looks like an image a little to not raise suspicion?
Favicons seem to be cached across private browsing sessions. Oh no
It doesn't matter because the duplicate is linked to the original, so most visitors coming from Google would still view the actual answer. It works like a soft HTTP 302 response.
1000%
I got legit Cloudflare Workers Anycast IPs that I was using for websockets blocked.
I also got blocked from using RustDesk.
It's been crazy. As this happens intermittently. I had to set up a tailscale exit node in one of my servers to circumvent this crap. I lost several days and called Vodafone (ISP) to understand what was going on.
Thanks for the heads up!
I'm using it self-hosted on a Hetzner VPS.
Apparently they also block certain ports. As soon as I route the traffic through Tailscale through the same VPS I can connect without issues (My phone was affected as well)
1. Compare the code against production data with MCP. We use a read only platform called Metabase which reads one of the MySQL replicas. I tell the agent to fetch production data and make a static pass (it doesn't run the code) in which it compares shapes and inputs, and oh boy it has caught a few misnomers.
2. To debug production data and create graphs. It connects to datadog (where we store the logs), checks the history of the commits, and many times suggest fixes. These are for low-medium impact like validations that didn't need to go through, or a step check that it was missing
3. Creating tickets on the board (we use linear). Now PRs are more detailed and can be understood.
And for coding? I've been spending the last 4 weeks scrutinizing EVERY output and decision from frontier models, and pushed back in many decisions.
reply