Comments URL: https://news.ycombinator.com/item?id=47904252

Points: 62

# Comments: 8

> This PR adds support for embedded Ruby (ERB) which is commonly used in Ruby on Rails projects. Note that I used heavy assistance from Claude Code and tried to ensure it didn't generate slop to the best of my abilities. All tests are passing and I also visually verified the end result which looks solid to me.

> Here's a screenshot that was generated by building the Chroma CLI with the ERB lexer and running it against the test data file with chroma --lexer=erb --style=monokai --html lexers/testdata/erb.actual

My findings:

1. The spec created by Superpowers was very detailed (described the specific fonts, color palette), included the exact content of config files, commit messages etc. But it missed a lot of things like analytics, RSS feed etc.

2. Superpowers wrote the spec and plan as two separate documents which was better than the collaborative method, which put both into one document.

3. Superpowers recommended an in-place migration of the blog whereas the collaborative spec suggested a parallel branch so that Hugo and Astro can co-exist until everything is stable.

And a few more difference written in [0].

In general, I liked the aspect of developing the spec through discussion rather than one-shotting it, it let me add things to the spec as I remember them. It felt like a more iterative discovery process vs. you need to get everything right the first time. That might just be a personal preference though.

At the end of this exercise, I asked Claude to review both specs in detail, it found a few things that both specs missed (SEO, rollback plan etc.) and made a final spec that consolidates everything.

[0] https://annjose.com/redesign/#two-specs-one-project

https://app.hncompanion.com/item?id=46962996

This post has 500+ comments with various viewpoints and you see the summary on the right side.

You are right that most of the time threads are organized into local groups. But in the above example, there are many comments that relate to the same topic, but are not under the same parent comment. HN Companion's summary surfaces this into a topic "Limitations of Current AI Models" which shows comments from up and down the post.

You can click on the author name in that topic in the summary panel, it will take you directly to the comment. This is what we meant by "continue the conversation there", i.e you are now in the main HN experience, so you can navigate to child/parent/sibling comments (through the link buttons or keyboard navigation).

We definitely don't want AI to write comments. Happy to elaborate if you need.

[0] https://huggingface.co/georgeck/models

Comments URL: https://news.ycombinator.com/item?id=46527626

Points: 4

# Comments: 0

1) Amen 2) I wonder if this is isolated to junior dev only? Perhaps it seems like that because junior devs do more AI assisted coding than seniors?

These are a good set of principles for any company (or individual) can follow to guide them how they use AI.

Comments URL: https://news.ycombinator.com/item?id=44218564

Points: 1

# Comments: 1

Just one feedback - on desktop browsers, I can see the list of answered clues below the textbox, but on the phone (Brave or Firefox on Android), I don't see that list. I am not sure if this is a feature or a bug, but it’s a feature I miss when playing on my phone. Seeing those answers gives that little “aha!” moment of satisfaction.

I also made a custom GPT - Bracket GPT [0] that helps in solving the clues when I am stuck. It doesn’t directly give the answers, but offers hints to help nudge you to the solution. It’s a fun companion when you're totally blanking.

[0] https://chatgpt.com/g/g-67e0f124cd408191943faadb3d70c6df-bra...

You can run it as: node summarize-comments.js Example: node summarize-comments.js 43597782

And the summary will be put in the "output" folder.

You need to set the environment variable (in this case OPENROUTER_API_KEY because LLama4 is currently available at OpenRouter).

These two lines really hit home:

> You don’t have to listen to any other voices here, except that quiet one inside of you that’s gently urging you to do the thing you know you need to do.

> You don’t need to know where it’s going to lead. For that matter, it doesn’t have to lead anywhere. Nothing ever has to come of it.

That freedom is everything. Just creating because it feels right (to me).

Comments URL: https://news.ycombinator.com/item?id=43500941

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43384531

Points: 3

# Comments: 0

The process - instead of typing code, I mostly just talked (voice commands) to an AI coding assistant - in this case, Claude Sonnet 3.7 with GitHub Copilot in Visual Studio Code and the macOS built-in Dictation app. After each change, I’d check if it was implemented correctly and if it looked good in the app. I’d review the code to see if there are any mistakes. If I want any changes, I will ask AI to fix it and again review the code. The code is open source and available in GitHub [2].

On one hand, it was amazing to see how quickly the ideas in my head were turning into real code. Yes reviewing the code take time, but it is far less than if I were to write all that code myself. On the other hand, it was eye-opening to realize that I need to be diligent about reviewing the code written by AI and ensuring that my code is secure, performant and architecturally stable. There were a few occasions when AI wouldn't realize there is a mistake (at one time, a compile error) and I had to tell it to fix it.

No doubt that AI assisted programming is changing how we build software. It gives you a pretty good starting point, it will take you almost 70-80% there. But a production grade application at scale requires a lot more work on architecture, system design, database, observability and end to end integration.

So I believe we developers need to adapt and understand these concepts deeply. We’ll need to be good at:

  - Reading code - Understanding, verifying and correcting the code written by AI
  - Systems thinking - understand the big picture and how different components interact with each other
  - Guiding the AI system - giving clear instructions about what you want it to do
  - Architecture and optimization - Ensuring the underlying structure is solid and performance is good
  - Understand the programming language - without this, we wouldn't know when AI makes a mistake
  - Designing good experiences - As coding gets easier, it becomes more important and easier to build user-friendly experiences

[0] https://en.wikipedia.org/wiki/Vibe_coding

[1] https://my-pomodoro-flow.netlify.app/

[2] https://github.com/annjose/pomodoro-flow

Spot on!

> Has an M2 Max with 64GB RAM but probably still complains when Chrome opens more than 5 tabs.

Not true, I have 40 tabs open!

> Created a tool to generate portfolios in 5 minutes but spent 5 hours explaining how to optimize YouTube settings. Priorities!

Ouch! Brutal and funny at the same time.

Thank you for making this!