Firfi's comments

Thank you (twice!) for reading it. The idea wrapped in a scandalous topic indeed, but the PR process ambiguity was also what was the last straw for me to write it.

That's one of my biggest frustrations - I wasted a lot of time on reprompting. I was making myself stick to 100% LLM approach for a while, in order to learn.

I can't say for everyone, but for me it's hit-and-miss: if LLM starts with "Oh, sorry, you're right" that's a STRONG signal I have to take over right now or rethink the approach, or I get into the doom spiral of reprompting and waste half a day on something I could've done myself by that point, with only difference that after half a day with a coding agent I discovered no important domain or technical knowledge.

So, "how much" to me depends so very much on seemingly random factors, including the time of the day when Antropic decides to serve their quantised version instead of a normal one. On non-random too, like how difficult the domain area is, how well you described it in the prompt, and how well you crafted your system queries. And I hate it very much! At this point, I'm trigger-happy to take over the control and write the stuff that LLM can't in the "controlling package" and tell it to use it as an example / safety check.

It seems to me we have to find out how to figure out "what matters" to have the benefits that 10x vibe coder bros promise. I think we still have to review (despite my clickbait title), it's just different things that we are looking for in slop, and different type/amount of mental strain required. For more important libs, I guess we can "overshoot" a bit and put more time into vetting vibe code (and making it the guardrail code). While in the "next revolutionary React Todo App" the balance could be much farther towards vibe...

I actually do recommend reviewing manually - it's just very convenient to see when a person wrote something (then much more scrutiny can be applied) vs. when the work was outsourced to AI. I feel like there is another application though, but didn't mention it for it's not that clear to me yet: you can yet again estimate whether a new programmer can actually code or if they 10x YOLO their way slowly bringing codebase maintainability down.

Just feeling and experience, really. For me, if I spent time with the vibe code snippet and improved it until I can say "yes I would've written this" it's not slop anymore, even if it was written by Claude initially.

On the contrary, if I glanced over the code and could say "ok it doesn't look terrible, no obvious `rm -rf` and all", even if I changed a couple obvious mistakes, I still consider it vibe.

After some vibe coding frustrations, ups and downs, I found that splitting the code explicitly into well-curated, domain-heavy guidance code and code marked “slop” can solve a lot of frustration and inefficiency.

We can be honest in our PR, “yes, this is slop,” while being technical and picky about code that actually matters.

The “guidance” code is not only great for preserving knowledge and aiding the discovery process, but it is very strong at creating a system of “checks and balances” for your AI slops to conform to, which greatly boosts vibe quality.

Helps me both technically (at least I feel so) with guiding claude code to do exactly what I want (or what we agreed to!) and psychologically because there's no detachment from the knowledge of the system anymore.

Hey folks, sometimes on PRs, I find that people aren't well-versed in the intricacies of code branching. So, I wrote a short article to educate fellow engineers and point to it sometimes so I don't have to explain things over and over.

Specifically, many people apparently don't know yet about exhaustiveness and the statement/expression dichotomy and how TS type system can help with it.

An app with typescript validators features tests. The test case is based on real use cases but is kept generic. Tests more advanced stuff like algebraic data types, template literals, nominal types, and recursive types. It's not a performance/size benchmark; there's a really nice performance benchmark app that exists already (I linked it there).

Hey, sharing my colleague's @juanArias8 article on Solana Mobile here. He'll answer questions/comments in this thread if any popup.

We joked with my colleague that this post about real-time text-to-speech lipsync of his was either born too late because Sora is here to rule the industry or too early because his solution is tailored better than Sora for the specific task. Anyway, it's an ironic coincidence that he finished writing it before OpenAI released their video monster

They use N-tier architecture and FastAPI to build a scalable Zulip bot that can retrieve messages, links, and images from Zulip

Author here! I've added it to my TODO list and will update the article at some point coming week or two. Love how the library looks like - thank you for the link!

"Fear" could be a wrong word here. I think there's contempt involved instead. Which isn't justified either though. Everything is a tool, and should be used in a right context. I.e. for loops can be better justified sometimes (I find them useful around 1% of cases, but when they are they do their job well)

Why not rewrite it to for loops, we need to also accommodate for the programmers who don't know what's .map.

SEEKING WORK | REMOTE | (UTC +7)

Remote: Yes, 9 years of remote experience, as a lead developer as well

Willing to relocate: Yes

Résumé/CV: http://www.loskutoff.com/resume.pdf

Availability: Full-time, although 30h/week is a bit more favorable

Email: igor [at] loskutoff.com

Upwork profile: https://www.upwork.com/fl/upwork

Have built web apps from scratch and have improved existing ones. Good at reworking existing poor/insufficient solutions.

Made (backend) apps/components with Typescript (Node, various incl. Next.js, Meteor), Rails, Java (Dropwizard), and small-ish apps with Scala (Akka HTTP), Rust (Hyper). With SQL (Postgres, MySql, Oracle), Mongo, Redis, and Elastic Search for Data storage layer.

Made (frontend and mobile) apps with Typescript-ed React (+React Native), Redux, Mobx, GraphQL/Apollo, Angular

Deployed components with Jenkins (+Ansible), DigitalOcean Apps (+Docker), GitHub Actions, AWS (Beanstalk), Heroku

Made components work together with the AWS stack (DynamoDB, SQS, Lambda/API Gateway), RabbitMQ, Zookeeper

Collaborated using such tools as Git (Github), various task trackers/boards

An ethic I’m looking for in a team is “I’m going to build upon this [code, infra, solution] in a year from now; will I thank myself then?”. Seeing solutions through; product-oriented.

Enthusiastic about: FP, Haskell, Rust

Can you offer them to pay with your unused connects thought? They seem to regard them very high!

SEEKING WORK - Remote

Remote: Yes

Willing to relocate: Yes

Technologies: Javascript, Node, React, Rails

I have 4 years remote independent contracts experience, besides previous office jobs experience. Worked with clients directly the whole time. Doing Rails and JS full stack (React, Redux, Angular). Can do Java and Scala as well. Passionate and interested in functional programming practices.

Résumé/CV: http://www.loskutoff.com/resume.pdf

https://github.com/Firfi

Email: [email protected]

SEEKING WORK - based in Moscow, remote/relocation

Remote: Yes

Willing to relocate: Yes

Technologies: Javascript, Node, React, Rails

A self-taught developer who started with Php and Java then moved to Rails then to JS full stack. Currently, maintain Meteor/React violin learning app, Scala slack bot and working on JS telegram MVC bot family.

Résumé/CV: http://www.loskutoff.com/resume.pdf https://github.com/Firfi

Email: [email protected]