CharlieDigital

    > however much you distrust the media, it's not enough...

The YT video is not from a Tesla hater, but shows real, structural failures with the CT and the engineering (using cast aluminum instead of steel).

I don't trust any singular source, but looking at evidence in aggregate across many sources, there are clear problems with the CT from material selection to parts engineering to overall capability vs what was sold.

Most cars are and have been roughly the same shape for decades now. Rare innovations here and there, but largely still hold the same basic shapes across manufacturers and markets.

Read the recall link:

    > If the cracks persist and worsen, it may result in the wheel detaching entirely.
    > 
    > ...engineers determined that continued use under strain could eventually lead to separation of the wheel stud from the hub.

Watch the YT video.

Telsa made bad engineering choices on this vehicle. There's no point defending it.

Is it because your world view fractures with a fallible Musk?

I have two girls; never mentioned Elon, Tesla, nor CT to them.

Both think it looks ugly.

No need to influence most people, IMO. Vehicles are shaped the way they are because the designs have broad appeal in general (familiarity? proportions? trends?). Most of us would find a normal, well-tailored black suit to be appealing and be baffled by avant garde, high fasion men's clothing.

Why should anyone be surprised that a completely novel design isn't appealing to most?

What's clear to me: leetcode and quality code are not the same skillset.

    > If they read their own link, that never happened?

https://www.foxbusiness.com/lifestyle/tesla-recalls-cybertru...

    > The issue stems from the brake rotors, and the report says more severe road conditions "may strain" the stud holes in the wheel rotor, causing cracks to form. If the cracks persist and worsen, it may result in the wheel detaching entirely.

https://autos.yahoo.com/ev-and-future-tech/articles/tesla-cy...

    > In a recent off-road escapade at the King of the Hammers event in Johnson Valley, California, a Tesla Cybertruck experienced a mechanical failure resulting in one of its wheels snapping off. The incident, captured over the weekend, has raised eyebrows about the durability of Tesla's much-touted electric truck.

I can't remember the specific video, but I recall seeing someone breakdown some of the poor materials/engineering choices for "truck" use cases and of the mass of the CT.

Found: https://www.youtube.com/watch?v=_scBKKHi7WQ

Never even heard of this until today.

I think they are doing a terrible job with their product packaging. Like others, I also gave up with Google models long ago due to difficulty in accessing and low limits.

My gut is that this is reflective of their fragmented internal product organization around AI.

Would disagree here given that Firebase is the only one of the three owned platform toolkits (Azure, AWS, GCP) that has a really complete first party emulator suite.

Sharing my perspective as a big time user of Firebase:

1. It is practically free for a lot of my projects. Yes, there are also other free platforms out there now, but because Firebase is largely an abstraction on GCP, I have more reach if I need to scale it or move it into a more capable backend that I have full control over (very natural progression from Firebase -> Cloud Run -> GKE Autopilot -> GKE). For a few use cases, I do pay (e.g. keep a warm Function for an auth flow).

2. Firebase auth is still really, really good. It is super easy to get SSO working with Firebase auth. End of the day, it is largely (entirely?) just an abstraction on top of Google OAuth API, but it is by far the easiest and most foolproof of the solutions on Azure, AWS. And again, for most use cases, it is entirely free.

3. A well-designed Firestore backend is for all intents and purposes free for side projects and can still scale without the need to overthink it. I have had a few projects that had big Reddit spikes and Firestore just swallows the volume like a champ (that would have swamped a small Pg instance). I have run several side projects, blogs, etc. for years purely on Firebase because Firestore's free tier is really, really generous and when you pass those limits, the pricing is still reasonable. Ridiculously generous.

4. Firestore gives you real-time websockets with no additional infra needed and again, practically free for most side projects. Cloudflare now has PartyKit which fills the same niche, but Firestore's real-time subscriptions are nice because of how integrated they are into the backing store. Amplify's AppSync (when I used it last) was janky AF; did not like it at all and did not like the fake relational abstraction over DynamoDB (dangerous at scale). Azure SignalR, Web PubSub, and Fluid Relay are not free or they are not usable at the free tier beyond initial sandboxing.

5. It is easy to operate. If you want to run directly on a hyperscaler cloud (AWS, Google, Azure), Firebase is the best tooling. Azure doesn't really have an equivalent. AWS killed off their Copilot CLI[0] which I felt like was approaching the utility of Firebase and not a fan of Amplify (which seems to have changed direction recently). I was a fanboy of CosmosDB, but Microsoft refused to ship a working ARM64 emulator version for YEARS[1] which made it unusable on Mac. I am comfortable operating at any layer of any of AWS, Azure, GCP, but most of the time I only want to when I need to. So Firebase lets me ship something fast, but drop down into the underlying cloud infra when I need to.

6. Until recently, the other platforms did not have great options for emulation. I think AI has changed that and now we are seeing more proliferation of platform emulators. LocalStack, for example, had already locked some of their emulation behind paid licenses. Firebase emulators were pretty complete in terms of what was needed to build and ship an app end to end. The OAuth emulator is still really, really nice.

[0] https://aws.github.io/copilot-cli/ : literally their best infrastructure tooling and they killed it....................

[1] https://github.com/Azure/azure-cosmos-db-emulator-docker/iss...

Haven't read the details, but is this because of prompt injection when CC reads the site?

C# `out` is kinda nice because it can be `var`d and used directly.

I use a mix of GPT/Codex, Claude, and DeepSeek for my workload (in that order of volume).

Each has their own characteristics and honestly you just get used to prompting each a bit differently.

Even better is to use an orchestrator (I switched to Paseo a few weeks back) with an agent "team" (in Paseo, these are just profiles that the orchestrator initiates). Then the orchestrator writes super detailed prompts to each sub-agent on your behalf and I find I get better results this way with less effort. I would describe it as "more autonomy".

This should not be marked as "resolved". "Mitigated" until some percentage of customers ack the email notification at least (track clicks, get teams on Zoom call, etc.).

Not quite; the point of the engineers is to build the machinery to make this "safe". Establishing key architectural decisions, rails, and safeguards; things that a product team isn't going to be able to resolve on their own.

What it does speak to me is that only the most senior engineers still have a significant role.

    > Five small models solve a programming problem together: a planner, two ideators, a solver and a manager, plus a repair worker. Each starts from a fresh context and talks only through files on disk. 

This seems to tie back to the paper Adaptive Auto-Harness: Sustained Self-Improvement for Agentic System Deployment on Open-Ended Task Streams[0].

In the Emory paper:

    > We reduce this loss by expanding Φ with a stateful four-phase multi-agent evolver, temporal-reveal feedback, and cross-cycle memory. This design targets the unbounded-stream failure where a single-agent evolver must absorb growing trajectories, delayed labels, and prior research within one context window

TL;DR: the solution approach uses "multi-agent evolution" and "multi-agent with distinct roles and objectives" for "solve-time adaptation" and improves performance with streams of heterogeneous tasks. The Emory team overall has congruent findings:

    > The experiments further show that...multi-agent evolution constructs benchmark-specific capabilities

Intuitively, the reason this works seems to be simple: multiple agents results in context spread to each agent by specific role. Each agent role only outputs the final, relevant result and not the noisy thinking tokens, tool calls, etc. so subsequent agents get smaller, more focused context, auto-adapting to each new task with prompt refinement at each step as the solution approach emerges.

4 weeks back I switched over to Paseo and started using the agent profiles on a whim and have observed similar outcomes and behavior (seat of the pants): the win in my use case is that it feels like I can get higher autonomy without sacrificing quality (less input from me required to get quality output). The Emory paper and this team-solve seem to reinforce that role-based, multi-agent setups can improve solve performance.

For the curious, I shared a bit of my setup in a blog post[1]

[0] https://arxiv.org/pdf/2606.01770

[1] https://chrlschn.dev/blog/2026/10/larping-with-agents-and-wh...

Paseo is Apache 2.0 (vs T3 MIT). Haven't tried T3 and can't find docs for it to get more insight without installing.

Re: changes: Paseo's plugin system is very, very good. Some limitations since not all of the internals are accessible via plugin system, but allows building very custom UIs. So this may be a point of delta with T3. But I have some coworkers that have gone absolutely HAM with the plugins and built entirely custom workspaces (wild).

For me, what I have found most useful about Paseo is the multi-platform, multi-agent setup because this has given my agent teams much, much more autonomy that I feel like I can trust (after weeks of watching them work). The agent profile system looks too simple at first blush, but actually, that simplicity and semi-structured dynamic nature of the sub-agents is what makes it powerful.

Might try T3 for a week and see; thanks for sharing!

EDIT: T3 has no docs site yet, but sifting through docs, this was interesting: https://github.com/pingdotgg/t3code/blob/main/docs/user/remo...

    > Each T3 Connect account can link up to 3 machines. Phones and browsers do not count. A paid T3 Chat plan raises the limit to 10 machines with Pro, or 100 with Premier.

Paseo has no paid features; only if you want to use the hosted hub gateway (entry point for Slack, Discord, GH). T3 Connect looks to be the equivalent of the Paseo Relay: https://paseo.sh/docs/connectivity#paseo-relay which has no limits (Herdr's ipml is better, though; Paseo currently cannot manage individual connections which would make it SICK for team collab. See: https://github.com/getpaseo/paseo/discussions/6896)

    > For sure it's annoying building up so much knowledge about a single product that changes every 6m anyway, but what can you do.

Use GPT :P

I use Paseo which can use both CC and Codex (and Pi, OpenCode, etc) and spread ownership of roles around. I find I get more autonomy from a team this way.

More detailed write up here: https://chrlschn.dev/blog/2026/10/larping-with-agents-and-wh...

The seniors shouldn't be building the product; the product team can build the product directly. There is no reason for a product manager to ask a senior engineer to fix the spacing or update the tab sequence for some workflow. The harness should be sufficient for them to do at least that. Get it right and a product manager should be able to build whole features if enough of the heuristics and system level constraints are in place.

I genuinely prefer OpenAI models for coding and building in general. My observation: GPT models are generally better at following the system prompt, tool use, and skill use.

I use Paseo and there is a noticeable difference when GPT-6.1 Sol is driving the orchestrator vs Opus/Sonnet 5.5 driving the orchestrator. Anthropic models ignore the shared system prompt to use the Paseo tools for sub-agents and prefer to use its own native sub-agents. It ignores the skills mentioned in the system prompt, but will use them if I explicitly tell it to in a user prompt or I extra emphasize the instruction in an XML fenced block in the system prompt or CLAUDE.md like <BOOTSTRAP_MUST_EXECUTE_AT_START>

Sometimes, I feel like I have to explicitly prompt Anthropic models to behave the way I want it to (even with system prompts in place with the EXACT instruction). Sometimes it even feels like it's disregarding CLAUDE.md. To me, this makes me feel like it is the less compliant of the two because I constantly have to steer it manually. Anthropic models also feels like they prefer to go lone-wolf. I want my orchestrator to use the other subs (configured with different platforms and models) to evaluate a design; Opus really wants to lone-wolf and solo everything.

That said, I prefer Anthropic models generally only when the task is more open ended and exploratory. The Anthropic models' "mind of their own" benefits here; GPT models tend to be too agreeable; and too eager to agree with any change in direction. But for actual coding once a direction/plan is in place, I would much rather delegate it to GPT (more likely to draw on the harness for context, skills, instructions, and tools -> more consistency).

Anthropic's 1m context window default and shorter cache TTL are also not great in agentic flows where an agent could become idle and then re-activated. Burns tokens very quickly. I have it tuned down to 300k across all models (recommend doing this for multi-agent coding).

The job of the best devs is to build the system ("the harness") that let's anyone build near their level of competency by unloading their heuristics into the harness. That is what the most senior, most talented devs on the team need to be doing so that the baseline gets lifted across the board.

A lot of accountants are old school and I'd guess that most folks outside of tech are not nearly as heavily on the AI train.

Additionally, I think the industry and individual practices are probably still figuring out contracts, accountability, and legality. Will their insurance policies cover mistakes made by an AI?

I'd also guess that its one thing for you to feed your financial documents to Claude; would you feel as comfortable if your accountant were feeding it to an unknown model of their choosing? I'm not so sure I'd be.

It can drive 3 displays using a DisplayLink dock/adapter.

Terrible idea because these two artifacts (ticket and code) have different lifecycles, different participants, different rates of churn, different needs from a reporting perspective, and different rules/workflows.

Tickets being external to source decouples the systems, parties, and lifecycles.

Difference is in the eventing model and complexity of state management in React's hooks based model vs vanilla's. WC is aligned with how JS callbacks naturally work. React is the only framework that points the callback to the component function.

My experience with Next.js is that because it mixes multiple paradigms, it makes using any single one of them more complicated and error prone.

Not just as the dev delivering the solution, but also library and package authors.

Ran into lots of issues around Next 12, Next 13 was very buggy, moved to Astro and never looked back.

Specifically Brotli2Shell

Feels like the goal was sensationalism.

I think also heavily depends on what you're doing.

If you're in a stable codebase with lots of best practices, patterns, controls (linters, analyzers, etc.), examples already established, then any model will do ~the same plus/minus since there's not much novelty.

If you're building ground up, entirely novel, no reference, I think results will vary with lower capability models.

For me, I do a mix, leaving implementation to Haiku/Luna/DeepSeek and research/feedback/critique to Opus/Sol/Astra/Fable

They've already established and accepted that level of trust with Microsoft and deemed it acceptable. In this particular case of Copilot vs OpenAI vs Anthropic, the question is whether OpenAI or Anthropic are higher trust than Microsoft when it comes to AI, data handling/retention, etc.

That's not how trust works in this context; the trust is in the handling of that data. It should be a given that if you're using a government machine, it's going to be under strict controls in the first place.