Earlier quoted context omitted.
Not CEO because I don’t like title, but yes In addition to many other things (like being a dad and farming peaches - hopefully 50 lbs this year)
Nice, respect
Thanks! I appreciate it
Reflections on software engineering in the age of AI
81–90 of 110 posts
Re: Reflections on software engineering in the age of AI
#82Earlier quoted context omitted.
> Don't use it to write code. It's a terrible programmer. I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.
I think a lot of the people saying AI code sucks is because the code isn't formatted the way they like, not because the code doesn't work. Basically, the people that leave dozens of bikeshed code review comments. Sure, sometimes I might ask the AI to break out a helper function or structure things differently, but that's the same as working with another dev
I've witnessed SQL executed with a where clause be wrapped in a function which then iterates over the result to re-enforce the where clause.
People need to read the slop they're throwing at reviewers.
Re: Reflections on software engineering in the age of AI
#83Earlier quoted context omitted.
> I’m working on a program for myself and the overall architecture of the program as well as some parts of its implementation are clever and compose well to make the codebase a joy to work in. I am not simply “mapping features to mundane technical details”. You said it: you are working on a "program for yourself". Hobbyist craft programming will always be here. The question is what kind of software engineering will b…
What I said equally applies to commercial software as well. It's pretty much the only way to build software which is extensible, maintainable, mostly bug-free, and performant. That companies often churn out slop isn't proof that it's unnecessary, it's evidence that it is.
I think most of what you claim to be doing better is really just a result of you not really being confronted with any sort of "adversarial input", at least not as much as you'd have in corporate
it's hard to trust a claim about someone writing "bug-free" and "extensible/maintainable" code from the singular developer and user for that system... maintainability can't really be a thing you can judge when you're not a single step removed from the person who built it in the first place - maybe you'll feel different if you have to pick up the project again after a couple years' inactivity
Re: Reflections on software engineering in the age of AI
#84Earlier quoted context omitted.
> Don't use it to write code. It's a terrible programmer. I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.
> I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience If you see people saying it often, but you are convinced they are just feeling threatened, what AI generated software would point to to say, "Look at this! Definitive evidence that they are just coping!"
Well, for one thing, I’d point to all the other anecdotes of developers being made 10x more efficient due to LLM use.
But really I’m just comparing against my personal experience. Once I learned how to use the tools well, and what to expect (and what not to), I’ve found LLMs to be very powerful.
Re: Reflections on software engineering in the age of AI
#85Not my experience at all (30+ years of experience as a professional software developer).
I currently work on a very large (multi-million lines) C++ code base and use Claude Code for the following:
1. I run Claude Code in the background finding bugs, while busy implementing new features.
It has so far found and fixed 100+ minor issues and a few major could-crash-the-server-in-production issues that I was really happy to get fixed before a customer found it.
2. I use Claude Code to do massive refactorings that would be really tedious to do by hand.
I love the fact that it updates not just the code but also comments and documentation.
3. I use Claude Code to implement features that I frankly am too bored to implement by hand.
Excellent! Less boredom at work!
4. I use Claude Code to generate tools to analyse the code and/or generate code.
This is a massive quality improvement. It allows me to make the code more maintainable and simpler while adding more features.
However I always always always check and verify every change before committing to git. Because the LLM it will occasionally add features or bugs I don't want.
The end result is really positive. Lots of productivity improvements, less tedious can't-be-bothered work, lots of bug fixes that otherwise would have triggered production issues etc. etc. while 100% maintaining my understanding of the code and all changes.
Love it.
Re: Reflections on software engineering in the age of AI
#86Earlier quoted context omitted.
| type errors, scope issues, import resolution, dependencies. I write code myself and use the LLM to find mistakes then fix them manually. I recommend inverting the conventional wisdom on LLMs: 1. Don't use it to write code. It's a terrible programmer. But it's an intelligent rubber duck and a solid analysis tool. 2. Write the code yourself. It'll go faster than figuring it out as you go along. It's just typing if yo…
> Don't use it to write code. It's a terrible programmer. I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.
I agree. Claude Code (for example) writes excellent code as long as the prompt is focused and clear.
Re: Reflections on software engineering in the age of AI
#87Earlier quoted context omitted.
Part 6 to me seems always totally useless. Whenever I let these tools look at existing repos they are too influenced by what's already there. I could even say "feel free to completely refactor or rewrite anything" and they'll still just do small performative changes. I've now changed my workflow to only using AI for prototyping and rewriting by hand once I can see something is viable. Takes longer but the results are…
I don’t have those problems You have to build your architecture modularly so you’re never having to reason about more than the schema and api-contracts for IPC
Well... again, I'm giving the LLM total freedom to destroy what's there and start from scratch. That could nudge it to structure the code base more like that.
It would be totally different if I told that to a junior developer.
But imo LLMs don't really structure code well or as well as humans could.
Re: Reflections on software engineering in the age of AI
#88Earlier quoted context omitted.
> Don't use it to write code. It's a terrible programmer. I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.
I see your sentiment quite often here on HN¹, I'm honestly not sure what kind of experience you may have had with automatic program writers. LLM code absolutely sucks. 1 - I wonder why my other social circles are so different.
I am really curious about this because my experience is completely different. Can you elaborate a bit more on how you use LLM's for coding? Are you doing one-shot coding? Vibe coding (not looking at code)? Small focused one-step-at-a-time with yourself verifying? Anything else?
Re: Reflections on software engineering in the age of AI
#89Earlier quoted context omitted.
I agree. This sentiment is quite tiring and I put it down to one of 3 things: 1) lies and/or cope 2) lack of actual software ability, therefore over evaluating your own skill 3) haven’t actually used LLMs, and want to do a “look at me I’m so unique and different” I roll my eyes whenever someone says “AI bad” “AI sucks” “AI can’t replace me” Yeah. Load of
Regarding 2 Isn't it possible that people who think LLMs are awesome at coding are in fact bad at it themselves, leading to them over estimating the LLMs "skill"? To me it feels like people telling on themselves that they aren't very good
30+ years of experience here writing everything from JIT high-performance compilers to professional game engines to mission critical biz servers:
Claude Code is excellent at writing (C++) code. Especially multi-threading code. However I still need to verify everything because it will occasionally make mistakes.
Re: Reflections on software engineering in the age of AI
#90Earlier quoted context omitted.
| type errors, scope issues, import resolution, dependencies. I write code myself and use the LLM to find mistakes then fix them manually. I recommend inverting the conventional wisdom on LLMs: 1. Don't use it to write code. It's a terrible programmer. But it's an intelligent rubber duck and a solid analysis tool. 2. Write the code yourself. It'll go faster than figuring it out as you go along. It's just typing if yo…
> Don't use it to write code One of the things I've started doing is to write the high level scaffold myself, create stubs (with comments) and have it fill out the details. I haven't done this for long, but I feel like my mental model of the code rots less, and I can review code faster. I used to do this in the past, when these models were not all that capable, now there is a huge temptation to leave everything to th…
I like to start out by creating the overall structure of my application: the module structure, high level components, feature boundaries. That way these decisions are already made for the LLM, and it can focus on filling in logic within the structure provided.
It works quite well for me, a lot better than when the LLM makes these decisions.