`Geoffrey Challen, a computer scientist at the University of Illinois at Urbana-Champaign, plans to offer a new course this fall in which he will teach students to develop software “without writing, reading, debugging, or viewing a single line of code,” he told me.`
This is "studying computer science" now? Vibe coding is easy and fun, but why spend 4 years and a small fortune to study it when practically anyone can pick it up over a weekend?
Heh, I think you meant to say math. Plenty of theoretical CS is study of things like algorithms, which looks more like math proofs than code. But we can all agree that vibe coding has little to do with Computer Science. And if you're not touching or reviewing the code, little to do with anything resembling software engineering, either!
I had an algorithms class in undergrad where we designed algorithms for computers with specific memory and processor configurations that didn’t exist, and specifically, would never be built.
Teaching systems is useful. The worst vibe coding I've seen has been bad system design choices. But I agree that we should also still look at the code.
Companies are laying off experienced developers 10,000 at a time with no end in sight. It's pretty irresponsible to be telling people it's a good time to get a Computer Science degree.
AI coding wouldn't even be an idea if you engineers hadn't turned everything into a peyote nightmare of distributed nodes. Stable, reliable, well-thought-out, debugged libraries are what we need. Write them!
We need more people who understand the software theories/models/mathematics/etc. of Computer Science and can develop large-scale systems via "Practical Software Engineering". Otoh, we need less of people who are mere Computer Programmers.
The idea was that you would have a Specification (Formal/Informal) defined by problem domain experts in some notation (textual/pictorial), have the tool generate code and the resulting artifact Verified (Formal/Informal) against the specification. A change in the specification will update the generated code and needed verification steps (and vice-versa) seamlessly.
This is what a current CS graduate needs to focus on (for employment purposes); viz.
2) Formal Methods for Specification and Verification. Focus on the complete end-to-end methodology like for example; The B-Method - https://en.wikipedia.org/wiki/B-Method Another example is to use Prolog for system specification.
3) Devising a methodology to trace the specification through the AI generated code using the above. For example, you can have the agent map the specifications to preconditions/postconditions/invariants in the runtime code and then have it extract those into appropriate functional documentation so you can see how functional requirements are enforced.
4) Understanding "Correctness-By-Construction"/"Design-By-Contract" approaches to software development which must be used for AI code generation.
5) Your AI prompt is now the specification. It would be a mix of Formal and Informal since only Formal can assure traceability. You have to find the balance for yourself and your problem.
The above are the main points. Each can be detailed further based on your CS study ;-)
While I agree with the message, I don't agree on the tools. It's very difficult to define a specification that works as intended, even with tools. Most waterfall software methodologies failed for a reason. And tools of the past are really not usable with AI. We need tools where it is way easier to adapt the specification iteratively, and even better, to have a bidirectional conversion. You define the spec, the LLM generate code, from the code you extract the spec, now you can compare and iterate. Then the model can focus only on the differences.
The other main issue that I see, is that even if there is a formally verified specification, at the moment, LLMs will not respect it perfectly. As long as LLMs are not able to non-deterministically follow a spec, the technology is not good enough.
A part from that, imo, in this age we should focus more on the mathematical aspect of computations, and I think we need to develop novel theories that take into account the non deterministic nature of LLMs in the process. I'm not sure this will ever work by merely extending current practices, as software design practices are extremely poorly defined from an engineer point of view. Just extending them by including randomeness does not seem a good idea.
`Geoffrey Challen, a computer scientist at the University of Illinois at Urbana-Champaign, plans to offer a new course this fall in which he will teach students to develop software “without writing, reading, debugging, or viewing a single line of code,” he told me.`
This is "studying computer science" now? Vibe coding is easy and fun, but why spend 4 years and a small fortune to study it when practically anyone can pick it up over a weekend?
Computer Science without code is as worthless as literary study without reading. That curriculum is going to be torture.
Heh, I think you meant to say math. Plenty of theoretical CS is study of things like algorithms, which looks more like math proofs than code. But we can all agree that vibe coding has little to do with Computer Science. And if you're not touching or reviewing the code, little to do with anything resembling software engineering, either!
>Plenty of theoretical CS is study of things like algorithms, which looks more like math proofs than code
Even those are just going to be outsourced to AI by the "students"
I had an algorithms class in undergrad where we designed algorithms for computers with specific memory and processor configurations that didn’t exist, and specifically, would never be built.
But we studied algorithms for them anyway.
Teaching systems is useful. The worst vibe coding I've seen has been bad system design choices. But I agree that we should also still look at the code.
You never really had to get a formal education in programming to be successful before AI either....
Companies are laying off experienced developers 10,000 at a time with no end in sight. It's pretty irresponsible to be telling people it's a good time to get a Computer Science degree.
Agree. Ai has placed the writing on the wall. killed this as a profession. I wish it wasn’t true. I have 15 years experience in the industry.
Do not learn computer science these days. We all are f***
And I’m a guy who solidly believes in understanding the fundamentals.
AI coding wouldn't even be an idea if you engineers hadn't turned everything into a peyote nightmare of distributed nodes. Stable, reliable, well-thought-out, debugged libraries are what we need. Write them!
Too little, too late.
https://archive.is/ka3wn
This is both True and False.
We need more people who understand the software theories/models/mathematics/etc. of Computer Science and can develop large-scale systems via "Practical Software Engineering". Otoh, we need less of people who are mere Computer Programmers.
I am not sure how many here on HN, are familiar with Computer-Aided Software Engineering (CASE - https://en.wikipedia.org/wiki/Computer-aided_software_engine...) methodologies/tools/techniques and how they were used for Round-Trip Engineering (RTE - https://en.wikipedia.org/wiki/Round-trip_engineering). That unrealized promise can now be realized using AI tools.
The idea was that you would have a Specification (Formal/Informal) defined by problem domain experts in some notation (textual/pictorial), have the tool generate code and the resulting artifact Verified (Formal/Informal) against the specification. A change in the specification will update the generated code and needed verification steps (and vice-versa) seamlessly.
This is what a current CS graduate needs to focus on (for employment purposes); viz.
1) The full Software Engineering process with focus on Requirements Specification and Verification. There are lots of notations/techniques available which you need to become familiar with. Some examples are Parnas Tables (https://cs.uwaterloo.ca/~jmatlee/Talks/Parnas01.pdf), Decision Tables (https://en.wikipedia.org/wiki/Decision_table), Structured English (https://en.wikipedia.org/wiki/Structured_English) etc.
2) Formal Methods for Specification and Verification. Focus on the complete end-to-end methodology like for example; The B-Method - https://en.wikipedia.org/wiki/B-Method Another example is to use Prolog for system specification.
3) Devising a methodology to trace the specification through the AI generated code using the above. For example, you can have the agent map the specifications to preconditions/postconditions/invariants in the runtime code and then have it extract those into appropriate functional documentation so you can see how functional requirements are enforced.
4) Understanding "Correctness-By-Construction"/"Design-By-Contract" approaches to software development which must be used for AI code generation.
5) Your AI prompt is now the specification. It would be a mix of Formal and Informal since only Formal can assure traceability. You have to find the balance for yourself and your problem.
The above are the main points. Each can be detailed further based on your CS study ;-)
While I agree with the message, I don't agree on the tools. It's very difficult to define a specification that works as intended, even with tools. Most waterfall software methodologies failed for a reason. And tools of the past are really not usable with AI. We need tools where it is way easier to adapt the specification iteratively, and even better, to have a bidirectional conversion. You define the spec, the LLM generate code, from the code you extract the spec, now you can compare and iterate. Then the model can focus only on the differences.
The other main issue that I see, is that even if there is a formally verified specification, at the moment, LLMs will not respect it perfectly. As long as LLMs are not able to non-deterministically follow a spec, the technology is not good enough.
A part from that, imo, in this age we should focus more on the mathematical aspect of computations, and I think we need to develop novel theories that take into account the non deterministic nature of LLMs in the process. I'm not sure this will ever work by merely extending current practices, as software design practices are extremely poorly defined from an engineer point of view. Just extending them by including randomeness does not seem a good idea.