2 ms·

> that most software will be built very quickly, and more complicated software should be developed by writing the specification, and then generating the code. W

> that most software will be built very quickly, and more complicated software should be developed by writing the specification, and then generating the code. We may still need to drop down to a programming language from time to time, but I believe that almost all development will be done with generative AI tools My strongly held belief is that anyone who think that way, also think that software engineering is reading tickets, searching for code snippets on stack overflow and copy-pasting code. Good specifications are always written after a lot of prototypes, experiments and sample implementations (which may be production level). Natural language specifications exist after the concept has been formalized. Before that process, you only have dreams and hopes.

leoedin 9mo ago
I've been playing around with "vibe coding" recently. Generally react front end and Rust back end. Rust has the nice benefit that you only really get logic bugs if it compiles. In the few apps I've built, progress is initially amazing. And then you get to a certain point and things slow down. I've built a list of things that are "not quite right" and then, as I work through each one all the strange architectural decisions the AI initially made start to become obvious. Much like any software development, you have to stop adding features and start refactoring. That's the point at which not being a good software developer will really start to bite you, because it's only experience that will point you in the right direction. It's completely incredible what the models can do. Both in speed of building (especially credible front ends), and as sounding boards for architecture. It's definitely a productivity boost. But I think we're still a long way off non-technical people being able to develop applications. A while ago I worked on a non-trivial no-code application. I realised then that even though there's "no code", you still needed to apply careful thought about data structures and UI and all the other things that make an application great. Otherwise it turned into a huge mess. This feels similar.
- throwaway0123_5 9mo ago
  > But I think we're still a long way off non-technical people being able to develop applications. I'm surprised I haven't seen anyone do a case study, having truly non-technical people build apps with these tools. Take a few moderately tech-savvy (can use MS office up to doing basic stuff in excel, understands a filesystem) people who work white collar jobs. Give them a one or two-day crash course on how Claude Code works. See what is the most complicated app which they can develop that is reasonably stable and secure.
- CuriouslyC 9mo ago
  This is a big part of why vibe coded projects fall over. AI creates big balls of mud because it's myopic as hell. Linters help but they're still pretty limited. I've had good success using https://github.com/sibyllinesoft/valknut https://github.com/sibyllinesoft/valknut to automate the majority of my refactoring work. I still do a style/naming pass on things, but it handles most issues that can be analytically measured.
JBAnderson5 9mo ago
I think part of the issue here is that software engineering is a very broad field. If you’re building another crud app, your job might only require reading a ticket and copy/pasting from stack overflow. If you are working in a regulated industry, you are spending most of your time complying with regulations. If you are building new programming languages or compilers, you are building the abstractions from the ground up. I’m sure there’s dozens if not hundreds of other sub fields that build software in other ways with different requirements and constraints. LLMs will trivialize some subfields, be nearly useless in others, but will probably help to some degree in most of them. The range of opinions online about how useful LLMs are in their work probably correlates to what subfields they work in
- skydhash 9mo ago
  The thing is if you’re working on a CRUD app, you probably have (and you should) a framework, which make it easy to do all the boilerplate. Editor fluency can add an extra boost to your development speed. I’ve done CRUD and the biggest proportion of the time was custom business rules and UI tweaking (updating the design system). And they were commits with small diffs. The huge commits were done by copy pasting, code generators and heavy use of the IDE refactoring tools.

leoedin 9mo ago

I've been playing around with "vibe coding" recently. Generally react front end and Rust back end. Rust has the nice benefit that you only really get logic bugs if it compiles. In the few apps I've built, progress is initially amazing. And then you get to a certain point and things slow down. I've built a list of things that are "not quite right" and then, as I work through each one all the strange architectural decisions the AI initially made start to become obvious. Much like any software development, you have to stop adding features and start refactoring. That's the point at which not being a good software developer will really start to bite you, because it's only experience that will point you in the right direction. It's completely incredible what the models can do. Both in speed of building (especially credible front ends), and as sounding boards for architecture. It's definitely a productivity boost. But I think we're still a long way off non-technical people being able to develop applications. A while ago I worked on a non-trivial no-code application. I realised then that even though there's "no code", you still needed to apply careful thought about data structures and UI and all the other things that make an application great. Otherwise it turned into a huge mess. This feels similar.

throwaway0123_5 9mo ago
> But I think we're still a long way off non-technical people being able to develop applications. I'm surprised I haven't seen anyone do a case study, having truly non-technical people build apps with these tools. Take a few moderately tech-savvy (can use MS office up to doing basic stuff in excel, understands a filesystem) people who work white collar jobs. Give them a one or two-day crash course on how Claude Code works. See what is the most complicated app which they can develop that is reasonably stable and secure.
CuriouslyC 9mo ago
This is a big part of why vibe coded projects fall over. AI creates big balls of mud because it's myopic as hell. Linters help but they're still pretty limited. I've had good success using https://github.com/sibyllinesoft/valknut https://github.com/sibyllinesoft/valknut to automate the majority of my refactoring work. I still do a style/naming pass on things, but it handles most issues that can be analytically measured.

JBAnderson5 9mo ago

I think part of the issue here is that software engineering is a very broad field. If you’re building another crud app, your job might only require reading a ticket and copy/pasting from stack overflow. If you are working in a regulated industry, you are spending most of your time complying with regulations. If you are building new programming languages or compilers, you are building the abstractions from the ground up. I’m sure there’s dozens if not hundreds of other sub fields that build software in other ways with different requirements and constraints. LLMs will trivialize some subfields, be nearly useless in others, but will probably help to some degree in most of them. The range of opinions online about how useful LLMs are in their work probably correlates to what subfields they work in

skydhash 9mo ago
The thing is if you’re working on a CRUD app, you probably have (and you should) a framework, which make it easy to do all the boilerplate. Editor fluency can add an extra boost to your development speed. I’ve done CRUD and the biggest proportion of the time was custom business rules and UI tweaking (updating the design system). And they were commits with small diffs. The huge commits were done by copy pasting, code generators and heavy use of the IDE refactoring tools.