[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <053939E0-5BAB-483A-9FE4-92BF35201A4C@kernel.org>
Date: Sun, 27 Jul 2025 08:23:44 -0700
From: Kees Cook <kees@...nel.org>
To: Sabyrzhan Tasbolatov <snovitoll@...il.com>, Sasha Levin <sashal@...nel.org>,
workflows@...r.kernel.org, linux-doc@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC: rostedt@...dmis.org, konstantin@...uxfoundation.org, corbet@....net,
josh@...htriplett.org
Subject: Re: [RFC 0/2] Add AI coding assistant configuration to Linux kernel
On July 27, 2025 2:37:22 AM PDT, Sabyrzhan Tasbolatov <snovitoll@...il.com> wrote:
> [...]
>- Code verification
>
>LLM does not do any kind of verification of proposed code. So the human still
>needs to compile, run, test it.
This hasn't been my experience. With the MCP cli tools I've had quite a bit of success with it doing build testing and unit testing. I'm hoping to add runtime testing, but the hurdles for getting it to sanely interact with a qemu instance is tricky.
That it will do basic build error analysis and fixing has been nice: it types faster than me, so if it's simple stuff, it's faster than me to find and fix typos or other missed refactoring work.
I've not used it for anything large for exactly the reason you mentioned: the context window is very small compared to the size of the Linux code base. But if it is given narrow goals, it does well.
>P.S.: Personally, I've decided to pause on the vibe coding, since I
>spent too much time on
>explaining to LLM the context and copy-pasting errors, and reading the notorious
>answer from LLM **You're absolutely right! Let me change my code ...**.
Oh yes; this can be so annoying. And the "mission accomplished"ism! "This is the most comprehensive set of tests ever added with 100% architecture coverage!" Sheesh, calm down. 100% build coverage is table stakes for Linux. ;)
--
Kees Cook
Powered by blists - more mailing lists