Live data from Hacker News

6 weeks of Claude Code

blog.puzzmo.com

411–420 of 603 posts

Re: 6 weeks of Claude Code

#411
post #349

Earlier quoted context omitted.

> I'm hearing from Senior devs all over thought, that Junior developers are just garbage at it. They product slow, insecure, or just outright awful code with it, and then they PR the code they don't even understand. If this is the case then we better have full AI generated code within the next 10 years since those "juniors" will remain atrophied juniors forever and the old timers will be checking in with the big cloc…

IT education and computer science (at least part of it) will need a stronger focus on software engineering and software architecture skills to teach developers how to be in control of an AI dev tool.

Brains are not computers and we don't learn by being given abstract rules. We also don't learn nearly as well from class room teaching as we do from doing things IRL for a real purpose - the brain always knows the difference and that the (real, non-artificially created) stakes are low in a teaching environment.

That's also the huge difference between AI and brains: AI does not work on the real world but on our communication (and even that is limited to text, missing all the nuance or face to face communication includes). The brain works based on sensor data from the real world. The communication method, language, is a very limited add-on on top of how the brain really works. We don't think in language, to do even some abstract language based thinking, e.g. when doing formal math, requires a lot of concentration and effort and still uses a lot of "under the hood" intuition.

That is why even with years of learning the same curriculum we still need to make a significant effort for every single concrete example to "get everyone on the same page", creating compatible internal models under the hood. Everybody's own internal model of even simple things are slightly different, depending on what brain they brought to learning and what exactly they learned, where even things like social classroom interactions went into how the connections were formed. Only based on a huge amount of effort can we then use language to communicate in the abstract, and even then, when we leave the central corridor of ideas people will start arguing forever about definitions. No matter how the written text is the same, the internal model is different for every person.

As someone who took neuroscience, I found this surprisingly well written:

"The brain doesn't like to abstract unless you make it"

http://howthebrainworks.science/how_the_brain_works_/the_bra...

> This resource, prepared by members of the University of London Centre for Educational Neuroscience (CEN), gives a brief overview of how the brain works for a general audience. It is based on the most recent research. It aims to give a gist of the brain’s principles of function, covering the brain’s evolutionary origin, how it develops, and how it copes in the modern world.

The best way to learn is to do things IRL that matter. School is a compromise and not really all that great. People motivated by actual need often can learn things that take years in school with middling results significantly faster and with better and deeper results.

Re: 6 weeks of Claude Code

#412
post #349

Earlier quoted context omitted.

IT education and computer science (at least part of it) will need a stronger focus on software engineering and software architecture skills to teach developers how to be in control of an AI dev tool.

Brains are not computers and we don't learn by being given abstract rules. We also don't learn nearly as well from class room teaching as we do from doing things IRL for a real purpose - the brain always knows the difference and that the (real, non-artificially created) stakes are low in a teaching environment. That's also the huge difference between AI and brains: AI does not work on the real world but on our commun…

And that is the best thing about AI, it allows you to do and try so much more in the limited time you have. If you have an idea, build it with AI, test it, see where it breaks. AI is going to be a big boost for education, because it allows for so much more experimentation and hands-on.

Re: 6 weeks of Claude Code

#413

I've been using Claude code 12-16 hours a day since I first got it running two weeks ago. Here's the tips I've discovered: 1. Immediately change to sonnet (the cli defaults to opus for max users). I tested coding with opus extensively and it never matches the quality of sonnet. 2. Compacting often ends progress - it's difficult to get back to the same quality of code after compacting. 3. First prompt is very importan…

Where are you hosting those containers? Our serverless/linux cli/browser IDE at https://brilliant.mplode.dev runs on containers in our nascent cloud platform and we’re almost ready to start serving arbitrary containers on it deployed directly from the IDE. I’m curious if there are any latency/data/auth/etc pain points you’ve been running into

Re: 6 weeks of Claude Code

#414

Earlier quoted context omitted.

If you are a Senior Developer, who is comfortable giving a Junior tips, and then guiding them to fixing them (or just stepping in for a brief moment and writing where they missed something) this is for you. I'm hearing from Senior devs all over thought, that Junior developers are just garbage at it. They product slow, insecure, or just outright awful code with it, and then they PR the code they don't even understand.…

Yes, can confirm that as a senior developer who has needed to spend huge amounts of time reviewing junior code from off-shore contractors with very detailed and explicit instructions, dabbling in agentic LLM coding tools like Claude Code has felt like like a gift from heaven. I also have concerns about said junior developers wielding such tools, because yes, without being able to supply the right kind of context and…

Ah mate I can’t relate more to the offshore component. I had a very sad experience where I recently had to let go of an offshore team due to them providing devs that essentially ‘junior with copilot’ but labelled as a ‘senior’.

Time and time again I would find telltale signs of dumping LLM output into PRs n then claiming it as their own. Not a problem, but the code didn’t do what the detailed ticket asked and introduced other bugs as a result.

It ultimately became a choice of ‘go through the hassle of making a detailed brief for it to just be put in copilot verbatim and then go through the hassle of reviewing it and explaining the issues back to the offshore dev’ or ‘brief Claude directly’

I hate to say it but from a business perspective the latter won outright. It tears me up as it goes against my morality.

Re: 6 weeks of Claude Code

#415

Earlier quoted context omitted.

> No answers to my question, completely different code gets pushed. at what point does that cost become higher than benefit?

It does but most execs dont care about long term they want that perf bonus before they leave in 3-4 years

That is how you get Oracle source code. It broke my illusions after entering real life big company coding after university, many years ago. It also led to this gem of an HN comment: https://news.ycombinator.com/item?id=18442637

Re: 6 weeks of Claude Code

#416
post #349

Earlier quoted context omitted.

> I'm hearing from Senior devs all over thought, that Junior developers are just garbage at it. They product slow, insecure, or just outright awful code with it, and then they PR the code they don't even understand. If this is the case then we better have full AI generated code within the next 10 years since those "juniors" will remain atrophied juniors forever and the old timers will be checking in with the big cloc…

IT education and computer science (at least part of it) will need a stronger focus on software engineering and software architecture skills to teach developers how to be in control of an AI dev tool.

Unfortunately education everywhere is getting really hurt by access to AI, both from students who are enabled to not their homework, and by teacher review/feedback being replaced by chatbots.

Re: 6 weeks of Claude Code

#417

> Painting by hand just doesn’t have the same appeal anymore when a single concept can just appear and you shape it into the thing you want with your code review and editing skills. In the meanwhile one the most anticipated game in the industry, a second chapter of an already acclaimed product, has its art totally hand painted

I think it's two schools of thought, end product vs process. It seems a lot of people who like AI only care about getting the end product, and don't care how it was made. On the other hand, some people are invested in how something is made, and see the process of creation and refinement as a part of the end product itself.

People are not invested in how something is made imo, it's just better and beautiful and connects better with them. I agree though that AI entusiast only care about getting stuff done, but I won't call it an "end-product"

Re: 6 weeks of Claude Code

#418

Earlier quoted context omitted.

Writing code that gets compiled is deterministic, but asking an LLM to produce code is a non-deterministic guessing game. Notice how nobody is skeptical of compilers?

No one is skeptical of compilers?! I guess you haven’t met many old fashioned C systems programmers, who go out of their way to disable compiler optimisations as much as they can because “it just produces garbage”. Every generation, we seem to add a level of abstraction conceding because for most of us, it enhances productivity. And every generation, there is a crowd who rails against the new abstraction, mostly unaw…

Abstractions and compilers are deterministic, no matter if a neckbeard is cranky about the results. LLMs are not deterministic, they are a guessing game. An LLM is not an abstraction, it's a distraction. If you can't tell the difference, then maybe you should lay off the "AI" slop.

Re: 6 weeks of Claude Code

#419
post #123

Earlier quoted context omitted.

Maybe our brains are wired different but reading and reviewing code is way faster for me than writing it.

There's very few objective ways to measure review 'performance'. Coding is easy, it works or doesn't.

This ignores a bunch of higher level and long-term concepts like maintenance, complexity and extensibility.

With only "it works" you end up like this (iconic HN comment on Oracle codebase): https://news.ycombinator.com/item?id=18442637

Re: 6 weeks of Claude Code

#420
post #24

Another really nice use case building very sophisticated test tooling. Normally a company might not allocate enough resources to a task like that but with Claude Code it's a no brainer. Also can create very sophisticated mocks like say db mock that can parse all queries in the codebase and apply them to in memory fake tables. Would be total pain to build and maintain by hand but with claude code takes literally minut…

Hill I’m willing to die on (metaphorically): If your test structure is a pain to interact with, that usually means some bad decisions somewhere in the architecture of your project.

Sure but thats pretty orthogonal to the above. Say had to create parser+mapper for a domain specific query language that than gets mapped to a number of SQL backends. Used cc to create custom test harness that can use SQLC style files to drive tests. They are way more readable and much easier to maintain vs plain Rust tests for this task. Took half a day to create with cc would prob take like a week without it.
Post reply on HN