Tim Fischbach

Been wondering: What does the codecamp hashtag relate to?

Tried it a bit, but found it a bit unclear when which skill is active - especially across context compactions. Would be nice if /context included that info. Felt a bit more in control with custom slash commands.

I use it to write and update FAQ articles in a multi-language helpdesk. Vibe coded an integration with the helpdesk API to sync the articles from/to a Git repository.

"This is why this series of blog posts, that could maybe become a book or a course or a musical or a cake, ..." 😂

> And models can’t distinguish between working code and broken code.
Having agents run tests to include test outputs in their context can greatly improve things. It basically gives the tool additional attempts with additional information without having to prompt multiple times.

Would be cool if editing the template tag of a web component in dev tools would automatically apply changes for all rendered elements. That would sort of be the equivalent... Looks like it doesn't though - appears to only a apply to newly inserted elements. Which makes sense, but still.

I sure like being able to prototype in the browser myself. Still, I'd say it's a trade-off. I think I was mainly reacting to equating friction in the browser use-case with a general maintainability issue. Utility classes can surely lead to a maintenance nightmare - but so can global styles.

Still worth considering whether "easy to edit *in the browser*" is the most important criterion, though...

Only read half the title and clicked expecting to hear a rendition of the Nas track.

The use case feels a bit like a web-based arcade game to me where keyboard control would be a natural fit.

Or clickable buttons with clearly displayed hotkeys

Yeah, so if region defined --gap in em, I'd see the difference, but like this, isn't it the same whether I derive from the computed value of the parent or read var(--gap) from the cascade?

Why wouldn't the region/card example work if card referenced --gap via var() instead of inherit()? Wouldn't it only make a difference if card wanted to define --gap *itself* in terms of the parent's --gap?

Final though: And something like your workflow linter could also be an interesting tool to keep the robot on track. Just like feedback from tests and code linters work better than long markdown wish lists.

If now I could use a local model to do that well enough...

Still, sometimes it can make it easier to find the discipline to round out the change you are making (test coverage sort of becomes a necessity, updating inline docs, adding a simple guide how to use a feature, covering features with things like storybooks for visual diffing etc.)

This of course comes down to what you already wrote elsewhere about already being able to work without AI to work well with AI.

- easing review by basically diffing the result against this expectation and treating each deviation as a warning sign that either things have gone of the rails or initial assumptions where flawed (this is the main point regarding "quicker than do all the checking and rework afterwards")

- generated tests and linter rules as a closed feedback loop to improve results before first human review

- humans come up with rather simple/ad-hoc/stream of consciousness prompts already having a clear mental model of the shape of the change they are trying to generate

- project has reached an architectural stability where many new features are just sort of more of the same/good kind of boring

- good automatic test coverage to keep the LLM from breaking what is there

Hard to fit this in a reply here, but I think there is a case which could be a sweet spot like that when all of the below are true:

- brownfield setting where there is already a lot of prior art for the LLM agent to draw "inspiration" from

See also bsky.app/profile/simo...

This really resonates. Wondering whether there should be a separate term for this kind of working very much with the code - but without touching the code directly. Tried to capture this here bsky.app/profile/tfis...

Workflows like running tests, linting or keeping documentation in sync can be codified in rules and commands.

Expressing desired change in patterns and higher level concepts allows for more coarse grained steps while still being super-intentional about the targeted result.

LLMs/agents can still be used, though, to increase the level of abstraction of the *transformations* we apply to extend or adapt our system.

So any attempt to use natural language or specs as the primary level of abstraction you operate on when thinking about your system, just removes you from the structural realities that should inform your decisions.

As long as you need to fully understand the internals of the artefacts you generate, your mental capacity will be the first bottleneck in your process.

The big leverage when building a system comes from intentionally designing or incrementally redesigning it to make certain things simple. This means knowing the internal structure of your system.

Current take on working with coding agents: Use them as an extra level of abstraction for the making, not for the made.