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…
A staff engineer's journey with Claude Code
261–270 of 410 posts
Re: A staff engineer's journey with Claude Code
#262Earlier 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…
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
#263Earlier 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.
Re: A staff engineer's journey with Claude Code
#264I 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…
Re: A staff engineer's journey with Claude Code
#265Does 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
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
#266Earlier 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?
Re: A staff engineer's journey with Claude Code
#267Does 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…
Re: A staff engineer's journey with Claude Code
#268Earlier 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…
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
#269Earlier 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…
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
#270Earlier 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.