zlumer.eth

@badlogicgames is it the kind of change that would take 8 hours pre-AI though?

@aidenybai I think this hasn't changed in the past 1.5 years

the bottleneck for coding agents is now testing / code quality agents are OK at writing code in the happy path, but don't consider edge cases on harder tasks it's also very messy (unnecessary utils, duplicated code, random `as` everywhere)

Biggest mistake in AI coding era: to believe that specifications should be either natural language OR something else. The best combo is a natural language high level specification (the intend), plus code (as it gets written) documenting the finer behaviors.

@FUCORY I thought Smithers plans were supposed to be created by AI on a per-task level, was I wrong?

Smithers shines at a high level of complexity. But it's a lot of boilerplate for simple scripts That's why we are going to introduce a new simpler syntax. TOON. TOON is the best way to write a very quick simple script and run it The old JSX api still exists for advanced components and workflows

@FUCORY for API calls — auto-generated typed clients (openapi/graphql/orpc/etc) for visual — storybook+react-grab for state — github.com/zlumer/tesm I'm obviously biased but I've been using it since 2020 and it prevents the whole categories of bugs, including the ones agents make

When you get very good at using agents, you realize frontend is actually harder than backend Backend is really easy to throw more black/white quality checks and backpressure at. Building a frontend that isn't slop ultimately requires lots of human in loop

@onehappyfellow could you please also make two versions of the language that are mutually incompatible and name them Goskell 2 and Goskell 2.1

finally, a language which combines the easiness of haskell and power of go type system presenting: Goskell

@VitalikButerin now if you slap any open source react-based diagram library on top, you'll get the best of both worlds: creative svg shapes + declarative connections between them

"Friendship ended with drawio, vibecoded SVG is my new friend"

@jxnlco if by value you mean "the max amount of tokens I get" then subscription doesn't make sense, best to burn them as you go however comparing a heavily subsidised $20 plan that provides $125 worth of tokens with $20 worth of tokens based on the current price is the other way around

if you were sponsored by codex / openai as developer would you want-

@materkel fomo is real

Every day not spent "coding" right now feels like missing out on weeks or even months' worth of focused work... I increasingly feel both excited and anxious. You can basically create a decade's worth of pre-agentic era output in only a few months... How can we even sleep with a good conscience knowing that? Even writing this tweet misses out on a prompt that could have created value for humanity. Let's go out and touch some grass though! Let's play with your children and enjoy a good sip of coffee... We never know how long we can still enjoy life... while our agents spend time inferring for us. You can only solve real problems if you live them.

I was a 10x engineer. Now I'm useless.

@rfleury it's like nobody studies information theory anymore

For any given desired computational outcome, there is some sequence of bits which encodes that. These bits of signal (of the desired outcome) can be intermixed with bits of noise. The reason why these LLM-generated codebases by default have so many obviously useless lines of code is that, for any given generative step, the LLM’s job is to package up the few signal bits (from the prompt) into a plausible presentation of other bits, which may or may not be noise. If they are extra signal (because they can be statistically inferred from the other signal bits), then that’s a win, but there’s a much higher probability that they’re actually just noise. This is why every AI generated tweet, article, or indeed code snippet contains drastically more fluff (noise) than what a focused person with reasonably good instincts for compression would produce. So, in order to actually accomplish anything (without extreme vetting, compression, and modification of generated code), the “programmer” (prompter) needs to continuously generate more code to obtain the next signal bit they wanted, at the expense of many, many more bits of noise. The result is often ~100x if not ~1000x more code than was needed, which is impossible to hand-edit, comprehensively understand, or compress. Layers upon layers of statically average nonsense, wrapping the few bits of utility you actually wanted.

We aren't all going to go back to a terminal. I'm not even sure windows people even know what that is.

@aarondfrancis one problem with git worktrees is that for actions as basic as commits you still need access to the original repo. prevents you from just mounting a worktree into a container this is the reason why hyperbranch is now using full git clones instead of worktrees

Why do people like git worktrees over discrete checkouts? (This isn't bait, it's research)

@dboskovic it looks like you're building something insanely cool, but you can't kick an open source software to the curb unless you also open source yours

unreasonably excited about this tool we're building to allow agents to "see" the visual work they're doing. time to kick storybook to the curb any wishlist ideas I should add? folio.stage.obvious.ai/obvious/reacts…

I remember writing prompts as comments inside an empty function body to get those sweet vscode co-pilot completions a hundred years ago

Programming language doesn’t matter until you need to: - have actual parallelism - scale horizontally - scale vertically - compile 1m LoC - incrementally compile 1m LOC - refactor without breaking anything - review a large diff - validate a change - detect and remove dead code - maintain backwards compatibility - get a large team working efficiently - onboard new hires - validate the security of a system - invent custom abstractions to reduce duplication - work around abstractions someone else invented - troubleshoot production issues at 2am - be operationally efficient - deploy on Friday - deploy 100 times a day - handle time & timezones correctly - handle currency correctly - eliminate null pointer exceptions - depend on libraries that are maintained & secure ​​- produce something of more value than a tweet

@forgebitz I can't even imagine running an agent on my local filesystem outside of the container, giving it keys to prod is really living on the edge

i let claude code run some migrations on a hobby project it straight up ignored the migration files and just wanted to push schema changes i do not know how people use this against prod enivrements

@tomfgoodwin twitter algo

I still don't get how my entire feed is either "AI can do everything" "What AI can do is going to change everything" "AI is improving faster than ever" "AI can't do anything" "AI is pointless" "AI is actually getting worse" And not, It's complex It depends on when it depends on where it depends on how it depends on who it depends on X,Y, Z and more It can both be magical and impressive but neither valuable or effective

@aidenybai @benjitaylor maybe add a comparison page on how you approach things differently? because both products look pretty cool at first sight and it's unclear what are the trade-offs of each

@benjitaylor lol we should honestly just merge. or at least have some shared primitives where people can vibe code their own element selector tools with different opinions/preferences

Might just have to reintroduce Agentation

@sasajuric for this approach try Aider with watch-files: you write short prompts inside the code files themselves and the agent works in parallel, every step committed to git and undoable

I recently reviewed some AI assisted code (Elixir). The core approach of the produced solution was solid, but I spotted a number of various issues: - Overly complicated module API - Too elaborate and subtly incorrect process structure - Redundant pieces of information in state - Too complicated and slow tests - Overlapping tests - Lots of subtle duplication between tests - Some tests were checking internal implementation details, not observable behavior - Some tests were never running (the execution was depending on a condition which was never satisfied) It was clear to me that it's not worth doing a standard review here. It would drag on for too long, and the code probably wouldn't be cleaned up completely. My typical approach in such situation is to submit a proposal refactoring instead. It took me the entire day (with AI assistance, more on that later), but I was able to address all of the issues above & more, shaving off about 500 LOC (from the previous total of 1000 LOC, which I'd say is not too shabby). I think that the key reason for the original state of the code was that too much code was generated at once without reviewing and steering the AI. So it ended up producing something which is technically correct, but may be overcomplicated in various ways. Reviewing and working with such code then becomes harder both for humans and machines. The approach I've been using so far is working in very small (really micro) steps. I ask the agent to make me a small change. Something like 100 LOC is about the capacity of what I can review reasonably well. I look through the changes, maybe do a bit of refactoring, ask the agent to review my changes and update its context, commit, and move on to the next step. I used the similar approach to refactor this code. Picked one issue, gave 2-3 sentences to the agent, checked the code, rinse and repeat. Most of my 44 commits were 100% AI generated, though for a few things I estimated it was quicker and easier to just make the change in the code. This doesn't give me dramatic speed improvements, it's more like 10-20%. But it gives me a good balance of velocity and code quality. In general, based on my admittedly small experience with AI assisted coding so far, I remain skeptical about the quality of the code, especially with larger LOC vs prompt size ratio. Though to be fair, I've certainly seen a lot of much worse codebases produced by humans than AI could ever make 😅 When writing production-ready code which is supposed to be maintained over longer period of time in a team setting, I still like to keep tight control over its quality. Working in small steps is my current way of doing it.