Many of the "look at what I did programming LLMs" blog posts on Hacker News have been developed and put out in academic papers and groups. The posts which gain traction here seem to be perennially behind the state of the art.
1,561 karma · joined July 20, 2020
https://github.com/femtomc
Removing the shown token comsumption rates (which allowed understanding when tokens were actually being sent / received!) … sometimes hiding the compaction percentage … the incredible lag on ESC interruption on long running sessions, the now broken clearing of the context window content on TASK tool usage
Who the fuck is working on this software and do they actually use it themselves?
Maybe the quality of Claude Code on any given day is indicative of whether their models are degraded …
On the other hand, Rust / Haskell provide partial solutions with static typing — but run into annoying boilerplate related to the orphan rule.
I’m not sure if there’s a true solution, given the level of thinking which has gone into these two forks in the road.
Play with it — that’s the only way anyone masters anything.
Separate yourself from the results, be prepared to waste time, but try and have some fun and keep your eyes open.
Having said that, I don't think an editor should be VC backed. It's the obvious pragmatic choice to get a team together to support a thing, but I'm concerned by it.
How many ways can you wrap (multiple agents, worktrees, file manager, diff viewer, accept reject loops, preset specifications for agents) -- let's try Electron! Let's try Tauri! Let's try a different TUI!
What if we sat down and really thought about how these agentic IDEs should feel first instead of copy pasting the ideas to get something out to acquire market and mind share? That's significantly harder, and more worthwhile.
That's how these agentic front ends should be advertised: "Claude Code, plus _our special feature_" and then one can immediately see if the software is filled or devoid of interesting ideas.
Why even pretend with this type of work? Laughable.
It has no semblance of a continuous stream of experiences ... it only experiences _a sort of world_ in ~250k tokens.
Perhaps we shouldn't fill up the context window at all? Because we kill that "reality" when we reach the max?
Also, these companies have the most advanced agentic coding systems on the planet. It should be able to fucking implement tree-like chat ...
I recently used an LLM to help scaffold a piece of technical writing. I showed it to several of my peers (sharp and accomplished PhD students), and they immediately identified the paragraphs (even sentences in captions!) written by an LLM. I had spent a good amount of time prompt engineering Opus 4 to try and produce a coherent piece of content aligned with a narrative which I had already developed, but it was still _immediately obvious_ what was not consistent ... it stood out like a sore thumb to experts.
By the the time we finished the content, there was not a sentence of LLM-generated writing in the final product.
Possibly an incorrect extrapolation, but I think my experience here is the current status quo. Code is a bit easier for these systems, because the LLM can align against test suites, type systems, etc. But for writing ... you just can't trust the current capabilities to pass the sniff test by experts.
After all, how does one commmunicate "coherence" as a test which the LLM might align its generations against? That's why you need a shared world model (with your audience) -- and if we could produce a computational representation of such a thing, we might have a chance at better coherent / consistent technical writing generations.
Perhaps good for someone just getting their feet wet with these computational objects, but not resolving or explaining things in a clear way, or highlighting trends in research and engineering that might point towards ways forward.
You also have a technical writing no no where you cite a rather precise and specific study with a paraphrase to support your claims … analogous to saying “Godel’s incompleteness theorem means _something something_ about the nature of consciousness”.
A phrase like: “Unfortunately, for now, they cannot (beyond a certain complexity) actually understand what is going on” referencing a precise study … is ambiguous and shoddy technical writing — what exactly does the author mean here? It’s vague.
I think it is even worse here because _the original study_ provides task-specific notions of complexity (a critique of the original study! Won’t different representations lead to different complexity scaling behavior? Of course! That’s what software engineering is all about: I need to think at different levels to control my exposure to complexity)
The resulting content lacks consistency and coherency. The generated prose is rather breathless: in carefully articulated content, every sentence should have a place. Flagship models (Opus 4~) don’t seem to understand the value of a sentence.
I’ve tried to prompt engineer this behavior (one should carefully attend to each sentence: how is it contributing to the technical narrative in this section, and overall?), but didn’t have much success.
I suspect this might be solved by research on grounding generation against world models: much of verifying “is this sentence correct here?” has to do with my sharing of a world model of some domain with my audience. I use that world model to debug my own writing.
One technique which appears to combat this is to do “red team / blue team Claude”
Red team Claude is hypercritical, and tries to find weaknesses in the code. Blue team Claude is your partner, who you collaborate with to setup PRs.
While this has definitely been helpful for me finding “issues” that blue team Claude will lie to you about — hallucinations are still a bit of an issue. I mostly put red team Claude into ultrathink + task mode to improve the veracity of its critiques.
Probably a bad habit.
Not very enlightening: just because Dropbox became big in one environment, doesn't mean the same questions aren't important in new spaces.
Truly — this is an excellent and accessible idea (bravo!), but if I can whittle away at a free and open source version, why should I ever consider paying for this?
Just letting a single instance run all the time … is not that bad, seriously.
Hardened and long use systems like TikZ of course, do have something like this -- but in complex TikZ graphics, you end up with a mixture of "right of" and "left of" (etc) and low-level manual specification, which I think tends to fall into the zone of issues.
It truly cannot reason well yet about geometry, visual aesthetics, placement, etc. The performance varies: it's quite good at matplotlib but terrible at any non-trivial LaTeX / TikZ layout or graphic. Why? Not a clear idea yet -- would love to think more about it.
I've tried many things now to try and give it eyes (via text), and this is unavoidably a place where things are ... rough ... right now.
I've had bad results with image screenshotting. More often than not, it has no idea what it is looking at -- won't even summarize the image correctly -- or will give me an incorrect take "Yes indeed we fixed the problem as you can tell by <this part of the UI> and <that part of the UI>" which is wrong.
I typically have to come in and make a bunch of fine-grained changes to get something visually appealing. I'm sure at some point we'll have a system which can go all the way, and I'd be excited to find approaches to this problem.
Note -- tasks which involve visual design which I've run into diminishing returns: * proper academic figures (had a good laugh at the GPT 5 announcement issues) * video game UI / assets * UI design for IDEs * Responsive web design for chat-based interfaces
All of these feel like "pelican" tasks -- they enter into a valley which can't be effectively communicated via textual feedback yet ...
I think you meant this: https://arxiv.org/abs/2506.08276
Context engineering is "just" prompt engineering for LLMs with tool use: it extends the concerns of prompt engineering with the concern of setting up an environment in which tools can be used, and how the LLM can most effectively interact with the environment.