HN Explorer

You Don't Need AI to Generate Code

1 points by Lozybug ↗ HN
Hi Guys, I'm going to make a heretical statement. It's this: you don't need AI to generate code and you shouldn't use AI to generate code.Instead I believe AI should be used to elicit the user requirements and the AI can then be used to generate a specification from which code can be mapped to produce code deterministically. We were doing this in a simplified form in the 1980s. If you think this is relevant as an alternative to vibe coding and agentic engineering. Let me know I can show you how all of this works and why it is important in 2026 and beyond. Yes, I am actually that old, but I have a view on the fundamental basics of software engineering. I feel like a survivor of a lost civilisation that has been washed away and forgotten. My approach brings together formal methods and AI in a way that was impossible back in the day. But... now that we have the compute and proper AI, not just IKBS, we can focus on generating a specification and not the code. A specification that can persist across the entire SDLC. All a bit like all the other branches of engineering that have drawings, specifications and circuit diagrams and things. Cheers me dears, Loz

20 comments

[ 2.5 ms ] story [ 54.1 ms ] thread
wseqyrku
It's not even about generating code now. Good luck getting "agentic programming" out of people's head.
Lozybug
Hi Wseqyrku, I'm curious. What is it about? Genuinely interested in your view. Cheers Loz
fedupofslop
Part of me really wants to agree, part of me just thinks it's too late to go back to the old ways and some slop will always exist. Do you have any good ways to evaluate AI Slop? Made a fun project (could call it a campaign) with a similar PoV, I'm spiritually old, check it out - dontshipslop.com, and let me know if you have any ideas on how to build a slop detector that evaluates things from a deterministic spec to code program synthesis approach...
Lozybug
Great site and great idea. I'm not sure I can add much to 'detecting' AI slop when it comes to code except to assume that all AI coding tools, particularly AI no-code tools, produce code slop. For me, the way round that is to take the screens and get the inputs and outputs from that plus any processing rules and get the AI to build a spec. Then from that mechanically produce the code deterministically without AI with zero token usage. The spec of course being target language independent. The spec can of course be reviewed by the user and changed as required before code is produced, I hope that helps.
mirmor23
> now that we have the compute and proper AI, not just IKBS, we can focus on generating a specification and not the code. A specification that can persist across the entire SDLC. All a bit like all the other branches of engineering that have drawings, specifications and circuit diagrams and things.

I'm not clear what this is supposed to achieve; if engineers can use AI to generate good specs, what's the issue with using llm in tdd/codegen cycle.

currently, for complex projects with big teams the strategy seems to let llm loose and shoot for impossible deadlines which will likely backfire as llm could generate good code for a small subsystem, it fails frequently in brownfield, large projects resulting in engineering rework;

by considering human effort to code in the release schedule, and then using llm to generate/refactor/tdd a good quality software could be built, without frustrating engineers having to deal with ai slop.

Lozybug
Great questions. By using the AI to help elicit requirements and then to generate a spec using a formal software development method you bridge the gap between the users intentions and the code. The spec is visible to the user and is in a form that is easily understood by the user. AI is not used to generate the code so token burn is greatly reduced. This maybe of significance enterprises and also if the cost of tokens increases (Chinese llms may help keep costs down here at least for a while). This maybe similar to using llms and test driven development to produce the code. I'll do some more research on llm/tdd/codegen to see how that compares to what I stated to start off this topic. Thank you, I might learn something here.
aristofun
> mapped to produce code deterministically

that means your "spec" is essentially a code and the point you're trying to make is empty

Lozybug
Your quite correct, the spec does in effect become the code and the workbench that produces that spec is in effect a system compiler because a system is a program that executes exactly once. Can you expand on empty please. You have something useful to say that I am not quite grasping. I can only add that the spec can be reviewed and changed by the user with help from the AI. The spec would use a user friendly specification language that the user can quite easily understand. This gets rid of the black box spaghetti code generated by the AI. The target computer language of choice is then produced but not by using AI. The code is deterministic and suitable for safety, mission and business critical systems whilst satisfying AI software regulations. The spec then persists across the SDLC. Hope that helps, if only a little.
Lozybug
It might be worth adding that with an approach such as this, it would be possible to meet AI software regulations, for example the EU AI Act and others now coming into force around the world. Other 'regulatory packs' could be obtained directly from the specification. Would AI generated code and no-code built systems be able to do that without much post-hoc activity? What do you think?
ramkry-green
Spot on—focusing AI on strict specification design rather than raw code generation fixes the core issue of probabilistic drift, giving us deterministic safety with modern speed
Lozybug
Wow! Thank you. You've got it. If I put up more info on this and what I'm doing (I'm building a tech demo workbench based on these ideas) would that be of interest? Are you doing anything yourself in this area? You obviously understand the process and the issues.
[deleted]
(comment deleted)