HackerTrans
TopNewTrendsCommentsPastAskShowJobs

nr378

396 karmajoined 3 yıl önce

Submissions

Why Integrated Copilots Suck

deadneurons.substack.com
3 points·by nr378·3 ay önce·0 comments

Where AI Will and Won't Replace Us

deadneurons.substack.com
2 points·by nr378·3 ay önce·0 comments

Why the most valuable things you know are things you cannot say

deadneurons.substack.com
162 points·by nr378·3 ay önce·63 comments

Thermodynamics, Organisations and Governments

deadneurons.substack.com
2 points·by nr378·3 ay önce·0 comments

An Open Letter to Mr Zuckerberg

deadneurons.substack.com
3 points·by nr378·4 ay önce·0 comments

Redux for Enterprise Context

deadneurons.substack.com
2 points·by nr378·4 ay önce·0 comments

Agentic Context Management: Why the Model Should Manage Its Own Context

deadneurons.substack.com
7 points·by nr378·4 ay önce·0 comments

The Great Rotation from Bits to Atoms

deadneurons.substack.com
2 points·by nr378·4 ay önce·0 comments

Housing: The Greatest Policy Failure in the Western World

deadneurons.substack.com
4 points·by nr378·4 ay önce·0 comments

AI Is Not Going to Kill Software Engineering

deadneurons.substack.com
3 points·by nr378·4 ay önce·0 comments

Software Engineering Isn't Dead Yet

deadneurons.substack.com
1 points·by nr378·4 ay önce·0 comments

What a negative AI economic scenario could look like

deadneurons.substack.com
2 points·by nr378·5 ay önce·0 comments

Why the Intelligence Crisis Scenario Is Wrong

deadneurons.substack.com
4 points·by nr378·5 ay önce·0 comments

Four Things OpenClaw Got Right

deadneurons.substack.com
1 points·by nr378·5 ay önce·0 comments

Companies should ship CLIs, not MCPs

deadneurons.substack.com
4 points·by nr378·5 ay önce·0 comments

Forget MCP, Bash Is All You Need

deadneurons.substack.com
12 points·by nr378·5 ay önce·2 comments

You Are a Business with Only One Client

deadneurons.substack.com
2 points·by nr378·5 ay önce·0 comments

Category Theory, AI and Jobs

deadneurons.substack.com
3 points·by nr378·5 ay önce·0 comments

AI and the Death of the Billable Hour

deadneurons.substack.com
1 points·by nr378·5 ay önce·1 comments

Show HN: Model Tools Protocol (MTP) – Forget MCP, bash is all you need

github.com
9 points·by nr378·5 ay önce·3 comments

comments

nr378
·4 gün önce·discuss
> The frontier LLM labs run on a huge fixed cost and very low marginal cost.

> Imagine that you want to buy a few B300s to run GLM 5.2 and rent the service out to other people. How could this business be viable and sustainable in the first place?

My understanding is the frontier labs have huge fixed costs and relatively low marginal costs because they have to bear the cost of training the model/R&D, and then amortise that cost over their userbase.

By contrast, if I buy a few B300s and run GLM5.2 and rent the service out to other people, I can be profitable at a comparatively very small scale because I got the model for free.
nr378
·17 gün önce·discuss
Arguably Google is both (with GCP and Gemini).
nr378
·geçen ay·discuss
Claude Teams and Claude Enterprise are 2 distinct plans. Simon is right that Enterprise seats have no included usage (and so all usage is charged at API billing rates), whereas Teams seats do.
nr378
·4 ay önce·discuss
Yep I think you can reasonably argue that immutability + strong conventions are the most important dimensions (as opposed to FP vs. OOP, as much as I like FP and dislike OOP):

Immutable by convention + Strong conventions: 91.3% - Elixir 97.5%, Kotlin 90.5%, Racket 88.9%, C# 88.4%

Immutable by convention + Fragmented: 78.4% - Scala 78.4% (n=1)

Mutable + Strong conventions: 77.5% - Ruby 81.0%, Swift 78.5%, Julia 78.5%, Dart 78.0%, Go 71.7%

Mutable + Fragmented: 67.9% - Java 80.9%, R 75.8%, C++ 75.8%, Shell 72.9%, Python 65.3%, Perl 64.5%, TS 61.3%, JS 60.9%, PHP 53.8%

(my grouping is somewhat subjective)
nr378
·4 ay önce·discuss
The data doesn't well support the claim that FP is best. Elixir tops the table at 97.5%, but C# (88.4%) is OOP and scores almost identically to Racket (88.9%), and Ruby (81.0%) and Java (80.9%) both outscore Scala (78.4%), which is explicitly functional. If FP were the driver, Scala should beat those languages, but it doesn't.

It's tempting to argue that a more constrained language helps, but Rust (62.8%) vs Elixir (97.5%) is an interesting data point here. Both are highly constrained, but in different directions. Elixir's constraints narrow the solution space because you can't mutate, you can't use loops, and you must pattern match, so every constraint eliminates options and funnels you toward fewer valid solutions that the LLM has to search through. Rust adds another constraint that must independently be satisfied on top of solving the actual problem, where the borrow checker doesn't eliminate approaches but adds a second axis of correctness the LLM has to get right simultaneously.

Overall, it seems like languages with strong conventions and ecosystems that narrow the solution space beat languages where there's a thousand ways to do something. Elixir has one build tool, one formatter, one way to do things. C#, Kotlin, and Java have strong ceremony and convention that effectively narrow how you write a program. Meanwhile JS, Python, PHP, and Perl offer endless choices, fragmented ecosystems, and rapidly shifting idioms, and they cluster at the bottom of the table.
nr378
·4 ay önce·discuss
> 3. Storing it the way this article presents makes it usable for agents, but not humans. Whereas the point of knowledge graph, ontology, etc is to create the same layer for both humans and AI to interact with

If storing it this way makes it usable for agents, then why don't humans just use agents when they need to interact with it?
nr378
·4 ay önce·discuss
Dario has made a specific cohort argument here. His numbers (from various interviews) are: you train a model in 2023 for $100M, deploy it, and it earns $200M over its lifetime. Meanwhile you train the 2024 model for $1B, which goes on to earn $2B. Each vintage returns 2x on its training cost.

However, the GAAP P&L tells the opposite story. You book $200M revenue in the same year you spend $1B training the next model, so you report an $800M loss. Next year you book $2B against $10B in training spend, reporting an $8B loss. The business looks like it's dying when every individual model generation actually generates a healthy profit.

That's actually Dario's answer to your depreciation question. If each cohort earns back its training cost within its natural lifespan (however short that lifespan is), the depreciation schedule is already baked in. The model doesn't need to live forever, it just needs to return more than it cost before the next one replaces it. Whether that's actually happening at Anthropic is a different question, and one we can't answer without audited financials, but it's the claim Dario makes (and seems entirely reasonable from a distance).
nr378
·4 ay önce·discuss
Based on the docs and API surface, I think the filesystem abstraction is probably copy-on-mount backed by object storage.

I suspect it works as follows: when a task starts, filesystem contents sync down from S3/R2/GCS to a local directory, which gets bind-mounted into the container. The agent reads and writes normally - no FUSE, no network round-trips per file op. On task completion or explicit sync, changes flush back to object storage. The presigned URL support for upload/download is the giveaway that object storage is the source of truth.

This makes way more sense than FUSE for agent workloads. Agents do thousands of small reads (find, grep, git status) that would each be a network call with FUSE. With copy-on-mount it's all local disk speed after initial sync.

Cross-task sharing falls out naturally - two tasks mounting the same filesystem ID just means two containers syncing from the same S3 prefix. Probably last-write-wins rather than distributed locking, which is fine since agents rarely have concurrent writes to the same file.
nr378
·4 ay önce·discuss
Oh that's quite a nice idea - agentic context management (riffing on agentic memory management).

There's some challenges around the LLM having enough output tokens to easily specify what it wants its next input tokens to be, but "snips" should be able to be expressed concisely (i.e. the next input should include everything sent previously except the chunk that starts XXX and ends YYY). The upside is tighter context, the downside is it'll bust the prompt cache (perhaps the optimal trade-off is to batch the snips).
nr378
·4 ay önce·discuss
Nice work.

It strikes me there's more low hanging fruit to pluck re. context window management. Backtracking strikes me as another promising direction to avoid context bloat and compaction (i.e. when a model takes a few attempts to do the right thing, once it's done the right thing, prune the failed attempts out of the context).
nr378
·5 ay önce·discuss
Here's a concrete example of what composition looks like in practice.

Say your team has an internal `infractl` CLI for managing your deploy infrastructure. No LLM has ever seen it in training data. You add `--mtp-describe` (one function call with any of the SDKs), then open Claude Code and type:

  > !mtpcli
  > How do I use infractl?
The first line runs `mtpcli`, which prints instructions teaching the LLM the `--mtp-describe` convention: how to discover tools, how schemas map to CLI invocations, how to compose with pipes. The second line causes the LLM to run `infractl --mtp-describe`, get back the full schema, and understand a tool it has never seen in training data. Now you say:

  > Write a crontab entry that posts unhealthy pods to the #ops Slack channel every 5 minutes
And it composes your custom CLI with a third-party MCP server it's never touched before:

  */5 * * * * infractl pods list --cluster prod --unhealthy --json \
    | mtpcli wrap --url "https://slack-mcp.example.com/v1/mcp" \
        postMessage -- --channel "#ops" --text "$(jq -r '.[] | .name')"
Your tool, a Slack MCP server, and `jq`, in a pipeline the LLM wrote because it could discover every piece. That script can run in CI, or on a Raspberry Pi. No tokens burned, no inference round-trips. The composition primitives have been here for 50 years. Bash is all you need!
nr378
·5 ay önce·discuss
Looks like another Claude App/Cowork-type competitor with slightly different tradeoffs (Cowork just calls Claude Code in a VM, this just calls Codex CLI with OS sandboxing).

Here's the Codex tech stack in case anyone was interested like me.

Framework: Electron 40.0.0

Frontend:

- React 19.2.0

- Jotai (state management)

- TanStack React Form

- Vite (bundler)

- TypeScript

Backend/Main Process:

- Node.js

- better-sqlite3 (local database)

- node-pty (terminal emulation)

- Zod (validation)

- Immer (immutable state)

Build & Dev:

- pnpm (package manager)

- Electron Forge

- Vitest (testing)

- ESLint + Prettier

Native/macOS:

- Sparkle (auto-updates)

- Squirrel (installer)

- electron-liquid-glass (macOS vibrancy effects)

- Sentry (error tracking)
nr378
·6 ay önce·discuss
100 SWEs running Claude Code generating 400mn tokens/mo = 400mn * $25/mn = $10,000/mo of revenue for Anthropic

10 SWEs running Claude Code generating 400mn tokens/mo = 400mn * $25/mn = $10,000/mo of revenue for Anthropic

If AI can make 10 engineers a productive as 100, then AI companies bank at least the same revenue.
nr378
·6 ay önce·discuss
> The simple evidence for this is that everyone who has invested the same resources in AI has produced roughly the same result.

I think this conflates together a lot of different types of AI investment - the application layer vs the model layer vs the cloud layer vs the chip layer.

It's entirely possible that it's hard to generate an economic profit at the model layer, but that doesn't mean that there can't be great returns from the other layers (and a lot of VC money is focused on the application layer).
nr378
·6 ay önce·discuss
> In python, ..., calling shell commands or other OS processes requires fiddling with the subprocess module, writing ad-hoc streaming loops, etc - don't even start with piping several commands together.

You inspired me to throw something simpler together - https://pypi.org/project/shell-pilot/
nr378
·8 ay önce·discuss
I suspect that the asymptotic price of consumer facing LLMs will be 0, much like Search - although just like Search, monetisation potential from ads will be high (perhaps even higher given the ability to truly integrate ads into the result itself using LLMs).

It potentially looks like Google and OpenAI will take this new market.
nr378
·8 ay önce·discuss
You can hide fields in Python with a little bit of gymnastics:

  class EncapsulatedCounter:
      def __init__(self, initial_value):
          _count = initial_value

          def increment():
              nonlocal _count
              _count += 1
              return _count

          self.increment = increment


  counter = EncapsulatedCounter(100)
  new_value = counter.increment()
  print(f"New value is: {new_value}")
nr378
·8 ay önce·discuss
The "bubble" will burst if it turns out that the demand for OpenAI/Anthropic's services is primarily driven by investment-dollars (i.e. VC money) rather than revenue-dollars.

If OpenAI/Anthropic's customers are themselves generating real revenue with reasonable margins, then it's not a bubble at all.
nr378
·8 ay önce·discuss
> Today, we’re pleased to announce a new round of financing: our Series D of $2.3B at a $29.3B post-money valuation.

> We’ve also crossed $1B in annualized revenue

A 30x revenue multiple on (presumably) relatively low-margin revenue is certainly punchy.

One wonders how much of their $1bn of ARR they're paying straight through to Claude/Anthropic.
nr378
·8 ay önce·discuss
Palantir is trading at 80x revenue (NTM), whereas Nvidia is only trading at 19x revenue (NTM).

Both companies are growing revenue at a similar rate (~50% YoY), and Nvidia has a higher net margin, however Palantir's share price is up 717% over 18 months, whereas Nvidia is only up 124%.

It's hard to argue Palantir's valuation reflects its fundamentals, even if you believe Palantir will be benefit from lucrative government contracts for years to come.

Buying companies at 80x revenue has not historically been a great way to make money, unless they're growing revenue at several hundred percent per year.