enobrev

Security questions have always been ridiculous, but I'll especially never understand how "favorite [thing]" ever made it to production anywhere. "Favorite movie" can change multiple times in the same conversation.

I love it! So much fun. Thanks for adding Free Play!

This is so well done and very cool. Thanks for building it and offering it.

As someone who hasn't had a piano lesson in about 40 years, I find myself wanting to play with the keys to match the melody. So I hear the initial melody, and then I'm practically hitting keys at random (guessing where I should be on the keyboard) until I find the first note, and then I have to listen over and over again while trying to find the second note. I kind of want to hunt and peck until I'm ready and then get tested to see if I nailed it.

I've done a similar thing with close friends and family who would constantly ask me things I couldn't possibly know because I always came up with an answer.

Eventually I realized why and explained, "you know, I'm really just going to do a web search for what you just asked me, and maybe a couple more until I have a decent answer and then give you that answer. Let me show you how I would go about that".

From then on, they started getting into the habit of doing that for themselves. I think now with LLMs, they've kept the habit, but the LLM gives a more complete answer with fewer steps so it becomes the default. I think the magic of AI is two-fold (well, more than two, but two bullets for this conversation).

1. You don't have to "query". You can just braindump, and it'll build a context and figure out what you're looking for

2. It's conversational, so instead of filtering and tweaking results from the first query, your second "query" builds on top of the context from the first question, and you get a stronger result as the conversation continues.

I've had cases where it doesn't explicitly use a skill I've added BUT it still performs the actions described in the skill on its own more often than it did before I created the skill. I'd rather it use the skill for consistency, but having it follow most of the steps most of the time in cases I've forgotten to explicitly call out the skill is a better outcome.

I really appreciate this post. It reminds me of a video I watched a couple years ago that does an excellent job of demonstrating how culling works with actual code and visuals

https://www.youtube.com/watch?v=CHYxjpYep_M

I'm similarly unpredictable in my home. Add to that the others in my house, and it's impossible to even guess what everyone's intentions are at any given time.

Sometimes I daydream about a "solo mode" where the timings on lights are tighter and my music can follow me around the house when I'm up at night and nobody else is. But most times I'm trying to find the get-out-of-way averages that keep everyone happy.

Some things work great: Automated lights everywhere. Automated dimming of lights at night or sunset or whatever. Notifications when the laundry is done, or the cat litter is ready to be changed, or someone is at the door, or the garage door has been left open - all great. What music to play in what room at any time? Always changes. When to "dim all the lights" because Plex started a movie? But my son is building Legos in the dining room, and my wife is knitting and needs the couch light on. Sometimes I want it, but not every time.

For those things having a single button press is still a huge win over opening multiple apps and getting the right things set the right way for each participant.

I feel like dealing with robo-calls for the past couple years had led me to this conclusion a bit before this boom in ai-generated text. When I answer my phone, if I hear a recording or a bot of some sorts, I hang up immediately with the thought "if it were important, a human would have called". I've adjusted this slightly for my kid's school's automated notifications, but otherwise, I don't have the time to listen to robots.

I have the same issue. Even when I ask it to do code-reviews and very explicitly tell it not to change files, it will occasionally just start "fixing" things.

My house is 150 years old, but it's also been rebuilt several times in that time. My neighbors' houses are less than a decade old. We have all swapped stories about replacing things behind drywall. Leaks. Electrical issues. Ducts. Everything. Consider yourself lucky if you have not. 50 years is not the number you should bet upon.

In Chicago, code requires EMT for all electrical, which can be annoying for adding a new run, but at the very least it makes it less likely for rodents to chew through or other interference.

After wiring my whole house with Ethernet and ceiling speakers, and now dealing with a couple leaky pipes and several problems from previous owners, I'm considering ways to make these things easily accessible/replaceable while keeping an eye toward aesthetics.

For sure. I've wired my old house with speakers in every ceiling, and cat-6 in every room. I've had a small pipe burst and a couple leaks behind a bathroom.

I've patched quite a bit of drywall, and I'm about mediocre at it. But it seems so silly and unnecessary to me.

Everything else in this world that requires maintenance comes with access panels and other means of easy access. In our living spaces, some of which should ideally last tens of years (mine is from the 1890s), we seal it all away.

I watched a video recently, which I can't find, where an architect set up a beautiful wooden baseboard around the entirety of their property, and that baseboard held all mechanicals and was perfectly clean and easy to get into as needed.

Drywall is manageable and cheap, I agree. But it's more painful than it should be for something that _will_ require maintenance.

I will never understand why we fill our walls with mechanical and electrical infrastructure and then wrap them in a paper and plaster, which then needs to be torn, broken, and repaired in order to maintain said infrastructure.

Pipes will fail. Wires will fail. Ducts will fail. Maybe not in 5 years, but over the span of 20, they will. Why make them so frustratingly inaccessible?

It wasn't clear to me that this was a joke either. I assume the same for others since the post is grayed out.

I can only wear tall-size clothing, and generally I've found that none of my t-shirts shrink "in", but they _all_ shrink "up". I can make them last longer washing them delicate and "air-drying" (in the dryer, light or no heat), but eventually they all get shorter. I have to replace most of my undershirts annually, and I rarely bother with t-shirts anymore.

I haven't used cursor, so I'm not sure I can be much help there. I've been mostly using claude code and IntelliJ IDEs for code-reviews when necessary. Over the past year I've moved to almost entirely coding via agent. Maybe my input will be helpful.

One very important thing to keep in mind is context management. Every time your agent reads a file, searches documentation, answers a question, writes a file, or otherwise iterates on a problem, the context will grow. The larger the context gets, the dumber the responses. It will basically start forgetting earlier parts of the conversation. To be explicit about this, I've disabled "auto-compact" in claude code and when I see a warning that it's getting too big, I cut things off, maybe ask the agent to commit, or write a summary, and then /compact or /clear. It's important to figure out the context limits of the model you're using and stay comfortably within them.

Next, I generally treat the agent like a mid-level engineer who answers to me. That is to say, I do not try to convince it to code like I do, instead I treat it like a member on my team. When I'm on a team, we stick to standards and use tools like prettier, etc to keep the code in shape. My personal preferences go out the window, unless there's solid technical reason for others to follow them.

With that out of the way, the general loop is to plan with the agent, spec the work to be done, let the agent do the work, review, and repeat. To start, I converse with the agent directly. I'm not writing a spec, I'm discussing the problem with the agent and asking the agent to write the spec. We review, and discuss, and once our decisions are aligned and documented, I'll ask it to break down how it would implement the plan we've agreed upon.

From there I'll keep the context size in mind. If implementation is a multi-hour endeavor, I'll work with the agent to break down the problem into pieces that should ideally fit into the context window. Otherwise, by this point the agent will have asked me "would you like me to go ahead and get started?" and I'll let it get started

Once it's done, I'll ask it to run lint, typechecks, automated testing, do a code review of what's in the current git workspace, compare the changes to the spec, do my own code reviews, run it myself, whatever is needed to make sure what was written solves the problem.

In general, I'd say it's a bad idea to just let the agent go off on its own with a giant task. It should be iterative and communicative. If the task is too big, it WILL take shortcuts. You can probably get an agent to rewrite your whole codebase with a big fancy prompt and a few markdown files. But if you're not part of the process, there's a good chance it'll create a serious mess.

For what you're doing, I would likely like ask the agent to read the mega python file and explain it to me. Then I would discuss what it missed or got wrong and add additional context and explain what needs to be done. Then I would ask it if it has any suggestions for how we should break it into submodules. If the plan looks good, run with it. If not, explain what you're going for and then ask how it would go about extracting the first submodule. If the plan looks good, ask it to write tests, let it extract the submodule, let it run the tests, review the results, do your own code review, tweak the formatting, Goto 10.

Additionally funny (and ironic) that the term "henge" comes from Stonehenge, even though Stonehenge is technically not a henge.

I had this exact same experience in ravenswood this weekend. I was walking to breakfast and one of these bots was blocking the entirety of the shoveled part of the sidewalk. I had to make may way into the snow to inch around the bot just so I could continue to use the sidewalk.

I had guessed it was stopped because it came to an unshoveled portion of the sidewalk. If it can't traverse that, it's not made for this city

I'm not fundamentally mad as these bots. But if they don't figure out how to make them work with other pedestrians, then I'm going to start cheering on any vandalism delivered upon them.

I wholeheartedly agree that it's significantly worse than single-payer, but to say it hurt young people simply doesn't match reality as I saw it play out.

The ACA allowed me to get insurance for the first time since I'd left home several years before. I knew lots of other freelancers at the time who were in the same boat.

Of course in the following years, insurers found plenty of loopholes to increase prices significantly year over year - and this is why leaving the middlemen in the middle was a TERRIBLE choice - but at the very least the quality of those plans still has a reasonable low bar.

I still find myself on the ACA from time to time. I can't afford it. But the plans are still significantly better and thus more affordable than what was available before.

Whenever people visit during the warmer months, I almost always recommend or take them on the Architectural tour. The tour guides are knowledgeable, friendly, and tell great stories. The actual tour is a treat - even if you don't care about the architecture or history, it's a nice way to spend some time on the river. And there's a bar on the boat. My 5-year-old even sat still for the whole ride last month (and there's a place to get ice-cream you can eat while waiting in line to board).

This is what slows me down most. The initial implementation of a well defined task is almost always quite fast. But then it's a balance of either...

* Checking it closely myself, which sometimes takes just as long as it would have taken me to implement it in the first-place, with just about as much cognitive load since I now have to understand something I didn't write

* OR automating the checking by pouring on more AI, and that takes just as long or longer than it would have taken me to check it closely myself. Especially in cases where suddenly 1/3 of automated tests are failing and it either needs to find the underlying system it broke or iterate through all the tests and fix them.

Doing this iteratively has made the overall process for an app I'm trying to implement 100% using LLMs to take at least 3x longer than I would have built it myself. That said, it's unclear I would have kept building this app without using these tools. The process has kept me in the game - so there's definitely some value there that offsets the longer implementation time.

I think there's something of a pendulum here, and I agree it's swayed too far to over-diagnosing ourselves. But I also think of my father who passed a couple years ago.

We didn't have much of a relationship. He had friends, but never close ones. He was weirdly mean or weirdly seclusive or weirdly awkward at times - and also incredibly intelligent and occasionally gracious and hilarious.

After he passed, I wondered if he might have been somewhere on the spectrum - but his peculiarities were simply ignored. A poor boy, in a poor urban neighborhood, with a dead father, being raised by an immigrant mother and immigrant siblings doesn't get diagnosed with much of anything - if they see doctors at all. And hey, he had a near photographic memory, and did great in school, so what's there to worry about?

It's always been "how he was", and that's probably ok, but I do wonder if he would have had a better or somehow different life if he knew more about _why_ he was the way he was.

I'm surprised by this take, simply because of my own experience, where the further I've gotten from religion over a very long time, the less significant I've found death.

Not having "answers" to what comes next has never been a weight for me - at least not since I was a child. Death being a completion, or a finality, is freeing; The end of what has been and what I hope continues to be a wonderful journey. The only weight I carry in regards to death are for those closest to me, and especially those for whom I'm responsible.

In theory, I'm a fan of it. I think getting a working mock-up as a demonstration of an idea is far better than building something from a few napkin sketches and then iterating while we close in on the original vision.

As for my own work, I just spent a couple hours this afternoon in a back and forth discussion with claude code, asking it to mock up a UI for me before "we" start building it tomorrow. It was just a mock-up, so I didn't require precision, but I was impressed with some tidbits that came along for the ride.

Some things it did without me asking

* Mock data for the lists and pages in json format, so I could easily add records to it for different scenarios

* Working navigation between pages, including modals

* Working progress bars and timers

* Working list sorts and filters

* Toasts for functionality that was beyond the scope of the mock-up ("sending email to author of post" or "banning user")

* Not-half-bad animations and transitions between pages, screens, modals, etc

* A responsive layout that worked better than expected on mobile and desktop

* Some ideas I hadn't considered, that we then expanded upon

I would have mocked this up for a client, but not for myself. It's quite nice to have a working html / javascript / css mockup to play with while I flesh out my own ideas - with a benefit that I actually fully understand the output and can tweak it myself as needed.

I grabbed a cheap one for my 5 year old with some blank tapes. I remember how much I loved recording my voice, or the TV, and eventually LOTS of radio. Tangible media has more weight than just the physical object. Especially in something as durable as a cassette.

It comes in bursts but when he's into it, he has a ton of fun, The manual nature of it is confusing for him (he's used to instant gratification), like waiting a few seconds at the beginning of the tape so he can record, but something about a cassette makes the whole process easier to explain and, I hope, to understand and visualize.

Not sure if you meant to post here intentionally, but also there's an Ask HN specifically for people who want to be hired.

https://news.ycombinator.com/item?id=45093190

I'm ok on speed. Not 10x or anything, but I've been writing full-stack web apps and websites from scratch for a quarter century.

The issue is getting the LLM to write _reasonably decent_ code without having to read every line and make sure it's not doing anything insane. I've tried a few different methods of prompting, but setting up a claude sub-agent that's doing TDD very explicitly and ensuring that all tests pass after every iteration has been most effective.

My first attempt was so fast, it was mind-bending. I had a "working" App and API running in about a day and a half. And then when I tried to adjust features, it would start changing things all over the place, LOTS of tests were failing, and after a couple prompts, I got to a point where the app was terribly broken. I spent about a day trying to prompt my way out of a seemingly infinite hole. I did a more thorough code review and it was a disaster: Random code styles, tons of half-written and abandoned code, tests that did nothing, //TODOs everywhere, and so, so many tweaks for backwards compatibility - which I did NOT need for a greenfield project

At that point I scrapped the project and adjusted my approach. I broke down the PRD into more thorough documentation for reference. I streamlined the CLAUDE.md files. I compiled a standard method of planning / documenting work to be done. I created sub-agents for planning and implementation. I set up the primary implementation sub-agents to split up the spec into bite-sized portions of work ("30-45 minute tasks").

Now I'm at the opposite side of the spectrum - implementation is dog slow, but I rarely have to read what was actually written. I still review the code at large after the primary tasks are finished (comparing the feature branch against main in my IDE), but for the most part I've been able to ignore the output and rely on my manual app tests and then occasionally switch models (or LLMs) and prompt for a thorough code-review.

The specs would not likely have happened at all, since this is a solo project; although this experience has led me to want to write these things out more thoroughly, even for myself. It's impressive how little work I need to put in going this route to have fairly thorough actionable specs for pretty much every major decision I've made through the process.

The commits - some would be detailed, plenty would have been "typo" or "same as last commit, but works this time"

The tests - Probably would have been decent for the API, but not as thorough. Likely non-existent for the UI.

As for time - I agree with the other response - I wouldn't have taken the time.

it doesn't seem to be making me any more efficient

That's been my experience.

I've been working on a 100% vibe-coded app for a few weeks. API, React-Native frontend, marketing website, CMS, CI/CD - all of it without changing a single line of code myself. Overall, the resulting codebase has been better than I expected before I started. But I would have accomplished everything it has (except for the detailed specs, detailed commit log, and thousands of tests), in about 1/3 of the time.