Hacker News Reader

Comment by retrac | Hacker News Reader

For fun I've been vibe coding something I know well: toolchains. Maybe not the right thing to vibe code. But I can more or less judge the quality of the output.

When left to its own devices with the instructions "make an assembler for the architecture in ISA.md" -- well Claude picked Python as the implementation language. Tokens lifted through a bunch of regex. No expression parser! Oh dear. My first assembler was like that too, to be fair.

However, when I described the desired passes and their types:

    collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text)
    
    runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)])
    
    evalExpr :: Text -> Map Text Text -> Either AsmError Int

etc. It was almost one-shot. About 20 minutes until I was happy. Assembles all the test programs correctly. Code is mediocre in many places. But it would have taken me weeks to implement.

View on HN

So where AI has deterministic inputs and outputs it is extremely good to the point I think that there's a theoretical issue around computational there.

Like - it can do the work for us.

It jives with post training and verifiable rewards.

The reason AI doesn't do well at 'architecture' is 1) are are bad at it and have given it a lot of mush and 2) we don't have good abstractions for it.

The result is - you stick to 'very strong conventions' and if you walk of that path you're risking a lot.

Toolchains are very deterministic, the AI can take it apart and re-assemble like Lego - and each level of the space is also deterministic. It's perfect for AI.

> The reason AI doesn't do well at 'architecture' is [...] 2) we don't have good abstractions for it.

Maybe it's time for an architecture-oriented programming language?

https://objective.st

https://dl.acm.org/doi/10.1145/3689492.3690052

I have found that if you give it a pre-baked architecture to work within it works really well. It's not really what you'd use here, but just saying "this project uses a ports and adapters architecture" can stop it from generating mush by default. I think it's not so much that they're bad at it as that they don't have a clear reason to pick something other than mush. And not just "something" - a specific something, from a fairly short list of architectures suitable for your problem domain.

Yes, totally,with examples and references.

But there's something existential there maybe?

NASA says, any time you make a program that has a new 'launch vehicle' (aka architecture) - the whole project is the 'launch vehicle'.

'Oh, you want use a new architecture? Welcome to the cesspit of hallucination!'

Basically, there's a lot more complexity than we might imagine 'hidden in the nothingness' of he unknown.

Pick a 'known off-the-shelf launch vehicle' first ... then you design the landing craft

LLMs are bringing us back to all the “proper” software engineering stuff that we’ve always known we should be doing, but until now we never had enough time/people/money to do it right.

Brainstorming and research before writing a design.

Writing a design or spec before writing the code.

Comprehensive unit tests.

Etc etc etc.

Like you, I get vastly better output from the tool when I create a detailed spec in markdown before I let it start coding. And bonus, the LLM is pretty good at helping with the spec too.

I’ve found the opposite. It’s making people lazy. We used to plan stuff and now it’s just dump this LLM created spec to an LLM and ship the code.

Yes that too but performing detailed planning is a minority viewpoint from what I've seen till now. Many Devs jump straight to code after briefly skimming the jira record.

yep and a side effect it is bringing back waterfall.

It doesn’t even to be that complex. You can just say do comprehensive research and analysis in the space and give me an implementation plan. Then if it is 20 steps, I ask it to implement 3-5 at once. It’s essentially been one shot for everything I can throw at it.

>Code is mediocre in many places.

As if code written by devs at major corporations is't mediocre at best.

Nokia's Symbian OS took days to build. Days. With a D. Not minutes, not hours but days.

One of our devs shipped code to prod with a memory leak thanks to including a library that had "do not use this library in production because it causes a memory leak" written everywhere as warning.

So I don't wanna hear about how poor AI code is when human code is shit too. Human laziness and stupidity can beat AI hallucinations.

Sure, maybe your DeepMind, OpenAI devs and your John Carmacks of the world can beat AI code 100% of the time, but most workers most companies get don't have John Carmack as candidates.

I agree with what you’re saying but I think the difference is many managers and above think that AI is infallible or at least much less so than it actually is and that causes problems.

Everyone is aware that humans write poor code and treat the code as so. Not so with AI code. I’ve seen devs and managers cut corners in testing/reviewing code cause AI wrote it and they think it’s solid. Sure you could blame anyone cutting corners, and that would be technically correct, but the notion is so deeply embedded in many managers and higher ups that’s it’s hard to fight back. AI companies push this narrative and many individuals who do not routinely use it believe it. There is a manager at my company who loves to reference a video anthropic released last year claiming that Claude could build an app start to finish essentially unaided. He believes it’s the lack of user skill that’s the issue and not a false claim by a startup trying to make as much money as possible.

> I think the difference is many managers and above think that AI is infallible

Good for them. I hope they believe this because one of two things will happen.

Either they win on the free market because they went all in on AI and beat their competition thanks to AI productivity increases.

Or, their AI code is shit and they collapse and go bankrupt, and get beaten by the competitors using human written code so then they win on the free market proving AI is useless.

So if AI is good or bad for productivity, the free market will ultimately decide.

My take is that AI is just an amplifier of existing skill. 1x devs using AI can use it to be 10x devs, 10x devs can become 100x devs, while -1x devs will be -10x devs and so on.

Quite an extreme view. Chances are it lands someplace in the middle.

I keep telling people that they have to design and think about it first and then go to the tool, but they keep saying “Claude can plan too” and obviously it produces some shit that requires a lot of changes while when I get it to go I can almost always one shot the stuff I want because I am actually putting in the time to give it a detailed plan of what to do.

Even just saving me the time to deal with CI is worth it.

Effective planning with LLMs isn’t prompting “design me a system” - it’s asking “how would a system to accomplish x be designed” and then engaging in dialogue and research with the LLM as an assistant and critic - running outputs through other agents for further critique and refinement - asking for justifications of decisions you are not informed enough to evaluate properly yourself. It is entirely possible to develop strong systems outside of your current skill and knowledge with methods like this. When done properly your own knowledge should have grown to meet the product you end up with.

> It is entirely possible to develop strong systems outside of your current skill and knowledge with methods like this.

If this is true how can you confidently make this assertion.

You yourself are not in a position to evaluate it, you are just running it through a couple times hoping for a "oh wait, you're right to call me out on that, that is not correct at all".

1. Tell it to find docs and research best practices.

2. Ask for references and read them.

> When done properly your own knowledge should have grown to meet the product you end up with.

I've found relying on my own research first for a local LLM works much better. Asking a biased source to find it's own research will result in biased research.

It sounds like people are treating it exactly like managers treat software engineers

"Here's my idea, go build it please"

"Can I ask you questions about it?"

"Hey, You're the engineer you figure it out. That's why I pay you"

Tale as old as time

Reply on news.ycombinator.com