Your subjective experience is only the tip of the iceberg of your entire brain activity. The conscious part is merely a tool your brain uses to help it achieve its goals, there's no inherent reason to favor it.
I don't agree entirely with this. I know why the LLM wrote the code that way. Because I told it to and _I_ know why I want the code that way.
If people are letting the LLM decide how the code will be written then I think they're using them wrong and yes 100% they won't understand the code as well as if they had written it by hand.
LLMs are just good pattern matchers and can spit out text faster than humans, so that's what I use them for mostly.
Anything that requires actual brainpower and thinking is still my domain. I just type a lot less than I used to.
> Anything that requires actual brainpower and thinking is still my domain. I just type a lot less than I used to.
And that's a problem. By typing out the code, your brain has time to process its implications and reflect on important implementation details, something you lose out on almost entirely when letting an LLM generate it.
Obviously, your high-level intentions and architectural planning are not tied to typing. However, I find that an entire class of nasty implementation bugs (memory and lifetime management, initialization, off-by-one errors, overflows, null handling, etc.) are easiest to spot and avoid right as you type them out. As a human capable of nonlinear cognition, I can catch many of these mid-typing and fix them immediately, saving an significant amount of time compared to if I did not. It doesn't help that LLMs are highly prone to generate these exact bugs, and no amount of agentic duct tape will make debugging these issues worthwhile.
The only two ways I see LLM code generation bring any value to you is if:
* Much of what you write is straight-up boilerplate. In this case, unless you are forced by your project or language to do this, you should stop. You are actively making the world a worse place.
* You simply want to complete your task and do not care about who else has to review, debug, or extend your code, and the massive costs in capital and human life quality your shitty code will incur downstream of you. In this case, you should also stop, as you are actively making the world a worse place.
So what about all these huge codebases you are expected to understand but you have not written? You can definitely understand code without writing it yourself.
> The only two ways I see LLM code generation bring any value to you is if
That is just an opinion.
I have projects I wrote with some help from the LLMs, and I understand ALL parts of it. In fact, it is written the way it is because I wanted it to be that way.
> So what about all these huge codebases you are expected to understand but you have not written?
You do not need to fully understand large codebases to use them; this is what APIs are for. If you are adventurous, you might hunt a bug in some part of a large codebase, which usually leads you from the manifestation to the source of the bug on a fairly narrow path. None of this requires "understanding all these huge codebases". Your statement implies a significant lack of experience on your part, which makes your use of LLMs for code generation a bit alarming, to be honest.
The only people expected to truly understand huge codebases are those who maintain them. And that is exactly why AI PRs are so insulting: you are asking a maintainer to vet code you did not properly vet yourself. Because no, you do not understand the generated code as well as if you wrote it yourself. By PRing code you have a subpar understanding of, you come across as entitled and disrespectful, even with the best of intentions.
> That is just an opinion.
As opposed to yours? If you don't want to engage meaningfully with a comment, then there is no need to reply.
> I have projects I wrote with some help from the LLMs, and I understand ALL parts of it. In fact, it is written the way it is because I wanted it to be that way.
See, I could hit you with "That is just an opinion" here, especially as your statement is entirely anecdotal But I won't, because that would be lame and cowardly.
When you say "because I wanted it to be that way", what exactly does that mean? You told an extremely complex, probabilistic, and uninterpretable automaton what you want to write, and it wrote it not approximately, but exactly as you wanted it? I don't think this is possible from a mathematical point of view.
You further insist that you "understand ALL parts" of the output. This actually is possible, but seems way too time-inefficient to be plausible. It is very hard to exhaustively analyze all possible failure modes of code, whether you wrote it yourself or not. There is a reason why certifying safety-critical embedded code is hell, and why investigating isolated autopilot malfunctions in aircraft takes experts years. That is before we consider that those systems are carefully designed to be highly predictable, unlike an LLM.
> I know why the LLM wrote the code that way. Because I told it to and _I_ know why I want the code that way.
That's a different "why".
> If people are letting the LLM decide how the code will be written then I think they're using them wrong
I'm unconvinced you can have an LLM produce code and you do all the decision making. These are fundamentally at odds. I am convinced that it will tend to follow your general direction, but when you write the code you're not just writing either.
I don't actually ever feel like the LLMs help me generate code faster because when writing I am also designing. It doesn't take much brain power to make my fingers move. They are a lot slower than my brain. Hell, I can talk and type at the same time, and it isn't like this is an uncommon feat. But I also can't talk and type if I'm working on the hard part of the code because I'm not just writing.
People often tell me they use LLMs to do boilerplate. I can understand this, but at the same time it begs the question "why are you writing boilerplate?" or "why are you writing so much boilerplate?" If it is boilerplate, why not generate it through scripts or libraries? Those have a lot of additional benefits. Saves you time, saves your coworkers time, and can make the code a lot cleaner because you're now explicitly saying "this is a routine". I mean... that's what functions are for, right? I find this has more value and saves more time in the long run than getting the LLMs to keep churning out boilerplate. It also makes things easier to debug because you have far fewer things to look at.
Haha yes, yes it is. I wrote out and implemented that approach in the links below. I've been playing with it for a few hours and I have to say I actually really really like it.
One thing I ran into is that since the RPC calls are independent Deno processes, you can't keep say DuckDB or SQLite open.
But since it's just typescript on Deno. I can just use a regular server process instead of MCP, expose it through the TS RPC files I define, and the LLM will have access to it.
For those of you interested, I wrote out and built an more RPC typescript centric approach to avoid using other MCP servers at all. Would appreciate some thoughts!
Yes I'm actually not too fond of the DX of Deno. I don't know why. It's a perfectly fine runtime and the permissions are obviously great but the texture is off if that makes sense.
I always gravitate to Bun when I can, it feels light and fresh.
Also I'm definitely going to try out your project this weekend, I've been looking for something like this to put together a free college info aggregation site from the college's public sites themselves, like financial aid dates, on campus programs, etc..
Like the the other commenter said, just for the permissions.
If Bun had a sandbox I'd use it.
Deno isn't my cup of tea (although I appreciate it more after building with it the past two days). My impression is that it is lightweight, you can deploy it easily to edge workers and it's built on rust so you can actually use it to build your own runtime with only the parts you want. (I was working on this for a game when I ran into the CF blog article).
Node/npm is the grandpa, can't go wrong but it doesn't run typescript by default and you'll lose cool points.
pnpm is cool don't really know what makes it different these days except it has a nice cache by default so you get faster installs, and you can do monorepos semi-easily. It's my default if I can't use Bun.
Bun is newer and my current favorite. You can compile to single executable, have access to most of the npm ecosystem (some packages still have minor issues), you have a built in sqlite db so it's great for prototyping, and some other niceties.
There's a lot more to it but that's the important differences I run into in my day to day.
So this is a first pass to capture the workflow part (mix code and MCP calls).
The fetch code isn't any better than the tool code I agree, but typescript code is more common so I'd guess this would be too?
But anyway I think the real power comes with the type-safety part that I left out this morning (working on it now). From what I understand Cloudflare is essentially generating an SDK for the LLM to write code against.
Instead of writing that fetch call. The LLM would generate
Correct, this is like giving the LLM full specs on your GraphQL endpoint, and telling it have fun, get only what you need.
Except it can use Typescript to manipulate the data mid stream.
So in reality this is MCP Middleware + MCP Orchestration + Tool Call Efficiency.
It will save tokens as well due to only returning what it needs, but more so just think of going from 10 consecutive tool calls, to 1 call that gives you everything you need and nothing you don't, with 1/10th the time taken to accomplish.
Yeah the main value is definitely the code execution layer. You could easily generate a type-safe client from your REST, GraphQL, TRPC layer, expose it to the Deno layer and list the types as a resource or something. No need to involve MCP at all. You're basically just defining a stdlib for the LLM.
If you run `deno check` before executing the code you'd get the type-safety loop (working on this now)
Later I want to see what'd happen if you give the LLM a repo of sorts to store useful snippets and functions with comments for later use. So the LLM itself would save workflows, be able to import them into the Deno environment and chain those together.
It definitely needs a prompt that tells it to use the MCP server but I can see it being pretty powerful.
I only did simple tests like get Reddit posts, their comments, find the weather on those days, stick them in duckdb, and run some social media metric queries.
I could see that same test being: "find me leads, filter by keywords, run against some parquet file stored somewhere using duckdb, craft an email for my boss."
I'm kind of ranting but I think this a pretty exciting approach.
Edit: GraphQL style codegen layer but for all your APIs seems like a pretty obvious middle layer for this, maybe next weekend.
I came here looking for partial solutions to fill gaps in our own attempts at CodeMode service. However I'll give you some hope ;)
> Later I want to see what'd happen if you give the LLM a repo of sorts to store useful snippets and functions with comments for later use. So the LLM itself would save workflows, be able to import them into the Deno environment and chain those together.
OMG this is the first thing you should do. We have similar now and its freaking amazing. Just discussing yesterday how I can't remember it going off the rails since implementing automem last week even.
Best thing it does, fully recaps all your daily accomplishments, across all platforms (Claude Code, Claude Desktop, ChatGPT, Cursor).
Called Automem by a friend of my (Jack Arturo), currently closed-source, though I'm sure you could reverse engineer it enough.
- its a hosted stack of FalkorDB + QDrant
- has endpoints for creating/retrieving memories
- embeds stuff using ChatGPT models
- Uses Graph nodes for relating memories together
- Has a dream/sleeping phase which degrades long term memory relevant, finds and tracks patterns and more.
- Has an MCP which connects any AI directly to memory
- Automated hooks which record memory queues on commit, deploy, learning moments
- Automated storing of all queued memories on chat end.
- A lot more magic under the hood too.
So in reality you get a near biological memory, useful by any MCP agent. To be fair Jack has about a 2 month head start on the rest of us with this idea haha.
--
The setup were building will be an always running setup, so it also has a scheduling runtime in Node that uses MD files to create automatable workflows, some uses agents, some just run bash. They can call mcps, tools, run commands, log output, use automem etc, all in human readable text.
PS Keep up the great work on your codemode service, got some great ideas from yours to incorporate to ours that should resolve the one or 2 issues we had outstanding. Will share if I get it working, https://github.com/danieliser/code-mode if it gets any where
Oh this sounds so awesome. The memory system sounds very cool. I could imagine decaying memories in the graph, their initial salience being N then as it gets referenced more and more N goes up (more edges?), keep a decay function over time?
Basically instead of mcp servers you write typescript files that are parsed to generate a typed client, these are executed in one deno sandbox, and the LLM code gets that typed client and its scripts are run in a sandbox with only net allowed.
Been having some fun testing it out today.
If you have time to take a look I would be curious to hear what you think.
Maybe I'm weird but I don't actually enjoy the act of _writing_ code. I enjoy problem solving and creating something. I enjoy decomposing systems and putting them back together in a better state, but actually manually typing out code isn't something I enjoy.
When I use an LLM to code I feel like I can go from idea to something I can work with in much less time than I would have normally.
Our codebase is more type-safe, better documented, and it's much easier to refactor messy code into the intended architecture.
Maybe I just have lower expectations of what these things can do but I don't expect it to problem solve. I expect it to be decent at gathering relevant context for me, at taking existing patterns and re-applying them to a different situation, and at letting me talk shit to it while I figure out what actually needs to be done.
I especially expect it to allow me to be lazy and not have to manually type out all of that code across different files when it can just generate them it in a few seconds and I can review each change as it happens.
Been doing it for ten years still love the profession as much if not more than when I started, but the joy of software development for me was always in seeing my idea come to life, in exploring all the clever ways people had solved so many problems, in trying to become as good at the craft as they were, and in sharing those solutions and ideas with like-minded peers.
I care deeply about the code quality that goes into the projects I work on because I end up having to maintain it, review it, or fix it when it goes south, and honestly it just feels wrong to me to see bad code.
But literally typing out the characters that make up the code? I could care less. I've done that already. I can do it in my sleep, there's no challenge.
At this stage in my career I'm looking for ways to take the experience I have and upskill my teams using it.
I'd be crazy not to try and leverage LLMs as much as possible. That includes spending the time to write good CLAUDE.md files, set up custom agents that work with our codebase and patterns, it also includes taking the time to explain the why behind those choices to the team so they understand them, calling out bad PRs that "work" but are AI slop and teaching them how to get better results out of these things.
Idk man the profession is pretty big and creating software is still just as fun as when I was doing it character by character in notepad. I just don't care to type more than I need to when I can focus on problem solving and building.
While reading your comment it occured to me that people code at different abstraction levels. I do systems programming in golang and rust and I - like you - enjoy seeing my ideas come to life not so much the typing. The final result (how performant, how correct, how elegant and not complex) is in my control instead of an agent's; I enjoy having the creativity in the implementation. I can imagine other flavors of the profession working at higher abstraction layers and using more frameworks, where their result is dependant on how the framework executes. At that point, you might just want to connect all the frameworks/systems and get the feature out the door. And it is definitely a spectrum of languages, tools, frameworks that are more or less involved.
The creativity in implementing (e.g an indexed array that, when it grows to large, gets reformated to a less performance hashmap) is what I imagine being lost and bring people satisfaction. Pulling that off in a clean and not in a complex way... well there is a certain reward in that. I don't have any long term proof but I also hypothesize it helps with maintainability.
But I also see your point, sometimes I need a tool that does a function and I don't care to write it and giving the agent requirements and having it implemented is enough. But typically these tools are used and discarded.
Agreed 100% and I enjoy that part too, I just don't really see how that is being taken away.
The way I see it these tools allow me to use my actual brainpower mostly on those problems. Because all the rote work can now be workably augmented away, I can choose which problems to actually focus on "by hand" as it were. I'd never give those problems to an LLM to solve. I might however ask it to search the web for papers or articles or what have you that have solved similar problems and go from there.
If someone is giving that up then I'd question why they're doing that.. No one is forcing them to.
It's the problem solving itself that is fun, the "layer" that it's in doesn't really make a difference to me.
> But it's not exactly rewarding to add one more CRUD endpoint. It's a shit-ton of typing in multiple layers.
i don't disagree with you but if "adding one more CRUD endpoint" and similar rote tasks represent any significant amount of your engineering hours, especially in the context of business impact, then something is fundamentally broken in your team, engineering org, or company overall
time spent typing code into an editor is usually, hopefully!, approximately statistically 0% of overall engineering time
If natural language was an efficient way to write software we would have done it already. Fact is that it's faster to write class X { etc }; Than it is to write "create a class named X with behavior etc". If you want to think and solve problems yourself, it doesn't make sense to then increase your workload by putting your thoughts in natural language, which will be more verbose.
I therefore think it makes the most sense to just feed it requirements and issues, and telling it to provide a solution.
Also unless you're starting a new project or big feature with a lot of boiler plate, in my experience it's almost never necessary to make a lot of files with a lot of text in it at once.
Yes, hence tests, linters, and actually verifying the changes it is making. You can't trust anything the LLM writes. It will hallucinate or misunderstand something at some point if your task gets long. But that's not the point, I'm not asking it to solve things for me.
I'm using it to get faster at building my own understanding of the problem, what needs to get done, and then just executing the rote steps I've already figured out.
Sometimes I get lucky and the feature is well defined enough just from the context gathering step that the implementation is literally just be hitting the enter key as I read the edits it wants to make.
Sometimes I have to interrupt it and guide it a bit more as it works.
Sometimes I realize I misunderstood something as it's thinking about what it needs to do.
One-shotting or asking the LLM to think for you is the worst way to use them.
I've found a pretty good speed up just letting Claude Code run with a custom prompt to gather the context (relevant files, types, etc..) for the task then having it put together a document with that context.
It takes all of five minutes to have it run and at the end I can review it, if it's small ask it to execute, and if it actually requires me to work it myself well now I have a reference with line numbers, some comments on how the system appears to work, what the intent is, areas of interest, etc..
I also rely heavily on the sequential thinking MCP server to give it more structure.
Edit:
I will say because I think it's important I've been a senior dev for a while now, a lot of my job _is_ reviewing other people's pull requests. I don't find it hard or tedious at all.
Honestly it's a lot easier to review a few small "PRs" as the agent works than some of the giant PRs I'd get from team members before.
> I've been a senior dev for a while now, a lot of my job _is_ reviewing other people's pull requests
I kind of hate that I'm saying this, but I'm sort of similar and one thing I really like is having zero guilt about trashing the LLM's code. So often people are submitting something and the code is OK but just pervasively not quite how I like it. Some staff will engage in micro arguments about things rather than just doing them how I want and it's just tiring. Then LLMs are really good at explaining why they did stuff (or simulating that) as well. LLMs will enthusiastically redo something and then help adjust their own AGENTS.md file to align better in the future.
Temperature changes, visual stimulus, auditory stimulus, body cues, random thoughts firing, etc.. Those are all going on all the time.