to be fair, #2 exists because monorepos and submodules are somewhat antithetical concepts. A monorepo is supposed tobe the single source of truth for the codebase, while submodules are pointers to external repos with their own history. That alone will increase the source of churn for teams that are constantly merging.
> All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
I think the author downplays how much of that knowledge is used on knowing what to zoom in on, what to prompt, or what to look for.
It's telling how rhetoric and conjecture are now normalized in company and business culture. When we were at the peak of remote work, companies were reporting record high revenues.
The issue was a compromised build pipeline that shipped a poisoned package.
But PSA: If something is critical to the business and you’re using npm, pin your dependencies. I’ve had this debate with other devs throughout the years and they usually point to the lockfile as assurance, but version ranges with a ^ mean that when the lockfile gets updated, you can pull in newer versions you didn’t explicitly choose.
If what you're building can put your company out of business it's worth the hassle.
A few years ago, intentionally fingerprinting or tracking your users without disclosure was spyware and unethical. Alas, here we are.
Anyway, what they're calling "spectroscopy", is a combination of extension probing and doing residue detection (looking for what extensions might leave behind in the DOM).
An ad blocker is not necessarily equipped to help since the script is embedded with the application code. Since they're targetting Chrome, switching browsers will help with the probing but not the detection part and you'll still be fingerprinted.
The only way forward is for browser vendors to offer a real privacy or incognito mode where sites are sandboxed by default. When the default profile is identical across millions of users there won't be anything unique to fingerprint.
This would make more sense if email was 100% guaranteed to be delivered. Not sure if this angle was argued, but just like regular mail, just because something was claimed to be delivered is not enough to prove that it was, hence the existence (in the US) of certified mail and signature return receipts.
I hear you, a lot of engineers have been there. Things are changing though, roles are evolving and the org chart is starting to flatten.
A couple of things worth separating: strategic direction in most orgs is already handed down from the VP or exec level, the PM is usually executing on that mandate.
Now that coding agents exist, both the PM and the engineer end up prompting a coding agent. So, over time, the roles converge and product ownership just becomes part of building.
That sounds more like a project or engineering manager role. Work environments obviously vary, and sometimes roles are assumed to counter dysfunction. But the PM here is the product manager, which owns the product direction. The argument is that their role can now venture into building. My comment extends it further that they can actually become the builders, absorbed into engineering and design.
My hot take: the dedicated PM role is becoming optional. Engineers already understand feasibility and tradeoffs, and they often end up informing the PM anyway, which usually comes at the cost of meetings and slow decisions. With clear quarterly goals, engineering and design can own product together. They would shape scope, ship in increments, measure, and iterate. So the "product" function still exists, but its not a separate PM attached to it.
To be fair, they do explain their motivation. It's an in-browser RSS reader, so it's fetching the RSS feed directly without a proxy server. There's not much risk since the content is public and non-credentialed. The bigger risk is misconfiguring CORS and inadvertently exposing other paths with the wildcard.
The article frames the premise that "everything will be fine" around people with "regular jobs", which I assume means non knowledge work, but most of public concern is on cognitive tasks being automated.
It also argues that models have existed for years and we're yet to see significant job loss. That's true, but AI is only now crossing the threshold of being both capable and reliable enough to be automate common tasks.
It's better to prepare for the disruption than the sink or swim approach we're taking now in hopes that things will sort themselves out.
Nice. These are the kind of boundary pushing projects I like to see. It challenges assumptions of where application logic should live. The implications around cost, latency, and recovery are going to be interesting.
This brings some interesting situations to light. Who's ultimately responsible for an agent committing libel (written defamation)? What about slander (spoken defamation) via synthetic media? Doesn't seem like a good idea to just let agents post on the internet willy-nilly.
I really liked this post. It's concise and gets straight to the point. When it comes to presenting ideas, I think this is the best way to counter AI slop.
Nothing new here. This is why they eventually rolled back Chrome's initiative to automatically reject third-party cookies. Industry backlash was that the analytics of too many sites would break. Best thing to do is to switch to a privacy centric browser.
I landed on a similar vision last year. The more I thought about it, the moat felt fragile. GitHub or GitLab could build the same capabilities and become a natural extension of what teams already use. That said, it addresses a real problem, and the SDLC needs to evolve.
I'm not disagreeing with standards but instead of creating adapters, can't we prompt the agent to create its own version of a skill using its preferred guidelines? I don't think machines care about standards in the way that humans do. If we maintain pure knowledge in markdown, the agents can extract what they need on demand.
I think the premise is a little shaky since a good servant leader is already transparent. But there's some good takeaways. Leaders should inform their team of what's happening behind the scenes and allow them to understand why things are playing out the way they are. Allowing people to take on more responsibility, if they want it, is a healthy sign of an organization, but it shouldn't be imposed nor expected if they already have enough on their plates.
> I want the things I do today to have an upside for people in the future.
I think most would agree with this, but the way things work today don't support it. As of now, AI gains are privatized while the losses are socialized. Until that one-sided imbalance is addressed, LLM's "use" of open source is unbounded and nonreciprocal.
Attribution is a big part of the human experience. Your response frames it as ego driven, but it's also what motivates people to maintain code that is not usually compensated, it's also what builds reputation, trust, communities, and even careers.
Until that’s figured out, we can still share, but maybe in ways that are closer to one another, or under distribution models that reflect the reality we’re in rather than the one we used to have.