Live data from Hacker News

Reflections on software engineering in the age of AI

adiamond.me

71–80 of 110 posts

Re: Reflections on software engineering in the age of AI

#71
post #37

Earlier 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 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

Re: Reflections on software engineering in the age of AI

#72
post #9

Reading posts on HN, I notice that even across different programming domains, surprisingly similar problems emerge. Seeing this, I can't help but think that programming might ultimately be a matter of organizational theory. Conway's Law speaks to this as well. Code structure and approach shift significantly depending on how an organization is structured. From that perspective, it makes sense why Gen AI coding yields…

> Programming is ultimately the work of constructing a mental model, and that mental model is inherently personal

So that’s why we now have as many different tech stacks as we have developers at work. Conway’s law taken to its logical conclusion?

Re: Reflections on software engineering in the age of AI

#73

> AI does not know whether the code it just added violates some legal requirement to which your product is subject. The rest of the paragraph is a list of similar complaints. All of these can be codified - the new work is the (fascinating!) challenge of working out how and codifying them, then giving the codified checker logic to the agent to run at will - thus taking yourself out of all of those loops. They don’t ev…

> They don’t even need to be deterministic checks - a shell script that wraps a `claude -p` - and maybe fetches some online resources to stuff into the context - can do your agent’s legal check for it.

No. It can't. If you think that injecting legal text into the context window and appending "make sure the output complies with this law" will solve your problems you have not understood how an LLM works. The kind of checks you are talking about cannot be codified.

Re: Reflections on software engineering in the age of AI

#74

I wonder if we're being overly selfish here and ignore the positive effects of democratizing programming and making software more accessible to less well funded causes and organizations. A good software engineer used to cost 100k/year, very few businesses could afford that. I also disagree that AI results are lower quality. Codex Pro results I get are marvelous but they sometimes miss things that humans understand na…

What AI does is the exact polar opposite of "democratizing". We're going from a world where high-quality learning content is plastered all over the internet for free, where open-source projects are desperate for contributors and full of "good first issue" tickets, and where the tools you need to code can be run on any crappy laptop from the past 15 years—to a world where the majority of content about programming is unverified AI slop, where open-source projects are locking down access to protect against an avalanche of drive-by AI garbage, and where you need a $200/month subscription or a $3,000 GPU to run AI models for coding.

Re: Reflections on software engineering in the age of AI

#75

Writing and coding are not the same thing; coding is a means to an end, since you don’t use the code , you use the software. This means the mechanism by which the code was created is orthogonal to the software as you’d experience it as a user. There are many reasons to curate what goes into the software - for example, if it must be maintainable, if it must conform to standards that cannot be fully codified into the s…

> But it takes a mountain of code to make an outwardly simple thing so why not use a work-amplifying tool to produce that code and get to working software more cheaply

The same reason we didn't just wholesale copy and paste from open source repos in the past?

Re: Reflections on software engineering in the age of AI

#76
post #73

> AI does not know whether the code it just added violates some legal requirement to which your product is subject. The rest of the paragraph is a list of similar complaints. All of these can be codified - the new work is the (fascinating!) challenge of working out how and codifying them, then giving the codified checker logic to the agent to run at will - thus taking yourself out of all of those loops. They don’t ev…

> They don’t even need to be deterministic checks - a shell script that wraps a `claude -p` - and maybe fetches some online resources to stuff into the context - can do your agent’s legal check for it. No. It can't. If you think that injecting legal text into the context window and appending "make sure the output complies with this law" will solve your problems you have not understood how an LLM works. The kind of ch…

So we should give up before we even tried?

Re: Reflections on software engineering in the age of AI

#77

Earlier 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

I don’t consider myself an expert, but I’ve been programming for the last 6 years, and of those 6 years I’ve spent almost all my spare time programming during this period except for a 1 year hiatus.

This includes personal projects with a decent amount of users, and 1 sold project. I’m not the best programmer, but I wouldn’t say I’m bad at all.

Question to you, have you actually used a leading model like Fable when it was available? I did. I was seriously impressed.

I’ll be honest I find it hard to take anyone seriously who says they can program better or faster than a model with those capabilities. That has not been my experience.

Architecting - yes people are still better overall. LLMs tend to go with the average middle of the road result. But in terms of output, raw speed, and getting something working? No way am I better than an llm.

Happy to be enlightened and told I’m completely wrong. Maybe I am an idiot. That is a possibility.

But how about I give you a task, and I give Claude that same task, and we compare results against execution speed? I’ll happily be the judge of that.

Re: Reflections on software engineering in the age of AI

#78
post #37

Earlier 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 think language, frameworks, domain and style can all influence the quality of the output. I think it’s hard to compare experiences.

Re: Reflections on software engineering in the age of AI

#79
> I don’t use AI when I write, for the very reason that writing itself is the act of organizing and clarifying my own thought. Letting the bot write for me would be like paying someone else to exercise for me and hoping that gets me in shape.

I don't know why the author chooses to distinguish writing prose and writing code here. [Software is made of decisions](https://siderea.dreamwidth.org/1219758.html) and at least I usually like to flesh out those decisions through the act of writing code, which forces a level of precision that makes it hard (though not impossible) to handwave away important decisions.

Re: Reflections on software engineering in the age of AI

#80

Earlier quoted context omitted.

You’re the founder and CEO of an AI startup but also vibecoding side gig work?

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
Post reply on HN