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

A staff engineer's journey with Claude Code

sanity.io

Post reply on HN
Print view View original

311–320 of 410 posts

Re: A staff engineer's journey with Claude Code

#311

Post by TiredOfLife »

bsder wrote: post #174
ale wrote: post #45

It’s about time these types of articles actually include the types of tasks being “orchestrated” (as the author writes) that aren’t just plain refactoring chores or React boilerplate. Sanity has quite a backlog of long-requested features and the message here is that these agents are supposedly parallelizing a lot of the work. What kind of staff engineer has “80% of their code” written by a “junior developer who doesn…

We have all these superpowered AI vibe coders, and yet open source projects still have vast backlogs of open issues. Things that make you go "Hmmmmmm."

The projects that have those backlogs dont allow ai made code

Re: A staff engineer's journey with Claude Code

#313

Post by imtringued »

yahoozoo wrote: post #113
nostrademons wrote: post #39

Earlier quoted context omitted.

I've found that an effective tactic for larger, more complex tasks is to tell it "Don't write any code now. I'm going to describe each of the steps of the problem in more detail. The rough outline is going to be 1) Read this input 2) Generate these candidates 3) apply heuristics to score candidates 4) prioritize and rank candidates 5) come up with this data structure reflecting the output 6) write the output back to…

How does a token predictor “apply heuristics to score candidates”? Is it running a tool, such as a Python script it writes for scoring candidates? If not, isn’t it just pulling some statistically-likely “score” out of its weights rather than actually calculating one?

You can think of the K(=key) matrix in attention as a neural network where each token is turned into a tiny classifier network with multiple inputs and a single output.

The softmax activation function picks the most promising activations for a given output token.

The V(=value) matrix forms another neural network where each token is turned into a tiny regressor neural network that accepts the activation as an input and produces multiple outputs that are summed up to produce an intermediate token which is then fed into the MLP layer.

From this perspective the transformer architecture is building neural networks at runtime.

But there are some pretty obvious limitations here: The LLM operates on tokens, which means it can only operate on what is in the KV-cache/context window. If the candidates are not in the context window, it can't score them.

Re: A staff engineer's journey with Claude Code

#314

Post by sunir »

rhubarbtree wrote: post #212

Does anyone have a link to a video that uses Claude Code to produce clean robust code that solves a non trivial problem (ie not tic tac toe or a landing page) more quickly than a human programmer can write? I don’t want a “demo”, I want a livestream from an independent programmer unaffiliated with any AI company and thus not incentivised to hype. I want the code to have subsequently been deployed in production and de…

I’ve built an agent system to quality control the output following my engineering know how.

The quality is much better but it is much slower than a human engineer. However that’s irrelevant to me. If I can build two projects a day I am more productive than if I can build one. And more importantly I can build projects that increase my velocity and capability.

The difference is I run my own business so that matters to me more than my value or aptitude as an engineer.

Re: A staff engineer's journey with Claude Code

#315

Post by specialist »

spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

> ...until everyone gets tired of talking about [LLMs]

Small price to pay for shuffling Agile Manifesto off the stage.

Re: A staff engineer's journey with Claude Code

#316

Post by theshrike79 »

spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

> - The code that is written by LLMs always needs to be heavily monitored for correctness, style, and design, and then typically edited down, often to at least half its original size

For this language matters a lot, if whatever you're using has robust tools for linting and style checks, it makes the LLMs job a lot easier. Give it a rule (or a forced hook) to always run tests and linters before claiming a job is done and it'll iterate until what it produces matches the rules.

But LLM code has a habit of being very verbose and covers every situation no matter how minuscule.

This is especially grating when you're doing a simple project for local use and it's bootstrapping something that's enterprise-ready :D

Re: A staff engineer's journey with Claude Code

#317

Post by theshrike79 »

sunir wrote: post #308
spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

All true if you one shot the code. If you have a sophisticated agent system that uses multiple forward and backward passes, the quality improves tremendously. Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year…

> Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year as well.

Currently it's just VC funded. The $20 packages they're selling are in no way cost-effective (for them).

That's why I'm driving all available models like I stole them, building every tool I can think of before they start charging actual money again.

By then local models will most likely be at a "good enough" level especially when combined with MCPs and tool use so I don't need to pay per token for APIs except for special cases.

Re: A staff engineer's journey with Claude Code

#318

Post by red-iron-pine »

chamomeal wrote: post #299
spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

Yeah every time I see one of these articles posted on HN I know I'll see a bunch of comments like "well here's how I use claude code: I keep it on a tight leash and have short feedback loops, so that I'm still the driver, and have markdown files that explain the style I'm going for...". Which is fine lol but I'm tired of seeing the exact same conversations. It's exhausting to hear about AI all the time but it's fun t…

> Which is fine lol but I'm tired of seeing the exact same conversations.

makes me think the bots are providing these conversations

Re: A staff engineer's journey with Claude Code

#319

Post by coldpie »

chamomeal wrote: post #299
spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

Yeah every time I see one of these articles posted on HN I know I'll see a bunch of comments like "well here's how I use claude code: I keep it on a tight leash and have short feedback loops, so that I'm still the driver, and have markdown files that explain the style I'm going for...". Which is fine lol but I'm tired of seeing the exact same conversations. It's exhausting to hear about AI all the time but it's fun t…

I'm thiiiis close to writing a Firefox extension that auto-hides any HN headline with an LLM/AI-related keyword in the title, just so I can find something interesting on here again.

Re: A staff engineer's journey with Claude Code

#320

Post by tempoponet »

theshrike79 wrote: post #317
sunir wrote: post #308

Earlier quoted context omitted.

All true if you one shot the code. If you have a sophisticated agent system that uses multiple forward and backward passes, the quality improves tremendously. Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year…

> Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year as well. Currently it's just VC funded. The $20 packages they're selling are in no way cost-effective (for them). That's why I'm driving all available models…

Once local models are good enough there will be a $20 cloud provider that can give you more context, parameters, and t/s than you could dream of at home. This is true today with services like groq.
Post reply on HN