bredren

That's neat. Once it is built, I think a cooler use is to trace wiring and plumbing through your walls of your existing house. Your revit model may include all of this data, or at least the plan. Things change. :)

Though this is especially helpful for old homes where you have to sort of improvise ethernet wiring.

I normally just use it to consume 4k hdr media though.

It has not lived up to being a utility player device, but so far it is so good at media delivery that is sort of okay.

Citizens was the worst part of the prior program

These cards are very important to knowing what the companies are tracking regarding safety.

Not just in what the models can or might want to do, but how they treat the operators they interact with.

If you look carefully, this card shows the addition of a new benchmark for "condescension" as a character trait.

I think a lot of people would like to see a comparable system card for the unannounced model that escaped openai last week.

I've been on one to two of these plans for eight months or so. There used to be a lot of issues with CC's terminal but at least in iterm2 they have largely been sorted.

What terminal tooling are you using?

I find that my orchestrating agent still needs to be fast to properly coordinate a fleet of slower models.

During post-training of opus 5, the last few days, opus was a real wreck. I had to swap in gpt 5.6 sol for my orchestrator and enable fast mode (1.5x speed) in order for it to keep up with work and communications from a handful of mostly 5.6 sol agents.

Also because interacting with a slow orchestrator is no fun, even when plenty of work is getting done in parallel in the background.

It has been a good long while, but in my undergrad the engineering dept did not put a lot of emphasis on being a well rounded individual. It was more about passing physics and getting through all of the math.

One of my first jobs out of undergrad was technical writing on EDA tools for Mentor Graphics Calibre product. For many years, I did not appreciate that experience--it seemed orthogonal to what I'd gone to school.

Once I did become a professional SWE, something that took me too long to realize was that writing documentation and tutorials for people and looking after the quality of onboarding materials was almost never rewarded.

I came to see it more of a liability with ~all emphasis being on human code gen.

I listened to an interview with Steve Yegge earlier this year, one of his concerns was that many people just don't type very fast or read very quickly. IIRC, he expressed concern this would continue to be a big barrier to successful use of AI.

I previously commented on annotation for coding agents that an important skill was knowing the beat of a conversation.

I think that extends into critical reading. For example, it is not that unusual for a Washington Post article to put some ~explosive detail deep in the article--this is called "burying the lede."

I see this regularly reading AI output. That is: the AI will lead with the strongest claim it can state cleanly, but not the most explosive implication.

With Claude Code and Codex, you're looking essentially neverending walls of text dense with technical information.

So now you have to have high domain expertise, a good understanding of written communication, a sense for the beat of a conversation (which assists in identifying understatements or overstatements), and the ability to dense text outputs quickly and then highlight critical statements for further exploration.

I'd almost describe part of this work as that of a skilled interviewer.

I used to read him in my dad's PC Magazine subscription. I had some ~falling out over what my teenage self perceived as backwards take on mp3s and their proliferation. Perhaps one one of my earliest experiences with "kill your heroes" concept.

Glad for all of his contributions, I did enjoy reading his work.

It is ~a meme on subreddits that developers struggling to get good results out of any given model is a "skills issue."

But I think your comment drives at some authentic take on this. Skill with AI is not only crafting iterative prompts the agent will understand, but also very high domain-specific knowledge of what the prompts explore.

One without the other can result in frustration or worse.

This goes straight to the compiler and whether that precludes original craft. But I think it would be more relevant to discuss the use of open source packages.

Because I absolutely feel I made entire SaaS products, cool ones, by hand and they sat on a multitude of packages and infra I but glued together.

For frontend, I tailored templates, and instead put energy and time into making modern frontend toolchains and Django backends work together. This was satisfying to understand and build.

Being at ease with the minute details of Django or latest flags of esbuild felt like knowing the various modes of my Dewalt or Dewalt-colored power tools.

Building with AI is not a passive activity, and doing so well and efficiently, there is a ton to master and it evolved a great deal in the past six months.

So leveraging the tools using custom skills, custom CLIs, etc this is very important and very valuable thing to do. I would classify it as a serious contemporary computer science skill that should be taught in addition to the fundamentals.

Presume now, you're making and leveraging all of the modern bells and whistles of Claude Code and Codex. That is, you're reading the release notes and you have personal tooling so you can switch between them easily.

You can build incredible things with sustainable release workflows and reasonable security and possibly more than what a solo dev's "production quality" of yore.

I know this because I had Fable look at an entirely "hand crafted" SaaS I built over two years and it found about a page of bullets just in p0-p1 that I had not caught in my artisanal best effort. They were real issues, maybe unlikely but still things that I would have fixed if I had known.

But what can not be replaced is *taste*.

You can build all day and night and if it ain't good people won't use it. If you can't describe it in a way that makes sense to people they won't care.

If you build something people don't want you've not really made anything more than we did before we had AI as a tool.

I do think it can still achieve the same level of satisfaction if it is built well. Because it actually does take a lot of skill and knowledge to make something well using agentic programming. This is regardless of whether people want it.

In the "old west" if a horse was spooked and ran a person over, liability for the horse's owner varied but was similar to how this might be handled.

Consider this Supreme Court case, Brown v. Collins. [0]

A pair of horses were spooked by a nearby train engine, causing the animals to damage a stone post.

The driver of the grain-loaded wagon was not found to be at fault because he was "not guilty of any malice or unreasonable unskilfulness or negligence." And that the horses "did damage there against the will, intent and desire of the defendant."

If you read OpenAI's statement, in the Actions Being Taken section:

    1. "As part of the investigation, we are implementing strict controls in infrastructure configuration at the cost of research velocity while the vulnerabilities are patched."

Which I think implies that as a result of this incident, OpenAI has instituted controls beyond ~"reasonable skillfulness" such that it might even impede their business (and from a certain point of view impede the progress of the people governed by the laws which might hold the company accountable.)

I'm not taking a position on the merit of the above but I can understand the line of thinking.

[0] https://www.jstor.org/stable/3303590

Pardon the plug, but I have built a tool that ingests the state of conversations to a local DB in realtime. It has both macOS and Linux clients.

When context compaction introduces a gap, I use the /total-recall skill to pull prior turns back into context and off it goes.

The tool is free for personal use and has a source available local cloud option to sync convo histories across multiple machines.

http://contextify.sh/docs

I can believe it, but if it is such a threat, why not warn or prevent it from harness level?

I'm remembering now warnings to this effect early on in CC.

Have you tried this:

   Look here and here and here are some tools, and /skill /skill [repo of folder paths etc] and here is what needs to happen: [stuff].

   ---

   Restate this request in your own words and enrich it as appropriate handling any gaps.

?

It is an ultra-lite way to plan, I suppose.

I like the format because:

    - I still get to put all my thinking into the request but then easily override the instruction
    - It is interesting to see my casual typo-riddled blast professionalized and improved upon.
    - Sometimes it surfaces useful questions that can save some time up front.

I think the models are doing this anyway, but I find the words "enrich" and "gap" are well understood by models and they demonstrate it in the response to the above pattern.

Anyhow, to get back to the point, there are still prompt-level tricks--but ultimately if repeated, should probably also be built into skills themselves!

Yes. I worked on two large monorepos, about one quarter per project. Maybe 80+ devs on first, maybe 40+ on second. Both were not sure how to describe this but ultra-high-velocity agentic driven development efforts.

On the first, there were ~no shared skills. There were some requirements set up but they were not minded properly and became stale / ate context for little gain. The hardest hit was in E2E tests which would flake and create long running, too-often failing CI. People would disable them, because they were not reliable and velocity was so high, no one was happy w them.

I maintained my own set of skills and CLIs to back them. I'd share them if they came up but it was like the old days of manage your own stuff. Not much credit for building and sharing devex tooling to the team.

But then on the second one we were in better shape--we had vendoring set up to distro skills automatically.

Before the project was well underway, I put time into understanding how all of our tests aught to be written. Finding the forbidden things, etc, getting review from our best test folks and ultimately landed on a `/test` that routed across all possible test types.

Like night and day. Instead of finding out while trying to get a release out the door that some corner of the project had a handful of flakes, tests were written the right way from the start.

Like, it was beautiful. And I don't think devs noted difference while building. Only that there was an absence of BS in CI.

Hard to quantify the lack of pain, but it was big!

I was thinking this past week I have gotten so lazy w my prompting via CLIs.

Back in the before I had put such discipline into my prompting and supporting context.

Now I’m like, “look here and here and here are some tools, and /skill /skill okay go.”

Or “restate this request in your own words and enrich it as appropriate handling any gaps. Okay go”

Do you have a link handy?

I used same session, set it to k3 model. I’ll look at the blog but the result was so bad I am prepared to abandon.

I should have saved the output.

I think maybe it was a mistake to not use open router.

I just tried this on the monthly $18 plan, having it do a basic task with its 2.7 model and then audit it using k3.

K3 got into some loop trying to run docker and after maybe the 6th attempt ran out of quota for the 5 hour window which represents 20% of the weekly.

I run 200 max and chatgpt pro, but I had to blink at that.

K3 didn't even write out what it was doing or provide any sense for why it was pursuing the execution path it was.

I'm in disbelief that this is a groundbreaking model, and do not think it represents a threat to Claude Code or Codex at this time.

It is a normal seat. It is simply covered by floof.

Except often queued agentic flows must be checked in on. Or to use the comparison, 3D printers are not immune to making spaghetti all night when something goes wrong. (I’m not a 3d printing expert so maybe that is solved now)

It is common for agents to just stop because overload or some API error hijinks.

Or you get a TUI question that is blocking.

In general you’re right though, staring at tokens from agentic is not time well spent.

Some of these I’ve built custom harness around in iterm2 though.

Thank you. How are you using the product?

Thanks for that. I updated the page.

If you have time to try the app out, I'd appreciate any further feedback.

I hadn’t thought about testing the bounds of model safety on comparatively benign requests compared to the type of thing described in frontier model cards.

I've been working on Contextify: https://contextify.sh

Makes it easy to use Claude Code or Codex interchangeably across multiple computers. Personal editions are free, I have a hosted commercial cloud (workgroups share AI history) and commercial self-hosted option available.

It has macOS and Linux clients and I released a guide for setting up the source-available, self-hosted cloud option this week: https://contextify.sh/docs/self-hosted/

I am thinking about the other AI cli environments and providing support for those as well.

I used their AI chat last night and I was impressed with the product implementation. I was able to use it to make quick sense of data and even generate prompts to solve problems locally.

IDK what the prior AI behaviors have been, but for me, what they have now is an ~idealized version of AI product.

It is basically what I'd do if they didn't offer it but not as well: export data, import their docs in md., import some industry best practices in analytics into context etc.

Except its all right there. Not sure of the economics of it, as it was on a free account and some reasonably good model was powering the discussion. But it was about as engaged as I've been with an analytics tool.

I think it is a mix of the sibling replies here. I'd add that the company has seemed to find ways to ~do more with less.

I have never liked the various nerfs Anthropic has used to balance GPU (slowing down responses, quota variance, model optimizations etc) and it definitely has burned a lot of good-will.

But it has seemed that being able to look beyond the short term pitchforks has worked quite well.

I also think this undersells the real value of the bot, which is to handle tasks via voice that an average human either would not or could not do.

In the video example with the grannies, the knitter is essentially wanting a PA. Regular folks don't have PAs. Even when that became a thing in the aughts they were all outsourced.

When I've used voice chat, it has often turns into rabbit holes on very niche topics. For example, I had one start about the 1996 performance of Rage Against the Machine in Portland, Oregon that was supposed to feature Wu Tang Clan. (already outside most human's knowledge) that dove into details of the club scene in Los Angeles at the time of RATM's signing to Epic Records.

Was anyone else here at that '96 show in Portland? It seems like it might be challenging to find a person on the internet able to engage on the topic.

The person may exist, but not during my fleeting interest in the subject while walking to the park.

How are y'all carrying context history from one agent to the other?

I also flip between the models due to quota, TUI enhancements, model updates and service availability.

To handle this, I built a thing that normalizes your transcripts between Claude Code and Codex into a shared DB, then a CLI and skill.

It has made it so it doesn't matter what I built where (or when) I just refer to the work and drop in a /total-recall (or $total-recall on codex) and the agent brings it into the current convo.

I realize there are a lot of ~memory tools out there, but I think particular my approach and product behavior is unique.

If you're open to giving it a try, I'd appreciate any feedback: https://contextify.sh recent show hn: https://news.ycombinator.com/item?id=48777790

It is not, I suppose it could be but it would be good to get feedback first. If you see this please shoot me an email.

Hey, I’m watching this thread and happy to answer questions or take feedback.

I’ve described some of the challenges in parsing and normalizing the variant JSONL files codex and Claude code produce in prior comments.

There is some interesting nuance to how Claude Code writes its queue-operation records.

Early on I focused on the macOS client, working. To get the summarization tuned in, and thought of the product as more of a HUD.

But as I used it I found that making the corpus of session data available to the AI was the real power tool.

This is what guided me toward adding a Linux client (which does not have a GUI, but provides all of the ingestion capability of the Mac app.)

I’ve written a skill for codex and Claude code that designates an orchestrator on the primary worktree and is agnostic about what type of AI workers are on the N supporting worktrees.

The orchestrator knows which AI client is running in any given worktree, so it would be fairly easy to designate which AI should receive what kind of tasks.

You run either Claude or Codex in tabs for each work tree. I do have some AI TUI specific instructions, for instance codex is primitive at monitoring compared to CC. So, there are additional notes for Codex workers on how to properly monitor for new "mail."

You work with the orchestrator on the primary worktree and allow it to delegates tasks to the workers and answer their smaller questions.

It surfaces results and assisting them with context clearing when needed.

The orchestrator and workers communicate using a simple shared file system under tmp/* and together they can handle a big and varied workload.

I use iterm2, so I’ve also added iterm2 specific python that allows the orchestrator to “kick” a worker or perform tasks otherwise veto'd by the TUIs (ie /clear) by modifying the input and submitting it.