Live data from Hacker News

Thoughts on the Future of Software Development

sheshbabu.com

231–240 of 434 posts

Re: Thoughts on the Future of Software Development

#231
post #119

Earlier quoted context omitted.

I remember back in the 80s I had friends who enjoyed coding in assembly and felt that using higher-level languages was "cheating" - isn't this just a continuation of that?

Yeah, that's a good way of looking at it. We gradually remove technical constraints and move to a higher level of abstraction, much closer to the level of the user and the business rather than the individual machine. But what's the endpoint of this? There will probably always be a need for expert-level troubleshooters and optimizers who understand all the layers, but for the rest of us, I'm wondering if the job would…

Is a more generic version of this argument be that there will always be a need for smart/experienced people?

Re: Thoughts on the Future of Software Development

#232
post #2

> the main argument against automating these tasks was that machines can’t think creatively. Now this argument gets weaker by the day. Citation needed.

To me, I think the end game for any code developing automation isn't that it needs to be creative to program, but..

A: needs to have a close to complete understanding of the problem to solve and the tools they have in languages to complete this in the most efficient way and..

B: need to be able to iterate through all of the different options it can generate and run `perf` or what have you on the outcomes of each and present the top few winners

AGI might not be a thing we can make, but if we can make enough semi-intelligent AIs communicating via a standardized format that are each 95% right on their respective domain we might be at a level that is good enough. Add in for critical domains some sort of polling that is done between a few admin AIs to make sure the winning results are not a hallucination.

Re: Thoughts on the Future of Software Development

#233

Earlier quoted context omitted.

Nah, you just throw it out and have the AI generate an all new one with different problems!

That's how bads use GPT to code. The right way is to ask GPT to break the problem down into a bunch of small strongly typed helper functions with unit tests, then ask it to compose the solution from those helper functions, also with integration tests. If tests fail at any point you can just feed the failure output along with the test and helper function code back in and it will almost always get it right for reasonab…

How do I know if a problem needs to be broken down by GPT, and how do I know if it broke the problem down correctly? What if GPT is broken or has a billing error, how do I break down the problem then?

Re: Thoughts on the Future of Software Development

#234
post #220

Earlier quoted context omitted.

> you need to refine what you choose to use them for This is making assumptions about the work I do which don't happen to be valid. For example: > libraries that [...] have star counts in the high thousands at least Play little to no role in my work, and > I'll let it convert css/style objects/etc into tailwind Is something I simply don't have a use for. Clearly your mileage varies, and that's fine. What I've found i…

> producing documentation I remember watching this really funny video where a writer, by trade, was talking about recent AI products they were exploring. They saw a "Make longer" button which took some text and made it longer by fluffing it out. He was saying that it was the antithesis of his entire career. As a high schooler who really didn't care, I would've loved it, though.

I've heard one CEO been asked about gen-ai tools to be used in the company. The answer was vague, like they are evaluating the tooling. However one good example was made: chatgpt is really good in writing mails, and in summarizing text as well.

He said they don't want to have situation when sender is using chatgpt to write a fancy mail and recipient is using chatgpt to read it. However I think that it is the direction where we are going right now.

Re: Thoughts on the Future of Software Development

#235

Earlier quoted context omitted.

That's how bads use GPT to code. The right way is to ask GPT to break the problem down into a bunch of small strongly typed helper functions with unit tests, then ask it to compose the solution from those helper functions, also with integration tests. If tests fail at any point you can just feed the failure output along with the test and helper function code back in and it will almost always get it right for reasonab…

If you're already doing all of this work then it's trivial to actually type all the stuff in yourself Is GPT actually saving you any time if it can't actually do the hard part?

It's not really "all this work," once you have good prompts you can use them to crank out a lot of code very quickly. You can use it to crank out thousands of lines of code a day that are somewhat formulaic, but not so formulaic that a simple rules based system could do it.

For example, I took text document with headers for table names and unordered lists for table columns, and had it produce a database schema which only required minor tuning, which I then used to generate sqlmodel classes and typescript types. Then I created an example component for one entity and it created similar components for the others in the schema. LLMS are exceptionally good at this sort of domain transformation, a decent engineer could easily crank out 2-5k lines/day if they were mostly doing this sort of work.

Re: Thoughts on the Future of Software Development

#236
> Though coding all day sounds very appealing, most of software development time is spent on communicating with other people or other admin work instead of just writing code

This sounds very...big corp, which inevitably needs many professional box drawers, expert negotiators, smooth communicators, miracle alignment workers, and etc. But guess what, if you are in a core group in a small company, you function as a grad student: you tackle hard problems, you spend time discussing insights, you derive theories, and you spend most of your time writing software, be it requirement gathering, designing, code writing, debugging, or documenting. But you definitely don't and shouldn't spend most of your time talking to other teams.

Re: Thoughts on the Future of Software Development

#237
post #119

Earlier quoted context omitted.

I remember back in the 80s I had friends who enjoyed coding in assembly and felt that using higher-level languages was "cheating" - isn't this just a continuation of that?

Seems so. Those friends did have to contend with the enjoyable part of their job disappearing. Whether they called it cheating or not is doesn't diminish their loss.

It didn't; there are still many roles for skilled assembly programmers in performance-critical or embedded systems. It's just their market share in the overall world of programming has decreased due to high-level programming languages; although better technology has increased the size of the market that might have demands for assembly.

Re: Thoughts on the Future of Software Development

#238

There is one fundamental flaw with the AI generated code: unmaintainability and unpredictability. An attempt to modify the already generated specific piece of code or the program in general will produce an unexpected result. Saving some money on programmers but then losing millions in lawsuits or losing customers and eventually the whole business due to an expected behaviour of the app or a data leak might not be a g…

Takes like this miss the forest for the trees. The overall point is that automated programming is now a target, just like automating assembly lines became a target back in the day. There will be kinks in the beginning, but once the target is set, there will be a huge incentive to work out the kinks to the point of near full automation

Re: Thoughts on the Future of Software Development

#239
post #213

Earlier quoted context omitted.

> The endpoint is that being a programmer becomes as obsolete as being a human "calculator" for a career. Yeah, the same time the singularity happens, and then your smallest problem will be eons bigger than your job. But LLMs can’t solve a sudoku, so I wouldn’t be too afraid.

They are pretty close. LLMs can write the code the solve a sudoku, or leverage an existing solver, and execute the code. Agent frameworks are going to push the boundaries here over the next few years.

> LLMs can write the code the solve a sudoku

It’s literally part of its training data. The same way it knows how to solve leetcode, etc.

Re: Thoughts on the Future of Software Development

#240
post #148

Earlier quoted context omitted.

How many humans do you need per project though? The number can only lower as AI tooling improves. And will employers pay the same rates when they’re already paying a sub for their AI tools and the work involved is so much more high level?

I don’t claim to have any particular prescience here, but doesn’t this assume that the scope of “software” remains static? The potential universe of programmatically implementable solutions is vast . Just so happens that many or most of those potential future verticals are not commercially viable in 2024.

Exactly. Custom software is currently very expensive. Making it cheaper to produce will presumably increase demand for it. Whether this results in more or fewer unemployed SWEs, and if I'll be one of them, I don't know.
Post reply on HN