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…
Thoughts on the Future of Software Development
231–240 of 434 posts
Re: Thoughts on the Future of Software Development
#232> the main argument against automating these tasks was that machines can’t think creatively. Now this argument gets weaker by the day. Citation needed.
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
#233Earlier 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…
Re: Thoughts on the Future of Software Development
#234Earlier 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.
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
#235Earlier 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?
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
#236This 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
#237Earlier 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.
Re: Thoughts on the Future of Software Development
#238There 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…
Re: Thoughts on the Future of Software Development
#239Earlier 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.
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
#240Earlier 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.