> At work I only have access to calude using the GitHub copilot integration so this could be the cause of my problems.

You really need to at least try Claude Code directly instead of using CoPilot. My work gives us access to CoPilot, Claude Code, and Codex. CoPilot isn’t close to the other more agentic products.

Vs code copilot extension the harness is not great, but Opus 4.5 with Copilot CLI works quite well.

Do they manage context differently or have different system prompts? I would assume a lot of that would be the same between them. I think GH Copilots biggest shortcoming is that they are too token cheap. Aggressively managing context to the detriment of the results. Watching Claude read a 500 line file in 100 line chunks just makes me sad.

> At the end of the day, the best option is to use an attorney who would at least run the risk of professional consequences for submitting false claims.

What if folks signed their work with a private PGP key and published their public key? If you wanted to submit a DMCA request, simply sign a message to prove you’re the content owner. It seems like that could work.

How does that prove I am the original author? Can't I just download a work and sign it as my own?

Let’s consider a scenario where you’ve published a video with a public key, and you have a history of using that key for publishing your work. If someone else were to download that video, they wouldn’t be able to sign it because they lack the key. I believe the same principle applies to PDFs and ebooks.

They wouldn’t be able to sign it as me but they could sign it as themselves, taking credit.

My question is what mechanism proves the video is signed by the rightful owner?

For context, I work in Metro Detroit, where a lot of people have strong ties to the automotive industry. At one non-automotive company I worked for, an executive gave a talk about how we needed to operate more like a “software factory.” I didn’t personally find the message offensive. The intent was to emphasize predictability, quality, and fewer defects by borrowing ideas from manufacturing. These were areas the company needed to address and improve.

That said, the framing landed very poorly with many developers. Some had parents who worked on assembly lines and were pushed to go to college specifically so they would not have factory jobs. For them, the “software factory” metaphor felt dismissive and demoralizing. Morale took a hit, and we eventually saw a noticeable wave of resignations. Some engineers felt that the challenges of software engineering weren’t appreciated my management, and that they saw us a cogs on a line. There were factory jokes made for weeks and months following the all team meeting where this concept was first presented. It was a mess.

This experience was a good lesson for me in how much messaging and metaphors matter. Even when the underlying idea is reasonable, the framing can completely change how it is received. Big, high-stakes messages are worth testing with a small, trusted group first.

Thank you for sharing. As an engineering leader this is a nightmare scenario. There is so much invisible context that you need to have someone in community to have context

Nice job building this out as a solo project. I played around with the free version and it felt solid and professional to me.

Thanks!

I have a feeling that I am going to soon become an old curmudgeon who tells stories of the good old days of the Internet to their kids and grandkids.

I had never heard of CNBC TV 18, and thought this was a sketchy domain, but it turns out to be legitimate (https://en.wikipedia.org/wiki/CNBC_TV18).

Unfortunately it's a) a holiday for most news orgs and b) about an issue which will likely require a lawyer read for most news orgs before they pub.

Many people feel threatened by the rapid advancements in LLMs, fearing that their skills may become obsolete, and in turn act irrationally. To navigate this change effectively, we must keep open minds, keep adaptable, and embrace continuous learning.

I'm not threatened by LLMs taking my job as much as they are taking away my sanity. Every time I tell someone no and they come back to me with a "but copilot said.." it's followed by something entirely incorrect it makes me want to autodefenestrate.

I am happy “autodefenestrate” is the first new word I learned in 2026. Thank you.

Autodefenestrate - To eject or hurl oneself from a window, especially lethally

Many comments discussing LLMs involve emotions, sure. :) Including, obviously, comments in favour of LLMs.

But most discussion I see is vague and without specificity and without nuance.

Recognising the shortcomings of LLMs makes comments praising LLMs that much more believable; and recognising the benefits of LLMs makes comments criticising LLMs more believable.

I'd completely believe anyone who says they've found the LLM very helpful at greenfield frontend tasks, and I'd believe someone who found the LLM unable to carry out subtle refactors on an old codebase in a language that's not Python or JavaScript.

> in turn act irrationally

it isn't irrational to act in self-interest. If LLM threatens someone's livelihood, it matters not that it helps humanity overall one bit - they will oppose it. I don't blame them. But i also hope that they cannot succeed in opposing it.

It's irrational to genuinely hold false beliefs about capabilities of LLMs. But at this point I assume around half of the skeptics are emotionally motivated anyway.

As opposed to having skin in the game for llms and are blind to their flaws???

I'd assume that around half of the optimists are emotionally motivated this way.

everybody is emotionally motivated, you included

rapid advancements in what? hallucinations..? FOMO marketing? certainly nothing productive.

I’m a big fan of the idea of an Office of the CTO group reporting directly to the CTO that helps with prototyping greenfield projects and exploring innovative ideas. I believe a group like this would be beneficial for larger organizations, like the one I work in. There are numerous opportunities for market disruption, but it becomes increasingly challenging to make bold bets as the company expands. If I had the power to do so, I’d set this up at my company asap.

If that group is necessary then it's a damning indictment of the product/engineering culture. The CTO's job should be to fix the broken culture, not try to side-step it.

Hard disagree. Culture isn’t the problem, org structure is. You can call it an experiment or even a hack. Every team is already innovating within their scope, and splitting becomes easier as that scope grows.

What is too much is asking an Engineering Manager to start a completely independent product line that may go nowhere. It’s far more effective to rely on senior, staff+ engineers who don’t need management and have experience taking things from 0 to 1. They can build an MVP quick. Once we see real signals of PMF, we can then build a team around it (or drop it)

Not every company is a product/engineering company.

A CTO is a common title at medium and larger law firms, and an office of the CTO for that org sounds like a great idea.

You’re right but you’re in the wrong place to argue this. Bezos has a talk where he famously talks about instituting weblabs and A/B testing because he doesn’t want to be a decision bottleneck and wants low stakes experiments with little friction.

But HN now is full of people completely removed from any kind of entrepreneurial mindset, people who aren’t “hackers” even in the most generous sense. They will not agree.

Keyboard warriors is probably the best descriptor of HN demo now.

Nokia had exactly this kind of CTO office during the 2005 - 2012 years when they lost the entire smartphone market.

The CTO fiddled with greenfield projects that had no path to products while the house burned down.

The best that can be said about it is that inventions outside of the product helped beef up Nokia’s patent portfolio, which played a role in the company surviving the post-phone years and transforming into a pure network company. But they lost a trillion-dollar opportunity and shrunk into an average B2B enterprise.

well you say that, but blackberry did exactly what you're saying Nokia should have done and we see how much that helped. Truth is iPhone was so far ahead technologically, no other company had a chance. At least Nokia still exists today, which can't be said about majority of other mobile phone manufacturers of that era.

Yes, but it wasn't iPhone that ate their markets, it was Android. Nokia and Blackberry were both at the top because they had their own operating systems, and while they were losing the high end market to iPhone, they would've kept the middle and low end markets where the volume was.

Android changed all that, all of the sudden all their competitors got a good OS for free. Commoditize your complement, Google took their markets.

Shouldn't this live under the VP of Product?

That’s a good point. Perhaps where this group lives depends on your organization. Unfortunately, the innovative ideas aren’t necessarily coming from product where I work.

No, product shouldn't be the head of an engineering team.

So you're argueing "prototyping greenfield projects and exploring innovative ideas" is something that should come solely out of engineering with no Product input?

That's not what I'm saying. There needs to be a collaboration with product ofc, product shouldn't be the boss though.

Should engineers be pushing product forward?

Traditionally that was R&D and its own department.

Having a CTO pet group isn’t the best use of the CTOs time. If you want to have better architecture and explore greenfield projects, you need an organization that supports R&D through cross functional groups.

A CTO should NOT be doing greenfield projects. A CTO should be setting technical vision and strategy for the entire company.

Cloudflare has an org whose job it is to do this sort of stuff.

Happy New Year from Troy, Michigan. I spent much of 2025 recovering from microfracture knee surgery. I’m hopeful for better health in 2026.