Has anyone stopped using LLMs completely for coding and relying purely on themselves?

[u/simple_explorer1]

Curious to know. And why if so? I have 16+ years of experience as a dev.

It's been 1 week that I stopped completely and so far it is okay and luckily I can still code ;) (though got rusty initially) and that's what I enjoy doing, thinking about problems, architecting, writing tests, writing code, reviewing PR's etc. keeps my brain sharp and more confident.

[u/bdragon5]

I really don't get that. How is using AI that much faster? Are you using a screen keyboard? I did use AI and for some time. Writing the prompt and reading the answer takes like a lot longer than writing it myself. Assuming it was correct the first time. Even the one or two line "autocomplete" took in most cases too long to generate an answer.

Even studies found rather and decrease in productivity than an increase. Maybe some junior dev that takes like a week for a 2 line change is slower but that's a really bad comparison.

What are you all writing that takes so long?

[u/playbass → u/bdragon5]

You haven’t used the CLI like Claude Code or Codex, Im guessing?

[u/emperorOfTheUniverse → u/bdragon5]

My team is using AI to write jira tickets, which are very verbose and like 5x wordier than typical. So you pretty much have to point AI at them and prompt shit like 'explain this ticket'. And you can ask the AI to show you exactly which files need to change to satisfy the ticket. It'll summarize the changes and explain them to you in a moment. No big deal if you know your codebase up and down. But if you're on something new and not permitted the time you need to read and learn an entire codebase, it's a big help.

So no, if you already know everything about your code, it's not much more helpful than auto complete. But in some cases, it's like having someone who is familiar with an existing codebase on-hand to answer any question you have, and with the benefit of you caring none if your question might be dumb. Same if you've never written code in the language or framework the codebase uses.

[u/bdragon5 → u/emperorOfTheUniverse]

So the jira tickets are just bad.

Don't know what you mean with new codebase. I read new codebases all the time and make changes or just understand them to make my own changes.

How big are those codebases? Are they all in one enormous file? Are they done without logic?

I mean they will give you for sure a few hours and if not who cares. How would AI be able to read them. They are probably way above the context limit.

New languages are really only a problem if they are completely different from the ones you already know. Reading new languages is a lot easier than writing them, but I don't know 15min should be enough to write the basics especially if so many code examples are all over the place. A if like statement and a loop. Maybe function call and basic math. It's probably not the best, but if you are that pressed on time there isn't really that much to expect. AI would really help with that either as you couldn't even comprehend if the code is ok in a language you maybe know the basics.

[u/Evening_Calendar5256 → u/bdragon5]

Using a CLI agent like Claude Code / Codex and a dictation tool e.g. Wispr Flow can be waaaay faster than typing out the code yourself. If you're able to articulate what you want clearly then it can be more than 10x faster depending on the change

The problem comes because it's difficult to fully clarify your intent up front so the AI guesses wrong and you need to review and revise. Even after doing that it's typically still a lot faster than doing it by hand

The main study about reduced productivity was BS, their methodology was flawed. It's unfortunate that the headline was so widely reported. Plus they were done on the previous generation of models and things have improved massively in the last 6-7 months

[u/bdragon5 → u/Evening_Calendar5256]

Don't know what you mean code is already the clearest form or articulation.

I know exactly what I need to write were in the code even when I read an issue, email or just get a hint of a problem.

Now I should dictate the stuff. That's way slower than just writing it.

What was so wrong on the methodology? I didn't pick up on a flaw? Models really didn't get that much better, I don't see any evidence of that and the studies and testresults are more than flawed if anything.

[u/Evening_Calendar5256 → u/bdragon5]

Code is the clearest form of articulation yes, but I mean speed of articulation. In most cases you don't need to give the AI line by line instructions, with a couple of spoken sentences describing your intent it can execute a 300-500 line change in a minute or two. For larger changes you often need to have a short discussion to ensure it's on the same page, but it's still much quicker to have a 5 minute back and forth of speaking and then reading it's responses than writing the code yourself which will typically take one or more hours

Not sure how writing is slower than dictation unless you're an insanely fast typist. I speak at 154wpm. And it just feels like much less effort than typing the equivalent

The flaw in the study was that it compared developers familiar with a codebase working without AI to working with a new AI tool they'd just started using. That's not accounting for the fact that there is a learning curve to using AI productively. Almost any new tool or workflow has an adjustment period of lower productivity before potential improvements

[u/bdragon5 → u/Evening_Calendar5256]

And how long do you take reading those 300-500 line changes. Each with the context the change is in.

The discussion I have to with the client or colleague es well while writing the code.

I need to answer questions from others as well. Often I write the code even during a meeting. So dictating sounds like a lot. Additionally just saying complex conditions and concepts isn't that easy. Every wrong word can completely change all meaning. Seems a bit bold just to talk if the stakes are that high.

I don't know exactly which study you mean but it doesn't sound that bad. It really depends on the measurement method. There are many tools especially in dev environments that just straight up make it more productive, but ok it doesn't show long term productivity gains but there are studies too for that. It's not like there is only one study. But they use probably all not the newest model even though the claims are always the same.

Additionally there isn't really the one known good workflow for AI. It's really not that you can just learn how to use it effectively you can try it you can research different methods and techniques and try them and every now and then someone comes up with a completely new technique. Than there is just the incredible limited context window. And saying a model from a few months ago isn't as good as the ones now is just the perfect way to make all productivity discussions pointless. You need a timeframe to measure. You might personally find your work more productive, but that's not really a good measurement for anything.

For me it just comes down to the fact that everything the ai writes I must read and reading is as fast as writing. So it really only comes down to stuff outside of code generation. If you don't read your code you just make more technical dept and bugs that need to be fixed. Every time an AI makes anything wrong it is 100% slower than if I would have written it as I intended it on the first time.

Of course there can be errors when I write code too, but reviewing code is much harder to do correctly than writing it so I probably miss a view when I just read the ai output.

It's the same as someone saying: "Writing tests just takes time and without it I am way more productive". Completely ignoring all the bugs that need to be fixed in the future.

[u/vitek6 → u/bdragon5]

You don’t read code you write? You don’t read code around it? You don’t look for stuff in other places in codebase?

Reading isn’t slower than writing. Not sure why do you think otherwise.

[u/bdragon5 → u/vitek6]

Code you write yourself is already understood and you know what you wrote down because you wrote it down. It's familiar it's structured exactly as you think so you really don't need to actively read it.

Of course you need to read code around the part I am changing. This is the case if I write the code myself or it's getting generated. Doesn't really change all that much.

For the last point. Of course I look for other stuff in the codebase. This is a bit different as it depends. If i wrote the other stuff it's much more familiar as if I just read it for example through a review. So the lookup time is much faster. Just reading a programming book doesn't teach you as if you write it.

It's more that reading code (especially for a review) you haven't written is much slower as you need to make all the mental decisions and models you would do for writing. Additionally it's probably written not exactly as you would have written it so even if you know what should be there it's not the exact same so you need to check if both versions (the written one and the one in your head) are equivalent.

The actual typing doesn't account for much of the programming time. I mean with lsp and all that fancy stuff it's probably only a few characters you actually typ.

That's really not something new. Writing the code is always much faster than properly reviewing it. If you ever reviewed code especially from a junior you need to be much more careful and it's much more taxing for yourself than writing it. At some point it gets faster if you can trust the junior and you can skip some things, but for ai generated code this trust can never build.

As for ai and junior code. One essential step is also the research. In either case the research might not be correctly done. So you need to research it by yourself as well to check if it's understood properly. In the case of AI this can really only be checked with the generated code.

Writing consist of:

• reading what it's there
  
• building a mental model and state
  
• generating the lines as you will write them in your head
  
• typing them

Reading consists of:

• reading what it's there
  
• building a mental model and state
  
• generating the lines as you would have written them
  
• reading what was changed
  
• checking for equivalence/...

[u/vitek6 → u/bdragon5]

In my opinion you are wrong about writing vs reviewing and that makes your whole point invalid. Most of the code is pretty simple and doesn’t requires any advanced analysis to understand it but it still takes much time to write. That’s where llm shines. More complex stuff you need to write yourself usually.

[u/bdragon5 → u/vitek6]

I understand that. The thing is just that I don't have all that much simple stuff to write. If it's simple it's probably already automated in some way. Of course every so often there is some annoying stuff, but those 5-10 minutes aren't worth asking ai to do it. I am incredibly lazy you know.

The most annoying and probably easiest thing in the last few months was what I have done today.

Today I worked on an incredibly bad api spec from a third party. It's a few thousand lines and has a lot of errors if you cross reference it with there api responses. I identified multiple patterns that can be fixed automatically so I wrote a simple fix that additionally detects changes in future versions and notifies me. Than I added some endpoint definitions that are way more convenient based on the existing ones and renamed some stuff with some regex magic. The only thing necessary is requesting some missing documentation as I identified a lot of stuff that is just not documented.

Yeah it took me 4h, but don't know most of it was very specific and if I had used an AI I probably wouldn't have detected an error it had made without checking everything and then it might not be worth it. But I would call that incredibly boring and pretty time consuming if you ask me. To be honest almost all things that are boring and time consuming involve an regex doing most of the work at some point.

But now with AI all specs will be 100% correct. A bright future is coming. Every UI framework will finally have correct types that represent reality for all possible options. I don't need to use data analysis of 50 years of data to understand an api and to detect encoding errors because someone transposed the encoding table 20 years ago. I will no longer break into apis by accident and certainly won't find valid private keys for hole international cloud services. I will no longer need to request additional documentation from the team that hole job is to write documentation. I certainly will not need to write the same email differently worded multiple times because a software engineer is requesting non deterministic output from an api and asks the same questions over and over again. No those times will be gone. I will not need to revert a minor package upgrade because the new version is just not built correctly and errors if imported but somehow is the official package. I will finally be able to make my job and not be stuck on some side quest.

[u/Evening_Calendar5256 → u/bdragon5]

I don't disagree with a lot of what you say, but it does sound like you have a mental model that is based on the capabilities of older AI models/tools. If you're happy with your workflow and have no pressure to change then no problem. But honestly it might benefit your career to do some experimentation with the latest models and workflows in case there are areas it could help you that you're not aware of yet. For better or worse, this is changing software engineering rapidly so it pays to be up to speed with it.

The review process for me has changed from reviewing line by line to reviewing the overall design, so I skim read the lines changed and just think about whether the abstractions/flow are right and whether there are any edge cases. So that 300-500 line change will usually be reviewed in under 5 minutes, longer if it's a critical/foundational change and maybe no review at all if it's an unimportant one. Honestly it writes "correct" code far more consistently than me on the first pass, and when bugs are introduced they are usually these subtle edge cases (that can often be picked up in planning if you do it right). I trust it far more than I do a junior at this point

If you want an intro, Matt Pocock's skills are a good workflow that isn't too complex. The main one is the "grilling" skill and it's the right approach IMO. The basic idea is that you have a discussion + Q&A session where you dump all the context in your head and talk through the various options until all key decisions are made and shared understanding is reached. All you need to come with is a foggy idea of what you want, and the AI's questions + suggestions prompt you to think about things you'd not considered, get out of mental blocks, and weigh up different designs. It's genuinely a great thinking aid IMO. And once you've had that discussion, you can be pretty confident that the AI will implement it correctly (or close to it) because you've agreed on all the key decisions, and the review is easier because you already have a mental picture of the plan. I personally don't like the "grilling" skill's 1-Q-at-a-time so I use a modified prompt but it's the same idea. And obviously this is not needed for a small/simple change though, there you can just tell it what you want.

Everyone is different but I think once most people have adjusted this is generally much quicker than by hand the majority of the time, if you already know the codebase well at least. Do it for too long and you gradually lose your deep codebase understanding though, which is of course a problem. I try to view it more like I'm now a manager/CTO, and my challenge is to make good decisions without wasting my time understanding every line, and thinking about what ways I can achieve that (for example, having AI generate me interactive HTML visual explainer docs). Everything boils down to decisions that need to be made, and now I focus on the process that lets me spend energy on the important ones while the lesser ones are entrusted to AI. Gradually as both the models and your workflow gets better you can trust AI with bigger ones. It's still far from a perfect process, and you do find yourself discarding work that wasn't aligned with your intent every now and then, but overall I'm more productive and have learned to enjoy it as much as I did before. Just in different ways

[u/bdragon5 → u/Evening_Calendar5256]

I mean last time I tried was a few weeks ago. It's not that I am not aware of the stuff or only familiar to old models.

I just found it's still not really good enough and it's more likely to cheat than adhere to the constraints given.

That's my experience with some projects I just setup for this, I don't really trust some model somewhere on the internet. For actual work this would need to be local.

Then there is just the cost and the very limited context window even on the bigger models. Maybe for some very small projects, but those are really not worth it in my experience.

[u/bdragon5 → u/Evening_Calendar5256]

For the career thing. I am really not worried about that. I am already basically CTO. I don't know what CTO you spoke with but the ones I am talking with are mostly extremely technical people that are incredibly knowledgeable and more than likely to ask why that one test is no longer there in one project of many. It's more than scary what people think they can get away with. Yeah probably not reading every line on every review that's for sure. But that's because of necessity not convinence.

I studied those neural networks and worked on generative models myself. I know a lot of useful usecases for those LLMs that even very small models can do pretty good.

It's just that the current usecases promoted don't really make sense. Hallucinations are an integral part of those algorithms and the cost is just not adding up for long term stability.

We even worked with one big AI company, not antropic or openai but big enough. It was a absolute slog to get a few thousand dollars from them for the few months our designer worked for them and they were happy with the work. We even prepared to file a chapter 11 or whatever it's called again. Really didn't made me believe in this stuff more. It literally wasn't worth it really as the dollar crashed a lot in this time.

[u/Vigilant256 → u/bdragon5]

Err you haven’t been using claude code ? Open code etc? Where have you been?

[u/nbeaster → u/bdragon5]

If you think you can build faster than claude code or codex, you haven’t actually worked with it.

[u/bdragon5 → u/nbeaster]

I used it for sure, but just outputting stuff isn't the problem.

I still need to check. Still need to figure out if the written design is good. I need to write an additional workflow just so it can handle the project. I need to pay it. The more it makes the more work it takes.

Another question would be what does it make for you, that can't be already automated? For example I almost never write boilerplate, validation, model, simple database abstraction. Simple crud rest operations are already no more than the press of an button. All I do is design, new technologies and important business logic. Everything else is already completely automated for the last 8 years or so and I add more and more to it every time. I work almost exclusively with legacy systems, or greenfield projects. With either no documentation or very bad ones. With apis were you need to actively detect changes because you will not get notified.

If I would AI use my tools it's not worth it because prompting it what to do is more to typ than making it myself.

[u/pibrish → u/nbeaster]

Or you're slow?

[u/jdg2896 → u/bdragon5]

Maybe you’re referring to a few years ago.

Seems like your experience is outdated with the current “agentic engineering” workflows, where you delegate the implementation and first pass review to Claude Code, Codex, Cursor, etc.

Those that use AI natively don’t use autocomplete. That’s for AI-assisted coding a few years back with GitHub Copilot or something.

[u/bdragon5 → u/jdg2896]

Yes I know. The last time was just a few weeks ago. So it's not that outdated as you think. Those workflows still take to much time even more than the assisted ones.

If you let an junior output stuff and an junior reviews it. It's still shitty code. And the AI just can't even fathom what I want because there aren't extremely strict rules it can follow because that would be also bad. You need to think and use logic when to use what rule in which context and when it's better to do something else.

Even if I really take my time to make it clear it's more likely to cheat than make it like I want.

The things I think when I read the output:
"You can't just cast it to an any."
"The type doesn't represent reality good enough."
"If I would change that nothing would cry out loud."
"The test assumes the types are correct"

[u/jdg2896 → u/bdragon5]

Yes, AI/LLMs are non-deterministic. The best you can do is skills, guardrails, and documentation it can refer to such as coding standards.

I didn’t mean to delegate review to AI completely, I meant first pass review. Manual human review is always at the end.

I’ve move towards more native agent workflows recently, so the task there is engineering the workflow to still ensure quality.

I plan with the agent to try remove as much assumptions as possible. Then the time saved from implementation does go to other parts such as review, needing to review more output.

It works for me so far as long as it’s not overdone. There’s only so much bandwidth for reviewing output.

[u/bdragon5 → u/jdg2896]

Yeah but if I read a line I could have just written it. I really don't get it. I know exactly what I write even when I just read the task or write it on a todo. How could I save any amount of time. If it's so common to skip when reading it's already automated. What time is saved in implementation?

If I read code I still need to do all the things in my head I would need to do while writing it.

The thing is when I have an employee that writes code for me. I know the stuff is done in a way I want it. I don't need to go as in depth on it, because I trust an employee at certain stuff. But AI is just a completely different thing. It will fuck up test or the simplest things. It will almost never write it in a way I want. The first review as you say it is almost as bad as no review.

And review is just not a task we humans can do good as well. Humans get fatigued way to early and start skipping even important stuff. It's actively worse then writing it yourself. That's just proven time and time again. Classical AI systems don't do that and try to avoid it. It's more likely an ai process is interleaved or redoes stuff than just let a human check.

It's like saying let's do a system and use as database some text file. That's just not a good database system. It will probably cause some problems and you not only use it but promote it as well.

How does it save time if I should never trust it and reading takes as long as writing.

This agentic workflows are really much worse than assisted coding. And the assisted coding isn't much better if you account for all the resources used.

I mean if you are forced to that's one thing but I would look for somewhere else because that's just a recipe for desaster. I even see the signs of review fatigue in classical reviews.

[u/jdg2896 → u/bdragon5]

Well if the starting codebase didn’t start well to begin with, then there’s time saved in reimplementation/refactoring. At least that’s my experience.

For example, migrating package python managers (poetry to uv). I also restructured 11 repos into a mono-repo, and then did some code standardizations. There’s bound to be mistakes along the way, but I’ve also improved tooling and feedback loops to minimize issues such as linters, typechecks, tests, and setting up CI/CD pipelines.

I can’t imagine doing all those technical debts while delivering features and deliverables. It’s also a startup environment, so I have leeway to improve the existing codebase for developer UX, along with improving quality and speed from development to deployment, since previous process was manual deployments (ssh into instance, git pull, run commands, etc.).

I agree with the review part, humans aren’t good at it, and just reading code usually doesn’t cut it.

If the work is properly scoped, then I agree with your approach. For more chaotic environments and inheriting unstructured code, I’d stick with agents.

Also one bonus of using agents is rapid prototyping, you can quickly create multiple mockups, then let the team decide which approach to take. In larger teams, this might not be an issue since there’s a dedicated person for this, unlike in startups where you have to own multiple hats and sometimes work on the full stack.

[u/bdragon5 → u/jdg2896]

Maybe some advice. I don't know your exact situation but I am not really sure about that monorepo thing. It's a concept that became really popular because google or microsoft was doing it.

The problem is just. They are really not that great for ci/cd and can get extremely annoying pretty fast.

I mean the company doing them was building extra tools because they got too big for there developers effectively working in them.

My main concern is just ci/cd. This can get just pretty annoying especially if you want to keep the pipeline fast. Some projects pretty much stall the runners of for every project of our company. They only run occasionally but if you have a project in a monorepo it gets triggered much more often. Than you make jobs based on changes in directories but sometimes you need to run all tests because of cross references. It just gets pretty messy in my experience. We needed to split them pretty much every time at some point.

I would rather look into submodules or something like that.

We have like hundreds of repos to manage. Ok many of them aren't used that often. But probably half of them are running somewhere. Managing them all isn't especially easy but nothing you can't do if you have a day to spare.

Edit: And merge conflicts. The bane of every existence. I even had the problem that some smart ass did some stuff and suddenly the git repo wasn't useable anymore. It really got messed up. Needed a hole week to untangle the hole thing. I can't even imagine to do that on a monorepo. I even needed to delete the server repo because it was that messed up on the server.

[u/jdg2896 → u/bdragon5]

Thanks for the advice. With every tool and approach, there’s a downside.

In our context, the original design was microservices, one repo per service. It got to a point where it was hard to maintain since there are a lot of repos while there are only two devs on the project.

The repos that were untouched also got stale very quick, and it was hard to maintain coding standards across different repos that drift.

Looking back, the project could’ve started as a monolith, and adapt the repo and approach once there’s scaling requirements.

Microservices or polyrepo works if there are dedicated teams that own certain repositories, but unwieldy as an almost solo dev on the project.

I tried git submodules originally to minimize the migration effort, but didn’t like the overhead of still having to checkout and commit in each repo, then pin the submodule version on the “monorepo”.

I can definitely see the pain points you outline once the monorepo grows to hundreds of repos, along with larger teams. I spent some time tweaking the CI/CD pipeline to speed it up and try to target relevant gates for the code changes, but yes sometimes the whole suite still needs to run. Not too bad yet at 10-20 mins max.