Live data from Hacker News

A staff engineer's journey with Claude Code

sanity.io

301–310 of 410 posts

Re: A staff engineer's journey with Claude Code

#301

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…

> but this was true when they wrote their own code with stack overflow. Searching for solutions and integrating examples found requires effort that develops into a skill. You would rarely get solutions that would just fit into the codebase from SO. If I give a task to you and you produce a correct solution on the initial review I now know I can trust you to deal with this kind of problem in the future. Especially aft…

Like with any kind of learning, without a feedback loop (as tight as possible IMHO), it's not gonna happen. And there is always some kind of feedback loop.

Ultra short cycle: Pairing with a senior, solid manual and automated testing during development.

Reasonably short cycle: Code review by a senior within hours and for small subsets of the work ideally, QA testing by a seperate person within hours.

Borderline too long cycle: Code review of larger chunks of code by a senior with days of delay, QA testing by a seperate person days or weeks after implementation.

Terminally long feedback cycle: Critical bug in production, data loss, negative career consequences.

I'm confident that juniors will still learn, eventually. Seniors can help them learn a whole lot faster though, if both sides want that, and if the organisation lets them. And yeah, that's even more the case than in the pre LLM world.

Re: A staff engineer's journey with Claude Code

#302

Earlier quoted context omitted.

If the code is disposable then where do all the rules and reasoning etc live apart from in your head?

In the spec.

Hmm... my code is the spec. It just happens to be executable. Is writing a precise spec in English easier than in a programming language?

Re: A staff engineer's journey with Claude Code

#303
post #54

Earlier quoted context omitted.

I feel like I do all of this stuff and still end up with unusable code in most cases, and the cases where I don't I still usually have to hand massage it into something usable. Sometimes it gets it right and it's really cool when it does, but anecdotally for me it doesn't seem to be making me any more efficient.

The key is prompting. Prompt to within an inch of your life. Treat prompts as source code - edit them in files, use @ notation to bring them into the console. Use Claude to generate its own prompts - https://github.com/wshobson/commands/ and https://github.com/wshobson/agents/ are very handy, they include a prompt-engineer persona. I'm at the point now where I have to yell at the AI once in a while, but I touch essen…

Have you made any attempt to quantify your efficiency/output vs writing the code yourself? I've done all of these things you've mentioned, with varying degrees of success. But also everything you're talking about doing is time consuming and eats away at whatever efficiency gain CC claims to offer.

Re: A staff engineer's journey with Claude Code

#304
One thing that I haven't seen a lot of people talk about is the relatively new model config "Opus Plan Mode: Use Opus 4.1 in plan mode, Sonnet 4 otherwise".

In my opinion this should be the default config. Increasing the quality of the plans gives you a much better experience using Claude Code.

Re: A staff engineer's journey with Claude Code

#305
post #258

Earlier quoted context omitted.

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 API…

I personally find Claude Code has no real issues working and producing code in the 40k LoC Ruby on Rails repo I work in nor in the 45k LoC Elixir/Phoenix repo I work in. For the last few months I'd say 99% of all changes I do to both are purely via Claude Code, I almost never use my editor anymore at all. It's common things don't work on the first try or aren't exactly what I want but usually just giving an error to Claude or further instructions will fix it in an iteration or two.

I think the code organization isn't amazing, but it's fine and frankly not that much of a concern to me usually as I'm usually just reading diffs and not digging around in the code much myself.

Re: A staff engineer's journey with Claude Code

#306
post #243

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 live streamed how I've built a tower defense game over a span of a week entirely using AI. I've also written down all the prompts were used to create this game, you can read about it here: https://news.ycombinator.com/item?id=44463967 Mind you I've never wrote a non-trivial game before in my life. It would take me weeks to do this on my own without any AI assistance. Right now I'm working on a 3d world map edito…

Unless you write tower defense games all day long for a living, I don't know how it's interesting.

Re: A staff engineer's journey with Claude Code

#307

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…

Forget a livestream, I want to hear from maintainers of complex, actively developed, and widely used open-source projects (e.g. ffmpeg, curl, openssh, sqlite). Highly capable coding LLMs have been out for long enough that if they do indeed have meaningful impact on writing non-trivial, non-greenfield/boilerplate code, it ought to be clearly apparent in an uptick of positive contributions to projects like these.

This contains some specific data with pretty graphs: https://youtu.be/tbDDYKRFjhk?t=623

But if you do professional development and use something like Claude Code (the current standard, IMO) you'll quickly get a handle on what it's good at and what it isn't. I think it took me about 3-4 weeks of working with it at an overall 0x gain to realize what it's going to help me with and what it will make take longer.

Re: A staff engineer's journey with Claude Code

#308

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 as well.

The net is that unsupervised AI engineering isn’t really cheaper better or faster than human engineering right now. Does that mean in two years it will be? Possibly.

There will be a lot of optimizations in the message traffic, token uses, foundational models, and also just the Moore’s law of the hardware and energy costs.

But really it’s the sophistication of the agent systems that control quality more than anything. Simply following waterfall (I know, right? Yuck… but it worked) increased code quality tremoundously.

I also gave it the SelfDocumentingCode pattern language that I wrote (on WikiWikiWeb) as a code review agent and quality improved tremendously again.

Re: A staff engineer's journey with Claude Code

#309

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…

My experience with the latest Claude Code has been: it's not nearly as bad as you say.
Post reply on HN