▲ 227 points
back
189 comments
I tried really hard to do this, but it turns out the models don't care about your ideas and want to do what's popular in their training data, so they will happily ignore anything you try to force down their throats, especially as context length grows or if you hit compaction.
So to make best use of the models steer them down familiar paths, mention common pattern and frameworks, use popular packages and languages that have the high median quality online.
I started my project with a few simple interface definitions and a short design / architecture doc that I include in the AGENTS.md file, but no matter how hard I try all of the models just end up ignoring it and sprinkled new seeds of variants of the same stuff all over my code base, that with each new session grow new branches.
I do highly unusual, off the beaten path projects with AI.
For instance, a game engine written entirely in LuaJIT, but allocating almost all data structures using CFFI, a very unusual, custom object-orientation DSL I designed myself, and that uses SDL3's SDL_gpu library to do all rendering, a ton of GLSL 4.6 compute shaders cross compiled to SPIR-V and Metal (which constraints what GLSL can be written), and is a hybrid tile-oriented and 3D engine.
Another example is my Emacs-like live-modifiable image-based editor, again in LuaJIT+CFFI, with a kqueue+atomic lock-free ring buffer+pthread based actor model, each running a separate LuaJIT interpreter, with a custom advicing system, event bus, async/await implementation riding on the event bus, a custom process management and IO library, and testing via Tmux.
Even DeepSeek V4 Flash mostly does fine with this, once it's built a few memories in the memory system. Let alone something like DSv4-Pro or GLM 5.2. All I can say is skill issue.
The key is to remove degrees of freedom from the agent. IMHO this is the really hard work of agentic engineering. You need to strongly constrain what the agent can even do in the first place to force it into a certain area.
That runs the danger of putting the model out of distribution, of course, so it takes some experimenting.
I'm working on a Ruby project where - on purpose - I'm disallowing any frameworks other than what's standard Ruby. So no Rails or Sinatra, just the inbuilt Webrick web server. Initially it was hard to keep the model on the rails but as I've learned more it gets easier. That said, it's clear to me that the model pulls very strongly in familiar directions in terms of how it writes code, i.e. a lot of what gets written still ends up looking "Railsy" even though my learning project doesn't use it.
It makes everyone more average and same-y. It’s a good average, better than bad, but I cringe everytime I see someone claiming it’s a force multiplier for their personal expression. Bullshit.
right, the model will listen to you for ~32k context; half of that is just getting them into the "downhill" path for being a coding assistant. You can throw in whatever your heart's desire and if it's a single fix, it might listen to you; but treating it like a smart-IDE basically means it'll follow whatever dominant pattern is in the training data.
If we had smart capitalism (the SAME PROBLEM) we'd realize what we want are per-framework or per-OS models that simply are 80% how to english and 20% the tools we need for a given project.
But that's no where the money is.
Very uncomfortable to read. The proposed idea of not reading the code you ostensibly wrote, doesn’t just challenge the traditional workflow or methodology, it challenges the identity of a programmer itself. For experienced, respected programmers like antirez perhaps reading and writing code truly has just gotten in the way of the ideas, but I cannot identify with that perspective. The devil is in the details, reading other peoples code (and code the LLM writes) evolves the idea itself, and changes my understanding of it. My view on this is so biased by the direct relation of code I read and write to feeding myself and my family (the vast majority of my programming is for a paycheck) that suggestions of removing myself from the process feel grim, not exciting.
I'm fully on the agentic coding train and haven't manually typed code in a while so I understand the sentiment around moving beyond this level of analysis. However, how can this advice work practically speaking, day to day? Especially at ones day job?
I'm sitting here working and just caught a handful of really bad decisions by the agent, one right after the other, cascading from an assumption that was incorrect. My ideas and architecture are sound in this codebase! Are those things simply to remain in the code if they work 'good enough', or are there consequences right around the corner?
For complex code changes or bigger features I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions, etc. It's not that you spend less time refining ideas, you just do it at another level of abstraction
But that does come with tradeoffs, and it's not the right thing for every project. But when it does work it does increase the amount of work you get out in the same time
People who do this are no longer engineers in any real sense. They’ve switched careers to technical management.
I don't get this perspective.
How much of the source code of the compiler you use did you read? How much of the source code of the standard library of your chosen language did you read? What about the dependencies?
How much of the source code of a huge codebase does the average developer read? I don't think any human alive has read the majority of code in huge codebases like Word, Windows, Linux, etc.
For almost every developer, the majority of the code you use every day, whether in software you use or actual code you're shipping, is not code you've ever read. And no one seems to have a problem with it, because we've built lots of processes around this. It's only when the code is written by an AI and not a coworker or random library author that people seem to have a problem.
And I get it! AI wasn't very good at writing code two years ago. Maybe even a year ago. I think it's good now, but maybe you don't - ok, that's fine, maybe it'll only live up to your standards in a year or two or ten. But that doesn't seem to be what people are arguing, it's not "AI isn't good enough", it's "how can we possibly ship code we never read", and my point is that we've all been doing this for our entire careers.
Ideas are a dime a dozen. All of us have half a dozen of what appear to be good ideas every. Execution matters, testing and sanity checking matters, actual engagement with users and iteration matters.
Sure, we're reducing the cost of idea -> prototype to near zero (well, as long as tokens are free or nearly free), but that just means we now have mountains of throw away code, within which there may a gem or two.
Nothing yet has replaced the curating of ideas that good teams do as a matter of course.
I highly respect Antirez, and as an Italian fellow programmer, for me, he's like a legend!
Although reading this article makes me quite sad; I consider myself an average, mediocre programmer, but I enjoy writing code since it's a way to build the mental model of a problem and to solve it iteratively.
I obviously use agents and all the new fancy tools, but if a great programmer like Antirez says that it's over, I think I'm not so faithful about my future as an engineer.
For some background on me to set the context for the following opinion:
- been a SRE/DevOps at banks/hedge funds for almost 20 years
- now work in L1 crypto
- have been coding since I was 12 and have also been using frontier models for the past year (including running multiple agents at the same time etc).
My thoughts:
The models are indeed amazing. They can read large codebases, find bugs, infer the root cause of an issue from partial logs etc etc.
They do still hallucinate. WAY less than they used to but it's still non-zero. In a way that's worse b/c the model will spit out a complex piece of software and say "Yep, no mistakes. I even wrote tests and they all pass!" You might think "Phew, that's great!" but in the same way we've all found bugs in production code written by smart people, there will be bugs here too.
I say this not to imply that you have to read all of the code. I say if only to underline that for big complex systems, the "let's write unit tests for the parts that ABSOLUTELY HAVE TO BE CORRECT" is still just as important as it ever was. I'm thinking of examples like:
- the order and execution handler of a trading system
- avionics flight controls
- healthcare related medical devices
- etc
As an example: I was working on a complex system. I wasn't sure if the LLM code was actually correct so I wrote up a quick script that I checked, line by line, to be 100% sure it was working as I expected. I then used that script to double check the LLM. I didn't read all of the code the LLM created. The sense of "ok, now this works" was astounding.
I'll add, a lot of the developers I work with are going this "hybrid" route too where they will have the LLM write code and tests but then go back in and double check.
In closing, a lot of these big rewrites with LLMs are possible only b/c the devs KNOW, FOR A FACT, that the unit/integration tests are correct. I'm still not convinced that you can have LLMs write all of the code and all of the unit tests and be 100% sure that it's all correct. (I will admit that this has always been difficult and even the pre-LLM days were not a guarantee that all of the code wa s correct)
>if you control the ideas of your software, looking at the code itself is suboptimal and often pointless.
This requires developers to have absolute and unconditional Trust in the LLM. It's not easy to trust it completely to the point of completely ignoring the implementation details of the code.
In one of Salvatore's discussions, he mentioned that he hasn't even opened a single file of DS4. This is a courageous choice.
But the real question is: if the younger generation stops writing code, how are they supposed to develop that "forma mentis" (mindset) that allows them to reason about design and architecture? It's only by *writing* the code that you gradually internalize development and design patterns, specifically by clashing with the "brutality" of bugs and solving implementation problems.
P.S. I read Wohpe. It's fascinating how back in 2022 (I think?) Salvatore already wrote down many insights that have actually come true (including, for instance, the ban on "strong artificial intelligence"...). So I suppose that the future will touch the very development of humanity (like the Genesi project :) )
Never thought I'd find myself questioning Antirez, but I have many questions about this post and overall attitude. For example:
> Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is far worse, and not since they are not good coders, but because it is a matter of taste.
Why is the attitude here about keeping the floor up rather than raising the bar?
Why can't we have better code with AIs? Its not impossible to do!
When I implement things by basically pairing with the AI, I end up with better designs/architectures/code than I could have written by myself.
It sounds like some people think of the AI code paradigm as one where there will be fewer but better devs producing code/designs of lower quality than they could individually produce, but that is higher quality than the average dev could produce.
Is that really better than a world where AI raises the average across the board at the expense of a bit of speed? At the very least, it seems like a far less risky and less disruptive way to still capture significant benefits from AI.
The people who I see who are "getting along just fine" in this current mess are either True Believer™ types, or are semi or fully retired and don't need to care particularly strongly which way any of this goes from an employment perspective (meaning: I know people in this group who refuse to use LLMs and people who have attitudes like the author of this article, with similar levels of experience).
I think on one level you can look at these folks and say "well, they may be able to see more clearly because they aren't so wrapped up in it all" but I've done a lot of self-reflection and I simply don't think this is true.
Some of the most exciting engineering work is happening in the DS4 repo - and I'm watching it almost like a sports game.
When the DSpark paper came out[1] the next day we had folks attempting to implement, working together, validating their failures. Eventually their work being synthesized into a PR[1] that admits performance is not ideal. Something antirez alluded to in one of his videos (speculative decoding is a great boon, but mostly for large labs hosting and serving many requests at once, and maybe not so effective for local inference).
There's recent work into "directional steering"[3] that has made it's way into per-session directional steering overrides thanks to audreyt[4].
There's support for the new Hy3[5] model also thanks to audreyt[6].
There's Pre-M5 optimizations[7] in the queue thanks to ivanfioravanti who also helped with some of the initial M5 optimizations.
I haven't watched a repo like this since llama.cpp and whisper.cpp in the early days (though llama.cpp is pretty exciting right now with the SYCL improvements that are flowing in for the new Intel GPUs).
The DS4 repo is a really interesting place to watch folks who heavily code with agents collaborate together in a way that seems pretty effective. I've been really enjoying it.
[1]: https://arxiv.org/abs/2607.05147
[2]: https://github.com/antirez/ds4/pull/502
[3]: https://arxiv.org/html/2406.00045v2
[4]: https://github.com/antirez/ds4/pull/148
[5]: https://hy.tencent.com/research/hy3
Code is not literature. It's not poetry. It does not express the human spirit. Code is a machine made of symbols. Engineers do care about the beauty of their machine designs, but in the end what matters is whether the machine performs its function correctly, efficiently, affordably. What's wonderful about software is that the function of software is to take input data and produce output data. Every aspect of it is measurable, if we build it to be measurable, because it's data all the way down. The future of software development is not reading code. It's specifying an outcome, success and failure conditions, and iterating until that outcome is reached. Throw out your software engineering "code quality" manuals, your SOLID and your Clean Code. It doesn't matter now.
This article feels too black and white
> How are you supposed to review 5k lines of code every day?
Maybe there’s grey areas of reviewing 10% of the code, ensuring tests actual are meaningful, the big ideas are correct etc. I personally find that more efficient to do by looking at some code than a proxied description of the code.
> “how is exactly the design of that part? How does it work?”
Isn’t code and syntax often, but not always, a more precise way to see that? Won’t it depend on what you mean by “how does it work”? I’d prefer pseudo code in some cases and actual code in other cases. There are times line by line details matter. There are times when bigger ideas matter.
It’s all like saying you run a car factory and should only ever give out the big ideas, never take a wrench to a car and figure out of if the factory builds cars to your expectations.
This position assumes that purely LLM-written codebases are able to scale infinitely.
IMO there isn’t enough evidence for me to feel comfortable in that judgement.
Anecdotally, I find that pretty often LLMs (even bleeding-edge models) write unidiomatic/unscalable/poorly-abstraced code when working in large codebases.
> Then I compared the implementation, for correctness, to other systems, finding that other implementations sometimes contained more errors. I researched more, and found that the local inference world is full of subtle errors that accumulate and damage the model output, issues in the attention implementation causing performance slopes after the context is over a certain limit because indexed attention implementations are broken (do more work than they should, for instance), and so forth.
I agree 100% that AI helps a lot with that. But I feel like there's something missing between "AI helps a lot with that" and "I believe reading code is mostly pointless". I genuinely wonder how the above can be accomplished without reading any code.
I believe issues will arive with AI in the near future in terms of their performance. Disagreeing with the author, I think code quality pre-AI, in certain languages, were golden. They all contained bugs but they were written in a way that bug sources would be more or less obvious and most but not all top open source software had linting guidelines, code styles & friends to help make it ingestible. Perhaps these helped said project's maintainers a great lot, but it absolutely SAVED AI when it came to training data. These top-quality repositories with thousands of lines of great code combined with hundred thousand lines of mixed quality code was the perfect formula for the big data churner™. Now what? All those repos, inflated with stars are generated by one of the 5 LLMs out there. There has been extended discussions about deterministic behaviour in LLMs, and I'm no ML engineer but to me this drop in entropy will surely cause backtracking in code quality. Of course there a vast array of improvements that can be made outside of training data, but the whole psychology attached to LLM marketing, in my opinion, obstructs those improvements. You could train a better suited way of input for LLMs, set cutoffs and posttraining in just the right places and everything but you gotta think it through. How many of those who ask their favourite LLM everything think anymore? How much of our current knowledge is safe from AI hallucinations or subtle nudges? AI has changed the world of coding, but the current state in Anthropic HQ will determine if it will just be mid-quality codegen or accelerationist fever dream.
I strongly agree with antirez. I believe that an intellectually honest programmer should recognize where their knowledge and experience is mostly beneficial, and at this point (and we've seen clear signs for some time) coding is largely solved. Which doesn't mean that you can just prompt at a very high level, but that iterating with the LLM over decisions, designs and tests, will essentially allow you to not write a single line of code by hand. Software engineering is not just coding, and it involves a whole set of other tasks requiring direction and creativity that can greatly influence the quality and impact of the software.
The most common arguments against this view seem to arise either from ideological resistance, which I understand given how painful it can be to see one’s job at risk or an important part of one’s identity taken away, or from generalizing a small number of experiences with LLMs to the technology as a whole. In the latter case, those experiences may also be heavily conditioned by the user’s inexperience in working with LLMs, or by the specific use case in which they were applied. There are still certain tasks that not all models can handle reliably as of now, however some can (usually the most expensive), and they will likely continue to improve over time.
I agree that not having to read the code is the future but I struggle to get there because the AI, like humans, can make mistakes (not follow instructions). For example, I might ask the AI to render a scene using a physical model, and we might come to an agreement at the plan stage, but then it will go off and cut some corner in implementation. So the question is how to reliably verify compliance. If you merely tell another AI to check it properly implemented the plan it too can miss bugs, so you need to put all your effort in making the acceptance tests foolproof, and this is easier said than done. You need a defense in depth approach, using the type system, unit tests, formal verification (if you can), linting, etc. It is an open question how to optimally allocate your correctness efforts for a given budget but, as models get smarter, it is clear to see that the amount of human diligence needed to achieve likely correctness for a given task (say, in LOC) is going to tend to zero (https://metr.org/time-horizons/)
What I'm curious about is how a young programmer in, say, Sicily or Finland or somewhere who is a student or doesn't have a lot of spare cash, is going to deal with a world where everything is predicated on access to expensive tokens controlled by megacorporations, or where even 'open source' models require fairly expensive hardware to run.
> looking at the code itself is suboptimal and often pointless
yeah I was having a convo with AI about this recently
I was like, I recognize AI tools are useful, but I don't end up using them as much as I'd like to
and the conversation kind of went towards acknowledging how dramatic the shift has been from using search engines to get ideas about how to manually code, to just sharing ideas for other people to maybe implement in their own way using AI
So, there were all kinds of buzz phrases that popped up like about "prompts as source code" and "spec driven development" and "context engineering" which just kind of confirmed for me that I think some of my "slowdown" with coding with AI has been due to a shift from this manual coding with search engine assistance to sharing ideas and letting AI do the actual coding
Manual review akin to skimming while reading and then reading in depth specific passages that need "deeper focus" is probably something to consider keeping doing
... I believe many programmers at this point have less impact they could have because they look at the code.
Antirez's take is bold, and probably very scary for most programmers (and especially for their managers), but I think he's mostly right. I'd even go further: people who don't adapt to this change will be soon left behind, because today things are moving blazingly fast.
This doesn't mean AI-generated code is safe. The key point here (which AR explains well in his latest YT video on his way to the gym :D) is that you still need to master the CS fundamentals. Which means:
- People who master the fundamentals will use AI to move much faster.
- People who don't master the fundamentasl and vibe code will evetually hit a wall,
but most importantly
- People who master the fundamentals but review all the code will move much slower.
Innit?
I am not sure I'm buying this. The raison d'être for our existing software engineering methods is that humans make mistakes and we needed to contain the effects of these mistakes; and without an appropriate methodology to do that, software defects will just accumulate over time. Worse, once they show up, nobody understands the code well enough to do anything about them, or at least not without considerable time investment.
This does not change with agents doing the coding. Coding agents make mistakes also. Not very often nowadays, but neither do competent human programmers. And without a methodology to keep problems in check your agentic code will also accumulate software defects over time and result in code that becomes less and less maintainable, because you have no mental model of the software.
Antirez is correct in pointing out that slop existed before we started to use LLMs for programming; I've worked with my share of really ugly legacy code myself. But the problems do not magically disappear in the LLM age, no matter how good your model is. They remain, as every model is ultimately a heuristic (albeit a very powerful one), and no heuristic is 100% accurate.
This does not mean that coding agents are useless; used correctly, they can be enormously powerful accelerators for the software development (and validation!) process, because combining your strengths with those of a modern LLM is generally a substantial net gain. But that must still happen as a part of an approach that results in maintainable software with minimal defects.
Personally, I primarily use agents as virtual pair programmers these days, which I find very useful. This is an iterative process with relatively small and contained changes, where "looking at the code" is just part and parcel of following along and building a mental model of the resulting piece of software.
Humans are fallible, so we review the code. They "hallucinate" and produce mistakes and go in the wrong direction. We evolved an entire discipline around processes, tools, reviews etc. to help remedy (not solve!) this.
For some reason, the moment those humans are being replaced by fallible, stochastic machines, we decide to just throw the baby out with the bathwater entirely and no longer leverage critical parts of this pipeline? Because it's inefficient and we're bottlenecking the process? The magic of LLMs has quite literally bought us more cycles to do this stuff, not less!
I use the things every day to an extreme degree and still I don't think I will ever quite understand the leaps in logic required to arrive at this position.
> Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. Yes, I do, but this is, at this point, something I need to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is far worse, and not since they are not good coders, but because it is a matter of taste.
I wonder why he HAS TO ("I need to...") review the code even if he thinks it is pointless? Is that because his employer, Redis, requires it?
I think the gist of what the author is saying is, AI is not good enough to just give one vague prompt to and let it go, but it's good enough for you to give it a "design" and then not worry about the actual code it writes. But you need to do a lot of QA still. And you still need to learn to code and write some code, I guess so you can give the LLM good instructions? But if giving good enough instructions requires some level of coding skill, how are you going to gain that skill if you don't do much programming or reading code?
It all sorta feels like an old guy (he says he's old in TFA) who forgot how he got to where he is today trying to give advice. Be careful what you believe, young programmers.
Problem is that in our job we are conflating several things that are different:
- Coding: Writing instructions in a programming language. Example: writing a function that calculates the total price of an order.
- Programming: Designing a solution, writing the code, testing it, and fixing problems. Example: building a small application that manages orders and payments.
- Software engineering: Creating and maintaining reliable software systems using structured processes, architecture, testing, documentation, and teamwork. Example: designing an online store that can support millions of users and be maintained for many years.
It seems like in the future coding will all be done by machines and we can use our brain for the other 2 things.
For "code", substitute "object code".
For "ideas", substitute "code in a higher level language". At least if we actually want to control the ideas. Right now, with those ideas expressed only in English, our control is limited.
What LLM coding does is generate lots of code from a fairly small English (natural language) prompt.
If you look closely, I think you'll see that this is two processes:
1. Translate from fuzzy English to precise machine-executable language
2. Translate from high-level description to lots of low-level code.
Although these two are still pretty great when they are mashed-together, I think they'd be even better, lots better, if we could separate them.
But today we cannot.
I think this blog post could use a disclaimer that Redis has AI offerings and would like to expand in the vector database market.
The fact that the author addresses the young makes me feel uncomfortable. Gen-Z knows that currently almost all blog posts have an ulterior motive and are worded in a way that claims to be in their best interests.
Do not listen to well-known programmers who use their non-AI earned fame to steer you into the unknown future.
The AI stock market is already collapsing as we speak and these recommendations aren't worth much.
I'll admit I have a bit of a skill issue here.
I'm letting go of reading every single line, especially within well-scoped modules that don't affect anything else. On the other hand I struggle to form the mental model required to "control the ideas", as it were, without reading at least some critical sections of the code and without grasping how the fundamental data structures relate to each other.
Are we saying that opening the editor is basically a mistake?
I agree that in the end the most important thing is to have the correct mental model of the code, and there is no need to know every implementation detail if you can ensure with other means that they address your requirements. An issue I can can see with not reviewing the code (especially code someone else wrote) is how do you create the mental model? Can a design.md file replace the process of slowly understanding the data flow by reading?
There are no "ideas" independent of expression.
This will be true because LLMs will increasingly generate better code faster and will outpace your patience to read the code while being entice to move forward faster because of partial trust. Like an engineer that you direct to do things, you as a technical manager can only review so much. It will drift till we are just asking it to review and give you a overview for you to review.
I think this is a possible future, but we are nowhere close with the current tech. It makes too many mistakes currently. I could envision a future where the hallucination and error rate is brought down to a very small number, but trusting your codebase completely to an LLM at this point has a 100% chance of eventually becoming a problem.
Do I have to look at the text of the article (words, letters, punctuation) to get to the ideas in it? Do ideas exist outside of the code where they are embedded? If the ideas live outside the code how confident can I be confident the code as written embodies the ideas? These are the things I keep thinking about.
It's kind of ironic reading a post with such bad grammar written by someone that seems to be so pro-AI
Actions speak louder than words.
> "didn’t you say that you check all the AI generated code for Redis?"... Yes, I do
For important code (Redis) he is still reading the diffs.
> but: try it yourself, you will discover you can’t just say “implement XYZ” and see it working.
Yes, good software still requires engineering today.
Strong agree, but in a subtly different way..
I still read the code; but I work to make a trustworthy agent, so I can skim read at review.
For a year+ I've been gaining leverage by codifying guardrails. Insanely intricate (and fun to create) lint scripts that catch things like python imports inside functions instead of the top of the file, or dumb use of dict return where the return should be a pydantic model, or the agent dumbly using the ugly default Tailwind color classes instead of my design system colors.
It's fun codifying "how we work around here" and it's been great for keeping dumb AI mistakes off my radar.
Last week I busted out my text editor and typed (typed!) a section into CLAUDE.md on my philosophy - my why. "We do test driven development because we have a computer that can instantly validate your code." "We don't modify code until we have created and witnessed some other thing that durably proves the need for our change." Etc. etc.
Well the agent leveled up suddenly and dramatically. It was a real mind opener. One of those banger realizations. I'd been leaving tons of power on the table.
When backfilling tests, it suddenly started mutating production code and rerunning to witness tests go red - something it calls "teeth". It doesn't just assume tests work and move on! I didn't ask for that, it was latent in the model. I no longer have to remind it to run new eslint rules first to prove they're correct. Sometimes it even proposes new lint rules and checks to tighten its guardrails.
What I learned that maps to what @antirez is saying:
With everything about agents, stop operating at a level of "what". The what is the agent's job.
Stop operating at a level of "how" too!
Just focus on not hoarding your "why". Tell your agent where your ideas come from, why they matter. Do not just think the why in your head. Write it down! Put it in CLAUDE.md. Offload it into the system!
Your tools will level up.
Even if it's not about the harness. Building product features? Tell it what you think the users will do. And why. It might codify the UX closer to how you'd have. Tell it what other UIs you've seen and like - it probably knows about them and can just code that - less detail needed.
And it'll bring the code closer to what you'd have written. And bring you closer to that holy grail, LGTM skim-review.
>What’s the point of scanning function by function, line by line?
Because a critical bug could be anywhere, even in a simple function. Particularly when it is written by an LLM.
Who knows when it chooses to have a bad hallucination?
Follow the vibes