I did a ^F for "update" and "dynamic" - didn't find any hits in that doc. Managing your dynamic environment values is table-stakes in most large deployments - and I didn't see any reference in `secretspec` as to how they plan to do that.

Is there any compelling reason not to?

I think what happens is that people often have passing familiarity with a word or topic and presume knowledge, and years (decades) later they realize they knew almost nothing.

I will say that Mathematics is different (for me at least) because unlike the infrastructure computing concepts (IETF type, not IEEE)- which mostly require studying, lab work, and some coding to get your hands dirty - advanced math is just ... really hard. There are IQ issues at play.

Obviously a lot of computing turns out to be mathematics - so there is clearly convergence/overlap as well...

It's not perfect, btw - to some degree you are at the mercy of which models they support - currently only 27 from Gemini, OpenAI, Anthropic, Grok, and Kimi (Just K2.5) - presumably because they have commercial arrangements with them. The "Bring your own Model" model requires you plunk in your API key - which sucks. And only one at a time.

To the best of my Knowledge, Claude Code only supports one model at a time if it's not one from Anthropic (which will use the the entire suite of Anthropic Models depending on the task) - and you have to override it to a single model with an environment variable at startup - no ability to flick between models from task to task.

Depending on your workflow - you can save 70-90% on costs just by chosing a reasonable model for really extensive tasks that don't require thinking, max context, etc....

Over time - I expect Composer will be cheaper than Opus 4.8 - but the nice thing about Cursor - you can flick between models.

And (this is purely a personal thing) - I really like the extensive collection of "Plans" that cursor tracks - there isn't really a similar thing in Claude Code - but I really like the Claude.AI interface for everything else. It's also a much better general knowledge agent - the Cursor Chat interface isn't as nice.

Some of the issues (off the top of my head):

- Note - that my "product" was about 3,000 lines of code - so tiny. But https://metr.org/ should give you some insight into the complexity the models are capable of.

- you have to be able to imagine the product. If I have the time, and energy, to imagine what I want - the model will build it. Here is an example of a much better programmer than I and something he wanted built - https://www.boatbomber.com/blog/claude-fable-5

- These are the first drafts. On average - any complex system needs about 10 years and at least 1000 active and enthusiastic about reporting users to really get robust code. Writing if via LLM doesn't (at least so far in my experience) help that much in reducing bugs if you were previously following any semblance of TDD. Lots of bugs in the code - the products you listed above have literally tens of millions of years of user experiences and bug reports that got them to where they are today. No silver bullet yet - just faster, less effort - and it enables non-technical people to create (still buggy) products.

Cursor does have it's own model - it's a heavily reworked version of KimiK2, called "composer" - that I use a lot of the time when I have fairly straightforward tasks that don't require a lot of exploration or independent thought. Lot cheaper - the Input/CacheWrite/CacheRead/Output costs of Opus 4.8 are $5/$6.25/$0.5/$25 per mm tokens, vs $0.5/-/$0.2/$2.5.

But - I don't know if it was April, or May - but very recently - the coding harnesses paired with decent SOTA models like Opus 4.8/GPT 5.5 - just started showing a lot more consistency, and completeness, and sometimes downright clever behavior - that they started to become way more useful.

Just one out of hundred+ examples - I gave Claude Code (Opus 4.8 High) a complex task that involved consul, vault - but I had neglected to give it sandbox permission to download from hashicorp.com. So - it created a entire test harness that simulated both the behavior of Vault and Consul - created all it's test cases, verified that they passed - and when I came back 40 minutes later said that it was all done.

It's test harnesses so accurately simulated the behavior of Vault/Consul - that on first try - no refactoring whatsoever - all of the protobuf/AESGCM/API behavior (that has varied significantly between versions) - worked.

This was something that would have taken me, someone super super familiar with the code and tools and APIs - a minimum of 3 solid days of work - and that would likely involve hundreds of attempts and refactors as I unwound all the weird encryption and packaging layers. It zero-shotted a full solution without having an API to test against

If these agents actually have an actual test-harness - It's honestly hard to imagine what they can't do - subject only to imagination and budget at this point.

Speaking personally - something changed Between January and, Let's say May - in which instead of seeing these things as mostly interesting technology demonstration, in which the flaws outweighed the benefits - I now genuinely think they are the future of programming. I'm dubious that I'll write much software manually in the future - beyond what I do for personal pleasure.

From a valuation model - $4B ARR with rapid growth, and the ability to shift traffic to internal models (honestly, massive amount of the time "composer" - their internal model is fine, and obviously going to get better). Say 17x Multiple which isn't unheard for a rapidly growing Startup with solid future structural profit elements (moving to internal model) - that gets you to $68B.

For example - I might (real world example from this morning):

"Create a script that installs hashicorp vault and consul, store the data on consul. Then create ahelper script that will fill the vault server with sample data. Add HTTPS support. Now write a framework that reads and decrypts the encrypted data in consul. Support old (pre 1.3) and new (post 1.3 vault). "

That generates a 6 page plan using Opus 4.8 w/1mm context, including notes on what to prioritize, what format to create the scripts in, etc... (My cursor guidance already has a couple months of hints as to what I want in terms of scaffolding unit tests, canonical linux, performance, security, etc...)

That 6 page plan is the "Prompt" - but it's entirely generated by Cursor/Opus. It's there to tweak if you want to emphasize, or provide some taste - but, honestly - it probably does a better job than I would - so ~90% of the time I just accept the plan as is.

- I work a lot with data - and streaming data through text tools is twitch fast. If someone has a question about data - before anybody else can log in to their superset, or analytics database, and try and work through the SQL queries or charts to get the answer - I've already jammed the data through awk and got an answer.

- As an SRE - I work with a lot of systems that have pretty rich APIs - so being able to send a request, get the answer back in json, dump it into jq, select the parts I care about - maybe -c to compress it and ripgrep a subset out - is just fast.

- I work in a lot of contexts with a lot of different systems, datacenters, applications - tmux lets me keep all of them cleanly organized in a separate windows and subpanes. I'll have 15-20 windows open per week, and maybe a 5-6 panes in each- keeping 100+ different contexts (and scroll backs, bash history) - all nicely organized is really useful.

- I'm also a systems guy - and there is no other way to dig into a system but the terminal - netstat, ps, dmesg, /proc - these are all components that have only one credible path to investigation and discovery. If you aren't super comfortable in the terminal - zero way to learn about this stuff.

- Working remotely - means ssh. So - once again - terminal.

The Focus on the terminal is that it's the best tool (and in some cases the only tool) for so many of these tasks - and by performing these tasks a lot - you learn about systems - so the people who spend a lot of time in the terminal tend to know a lot more about systems than people who don't.

Workflow in Cursor is actually awesome - I'm a little outdated in how I use it - I still establish goals/objectives, rather than managing the loop which does so - but if you can think broadly enough - I find it's pretty efficient.

Key things I like about Cursor (and I recognize I'm dating myself a bit here): - Plan Mode is really solid - I shift-tab, have it go create the plan using whatever insanely expensive SOTA model is available - I will usually spend 5-10 minutes on the Plan - review it, maybe even tweak it a little. (though 90% of the time it's fine out of the gate)

  - Ability to select any model for every task - I'll switch between Opus 4.8 High/xHigh/...  I'll even switch to 1M context for the planning phase upfront.   

  - It does an *excellent* job managing permissions and looping the agents and spinning up sub-agents for you - you set the goal, run the plan mode - and then let it churn for however long is required - pretty common to have a 30-45 minute run and come back to a fully created/tested product.   

   

But - these $3k-$5k/month/engineer bills are going to start to get attention soon - only question is whether the response is to slow down on the $$$ spending or reduce the # of engineers.