For Anthropic, it’s highly likely that the watermark is a SynthID type mark similar to the one that Sean is talking about (I actually ran the analysis here https://johnjwang.com/post/2026/08/12/how-claude-watermarkin...). When we get confirmation of whether all models actually are watermarked, I think we’ll be even more confident.

Of course it’s always possible that Anthropic has come up with a proprietary scheme, but I think it’s definitely harder to implement.

I think the game will be a cat and mouse game similar to LinkedIn and other websites trying to block scrapers: each iteration makes it harder for someone to figure out the watermarking scheme, but likely not impossible

Short version: it's likely a SynthID style statistical watermarking scheme that Anthropic is using. There's likely no hidden unicode and no large stable green/red scheme.

Longer version: I found some really statistically significant outcomes when using Gloaguen et al.’s (https://www.sri.inf.ethz.ch/blog/probingsynthid) detection algorithm for SynthID, though unfortunately it seems like the models might be pre-biased to pass that test already. The difficult thing is that it's hard to conclusively know which models definitely already have watermarking enabled and if there are any models that don't have watermarking, which means that being able to get a highly positive statistical result is much harder.

You can take a look at the full writeup, but many of the clues from Anthropic's blog post, plus negative results on many of the simpler tests, point to them using such a scheme. Of course, it's possible that they came up with a novel new scheme/algorithm, but amongst the available literature, the SynthID family of models is probably the best bet.

Comments URL: https://news.ycombinator.com/item?id=49276728

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49212587

Points: 11

# Comments: 0

Coding agents worked well for individual engineers, but the surrounding workflow was a bit of a mess. We generally found that many engineers had different MCP connections and context for their agents, personal automations running that other people couldn’t access, and very little introspection for what a human’s input into the coding agent looked like.

So we built an internal system that converted coding agents into shared team infrastructure.

The system runs Codex, Claude Code, OpenCode, and other agent harnesses in gVisor sandboxes. You can mix and match coding agents to tune your cost and intelligence tradeoff (for example, our team has started to use GLM 5.2 for automation tasks and a combination of Codex/Claude Code for manual tasks). It connects to a bunch of tools like GitHub, Linear, Sentry, Slack, PagerDuty and makes previews easy to generate.

We were inspired by internal systems like Stripe Minions and Ramp Inspect, but wanted an open version other teams could inspect, run, and adapt so we made it MIT-licensed and self-hostable.

Hope you like it!

Website: https://143.dev

Github: https://github.com/assembledhq/143

Comments URL: https://news.ycombinator.com/item?id=48736251

Points: 13

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=48349039

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48042789

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47549649

Points: 109

# Comments: 168

My team and I have been extremely lucky in hiring Joe, our excellent head of engineering, and an extremely strong set of engineering managers. Not to mention incredibly strong product and user experience management.

I think it’s pretty obvious that my approach wouldn’t work if I didn’t have this bench of talented managers, but because I do it affords me the luxury to spend time doing things that I love and which are also valuable to the company.

In general, I wrote this article because I think that the classical approach to engineering management isn’t the only path you need to take, and a lot depends on the team you work with (thankfully we have a team that complements each other really well).

Do I love to code? For sure. Is it something I do on the weekends? Generally yes because it’s something incredibly fun for me, and it gives me a lot of energy. Now, is it an expectation I have of my team? No, it’s not because I want a sustainable pace for the team and I recognize not everyone has the same relationship with work or coding as I do.

And on the “circumventing process” bit — what I shared wasn’t an example of blowing past legal/security review recklessly. It was a case where I, as someone with full context, could quickly build something safe and unblock a customer, going through our normal code review and deploy process. I don’t expect anyone (myself included), to have any exceptions to this.

Comments URL: https://news.ycombinator.com/item?id=45695979

Points: 308

# Comments: 282

Comments URL: https://news.ycombinator.com/item?id=45640827

Points: 9

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=45618254

Points: 28

# Comments: 6

Comments URL: https://news.ycombinator.com/item?id=44830838

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44815125

Points: 59

# Comments: 77

Comments URL: https://news.ycombinator.com/item?id=44269623

Points: 24

# Comments: 3

All the same principles apply as before: smart, driven, high ownership engineers make a huge difference to a company's success, and I find that the trend is even stronger now than before because of all the tools that these early career engineers have access to. Many of the folks we've hired have been able to spin up on our codebase much faster than in the past.

We're mainly helping them develop taste for what good code / good practices look like.