Live data from Hacker News

A staff engineer's journey with Claude Code

sanity.io

261–270 of 410 posts

Re: A staff engineer's journey with Claude Code

#261

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…

Armin Ronacher (long-time Python and Rust open source community figure, creator of Flask and Jinja among others) has several YouTube videos that partially fit the bill. https://www.youtube.com/watch?v=sQYXZCUvpIc and https://www.youtube.com/watch?v=Y4_YYrIKLac and https://www.youtube.com/watch?v=tg61cevJthc

Re: A staff engineer's journey with Claude Code

#262

Earlier quoted context omitted.

This video [0] is relevant, though it actually supports your point - it shows Claude Code struggling with non-trivial tasks and needing significant hand-holding. I suspect videos meeting your criteria are rare because most AI coding demos either cherry-pick simple problems or skip the messy reality of maintaining real codebases. [0] https://www.youtube.com/watch?v=EL7Au1tzNxE

Great video! Even more, shows a few things - how good it is with such a niche language but also exposes some direct flaws. First off, Rust represents quite a small part of the training dataset (last I checked it was under 1% of code dataset) in most public sets, so it's got waaay less training then other languages like TS or Java. You added 2 solid features, backed with tests and documentation and nice commit message…

> #1: Add a subagent for git that knows your style, so you don't poison direct claude context and spend less tokens/time fighting it.

I've not heard of this for, what does this mean practically? Some kind of invocation in claude? Opening another claude window?

Re: A staff engineer's journey with Claude Code

#263
post #213

Earlier quoted context omitted.

I reached this conclusion pretty quickly. With all the hand holding I can write it faster - and it’s not bragging, almost anyone experienced here could do the same. Writing the code is the fast and easy part once you know what you want to do. I use AI as a rubber duck to shorten that cycle, then write it myself.

Writing the code in the grand scheme of things isn't the hard part in software development. The hard parts are architecture and actually building the right thing, something an LLM can't really help you with. It's not AI, there is no intelligence. A language model as the name says deals with language. Current ones are surprisingly good at it but it's still not more than that.

What? Leading edge LLMs are great at architecture, schema design and that sort of thing if you give them enough context and are not working on anything too esoteric. I’d argue they are better at this than the actual coding part.

Re: A staff engineer's journey with Claude Code

#264
post #62

I have barely written any code since my switch to Claude Code! It's the best thing since sliced bread! Here's what works for me: - Detailed claude.md containing overall information about the project. - Anytime Claude chooses a different route that's not my preferred route - ask my preference to be saved in global memory. - Detailed planning documentation for each feature - Describe high-level functionality. - As I de…

How have you been using Playwright MCP?

Re: A staff engineer's journey with Claude Code

#265

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…

This video [0] is relevant, though it actually supports your point - it shows Claude Code struggling with non-trivial tasks and needing significant hand-holding. I suspect videos meeting your criteria are rare because most AI coding demos either cherry-pick simple problems or skip the messy reality of maintaining real codebases. [0] https://www.youtube.com/watch?v=EL7Au1tzNxE

> I suspect videos meeting your criteria are rare because most AI coding demos either cherry-pick simple problems or skip the messy reality of maintaining real codebases.

Or we’re just having too much fun making stuff to make videos to convince people that are never going to be convinced.

Re: A staff engineer's journey with Claude Code

#266

Earlier quoted context omitted.

Great video! Even more, shows a few things - how good it is with such a niche language but also exposes some direct flaws. First off, Rust represents quite a small part of the training dataset (last I checked it was under 1% of code dataset) in most public sets, so it's got waaay less training then other languages like TS or Java. You added 2 solid features, backed with tests and documentation and nice commit message…

> #1: Add a subagent for git that knows your style, so you don't poison direct claude context and spend less tokens/time fighting it. I've not heard of this for, what does this mean practically? Some kind of invocation in claude? Opening another claude window?

You ask claude to use an agent, and it’ll spawn a sub agent that takes a bunch of actions in a new context, then lets the original agent only know a summary of the results.

Re: A staff engineer's journey with Claude Code

#267

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…

Jon Gjengset (of MIT Missing Semester, Rust for Rustsceans, etc) shared a stream doing complex changes of increasing complexity to a geospatial math library in Rust. He’s an excellent engineer, and was able to pick apart AI-suggested changes liberally. The caveat is that the video is a bit long, but segmented nicely. I think he had a positive experience overall, but it was clear throughout the stream that he was not…

I think you shared the wrong link. Based on a quick youtube search I think you meant this one

https://youtu.be/EL7Au1tzNxE

Re: A staff engineer's journey with Claude Code

#268
post #258
post #255

Earlier quoted context omitted.

> What matters is I manage to finish projects that I would not otherwise if not for the AI coding tools, so having them is a huge win for me. I think the problem is in your definition of finishing a project. Can you support said code, can you extend it, are you able to figure out where bugs are when they show up? In a professional setting, the answer to all of those should likely be yes. That's what production code i…

I disagree with your sentiment. The difference isn't what's finishing a project is, is the dissonance between what M4v3R and rhubarbtree understand when talking about "nontrivial production" software. When you're working in enterprise, you usually have multiple stakeholders each defining sometimes even conflicting requirements to behavior of your software. And you're required to adhere to these requirements stringent…

I don't believe it's to do with the requirements. I think you'll still hit the same problems if those greenfield projects grow. It's still fundamentally about the code. I think you're missing the difference between a 10/100k+ lines of code professional software vs a quick 3k lines greenfield project.

In a few thousand lines of code you can get away with a massive amount of code bloat, quick hacks and inconsistent APIs. In a program that's anything more than a few thousand lines, you can't. It just becomes too confusing. You have to be deliberate. Code has to follow patterns so the cognitive load is lowered. Stuff has to be split up in a predictable manner.

And there's another problem, sensible and predictable maintenance. Changes and fixes have to be targeted and specific. They have to be written to avoid side-effect.

For organisation, it's been a huge effort on everyone's part these last 30 years to achieve that. Make code understandable, by organising it better. From one direction, languages have improved, with authors reducing boilerplate + cross-pollination of ideas between languages like anonymous methods. On the other, it's developers inventing + describing patterns or KISS or the single responsibility principle. Or even seemingly trivial things like choosing predictable folder structures and enforcing indentation rules[1]. I'm starting to feel that's often the main skill a senior dev brings to the table, organising code well.

Better code organization has made it possible for developers to make larger program. Code organisation is a need that becomes a big problem if you're not doing it well in large projects, but not really a problem if you're not doing it well in small projects.

And right now, AI isn't very good at code organisation. We might believe that you have to have a mental model of the whole program in your head, something an LLM is just not capable of right now. And I don't know if that's going to turn out to be a solvable problem as it seems like a huge context problem.

For maintenance, I'm not sure. AI seems pretty terrible at it. It often rewrites everything and throws the baby out with the bathwater. Again, it's a context problem.

Both could turn out to be easy to solve for this generation of AI, in the end.

[1] Younger programmers will not believe that even 15/20 years ago it was still a common problem that developers did not bother to indent their code consistently. In my first two jobs I'd regularly hit inconsistently indented code.

Re: A staff engineer's journey with Claude Code

#269

Earlier quoted context omitted.

This video [0] is relevant, though it actually supports your point - it shows Claude Code struggling with non-trivial tasks and needing significant hand-holding. I suspect videos meeting your criteria are rare because most AI coding demos either cherry-pick simple problems or skip the messy reality of maintaining real codebases. [0] https://www.youtube.com/watch?v=EL7Au1tzNxE

Great video! Even more, shows a few things - how good it is with such a niche language but also exposes some direct flaws. First off, Rust represents quite a small part of the training dataset (last I checked it was under 1% of code dataset) in most public sets, so it's got waaay less training then other languages like TS or Java. You added 2 solid features, backed with tests and documentation and nice commit message…

> #3: Limit what they test, as most LLM models tend to write overeager tests, including testing if "the field you set as null is null", wasting tokens.

Heh, I write this for some production code too (python). I guess because python is not typed, I'm testing if my pydantic implementation works.

Re: A staff engineer's journey with Claude Code

#270

Earlier quoted context omitted.

Yes, people who are: - Working on hobby projects/sideprojects - Working on open-source projects - Selling stuff For someone to create this example, they would either have to do it in a codebase they don't have problem open sourcing or which is open source, so they do not break NDA's and divulge company info/source code. How many people are ready to do that? The conditions of the OP are: - No demo, independent program…

I’m happy for it to be on OSS, so long as that software is reasonably well known (ie user base is not a handful of people) and is used in production.

What difference does it make how many people use it? Complex software exists all over the world for handful of users. I personally work in an industry where anything we create will be used by at max 100 people worldwide. Does it diminish the complexity of code? I think not.
Post reply on HN