Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Huzzah – a novel approach to coding with AI

danielvaughn.dev

Post reply on HN
Print view View original

151–160 of 234 posts

Re: Show HN: Huzzah – a novel approach to coding with AI

#151

Post by vivzkestrel »

" I also don’t want to go back to writing all my code manually "

- a whole generation of you guys are going to regret this decision very seriously 5 years down the line

- mark my words

- just like how studies are being published currently on how meta algorithms are designed to have you hooked and causes brainfart, 5 yrs down the line , studies ll come out showing how LLMs have caused degradation in critical thinking and coding for programmers

- A whole batch of people ll be forced to go back to the basics is how this ll end

Re: Show HN: Huzzah – a novel approach to coding with AI

#153

Post by globular-toast »

lofties wrote: post #150
danielvaughn wrote: post #138

Earlier quoted context omitted.

Yes exactly. Except now, the language has zero constraints. It can be a perfect distillation of your intentions. You might think, well code is perfect. But code is syntactically perfect, because it has to be. Because compilers can handle very little ambiguity. But that doesn't mean it's a perfect representation of your thoughts. A huge part of language design is for the compiler, not for the author. And I'm not 100%…

I could do this before too. The way I work is that I just write some functions, fully annotated, in whatever language the project is in, with a comment on what I expect the code to do, and an empty return. Then get an LLM to fill in the functions. Helps me think about the problem, like your post mentioned, but I don't have to pay a tax on converting a prototyping language to a different language.

This is how I liked to write software pre-LLM. Top down. Write the interface and tests first, implementation second. I think I got it from SICP. "Wish-driven programming" I think I heard once.

Re: Show HN: Huzzah – a novel approach to coding with AI

#154

Post by cyteeditor »

As someone who collaborates with AI programming tools daily, I understand this feeling of exhaustion.

My project is a rich text editor SDK, with a considerable amount of code. AI tools are indeed very useful for writing glue code and generating boilerplate code. However, when faced with complex cross-browser compatibility issues (such as parsing mso-* CSS pasted from Word), AI is basically useless; I still have to understand the problem domain and write the code manually.

The idea of converting pseudocode to source code is interesting. The key is whether the pseudocode can clearly express the intent—if the intent itself is complex, the pseudocode may not be much shorter than the actual code.

Re: Show HN: Huzzah – a novel approach to coding with AI

#156

Post by rpunkfu »

avaer wrote: post #36

I think the reverse direction is more important: taking a massive complex problem/codebase and decomposing it to short pseudocode. Then you could edit the pseudocode and compile it back into the system. That's the way software engineers working on large projects work anyway: you first gather context on the state of the system and read it at a level you can understand. Then you propose a change on the simplified repre…

I think you might be interested in what I’m working on:

https://ctx.company/blog/introducing-ctx-traits/

Re: Show HN: Huzzah – a novel approach to coding with AI

#157

Post by pixelatedindex »

dotancohen wrote: post #147
pixelatedindex wrote: post #131

Earlier quoted context omitted.

I sympathize with this take but I think it’s conflating programming as a hobby vs code needed to run a business. I always believed that programming was solving problems and building things. With AI, you can still solve problems - the better your questions/ prompts the faster you get to your answer. To ask those questions you need to probably have that meditative thinking to grasp the crux of what you’re trying to sol…

When a business pays me to develop software, that's a lot more than coding. Sometimes it takes weeks to just translate the business needs into a plan, budget, and timeline (not that I ever meet it). Often that includes documentation, training, infra, and a maintenance contract (hopefully with retainer). The coding really is such a small part of that process.

Absolutely. And honestly, I don't think AI can really replace that. It can execute a plan, but it can't really figure out the best plan from a sea of unknowns strewn within people's minds. There's a certain meditative aspect to this stream of work still, but I would hesitate to call it "programming".

Re: Show HN: Huzzah – a novel approach to coding with AI

#158

Post by altmanaltman »

pizzly wrote: post #82
reticulates wrote: post #47

I think you’re probably missing why it’s exhausting. The problem is not writing English, it’s the rate of change. Programming is meditative, it is a thinking process, the code you output is an artifact of your thinking. Agent-based development… there is no thinking, no meditation, you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly. For businesses it makes sens…

Agree with programming is meditative but disagree that agent-based development means there is no thinking. Agent-based development means more thinking like a lower level manager. You spend more time making architecture decisions, making decisions on the user interface, trying to manage your time and your agents time to increase the amount of work produced in the same time, asking the agent about the code and making n…

But how many "architecture decisions" do you really have to make when it comes to any proper project? Also "making decisions on the user interface" is literally what frontend engineers have done for years (so you're still working as an engineer while you claim to be a "manager"). If you are in programming and programming is not your strong suite, the moral thing to do is either get better at programming or seek an actual manager job where it makes sense to use the "part of the brain" you are good at. Why do you need to pretend that being a good manager = being a good programmer? Why do you not care about being a good programmer and just the output of waht the agents are doing? You're purely thinking of it from a business pov and optimizing time but you're missing the individual programmer who actually sees value in programming and wants to get better.

Re: Show HN: Huzzah – a novel approach to coding with AI

#159

Post by danielvaughn »

lofties wrote: post #150
danielvaughn wrote: post #138

Earlier quoted context omitted.

Yes exactly. Except now, the language has zero constraints. It can be a perfect distillation of your intentions. You might think, well code is perfect. But code is syntactically perfect, because it has to be. Because compilers can handle very little ambiguity. But that doesn't mean it's a perfect representation of your thoughts. A huge part of language design is for the compiler, not for the author. And I'm not 100%…

I could do this before too. The way I work is that I just write some functions, fully annotated, in whatever language the project is in, with a comment on what I expect the code to do, and an empty return. Then get an LLM to fill in the functions. Helps me think about the problem, like your post mentioned, but I don't have to pay a tax on converting a prototyping language to a different language.

That’s exactly what this editor is for, except that your original written version is retained and source-mapped to the code that it generated. So as a project grows in size and complexity, you have a smaller foot print of human-written intent that acts as a reference. There’s no “prototyping language”, it’s just whatever you want to write.

Re: Show HN: Huzzah – a novel approach to coding with AI

#160

Post by duttish »

reticulates wrote: post #47

I think you’re probably missing why it’s exhausting. The problem is not writing English, it’s the rate of change. Programming is meditative, it is a thinking process, the code you output is an artifact of your thinking. Agent-based development… there is no thinking, no meditation, you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly. For businesses it makes sens…

For me thinking and understanding is the primary bottleneck. Sure I could spin up 4-5 more parallel things but it doesn't matter because they're soon bottlenecked by my writing/review of their input or output. I can manage 1-2, maybe 3 if one is a long term running task. And having thinking be the bottleneck makes for a very taxing workload...

I tend to work like this:

1. Write a very vague spec of what I want

2. Iterate on that with claude until there's no major open questions.

3. Depending on the size either turn that into a requirements file (large things), a design (medium things) or an implementation plan (small things). Implementation plans for large / medium tasks are split into phases.

4. Once all the plans are iterated on and approved I send claude off to implement with subagents, but not commit. I usually find some weird stuff when reviewing the code to fix before commit. Any time I've let claude commit I've ended up with weird stuff.

Post reply on HN