I have a new technique for reliably vibecoding apps:
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
@david_chisnall around 10 years ago i had a slide in a presentation about the "ideal tool" which was "DWIM" - do what i mean.
This was meant a joke and in the following i presented, that (especially in research) "what i mean" is helplessly weak defined.
(The presentation was about "the reasonable tool")
Fast-forward 10 years.
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
@david_chisnall Those who understand history are doomed to reframe it?
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
@david_chisnall
I dunno, sounds kinda pie-in-the-sky.
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
-
R relay@relay.an.exchange shared this topic
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
@david_chisnall Let's make a Start-up and collect money first. LOTS OF MONEY. Then, we'll see if we still want to work.
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
@david_chisnall
I wish the market cared about reliability -
@david_chisnall
I wish the market cared about reliability> I wish the market cared about reliability
Nobody has cared enough about FOSS maintainers to make sure they can eat. Why would they start caring about the purity ideals of noncontributing users?
-
> I wish the market cared about reliability
Nobody has cared enough about FOSS maintainers to make sure they can eat. Why would they start caring about the purity ideals of noncontributing users?
I don't mean it from a noncontributing FOSS user perspective.
Imagine two SaaS companies.
One of them takes its time to make reliable software, and run it in a fault-tolerant configuration.
The other vibe-codes everything in a fraction of that time and releases a buggy service.
Both charge their users a subscription for the use of their service.
Which do you think will make more money?
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
@david_chisnall this will never catch on
-
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
@david_chisnall Wow, this is such a clever idea, I can't believe no-one's thought of it before. Good luck, and enjoy rolling in all that VC monies!
-
@david_chisnall
I wish the market cared about reliability@wolf480pl@mstdn.io @david_chisnall@infosec.exchange there's no need for reliability when there's a lot of liquidity.
(if there was a 1 year minimum holding period on stocks, that would change things a lot, but that would require a whole ton of restructuring of global markets) -
I have a new technique for reliably vibecoding apps:
First, you write your requirements in an unambiguous specification language. This is the prompt, but to disambiguate it from less precise prompts, we will call it the source of truth encoding, or source code for short. You then feed it to an agent that will create an of outputs by applying some heuristic-driven transforms that are likely (but not guaranteed) to improve performance. This agent compiles a load of information about how to transform the code into a single pipeline, so we’ll call it a ‘compiler’. This then feeds to the next agent that finds missing parts of the program and tries to fill them in with existing implementations. This is more efficient than simply generating new code and more reliable since the existing implementations are better tested. This agent has a knowledge base of existing code organised in grouping that I’ll refer to as ‘libraries’. It creates links in that web of knowledge between the outputs of the first agent and these existing ‘libraries’ and so we’ll call it a ‘linker’.
I think it might catch on. VCs: I think we can build this thing for only a couple of hundred million dollars! And the compute requirements are far lower than for existing agentic workflows, so we can sell it as a service and become profitable far sooner than other AI startups. Sign up now for our A round! We have a working proof of concept that can output the Linux kernel, LibreOffice, and many other large codebases from existing prompts!
This is like the conversations our town had with some university students about sustainable energy innovations.
Them, excited, clutching their speaking notes: “We have worked out that if you had a way to move individuals collectively from one place to another, for a fee that amounted to less than the total cost of ownership of their cars over a measured period, and was dependable enough for the majority of people that the cost of switching was minimized, then you would significantly reduce carbon emissions, road repairs, and traffic jams.”
Me, in my outside voice: “So you’ve invented buses.”
-
R relay@relay.infosec.exchange shared this topic
