So? Cambridge analytica did the same. Nobody seemed to care much in the US

Cambridge Analytica isn't funded by my taxes and can't put me in jail

Or have me shot.

It'll be interesting to see where Zuck's loyalty lies if the Pentagon asks him to do so...

> Yes it's closed source but since all your files are markdown there is no lock-in risk

Not true. The lock-in risk is the flow you get used to with Obsidian. If Obsidian disappears, I'm left with a bunch of MD files... so that's just like my file system, and if I needed just a file system to begin with, I wouldn't use Obsidian

People who care and don't want Obsidian to disappear should support them, not destroy them. They are providing fair price product.

This is an example of why I don't think we're getting anywhere near an age of abundance with AI: we're using the power we've gained in a reductive way.

However, Obsidian isn't a saas, it can't just disappear. As long as you have the installer you are fine.

> The icons were overlapping with the search box. Clearly a product in decline

Isn't that an exaggeration? Linkedin search works fine for me. I dislike all the other social media crap of linkedin, but I have found all my jobs in the last 16 years via linkedin.

I'm working at a big tech company (not faang). I use agents (claude/codex) in 3 ways:

1. mainly for discovery and research. I clone all the repos I need and then I talk with the agent: "I need to work on service A which has dependencies on service B, C, D and E. How can I accomplish X? Oh ok it seems, B can offer that but only when Z happens, after that I should rely on C. Cool. And now we probably need to extend E. Umm, ok, but I think E's team won't like that. Hold on, I'll reach out to them. Give me a succinct paragraph explaining what we need from them. Alright I'm back, so we have green light but only if we implement it like H. So, give me a plan"

2. Implement the plan. So the agent spits out code that I need to babysit (e.g., perhaps the class is not in the best package, or perhaps we are adding too many e2e tests when unit tests could be enough, etc.)

3. Answer product questions like: "Why is button K disabled in this screenshot? What are the potential causes? Afaik, I have the permissions A, B and C, and I have enough Z, so why is still disabled?", "How does the flow for endpoint 'api/a/b/c/ work? Where are the entry points? Dependant services? Tables touched?"

I could live without the agent generating the code, but not anymore without their help for discovery and research. I dislike using agents for coding (I feel the same as you), but not for research (I actually use them as a sort of improved "google for everything")

yeah, that's a great way to use AI as an assistant to understand complex projects. I was using AI in a similar fashion to you before, but then the management started to push for more features and put pressure on the team.

I pushed back really hard on this and gave them the arguments that

1. To Meet their expectation, we had to let AI compose code in a complex system (Tokenmaxing) 2. They don't have the engineering background to propose policy like that because in their mind, AI is supposed to supercharge developers

Over 50 npm dependencies (dev and non-dev). Is this really how things are developed in 2026? After all what's happening (cyber security), is any developer out there running this kind of software just like that in their main machines without any concerns?

It is if someone forgot to prompt their harness "don't pull in unnecessary dependencies".

Problem with Python and other non-strict typed languages is that if you let an LLM to write some stuff, you cannot truly be confident that nothing has broken. Even if your tests all pass. The LLM could have broken some path that only gets run in production in a very specific case. At least with strongly-typed languages you get a compiler error. In big codebases is non-negotiable

Python has had type hinting for quite a while, and adding validation with mypy/pyright/ty as a step in CLAUDE.md (as well as having it as part of your CI pipeline) can emulate static type checking pretty well.

Agree.

I am using type hints in Python as much as possible for my hand-coding. And it catches a lot of bugs (especially during code refactoring) that I would not have noticed so easily.

> And it catches a lot of bugs (especially during code refactoring) that I would not have noticed so easily.

Can you give me an example of a recent experience with this? I've been working without type annotations for many, many years, and I keep finding that every time I find a bug I just don't feel like type annotations would have helped catch it, at least not to an extent that justifies the effort to put them in in the first place.

I'm not sure how many bugs type hinting in Python finds.

But it is another guardrail that you are giving AI. When you have the AI use ty (and it runs almost instantaneously) after every edit, you are stacking the odds in you favor. There's no reason not to do this.

May the tokens ever flow.

True, but in my experience teams don't make the whole codebase type hinted. There's always something that escapes.

Dynamically typed languages just add one more type of bug that can’t be caught at compile time. That’s not helpful, sure, but it’s one type of bug among many.

The issue you mention, execution paths not hit by test cases, is made worse by having more complicated code. Duck-typing can help reduce the number of paths.

Static vs dynamic… I don’t see an obvious winner here.

My take is that I can never be confident that anything an LLM produce will not be broken. Since I will have to check everything it produces anyways, why not write it in a human friendly language, i.e. python? C and rust may have better strictness, but the amount of boiler code to set up that system takes up a lot of mental space that could be better used to architect the problem at hand.

Perhaps we could do it in Python in the first pass for validation purpose. And then vibe rewrite it in Haskell.

so it just boils down to strictness even when we're talking LLMs?

I agree with you about fast failure being a nice feature , but I also think that if you're TDDing a bunch of stuff and it fails in some categorical way , well then the test suite was lazy.

> so it just boils down to strictness even when we're talking LLMs?

The article describes what I've been doing for the past few months - I did small python projects in the past because of the ecosystem: I couldn't possibly write a ton of the stuff required for the things I wanted to do, so I leaned into python because someone already wrote it for me. Quality of deps was mostly ok for the happy paths, but always a chore to patch the broken ones.

Nowadays I tell Claude what I want to build and I always ask it whether rust is a good choice for it. It'll pick up the right crates or choose whether it should DIY, do all the plumbing, nail all the logic, and in ~30m I'll have something very solid that would have taken me 3+ weeks of part-time evening coding in python. I think the article is right and rust is the closest to the "best language" we have for LLM coding at the moment: the strict typing and the tooling dramatically reduce the output space for LLMs, and 99% of errors have a clear, precise explanation that is actionable, and the compiler helps you a lot there too.

I think it also boils down to the fact that you cannot reliably and quickly answer "why is this arg None?" in languages like python without figuring out the call graph and evaluating possible states and inputs/outputs. Rust makes all that explicit and forces you handle it, which I feel dramatically cuts the time an LLM needs to spend figuring out why it's broken or what to do next. EDIT: The fact that you get memory safety on top of all this and it's handled by the compiler is yet another advantage for LLMs: the logic that gets written is simpler to reason about, because if you try to mutably access the same variable in two different places, the compiler will feed this back to the LLM at build time. In other languages that would be a "code smell" or would require static analysis.

Strictness is a quality for software and a chore for humans, and of course the stricter you are at representing your logic and your state machine, the less ways a program can break. LLMs writing in rust give you the strictness without the chore part, and it's a very good deal from my point of view.

If you are using TDD with any recent model and even local models (qwen3.5+), you alleviate most of the issues mentioned.

Note that:

Writing code, then tests

Is not equivalent to:

Writing tests, then code

This is why you should use Haskell.

Haskell is a good language for LLMs! Claude knows it really well, and the type system catches so many mistakes. Just make sure to tell it to model the domain in the type from the start.

Also, Haskell can be really performant and low level, while still keeping the benefits of typing. With the C foreign function interface you can really do anything in Haskell!

i have bad news

Lay it on. I love to collect other's anecdotes and see where they align (or disagree)