A bit tongue-in-cheek but I'm amazed by people that don't open an IDE or look at code. Are you paid to press enter at anything that Claude present to you?
Personally I usually use Claude inside the Jetbrain's IDE terminal, even if I code by hand obviously less. I still like using the diff, navigation, quick access to any file path for my prompt etc but maybe that won't last.
(edit: although I currently use an old perpetual fallback license because I didn't like the last price increase especially as they slowly remove what I like in the UI)
You will be surprised by how many professional software engineers don't read their code or care these days.
I have seen a bubble sort function in a PR from an engineer with 10 years of experience. Meanwhile sort from standard library is easily available with one single line.
The bar has become as low as "it works" without considering what's in the code or whether the entire feature should even exist at all.
P.S. that same engineer sent out a PR of 200-file feature. The PR is so large that it freezes the latest MacBook Pro if you try to read it. Nobody reviewed it and he merged it himself. Nobody uses that feature, and nobody in the teams wants to maintain it. Now we are considering scrapping it.
The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
So it's already an improvement. Should it be manually read, comprehended, reviewed? Probably. But they can get to an improvement over what they did 2 years ago, with basically no effort. And then they can get a little bit further, with massive effort?
The "LLM-yolo" is a big knee in the cost/benefit curve. It's an improvement over their "old code". The only drawback is: it's still containing bugs, and now no one understands them. But that's not hitting them until that code has aged somewhat, so a year or two down the line.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
If mediocre code is better quality than what you wrote by hand, you've quickly discovered that you're incompetent.
> If mediocre code is better quality than what you wrote by hand
Most code I have seen and reviewed over my 25+ year programmer life has been no worse than mediocre LLM code.
It's not a massive sample, but to me it suggests, most code programmers write, is somewhere between bad and mediocre.
And here's the appeal of the models: if what you used to produced was bad-to-mediocre, and you can now do slightly better for much cheaper, that's a huge win.
> And here's the appeal of the models: if what you used to produced was bad-to-mediocre, and you can now do slightly better for much cheaper, that's a huge win.
And the guy you were responding to is seeing people produce worse code with LLMs (e.g. senior engineers pushing non-library bubble sort implementations, like they're in a high school programming class).
And if you're somehow right, it's not a "huge win" for you. It's a sign you're personally providing little value to the business, and sooner or later you'll need to find a new career.
What I'm saying is the quiet part out loud: A majority of coders and a majority of really IS bad. And now a lot of that code is actually better (big win).
Basically: the code was so bad before, that un-reviewed LLM-code is now better than the average contribution. That means, that at least short term, the vibe coding can increase quality.
The problem is that it also increases code volume (bad) and rapidly decreases understanding (even worse).
Yeah I've been experimenting with a bunch of different domains: 2D CAD, PCB design, coding obviously and recently I had Claude finish a project on all three fronts: finish the firmware(in rust because why not), change up a few components and finalise the pcb design, source all the non pcb components and do all the documentation for the installer. To be fair, it had a solid base to build from, but still, almost everything was "good enough", now I'm at work looking at PCB design that take the electrical engineers 8 weeks when I know I could have had two prototypes shipped and tested already. The fact is 90% of people are not doing the really hard stuff and Claude can just brute force pretty much any low to mid tier white collar task given enough information.
Code volume and understanding can be tackled with a proper system prompt. Even afterwards, apart from costing resources, a cross-model optimization can increase quality of the output.
Unix philosophy in the system prompt could be useful if the code wants to be worked on later again.
> Unix philosophy in the system prompt could be useful if the code wants to be worked on later again
There is no system prompt that can prevent this. If all you needed was some kind of rather short instruction we'd already have that baked into harnesses a long time ago. The problem is not that agents do not have the right instructions, they theoretically have everything there is to know about software architecture already in their training data.
They do have "everything" but that's too much, I think. They need to have direct instruction that is in the context, that is appropriate for the project and codebase at hand. In the whole universe of training data, there's every approach imaginable. What's needed is enough guidance to identify the right approach consistently.
I recognize that crafting a 'perfect' prompt is impossible, but neither is writing the perfect code, or even the 'perfect' code style guide. But it is 100% the kind of problem that can be iteratively improved to a point where it's much better than what you get by one-shotting everything without much consideration of these details.
I myself am maybe 5% sophisticated if 0 is I just discovered LLMs today, and 100 is the most skilled at using AI the world has seen. What I've learned so far is that I have a lot of room to improve.
Which is why I am actually not completely worried about the careers of current software engineers: If you brought in a bunch of non-engineers to prompt Claude to build and maintain an ERP system, or a social networking site, or an ad exchange, or even Shopify clone, I don't see those products being competitive with ones where engineers armed with the same LLMs are building them.
> They need to have direct instruction that is in the context, that is appropriate for the project and codebase at hand
> I recognize that crafting a 'perfect' prompt is impossible, but neither is writing the perfect code, or even the 'perfect' code style guide
This is not about "perfect code" or style guides. For code styles we have linters, that does not require any instructions. I'm talking about software architecture for large complex web applications that dozens of people (that also change frequently) contribute to and that is spread across many different repos/services and an environment with constantly changing business requirements.
The terms that are relevant here are: coupling, cohesion, vertical slices, module boundaries and so on. This is software architecture and coding agents are terrible at this and there is no prompt and no instruction fixes this that could reasonably fit into a context window. I don't even think that coding agents fail because the lack the instructions and therefore adding instructions won't fix these failure modes.
> What I'm saying is the quiet part out loud: A majority of coders and a majority of really IS bad....
How would you know "the majority" from your anecdotes? Maybe you just spent your career working with incompetent people who didn't care.
And actually there's a point I forgot to address earlier, in my first comment:
>>>>> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
People whose hand-written code is worse than "mediocre LLM-code with a mediocre LLM-review" are not going to discover the LLM-code is better, because they typically don't care. That's usually the whole problem with that kind of person.
> ...And now a lot of that code is actually better (big win).
> Basically: the code was so bad before, that un-reviewed LLM-code is now better than the average contribution. That means, that at least short term, the vibe coding can increase quality.
> The problem is that it also increases code volume (bad) and rapidly decreases understanding (even worse).
You're contradicting yourself here. Even accepting your statements uncritically, it doesn't sound like a "big win." It sounds like a marginal improvement that's ultimately self-defeating.
The problem with hand review I always had was trying to teach the other person. You don't want to present them with an avalanche of problems. So you pick the most important 5. Over time this iterates and you build someone good at what they do.
The good part of LLMs is you don't have to worry about overloading them: you can just outline every problem with the code they produce.
The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
There's also the problem of this ultimately being my code. It isn't Claude's - Claude isn't a person.
I still read the code. I use LLMs to review it. But I also review it myself. Ultimately its faster than before, and probably better quality (because I can just give all the problems to the LLM), but slower than people doing zero review.
> The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
After I give feedback to the AI I then ask it if we learned something and then I ask it to store that guidance in a relevant skill file.
I have skill files for everything and anything in my project. Three just for testing - one for frontend, backend, and e2e. I have one just for frontend forms. I have one for project terms, which I ask it to read before doing anything, so it keeps the terms in the project right. I have one for doing db migrations and one for doing backend routes. I have many tens of skills that have been slowly built up like this.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
Not my experience at all. Mediocre LLM-code, mediocrely reviewed is a loaded footgun aimed at both your feet.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
Emphasis mine.
I can't phantom some that bad at coding. Using such exaggeration void your comment.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
No, I find that most teams I've been on have 5% to 20% of their most artisan engineers actually giving a shit about the code, and gently coaching the other 95% to 80% of the engineers who are usually much more junior during code review to not push unmaintainable slop. If you're on a team that doesn't still have someone giving a shit, it's not a sign that there are no teams that don't give a shit, it's that you're on a shit team.
There are also teams where the incentive is to get to pull request (or merge request) as soon as possible, so that you can move the ticket across the board and relieve downward pressure. That usually means pushing subpar code to PR that you know you'll spend another few hours fixing. EDIT: I bring this up because this can bias one's belief that humans produce poor quality code, when you're usually looking at the first draft that was incentivized to be pushed out "too early".
Anyway, if you're on a shit team, but you're still satisfying product and nothing is blowing up yet, there's a pretty good sign that your software has no moat and will be the first to be replaced by LLM-generated software on-demand. This is probably where most niche B2B back-office, front-office software sits. Stuff that sits somewhere in the realm of "We could probably do this in Excel if we wanted to."
It’s so easy to generate a pile of crap now that it “just works” as you say.
Quality, maintainability, simplicity, understandability, flexibility etc all still matter at $DAY_JOB, where you’ve got paying customers. We’ve got a responsibility to write good software that adds to people’s lives.
I’d recommend to try to raise the bar. Commit messages written by humans, no PRs above a certain size, any PR needs an introduction / explanation by author first for the reviewers.
This is not overly surprising to me, the last decade or so has seen the industry become a "good job that pays well" and many people got into not for the love and craft, but for the money
I dont think it has as much to do with that as it does rising expectations from leadership to just ship MORE.
MORE MORE MORE like AI has given executives an excuse to ratchet up performance expectations by at least 3x (as in my company) up to 10x for certain start ups I've heard.
There's literally not enough time for a human to do all the activities around quality they were doing even a year ago.
This kind of thing is awful if this is how engineering is going for user-facing apps, but disastrous if this is how it's going for infrastructure and libraries.
It's interesting your complaints are similar to mine about TDD. I've dealt with so many engineers that assume that coverage and passing tests is the bar.
When you get paid to care, you will care. Unfortunately, no one cares, they just want results, any result. Bubble sort will do, especially for low volume tasks.
Use the time you save by not caring, to do other fun stuff.
> Use the time you save by not caring, to do other fun stuff
What kind of time do you save, especially at work? At any normal software shop you have an endless list of things to do. And most often you don't get to choose the "fun" part.
Had AI do some work parsing markdown with the leading library for it.
Follow up work to generate markdown? It wrote a mess of manual string building instead of using said library lol. Even with strong AGENTS.md guidance around using existing and leading community libraries they will often take a hard left and write stdlib straight into your repo.
Y'all should scrap that feature and maybe the engineer. I believe the Shopify CEO recently referred to those types of PR as "slop grenades" that cause headaches for everyone else..
I used to use Claude inside of a terminal within Webstorm until I realized I rarely looked at the code in the IDE. Instead I was creating draft PRs and reviewing the code in github. Now I use claude inside of herdr, and I appreciate having more screen real estate devoted to claude. As a long-time Jetbrains subscriber it pains me to stop using it. But at this point, I'm not sure what they could come up with that would be compelling enough for me to switch back.
Their coding agent "Junie" is actually really good. The problem is they force you through only a few curated models. And try to funnel you through them to subscribe to do it, too. It's not like Pi or opencode that lets you just point at an OpenAI API endpoint and then choose whatever model. If I recall you can even actually use local models, or openrouter etc, but only use the specific model variants from their curated list. It's insane. They tried to stick themselves in the middle, and failed. Nobody will use it.
They've also done so many pivots on AI, all of them weakly and annoyingly done. They couldn't even pull of FiTM copilot well, they were super late on it and it had all sort of bugs.
They could have just taken the loss and written an amazing GUI coding agent that integrated well with their IDE -- amazing integrations with their refactorings, etc. -- but that played well in other people's ecosystems but they refused and tried to own the whole pipe. Or something. They just confused me.
Their latest attempt is to allow you to connect to and run other people's agent harnesses inside the IDE and it works well enough but it wasn't enough to grab me since I (like you) use herdr on another machine to do the coding.
I've been using their products since ~IDEA 3.x. Almost my entire 25+ year career really. My fingers are wedded to their keystrokes.
JetBrains face a unique problem: they are a real business that can't just raise infinity money from SoftBank or request government bailouts because the sheer size of their debts imperils the financial system. So they have to do things that might seem annoying or overly pushy versus their competitors.
For their entire existence people have complained about JetBrains this way because they always face some competitor that isn't making money and isn't even trying. Eventually those competitors go down, but a new one instantly arises. People just really love losing money on developer tools.
Wanting to charge money for an AI service is a clearly sensible business move. If their competitors weren't shredding the world's entire supply of investable capital as quickly as possible, this would be a good strategy. Alas.
You can actually configure the ide with any open ai compatible endpoint, I use llma and it lists all the models that I have currently installed, works well. Or am I missing your point?
Junie in particular, or just their various other "AI Assistant" / "Chat" things? They have multiple confusing overlapping products/modes going on. "JetBrains AI" -- which may or may not be same as "Junie"?, "AI Chat", then there's the "Agents" tab which integrates outside coding agents.
I guess they iterated quite a few products to "not get behind" and see what sticks.
Most recently they integrated air, which is basically an "agent management/orchestrator" where you can run any ACP-compatible agent with any model you want and it's just the single place where you manage them, see their progress, steer them, merge their results etc.
AI Assistant > Providers & API Key
There is an option Third Party AI Provider, where you can select OpenAI compatible, and then you can customize where (core, instant helper, inline etc) do you want to use third party, where JetBrains.
I switched to vscode because the complexity and runtime overhead of intellij were no longer justified with Claude writing most of the code. I work on a big java code base and every two days I had to wrangle with intellij cache, clearing it or what not. With Claude I'm working in multiple work trees at the same time and this just amplifies every issue intellij had with slow indexing and broken caches. And TBH nowadays I eyeball the code more than read, so a basic code editor with navigation seems enough
I'm slowly accepting that this is the new reality.
I've spent 1 month between august and early september writing some of the best code of my life. LLMs only provided feedback, I wrote all the code manually, still remember it by heart.
I was very delighted by the many architectural iterations that led to it. 9 files, around 10k lines of code (of those, 7k tests).
By the end of super funny exercise I kinda realized that if I had the same feature vibe coded it would've been better. I would've done much more and progressed more feature wise.
I just feel stupid hand writing my code.
It doesn't help that I work with stellar individual contributors. All of my team mates (except a junior) are either all former faang or contributed to projects we all use (from the TypeScript compiler to Linux). And they are all abandoning if not spearheading the abandonment of reading code. I'm talking people that truly loved the technical aspect of it and excelled in it.
I just feel stupid, like I'm carrying a weight that I should abandon.
Comments like yours feel would've made sense 6 months ago, but now are crumbling.
Software is essentially so cheap and throwaway nowadays that letting LLMs write it is imperative. When you find your use cases you start reviewing it or rewriting it thoroughly.
I’ve been using agents to do the code for me, but I explicitly tells it to iterate in small changes that I can review and approve as it happens, not after a 2k lines diff. It makes me understand what’s being made, and test every little change before we move on to change other parts of the code. Also helps you correct any misunderstanding right from the start.
I just look at my own diffs in a draft GHE PR and iterate with my agent on Github. This is often a much better UX than trying to make sure every single linter or thing is consistent between my machine and the CI machine. We do use Docker but it's still just easier to do it all on the CI box / Github.
When you give a ticket to a jr developer, do you look over their shoulder the entire time they write the code? Or do pause to answer questions, give feedback on how to go about a task, and review their results?
Using a CLI coding agent in your IDE's terminal is a terrible way to view conversation history and works poorly for organizing multiple conversations.
It only fits a hands-on, merely AI-assisted development approach, on one feature at a time, that is not typically productive compared to agentic development.
You might disagree, but you'll find that the proponents of the hands-on approach are losing ground every month as AI gets better at working autonomously.
Agentic development is basically a scam IMO. I’ve written about this before, but collaborative coding with AI is a huge productivity boost and you can still own all the quality. Ultimately with agentic development there’s too much you can’t, and won’t, review. The quality slips out of your hands.
I still read all the code AI produces, and I have a specific workflow. I scaffold the API first using AI, then review it for quality. Then I write tests, and review them for quality. Implementation is last, and technically I need not review the code but I choose to.
When I’ve done agentic development, the only thing I’ve accomplished is 100x more token burn with lower-quality code. It’s also not faster, because the tokens cost time and so many mistakes are made that must be cleaned up. The agents burn so much time going around in circles, when I could’ve just steered the model to write a good implementation.
Keep in mind, this is very fast. Models still produce thousands of lines of code in mere minutes. And with tests backing them up and an API frozen, the model goes much faster as it can iterate and has a framework for what it’s doing.
Except surrendering cognitive control over the system being built makes things worse.
Claude constantly makes poor architectural decisions, adds unnecessary and costly checks, makes wrong assumptions, etc.
Doesn't take the value out of LLMs writing code, but they need to be properly steered and reasoned with. How will you do so if you don't even browse the code it generates.
I always suspect that the people all in fully agentic codig like this are mostly creating prototypes, half-assed copies of existing products, etc.
This doesn't say much. Plenty mobile apps, even paid ones, are of shovelware quality. And even if that's not the case, it's typically something very self-contained and of relatively low complexity.
On my personal projects I also seldom need to review code very thoroughly. But it's also not super complex stuff.
At my workplace things are not like that. It's a very complex system on a highly regulated environment. Opus 5.5 constantly get things wrong in ways that are simply not acceptable.
And I am not even an AI naysayer. I accept it as another development tool.
The quickest sign I have right now to find if the developer/team don't read their code is looking at their recently AI-generated test cases. Often, coding agents go too verbose in their tests and they are most often overlooked even during normal reviews. If there are verbose tests, like declaring a constant and asserting it's value, you know that the code isn't being read much.
JetBrains still has best tooling for previewing changes, resolving conflicts, git integration. I get that vibe coders not necessarily need all that but it's the best class tooling money can buy.
They should look into selling a standalone git conflict resolution app. Though for my money, nothing beats Fork if you're on a Mac: https://fork.dev (just wish it supported jujutsu)
Personally I don't use CLI anymore, Codex app is very good and it starts to look like how IDEs will be in the future. You can review code in a GitHub style diff and leave inline comments (super useful), have multiple agents work in parallel with or without worktrees, plus there is very good code navigation (especially if you ask followup clarification questions that will link to other parts of code).
I keep lazygit open next to each Claude/Codex session that's working on a change, but over time scrolling the changes has gone from necessary to just out of curiosity.
At this point of 2026, if you're reading code and still catching things, then the problem was before the code was written. You should have decided more high level preferences like invariants before the work began.
Related, it amazes me how many seasoned developers don't know how to do basic tasks in their editor/IDE with the keyboard and instead rely on their mouse. Most people don't need to be super users, but it baffles me when I see a developer who hasn't at least learned the keyboard shortcuts for opening files and jumping to functions/methods, etc.
I’m only a mild keyboard user in IDEs, but I think I’d go mad if the keyboard shortcuts for quick open, jump to line, jump to function, etc suddenly disappeared.
I was at a product developer conference a few weeks ago (will keep the company name private for now), and the speaker asked the room, How many of you are "still" using an IDE to create your applications, implying that if you are using an IDE, you are a dinosaur. I don't believe that but some company leaders are thinking it.
I’m sure there are people who aren’t looking at the code at all. But for those that are I guess I’m wondering why bother with an IDE anymore?
I’m finding I can just review everything I need to with a text editor like Neovim now. Even GitHub review is probably good enough for people.
I've found that reviewing generated code, leaving comments, and asking Claude to address my comments is usually enough. When it isn't, a common editor is usually sufficient, and an IDE takes too long to start for the very small change I want to make.
I am mostly happy with Neovim with an LSP integration. I'm not going to say it's "lighter" or anything because rust-analyzer isn't exactly "small", but it is a simpler, and IMO "cleaner" interface. Also completely free.
I do look at the code and have to correct Claude most of the time, but I've noticed that with AI-assisted coding, I mostly look at the diffs when i'm inside IntelliJ. I don't need a pricey full-fledged IDE to just look at files and their diffs.
Actually I really only need bare vim now. It's really refreshing. I can view, navigate, diff etc without any fancy plugins. I can add comments where I want the agent to change something.
> Are you paid to press enter at anything that Claude present to you?
I mean, sometimes work falls exactly at the tool's strongest suit/match.
I am trying to think of what a comparison here could be but, for example, I remember early days in my career where pretty much 80% of the work was writing boilerplate and using scaffolding/generator tools, plugging them in the various plumbing and pipes of the stack, and just ticking boxes through Jira
Lots of "CRUD" and/or similar "recipe" type of work that was really just turning your brain off and needed that grunt labour force
You may ask: why is the person even needed?
My answer is the same as before: I don't know, I didn't know why were they needed back them either, felt like all could be automated as well, maybe the cost to invest in automating and mapping that all out was never a priority and the ROI math was "good enough" for the business while leadership had other north stars they were worried about?
> I'm amazed by people that don't open an IDE or look at code
Oh, boy, here we go... Sighs and pulls up a chair.
Using an IDE has nothing to do with looking at code. The best engineers I've ever known use what JetBrains aficionados would refer to as "editors", not full-blown IDEs. To a person, not one of them felt as though they were missing anything they wanted or needed. I would probably even say "Unix is my IDE". I have a terminal chock-full of advanced command line tools to search and manipulate codebases. It's always fun and convenient when a GUI gives easy access to those things, but it's just that: a convenience, and only when the GUI exposes the full option set of the underlying tool, which they almost never do. Basically, I can alt-tab to a terminal, press up-arrow to expose "cargo build", and hit enter to run it, about as easily as someone else can select the build menu in an IDE. Further, if that build menu option is any less configurable than Cargo.toml, I'd prefer the text config any day. And finally, "cargo build" works with any editor I'm using that day, even if they don't their own build system wrappers.
IDEs are fine for people who enjoy them. I grind my teeth whenever anyone hints that they're remotely necessary for, well, anything, or that people who aren't using them are somehow missing out on something. We know what we're missing, and frankly, we're not missing it.
If you need to review every edit that claude wants to make what's the point in using it? We're now treating it basically like a junior dev. Do our best to make sure that it's on the right path (leaning hard on the superpowers plugin) then let it work and look at the result. Though even that review is heavily AI assisted now. Our leadership has mandated that everything that can be done by AI, should be done by AI. We've only been in that mode for a couple of months but I'm starting to think that it's plausible with proper human steering and oversight.
I'm not being flippant. If I need to sit and watch a claude session reviewing every edit it makes, that's slower than me coding the changes by hand. Either it's good enough to work independently or it's not worth using. I have no idea how Google is using AI, but from what I've seen at my own company I do know that using AI effectively _and_ setting up repos/projects for good AI usage (and with guardrails to keep AI in check) are both acquired skills. Skills that the majority of devs don't have right now.
Really the single biggest piece I use today is using a tool like superpowers to ensure your task is well defined. Added bonuses are its TDD implementation skills and multiple review steps baked into the workflow. Before I discovered superpowers I was manually telling claude to do these workflows, the plugin makes it easy.
In the repo itself:
* Keep agents.md focused; claude likes to really bloat it by default. The "Adding guidance for AI agents" rules go into every project and have worked pretty well.
* Aggressively use nested agents.md files. Focused rules located where they're relevant seem to do much better than having a large whole-project rule dump in the root agents.md.
* Recently I've started using the tech debt and deferred work documentation rules. Claude frequently decides on its own that some piece of functionality or issue is "deferred until later" or "out of scope". These rules help make it clear so that you can make it fix the item or at least have it documented for a followup session.
* Have it test all the things. Most of my personal projects with claude have about a 3:1 ratio of test:application code and high coverage. Claude make it easy to build test harnesses for things that most of us wouldn't have bothered with 5 years ago.
* Strict type checking, linting, static analysis, warnings as errors, etc. Anything you can turn on or add to block questionable code, do it.
* Use a claude pre-tool hook to run all of your checks before you allow a git commit command. Left on its own it can and will decide that it has a valid reason to bypass git commit hooks (husky) to commit broken code or tests.
I'm paid to produce software that has features and works.
Nobody cares how I get there or how ugly the code is. They care how fast I can do it and how reliable the software is.
I look at code sometimes, in down time, to see what's been done terribly by AI, and to fix it and hopefully fix the process so that things don't get done terribly in that particular way in the future.
It's not about "how ugly the code is". Poor solutions heaped on top of poor solutions can result in a system with real users and intractable issues. I'm all for AI, but not reviewing the code seems likely to cause issues long term.
Well, I used to pay more attention to the code, and then I found that if I spent more tokens having the AI review its work than actually creating new features, I was able to get more, better work done.
The AI review stage is where I've found prompting matters a lot more than that initial prototyping phase. I've iterated on prompts and tooling that help the AI keep the codebase clean-ish.
> Well, I used to pay more attention to the code, and then I found that if I spent more tokens having the AI review its work than actually creating new features, I was able to get more, better work done.
Of course it did. Because reviewing code thoroughly is harder than writing it.
Writing only consists of "making sure it does the task", reviewer have to understand code first, check if it does the task, then check whether it doesn't affect something else negatively (and it can be meta things like "doesn't adhere to project style", even if technical side is correct)
> Of course it did. Because reviewing code thoroughly is harder than writing it.
If there's one thing that I learned from AI proponents is that they don't value correctness. They only want to write more code every day. Which actually baffles me, because for a given feature set, there should be a Definition of Done, and the only work left should be slight alterations for oversight and dependency updates.
Reviews take way more time than new features, and often utilize 3 subagents at a time - it's not uncommon to have reviews take 3 hours when the feature only took 15 minutes. The numbers here are just estimates, though - I don't keep track. "10x to 20x tokens on review" is probably underestimating review cost, if anything.
I don't review all code myself, but I do spend down-time reading code. When I find obviously bad code/patterns/whatever, I don't just fix it directly - I work to create automated tests (like static analysis, almost) or adjust or create prompts and tools for agents (either for review stage or initial implementation) to solve that class of issue, instead of just that instance of it.
I never review the first iteration. I review it after the agents have already poured a ton of time into it, if ever.
I do sometimes watch agents work, and redirect them if I see them doing something dumb. But, usually, I have 5+ agents running, not counting sub-agents, and I'm just messing with the apps myself to find the next feature to create or polish.
Whats your YOE, like when did you enter tech as a SWE?
This shouldn't be normalized for you yet unless you're at a faang pushing this at the edge and new to the field, cause this isn't what we used to do 2 years ago.
If you're happy with the ai slop $$$ job more power to you but that isn't the entire field and there used to be (and hopefully still are) good and fun engineering jobs.
Contrary to popular normie belief, no not everyone wants to work at the Metas and OpenAIs and for good reason.
edit: Guys a literal business owner writing code for his own business, christ, what a waste of my time. So instead of hiring actual engineers you try to make it sound like you're employed as a software engineer and your experience is remotely normal. You are the literal business owner not filling seats because you're using AI.
"I'm paid to just shut up and code, baby!"
Yeah, that isn't a real SWE job, bud, don't make comments like you're in the trenches.
YOE is ~30, from my first PHP app to present. I've spent somewhere between 5 and 80 hours a week coding for the past 30 years, mostly self-employed, writing tools and creating custom CNC machines/robots for my own business, but more recently doing same thing for a company as a full time employee.
I still get to do some coding, where there are safety-critical production systems, but the work is mostly tooling that gets us to that point or supports the business otherwise.
It's an awesome job. Couldn't be funner, pretty much, except on data collection days. I get high level tasks, or come up with my own, and find or build solutions - no more running a whole business, doing production, keeping books, shipping orders, doing customer support - I only do the stuff I like.
Why's that? Ruby on Rails is a fantastic framework. My point was that if somebody who has done the work before AI agents is now following the footsteps of not reading code, then why are we still telling people that it's still useful to read code?
I think you're paid to deliver. Lots of developers for decades have delivered crap that looks good on the surface and is otherwise unmaintainable. Now we're reaching the point where "everyone can code" and review queues are getting too long, with the result of many PRs being yoloed.
This of course varies by company but this is clearly where it's headed: bot pushes, bot reviews, you look at the PR title and click merge.
Personally I usually use Claude inside the Jetbrain's IDE terminal, even if I code by hand obviously less. I still like using the diff, navigation, quick access to any file path for my prompt etc but maybe that won't last.
(edit: although I currently use an old perpetual fallback license because I didn't like the last price increase especially as they slowly remove what I like in the UI)