CharlieDigital

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.

    > Microsoft is shoving Copilot down everyones throat

Of the three, I would rank Microsoft as less risky with data handling. Even if the other two are better products, I can see how data control is an important consideration in government. Of course, best is if they operate a fully controlled platform; that may yet be their endpoint.

these aren't mutually exclusive.

they can capture even more human trajectories by also owning all the data on how people do things in software.

ZLinq exists: https://github.com/Cysharp/ZLinq

    > Zero allocation LINQ with LINQ to Span, LINQ to SIMD, and LINQ to Tree (FileSystem, JSON, GameObject, etc.) for all .NET platforms and Unity, Godot.

Async carries its own ExecutionContext that crosses threads.

Multi-threaded/parallel is a LOT easier now with the Task Parallel Library (TPL, https://learn.microsoft.com/en-us/dotnet/standard/parallel-p...) and System.Threading.Channels. Channels in particular are nice because it can fan out and then back in to one aggregator, removing the need for self managing synchronization primitives.

I usually default to channels first, TPL when I want threads.

Generators in the time of AI are pretty sick, though.

Let's make T# happen: take C#, trim away the legacy syntax from the Framework days, converge to TypeScript even more.

Why I qualified it "for backends".

C# sweet spot is really web APIs (and all variants thereof), IMO.

Eval it and see.

You might be surprised.

(But also, this is more or less what I do with Paseo profiles)

I really like TS as well, but what kills it for me is the fragmented tooling landscape and tendency to bad practices by undisciplined devs (lack of explicit types making things hard to track down). I also hate writing intermediate schemas (zod, valibot, etc.) to get runtime type safety (love Typia for this). Debugger is flaky based on setup as well. I like writing TS solo, but hate doing it in a team environment.

Yes, have done cross plat plan review. But why it works so well with Paseo is that it's automatic and multi-turn (agents kind of "discuss" (I say "kind of" because agents don't really discuss like you or I would with short, multi-turn speak-listen-pivot-repeat).

Work tokens are severely limited to the extent that if I used Sonnet 5.5 for implementation, I'd be out 2h into a session (Team 5x). +$400/mo. at API rates on OpenAI. So Haiku + Luna it is. There is no other way this is even usable for agentic dev at work. Works fine for people who multi-turn with a single agent.

Personal accounts I run the $17 Anthropic plan + $100 Codex Pro + DeepSeek. It's insane how much this stretches with this setup.

Maybe the crux here is how hands on you are with your sessions. As I've moved more hands off, I'm relying on other agents to take my place by embedding my heuristics into their config.

There's something about C# that just feels so right for me for backends (as long as you stick to the more modern conventions).

Good tooling, modern language features (C# 15 has the long awaited unions, closed hierarchies), great debugging experience, etc.

Try it. 3 weeks ago I was in the same boat. Single model, TUI. I only tried Paseo primarily to test multi-host orchestration (after giving up on Herdr) and not even multi-agent, multi-plat behavior.

Output quality, especially subjective bits, has improved relative to my attention needed. Autonomous decision making is much, much better for me adding one profile that specifically is instructed to focus on UI/UX, one for end user proxy, and one for MTS.

It costs you nothing to try except maybe 15 minutes of setup. Give it a solid, skeptical week. It's good even without the profiles, but way better with.

Try my profiles as a starting point: https://gist.github.com/CharlieDigital/1c496a2799862795f0c31...

All I can say is give it a try. We can debate hypotheticals all day, but it costs nothing to try and see.

The Paseo harness/orchestrator is doing something right. I switched from TUI after trying it as a candidate for a non-TUI user.

It's not the same behavior as Claude starting a Claude sub-agent.

    > The planner / overseer model ends up reading all the output of the coder model anyway

I mean, even that's fine because output tokens cost ~5x input tokens. So that's still a win if the agent that does the heavy code reading and writing produces output that may be read again by the lead (not my observation of how agents in Paseo interact and of course, correctable to degrees with shared system prompt).

Here's a snippet of a sample prompt downwards from the lead for a piece of code I'm working on:

    From agent: 3ff73f80-9713-458c-8271-d275f03609c6

    <role>
    You are the Principal Engineer on <snipped ... /> (.NET 11 / Vue MCP server; read CLAUDE.md in your working directory first). ...
    </role>

    <lead_role>
    I am the Director of Engineering. The System Architect and the DMTS reviewed this approach ...
    </lead_role>

    <sniped ... />

    <comms>
    Run all gating commands in the FOREGROUND. End your turn ONLY with the final report: pass/fail per success criterion (a)-(i) with evidence, the branch tip SHA and `git log --oneline origin/main..HEAD`, lines added/deleted, the exact 0factor image digest and version you pinned, every deviation from this brief and why, risks you saw,...
    </comms>

The agent is given explicit "comms" instructions upwards and I find that both agents in this exchange stick to the contract.

Paseo is open source (https://github.com/getpaseo/paseo, Apache 2.0) and not my project; not affiliated.

I have other products and I work for private equity (no affiliation with Paseo at all).

You've entirely missed the lede.

Nah; I can use my token budget across both providers this way, use tokens more sparingly with smaller models for heavy text in/out (why pay Opus prices to babysit a PR? run tests?), and you'd be surprised when the agents talk to each other and "role play" how much this improves things like the UX as well as technical design which are more subjective.

Distinguished Member of Technical Staff, for example, is asked to "expand the solution space" which I find has a strong effect on approaches considered (it doesn't know what was already considered on the main thread; only the domain and problem space).

This also helps with context growth since the sub-agents do the heavy lifting (e.g. search, read docs) and just provide the key bits back to the lead.

Like you, I was a single-model, single-TUI user up until three weeks ago when I picked up Paseo and it is the only tool that I've found that has significantly positively improved my throughput without sacrificing quality of product.

Is it "larping"? I ran an eval today on a contract ingest and extract agent I'm working on. Changing the <role> fragment of the prompt lifted the results by +7 points by simply changing the text to the effect of "You are a senior partner at a prestigious law firm that focuses on reading licensing contracts..." and some bits about the content the agent is reviewing + objective. No one would believe it without an eval.

Claude docs explicitly say to LARP[0]:

    > Give Claude a role
    > 
    > Setting a role in the system prompt focuses Claude's behavior and tone for your use case. Even a single sentence makes a difference

My conclusion: the agents like to LARP so I'm happy to LARP with them.

[0] https://platform.claude.com/docs/en/build-with-claude/prompt...

I use the frontier models only in plan mode; coding is held out to cheaper models.

I run Paseo as an orchestrator with agent profiles. "Distinguished Member of Technical Staff" -> Fable, plan mode. "End-User Customer Advocate" -> Astra, plan mode. A few others. Basically, these agents (with profile prompts) can only be "consulted" for input on design elements; it's OK if they produce a bit of verbosity here. This has worked fantastically for me, really awesome to see a self-constructed team own the work end-to-end.

A "Director of Engineering" (6.1 Sol or Opus 5.5) also in plan mode organizes the team for the task and then owns coordination and instruction. You can think of this in essence like a "model router".

Coding is handled by Haiku 5.5/GPT 6 Luna/DeepSeek v4.1 Flash. One "Principal Engineer" Sonnet 5.5 or 6.1 Sol for some tasks.

https://github.com/tzachbon/claude-model-router-hook no?

Lesson from 6 years working at various startups from ideation - series C: there is no such thing as a business idea. There are problems that people have and the way to start a business is to find and talk to those people with the problem and solve it for them. Then find more people like them.

Even better: don't solve it; propose to solve it and shop that proposal to see how many other people have that problem.

Sure, but OTEL has all of the right qualities for the majority of use cases here.

Standards based, many off-the-shelf providers, out-of-process + buffered by default, many standard processors for traces + spans, many tools for storing and querying.

OTEL is pretty widely supported and mostly "just works" at this stage of maturity. A failing/mis-configured OTEL endpoint/collector isn't going to stop you from getting work done in the same way that a failing proxy is. You'll drop some traces, but that's probably OK in most cases.

There is a place for proxies, but those places should share the same failure boundary mode. Meaning if the proxy fails, it should necessarily stop forward agent activity. Example: proxy injection of secrets instead of local acquisition.