Control the Ideas, Not the Code

by surprisetalk • 9 days ago

226 189 9 days ago

m_ke3• 9 days ago

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.

logicprog10• 9 days ago

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.

m_ke3• 9 days ago

It's not an issue of usual vs unusual, I'm saying the models are way better at writing and maintaining django or react code bases than your own hand rolled architecture that you define in some docs that it has to learn and keep in context. All of the models do an amazing job making local edits and working in small greenfield projects but once you get to full production systems with close to a million lines things start to rot. The code still works and the models are able to make progress but all of a sudden you have 3-4 different versions of your concepts sprinkled in random corners of your code base.

My second point is that the models are way better at things like Rust or Lua than Python or JS, because the average person producing code in those languages has way more programming experience, so the code quality of training data online in those languages is higher than the programming 101 medium blogspam type content you see in more popular intro languages.

saghm6• 9 days ago

All I can say is skill issue.

I don't necessarily disagree with the overall point you're making, but I think calling it a "skill issue" is a bit reductive. These are relatively new tools that are changing quickly, and the amount of flexibility in how you can use them is a lot higher than pretty much anything else we've built up patterns for in the industry in recent years. Rather than dismissing people who express having trouble producing the results you can, I feel like we should be giving lifting others up by providing insights into how we're able to do those things when we know that they're possible. Otherwise, how do we know it's truly a "skill" issue and not a "knowledge" issue, and the only thing stopping them is that no one has helped them understand?

ssivark• 9 days ago

All I can say is skill issue

I know nothing about you or your code, but till you make your code + workflows public and have all of it reviewed / critiqued (so that other can replicate the performance), it's hard to accept it as a serious case study.

For all we know, this could just as well be a severe case of Dunning-Kruger.

atoav• 9 days ago

It is easier to get an LLM to tell an unusual story using the most popular phrases than have it tell a common story using off-kilter uncommon phrases.

The big arc is easy to get using an LLM, getting it to do the details correctly, that is the actual hard part. So in my cases I (by other people's account a legendarily patient person) lost my cool trying to get a LLM to write CSS in a way that makes any sense if you have a design background. I ended up rewriting the whole CSS by hand, because it is inconsistent, piecemeal and just doesn't make sense. Yeah let's make everything bold and important. Yeah let's write internal implementation details into a label in the UI.

I decided to use LLMs as an aid to my own thinking, not as a replacement.

dominotw5• 9 days ago

things you described are not "highly unusual" in the way gp comment is describing. you are just remixing bunch of stuff. Thats the type of thing ai is really good at.

mpweiher2• 9 days ago

Maybe the key difference is that you are so far off the beaten path that there simply are no examples of what you are doing that the models "want" to emulate?

I've also had reasonable success with the models generating fairly idiomatic Objective-Smalltalk, my own language of which there are likely few to no examples in the training data.

I do steer them towards my own sample programs.

rstuart4133• 9 days ago

All I can say is skill issue.

I regularly see claims by people that they have produced large, reliable bodies of code using vibe coding. Unfortunately, no vibe coded project I've used comes anywhere close to code reviewed by a human. Admittedly, my sample size is very small: things like claude-code, OpenClaw, and the occasional project I see mentioned here. But compared to the things I used regularly like GNU coreutils, Firefox, Linux, vim, git and the hundreds of other software projects I use daily, vibe coded apps are in a different ballpark. Vibe coded apps of a few 100k lines often glitch several times a day, the traditional ones that have several orders of magnitude more lines often don't fail in several years of use.

AI is now being used to assist in creating and maintaining these traditional bodies of software, of course. It looks like it has enhanced productivity as open source contributions have grown by 20% or so, and we've only just started to learn how to use it. I haven't noticed any degradation in quality. It may be too early to tell, but I suspect the engineers involved wouldn't let that happen.

As you say, it's a skill issue - it takes considerable skill to produce reliable maintainable code. But I suspect that wasn't the skill you are referring to.

cyanydeez2• 9 days ago

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.

m_ke3• 9 days ago

yeah I tried rules, hooks and forbidding things like pip / python3 but it just led to the model failing to do what it wants and a bunch of token churn trying to get around my more rigid constraints.

main problem is that the harness files get loaded into context early in the session and slowly wash away as new information comes in.

_doctor_love2• 9 days ago

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.

iwontberude• 9 days ago

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.

inigyou6• 9 days ago

As a reminder, Redis was widely replaced by its non-vibe-coded fork Valkey.

logicprog10• 9 days ago

Do you have any evidence for Valkey "widely replacing" Redis, instead of just rapidly gaining adoption as well? Additionally, it's important to clarify that the replacement was 100% over licensing issues — iirc predating the vibe coding entirely — not the use of AI to code, and that furthermore, no one has to my knowledge pointed to any flaws in the Redis codebase even correlated with AI use. So this is a disingenuous framing.

inigyou6• 9 days ago

100% of the employers I worked for since the time of Valkey had replaced Redis with Valkey.

godtoldmetodoit• 9 days ago

I think that's a very unfair characterization. The Valkey fork happened due to licensing changes in Redis in early 2024.

antirez8• 9 days ago

Do you understand Redis and ValKey have mostly overlapping code bases? And of that intersection, a big part of the code was written by myself by hand. So no, that's not the case. Also as I wrote in the blog post, Redis is currently not using AI if not as AI-assisted coding. Of course I'm not writing this reply for you, since I believe if you write a comment like that, you are part of that HN slice that makes this site at this point a slop place (no need for AI for very low quality), but for others that may find this information useful.

echelon4• 9 days ago

As a reminder, Amazon and Google pillaged the Redis project and took all the profits of themselves.

OSI purity is hyperscaler brainwashing. They don't want to pay you. They want to take your labor.

Amazon and Google have made billions of dollars off of Redis while the original authors and the company formed around it have gotten none of that.

The best licenses for new database projects are fair source and open core.

Tell the hyperscalers, "fuck you, pay me".

Fuck valkey. Fuck Amazon. Fuck Google.

They're fucking thieves. And they'll lay you off the second they get the chance.

dominotw5• 9 days ago

took all the profits of themselves.

some of those profits are passed on to users too. valkey on aws is cheaper for customers too.

philipallstar• 9 days ago

This isn't true, I don't think. For example, Instagram was built on Django, but I don't believe the Django founders magically got money because their totally free to use OSS was used in the way it was licenced.

If you don't want people to use your software and make money, then don't release it with a licence that explicitly says you may make money from this software.

What was stolen?

rpdillon• 9 days ago

I don't find this argument compelling because you're selectively applying logic.

Okay, so you don't like AWS or Google. Fine. What about the thousands of other hosting companies that use Linux, Apache, Nginx, PHP, Ruby, Python, and Perl for their offerings? Are Yunohost and Dreamhost evil for using Postgres and not open-sourcing their orchestration layer?

The precise reason I build my sites on top of Linux and Apache and Postgres is because I can switch hosts at any time. But what you're advocating for is being completely locked in to the hosting service that is controlled by the company that happened to have authored the database. I would never use a product from a company that had that attitude because I would be completely beholden to them.

I get your frustration that AWS and Google make it hard for database vendors to release their work under a truly open source license. But what you're advocating for would destroy a huge amount of the value of self-hosting and open-source.

witx• 9 days ago

Follow the vibes

alexpotato• 9 days ago

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)

hollowturtle6• 9 days ago

You can have almost 100% tests coverage and green tests and still have a plane crash and LLMs shilling with you that everything is ok. To me it seems we havent learned yet tests coverage means nothing without solid code

notpachet• 9 days ago

"Testing shows the presence, not the absence of bugs"

- Dijkstra

zetalyrae• 9 days ago

There are no "ideas" independent of expression.

falcor842• 9 days ago

What do you mean? Are you arguing that it's impossible to fully translate things? Would you argue that "apple", "manzana", "pomme", "mela", "maçã" etc. all refer to different ideas?

jgeada3• 9 days ago

"Apple" is a generic name, that does not actually really express anything particularly specific.

Eating apple, cooking apple, cider apple, pig feed?

Granny Smith, Honeycrisp, Red Delicious? All apples, wildly different, all common. Even within the more commercially available variants there are significant differences: https://www.jessicagavin.com/types-of-apples/

Heck, just for cooking apples there are huge number of different varieties: https://en.wikipedia.org/wiki/Cooking_apple

Yea, "apple" as an idea doesn't really express anything concrete without lots more context.

And without more context, Apple may even mean something that isn't even a fruit, but still popular: www.apple.com

pixlmint3• 9 days ago

It's kind of ironic reading a post with such bad grammar written by someone that seems to be so pro-AI

krupan8• 9 days ago

I didn't want to say that out loud, but you are right and it's unfortunately hard to understand some of what he's trying to say

pixlmint3• 9 days ago

Exactly. And I don't want to encourage him to have the AI write the whole text, just to let it proofread what he wrote. It's a natural language processing tool. Let's use it for that.

antirez8• 9 days ago

I'm against using AI to write text targeting other humans.

hbcdbff2• 9 days ago

I appreciate the human writing, fwiw

thraxil• 9 days ago

You realize he's not a native English speaker, right? His English grammar is better than my Italian, so I don't feel the need to criticize.

krupan8• 9 days ago

There's a difference between criticizing and saying, "I'm sorry, I don't understand what you are trying to say."

pixlmint3• 9 days ago

And if you had to email someone in Italian, would you really do it with poor grammar? Or would you write it in English and translate it, or use a tool to ensure it's correct?

I'm not telling him to stop writing on his own and instead just let AI write for him, but there's no shame in letting an NLP tool do what it's made for and correct the mistakes you made writing in a language you aren't native to.

kamranjon2• 9 days ago

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

[6] https://github.com/antirez/ds4/pull/523

[7] https://github.com/antirez/ds4/pull/555

antirez8• 9 days ago

Thanks! And sorry for not yet merging many of those. The problem is, I'm dealing with tensor parallelism for the CUDA and Metal-RDMA fork right now, so was not albe to care about PR / issues for a lot of time.

zozbot2342• 9 days ago

I don't want to sound overly dismissive, but for quite a few practical cases pipeline parallelism with micro-batches will be a likely win over tensor parallelism. Of course this inherently comes with a requirement to take batched inference seriously for local use, at least in special cases where this doesn't put too much of a requirement on memory capacity. By comparison, tensor parallelism is probably good wrt. making memory- and KV-cache hungry models like GLM 5.2 and perhaps Kimi genuinely viable in a non-trivial local inference scenario.

kamranjon2• 9 days ago

Oh that’s great - I’m generally more interested in single machine use cases but the RDMA stuff is super interesting.

I do wonder if you are planning to eventually delegate some of the merging responsibilities? I see some other projects follow a similar pattern when they grow to a certain size.

wongarsu3• 9 days ago

The ability to use steering vectors seems really powerful. I know you can build your own, but are there any collections of prebuilt steering vectors? Or even just mentions of what kinds of steering vectors people are building for their own use?

zozbot2342• 9 days ago

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

This is somewhat of a nitpicking point, but AIUI speculative decoding is worthwhile if (1) you have viable unexploited parallelism that can speed up the "verify" step compared to plain decode, and (2) it's profitable for you to load complete model layers into memory in bulk, not just a tiny fraction of active parameters. (2) tends to be true for large hosters, but not only, e.g. if you're running inference on a large dense model (think Mistral Medium) with SSD streaming and a single session (no concurrent batching), speculative decoding can be quite great.

It's also a spectrum, e.g. some MoE models are not very sparse and comparatively few concurrent requests might already span most of the experts, such that loading a complete set of layer parameters and doing speculative decoding to increase compute intensity actually becomes worthwhile.

danceparty• 9 days ago

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.

wongarsu3• 9 days ago

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

qsera2• 9 days ago

For complex code changes or bigger features I often spend hours with an LLM refining architecture

The problem here is that the LLM hallucinates, so

* it will tell that something is a bad idea, even when it is not. * it will miss good ideas.

But here is the thing. Even discussing with a rubber duck can do wonders to your thought process. So may people who are noticing the usefulness of this procedure might be actually just doing a slightly better rubber ducking...

cyphar• 9 days ago

But the CPU is not executing the textual description of your architecture. It executes code.

Honestly, I've found that the architecture described to and by LLMs is always a more rosy picture than what is actually generated, no matter how many times you do an adversarial review. It's less visceral than in image generation, but the pattern is the same -- the broad strokes seem fine but the details are awful.

skydhash3• 9 days ago

I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions,

Is that something recent? I’ve been doing this for years, even in high school where we were asked essays on contrast between different viewpoints.

I don’t need LLM to do this. It’s the 101 of any engineering process to not rush with the first thought you have and indeed try to explicitly explore the solution space and base your decisions according to defined tradeoffs.

sibeliuss• 9 days ago

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?

puglr2• 9 days ago

cascading from an assumption that was incorrect

I have found including this in my AGENTS.md to be quite transformative in this regard:

Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run. For this, you must create stubs of the expected modules and exports in the red phase, so that the test cases actually run and fail on the test case assertions themselves. In some cases, when using this approach, once in a while some of the red phase test cases might "incidentally" pass, and this is ok. Before running red phase tests you should always make predictions about the number of test cases you expect to fail/pass -- this count is not the number of test files or test suites, but rather the number of test cases. By performing these red phase expected counts of passing/failing test cases, it will help you catch errors in your prior reasoning quickly and efficiently.
Always use a proof-driven, scientific method-based approach to validate hypotheses, assumptions, and conclusions: define the smallest falsifiable hypothesis, create or identify a reproducible failing case, gather direct evidence, make the smallest targeted change, and then re-run the same proof to confirm the issue is fixed. Avoid speculative fixes, broad rewrites, or changing multiple variables at once. When possible, preserve the reproduction as a regression test before implementing the fix. Consider that when gathering evidence, additional logging and durable files can be very helpful.
The strict TDD and proof-driven approaches described above could be described as "proof-driven development". Try to internalize and generalize these concepts, as they are broadly applicable.

archagon• 9 days ago

People who do this are no longer engineers in any real sense. They’ve switched careers to technical management.

edanm• 9 days ago

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.

yladiz• 9 days ago

You do not need to understand an entire program to get the benefit of reading a chunk of source code that is part of that program.

phmx• 9 days ago

The code we've shipped throughout our careers certainly wasn't reviewed only by us. It was reviewed by programmers with more expertise in the relevant area. That's a healthy and efficient division of labor, expertise, and responsibility.

huimang• 7 days ago

The idea is that -someone- reviewed the lines of code they modified, leading to the sum of code being looked at by many human eyes. Using someone else's code has always been a system of trust in this way.

AI/Vibecoding breaks this social trust, hence the general aversion to using those codebases or bringing LLM code in. It's not really about the general quality of the agents. It's about the code no longer being reviewed and understood by a human. How can one place trust in that? Unit tests don't replace careful review and considerate design.

rbehrends• 9 days ago

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.

krupan8• 9 days ago

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.

antirez8• 9 days ago

Never comment till you read the whole post, since your question is exactly addressed at the end.

krupan8• 9 days ago

The end is where you said people should still learn to program, I wouldn't know that you said that without reading to the end.

hbcdbff2• 9 days ago

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.

jgeada3• 9 days ago

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.

lantry• 9 days ago

I think "idea" is getting overloaded here. The article isn't talking about new feature/product/tool ideas, but about what concepts to use to build those features. e.g. what data structures and algorithms to use.

So your last line agrees with the article, I think. They are saying that it's still important to curate ideas, and no longer important to read the code; the time you would have spent reading the code should be spent curating ideas.

jgeada3• 9 days ago

Curating ideas requires experience and taste. Can you really develop that without looking at code? Compare Steve Jobs vs Joni Ive curating as a prime example of how taste without practical experience and context can lead things astray. And the worst of it is that it can take a while for the problem to be easily noticeable.

nimonian2• 9 days ago

I completely agree with this you. The article is NOT about product ideas. Your parent has misunderstood the article.

p2detar2• 9 days ago

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.

This doesn't strike me as wrong, but where the rubber meets the road. Let me give you an example.

My superior with close to zero programming skills, sat down with Claude and "wrote" a Django backend with SPA React frontend that enables user directory sync from one source to another and then exposes an API for other services to consume. It supports RBAC, 2FA, extensions for directory sources, dashboard with stats and what not. Everything packed into docker containers ready to deploy on the cloud. Again, the person is very skilled as a consultant, but lacks programming skills whatsoever. I did a code review, prepped a list of things to fix and he did fix them with Claude again. Later on, he used Claude to rewrite the Python backend to Go. I did no code review on that part. Fable was used in several iterations to test for security issues before each release.

Long story short, this service is now running in the cloud and the customer uses it to solve their problem. We got a couple of other customers on the line as well.

You tell me what to do with that.

Chu4eeno3• 9 days ago

Fable was used in several iterations to test for security issues before each release.

How? The point of Fable (vs. Mythos) is that it has extreme guardrails against doing e. g. security work, even mentioning "security" or "vulnerability" in the prompt will shut it down.

skydhash3• 9 days ago

You tell me what to do with that.

That if you polish it a bit, you can probably write a short story. /s

The thing is, making claims like that doesn’t prove anything. You have to either show the result or prove that is reproducible. Otherwise, it may as well be something you dream up this morning.

antirez8• 9 days ago

Execution is not the code, but how do you decide to do every part. "Idea does not matter, execution does" always meant: "big generic ideas don't matter, it is how you organize it in the myriad of details it is composed of (in a given incarnation of the general idea) that matters."

softwaredoug3• 9 days ago

But why aren't lower level "ideas about execution" more clearly expressed in code? Or at least pseudocode?

Many of us would struggle with our reading comprehension of an English description of an algorithm. But the pseudo / actual code? Much easier to reason about.

I'm not saying you should review even 90% of code. But it feels like an arbitrary line to say "never look at code". It's like never taking a wrench to a car to look at what's built to see whether you trust the car factory.

andsoitis2• 9 days ago

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?

antirez8• 9 days ago

Because Redis is not "my project", it is a piece of software many relies upon, so I use, for that software, what the community at large agrees to be ok: AI-assisted coding with human careful reading and evaluation of every line.

andsoitis2• 9 days ago

One thing I've been thinking about is what a new SDLC ought to look like in the age of agentic engineering, since the "old" workflows are likely suboptimal (e.g. PR reviews). Have you given it some thought?

iparaskev2• 9 days ago

He is the creator of redis.

simonw2• 9 days ago

I also got a hint from this that he worries the community would reject features in Redis (and Redis itself) if they expected that the code has not been human-reviewed.

I'm facing this with some of my own open source projects: I feel a responsibility to manually review the code because I don't want to damage the reputation of those projects by shopping code I haven't looked at myself, even where I'm confident that it works and is well structured already.

xpct3• 9 days ago

I really don't understand why we feel the need to drop the review aspect. Programming with LLMs is a very non-linear process, there's no prompt-to-code mapping where editing a part of the prompt would produce an identical code construct with just a small part of it changed. LLMs are incapable of ensuring the thing works as expected, and the prompt itself is lossy too. Without review, we have no tangible way to interact with the system being constructed.

titularcomment• 9 days ago

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.

xpct3• 9 days ago

I think it's related that we as humans see when something becomes hard to reason about, and decide to refactor it. I'm not sure whether an LLM with full ownership of a codebase could do that, for its own benefit.

I do see a world where models could be trained on it, but I imagine it will be more expensive, because it requires including future rewards about the models' own later efficiency.

efficax4• 9 days ago

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.

krupan8• 9 days ago

This argument is so old and tired. It started long before LLMs. People thought senior engineers could write a detailed spec and then the actual coding could be outsourced to just any bunch of cheap programmers. It never worked. A detailed enough English specification doesn't look very different from code written in our current high level programming languages

efficax4• 9 days ago

You build your outcome conditions and specifications in code as well. And you iterate on them too. I'm not talking about waterfall development. It's something else. You can spend a day just prototyping, spiking, experimenting, and then use that to refine what the outcome can be, doing more work that way than you could in a week before. I think it's crazy to think that software development processes aren't going to change.

tauroid• 9 days ago

if we build it to be measurable

I.e. if by its structure we can conclude that our test cases are sufficient. Because if we don't know its structure then we don't know there aren't undisclosed sub-partitions of (combinatorially exploded) test space where it breaks.

How do we know its structure? By specifying it. How do we do that in enough detail? Code. Or we use static analysis I guess. Which is harder.

prmph• 9 days ago

I could not disagree more.

I can't even fathom how someone can say this with a straight face. Judging by the absolute garbage (architecture-wise) that the frontier models put out, I pity anyone taken in by this sort of thinking. They regularly tie themselves in knots and dig deeper holes for themselves without my intervention.

Software is exact; its maths. We would not tolerate a machine that operates on the basis proving/applying theorems right like 60% of the time. How we think this is suddenly acceptable in software engineering baffles me. CVEs can kill people, bad software can cause severe harms

But maybe I should not be on here arguing about this. I should be out there working on how to profit off such fundamental misunderstandings.

efficax4• 9 days ago

the model does not make the architecture decisions, you make the architecture decisions. you define what success is, including performance characteristics. fuzzing and property based testing ensure correctness. what does it matter what the code looks like if it the machine you've created fulfills the criteria you define?

esafak• 9 days ago

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/)

aledevv• 9 days ago

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 :) )

aerodexis• 9 days ago

We're all project-managers now. The trust required of the LLM is no different than that that required when a PM trusts a dev-team to implement correctly. As a PM, you need to understand testability and write that into the requirements.

iparaskev2• 9 days ago

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?

qsort• 9 days ago

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?

justincormack3• 9 days ago

No its fine. The problem is trying to read all the code. Reading some is fine. I tend to focus on public APIs, and key areas. But not the thousands of lines which arre tests or will be refactored.

craigmart• 9 days ago

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.

devin2• 9 days ago

"coding is largely solved" and "self-driving is largely solved" smell exactly the same to me.

ETA: I bristle deeply at your idea that anyone who doesn't agree with you is letting their emotions get the better of them. Perhaps the world is not as black and white as you're painting it?

xpct3• 9 days ago

What does it mean for coding to be solved, and software engineering to not have been solved? If it implies there's now a set protocol that can be followed to reach good results, how has that not been the case before? If it means that we can reach better results than before, then how do we know that can't be improved further? Or does that mean we should know how English language, instead of computer code, maps to computer instructions?

djx22• 9 days ago

Actually, this paper shows that the LLMs create a lot more slop and degradation of the code after the first prompt. https://arxiv.org/html/2603.24755v1.

So iterating with the LLM will simply make it to produce worse and worse code.

brunocalza3• 9 days ago

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.

dionian• 9 days ago

he said he read it though, and check the last line

am17an• 9 days ago

Having looked at his code, I doubt this.

throwdbaaway• 8 days ago

Yeah antirez made a lot of big claims in that paragraph. Sounds like a case of AI psychosis.

__MatrixMan__• 9 days ago

I genuinely wonder how the above can be accomplished without reading any code.

We can't see the code for the laws of physics, and yet experiment by experiment we've come a long way.

That's not usually going to be the most efficient way to understand code, but I've found that it's pretty useful to be one of the few empiricists in an organization full of rationalists (software engineers are typically rationalists in my experience). I wouldn't propose that we dispense with rationalism altogether, but it does seem that the we'll benefit by achieving a better balance than we've traditionally had.

brunocalza3• 9 days ago

We can't see the code for the laws of physics, and yet experiment by experiment we've come a long way.

Interesting perspective. Haven't really thought through that lens

softwaredoug3• 9 days ago

I write 2% of code. And read 5-10%.

I feel like everyone is being too black and white. And everyone has different ways of staying in flow with a software task.

brunocalza3• 9 days ago

Yeah, totally

qsera2• 9 days ago

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?

adverbly• 9 days ago

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.

devin2• 9 days ago

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.

hollowturtle6• 9 days ago

In 2022 I published, before ChatGPT existed, a book preannouncing many things that now happened and other things that I believe will happen, so I feel like I can say this without sounding egocentric

Not egocentric but surely full of himself

This is why yesterday, on X, I said that I believe many programmers at this point have less impact they could have because they look at the code. I truly believe into that.

I have great impact because I own the code and I read it when I generate it not the contrary

How are you supposed to review 5k lines of code every day?

I have the feeling we will just lose the battle and start to randomly die inside crushing planes or sinking ships thanks to unreviewed code. Or lose money, or whatever you can think of many examples.

The working day is 8 hours. If you read the code, it is a tradeoff. You are doing less of what today is the most important part of your job, that is, asking yourself: what I’m doing with this software? What are the new directions I want to take? And also, think at new ideas, features, optimizations tricks. And doing a lot of QA.

Guess what when we hand coded we did all these points every day, now we can't because we need to go 100x faster, understand nothing that came out from the slot machine and, cherry on top, we should focus on QA instead of pushing high quality code first.

I'm really worried by the direction the industry is taking and how dangerous these "influencers" are, especially in Italy where I see he has a big follow up.

We lied on a mountain of slop before LLMs sure but at least some systems were still reliable, today you can already see nothing is reliable not even the simplest service like Spotify, programmers are already not verifying the output.

davidw• 9 days ago

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.

debugnik• 9 days ago

I think about that too. Had I grown up thinking that I need to pay a subscription to build software, I wouldn't have tried to get into engineering at all. As a teen I wanted to learn electronics and robotics, but I couldn't afford the parts to build anything so I taught myself programming and CS instead, and that's the only thing that helped me slog through academic education.

I can't imagine making the same choice again today. Nowadays I worry that software engineering is about to become short-lived right after I've entered the workforce, in which case I'll regret the time I spent to get to this point based on a false hope.

gabrieledarrigo• 9 days ago

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.

Zsfe510asG2• 9 days ago

All AI stocks are plummeting right now. Go your own way and don't listen to tech predictions, no matter how much you revere a person. Often they are all wrong.

hollowturtle6• 9 days ago

From another Italian fellow: stop following people and do your own thing, it will be worth it no matter what influencers says

softwaredoug3• 9 days ago

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.

chr15m• 9 days ago

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.

mpweiher2• 9 days ago

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.

TZubiri• 9 days ago

Author is redis dev. Seems deep in vibecode mode

Genuine question, is redis actually used by competent engineers?

The idea of a separate networked process to store and retrieve variables from memory sounds like something a first year engineer would do when they learn about a hot tech netflix uses before they learn about fundamentals like what a heap and a stack are.

fnoef3• 9 days ago

Very egocentric piece. Almost reads as “I’m so cool, I did so many cool things, and most things other people did is way worse than even the slop that my LLM prompting skills are capable to produce”.

Also “ You have to understand how things work, what is the best design, how to reach a certain level of performance.” - how does OP propose to understand how things work or what is the best design if you don’t actually go and build things or read the code? I hope the answer is not “reading mythical man month” or “watching YouTube video tutorials”.

nimonian2• 9 days ago

This is pretty unfair. If the author didn't establish some context there would be someone else here saying "Check out this dilettante telling me what to think."

I have a degree in mathematics followed by twenty years in software development (pillory me, if you like). My conclusions after 6 months of using LLMs every day are remarkably similar to the author's. I increasingly think in shapes, architectures, data structures and ideas; less and less in lines of code.

And I fully understand his point that, once the architecture of an idea is settled, reading LLM code does not feel worse than reading human generated code. Especially if you have a strong style and conventions guide.

The idea is the hard part, and it's the right place to focus your effort.

fnoef3• 9 days ago

I bet you had to solve math equations and prove math stuff to get your degree, am I right? Now imagine I tell you that you could have just prompted LLMs with “please solve the is and make no mistakes”, would you think you’d be able to get your math degree?

The point I’m trying to make is that it’s very easy to tell everyone “don’t read the code, just focus on architecture” when you have decades of experience behind your shoulders, where you HAD to read the code, iterate, learn from your mistakes, read code written by others, and actually writing and making stuff yourself to gain that experience and understand architecture.

How do you expect people to learn all this stuff that you know if don’t want them to actually do the work but instead “control the idea”, whatever this means? It’s just baffles me that people don’t see this.

Zsfe510asG2• 9 days ago

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.

hollowturtle6• 9 days ago

Totally agree. But I have the feeling damage has already been done, like full oop back then. To be precise I don't think oop was a total mistake, rather being maximalists about it was a mistake like with AI. I am so pessimist that I believe sooner or later we will testify the first death because of ai unreviewed code. I hope I'll be wrong

lioeters• 9 days ago

You're right. It's disappointing to see an established name, which I used to respect as a voice of an experienced programmer, pivoted to a different field and purpose. There's no substance or personality there anymore, only a kind of indirect marketing for how to drive an overhyped code-generation service provided by a corporation.

From out of the ruins other voices of reason, talent and expertise will surely emerge, but it will be difficult to find and listen amidst the public pollution and industrial megaphone drowning them out. The mainstream culture has been enshittified, and healthy creative subcultures have yet to grow into their stride.

waynecochran3• 9 days ago

    ... I believe many programmers at this point have less impact they could have because they look at the code.

I think my strength is now more in my ability as a mathematician and a writer than as a programmer. Being able to write detailed specs and doing QA by testing is far more productive than looking at code.

hollowturtle6• 9 days ago

Right don't do that then when you have a floating point problem or an integer overflow let's see if your ability as a mathematician helps or if you need to know the machine and the code

waynecochran3• 9 days ago

That is the part Claude can handle and actually does. In fact, recently claude automaticaly converted some spline generating code to double precision and did some other refactoring as well after it realized poor results thru tests it generated on its own! I was gobsmacked!

m3kw92• 9 days ago

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.

krupan8• 9 days ago

Everyone's a prophet now

m3kw92• 9 days ago

i use it daily and it's what is trending towards

erelong• 9 days ago

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

amatheus• 9 days ago

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.

yomismoaqui• 9 days ago

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.

hegstal• 9 days ago

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.

IAmGraydon• 9 days ago

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.

cadamsdotcom• 9 days ago

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.

mrsalty2• 7 days ago

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?

AnimalMuppet• 7 days ago

Maybe. Depends on how solid the code is in the directions that matter for that code. Does security matter? Real-time performance? Never losing a transaction? Never leaking memory? What matters for the code you're trying to write? Future maintainability? How good is AI at producing code that does not fail in the directions that matter?

People who master the fundamentals but review all the code will move much slower. But they'll be more successful in the medium to long run if they're catching things that matter. (If they aren't, of course, they're just wasting time.)

mrsalty2• 7 days ago

Does security matter? Real-time performance? Never losing a transaction? Never leaking memory? What matters for the code you're trying to write? Future maintainability?

The assumption I believe is: if you are experienced enough you will instruct your agent(s) to address all of these during your iterations.

Control the Ideas, Not the Code

Related Stories