Ask HN: How is AI-assisted coding going for you professionally?

I’d be more curious to hear about the processes people have put in place for AI code reviews

On the one hand, past some threshold of criticality/complexity, you can’t push AI unreviewed, on the other, you can’t relegate your senior best engineers to do nothing but review code

It doesn’t just not scale, it makes their lives miserable

So then, what’s the best approach?

I think over time that threshold I mentioned will get higher and higher, but at the moment the ratio of code that needs to be reviewed to reviewers is a little high

It is a very mixed bag. I have enjoyed using opus 4.5 and 4.6 to add functionality to existing medium complexity codebases. It’s great for green field scripts and small POCs. I absolutely cannot stand reviewing the mostly insane PRs that other people generate with it.

I'm repeating this 3rd time, but, a non-technical client of mine has whipped up an impressive SaaS prototype with tons of features. They still need help with the cleanup, it's all slop, but I was doing many small coding requests for that client. Those gigs will simply disappear.

I just got started using Claude very recently. I have not been in the loop how much better it got. Now it's obvious that no one will write code by hand. I genuinely fear for my ability to make a living as soon as 2 years from now, if not sooner. I figure the only way is to enter the red queen race and ship some good products. This is the positive I see. If I put 30h/week into something, I have productivity of 3 people. If it's a weekend project at 10h/week, I have now what used to be that full week of productivity. The economics of developing products solo have vastly changed for the better.

I work at a unicorn in EU. Claude Code has been rolled out to all of engineering with strict cost control policies, even with these in place we burn through tens of thousands of euro per months that I think could translate in 15/20 hires easily. Are we more productive than adding people to the headcount? That's a good question that I cannot answer.

Some senior people that were in the AI pilot, have been using this for a while, and are very into it claimed that it can open PRs autonomously with minimum input or supervision (with a ton of MD files and skills in repos with clear architecture standards). I couldn't replicate this yet.

I'm objectively happy to have access to this tool, it feels like a cheat code sometimes. I can research things in the codebase so fast, or update tests and glue code so quickly that my life is objectively better. If the change is small or a simple bugfix it can truly do it autonomously quicker than me. It does make me lazier though, sometimes it's just easier to fire up claude than to focus and do it by myself.

I'm careful to not overuse it mostly to not reach the montlhy cap, so that I can "keep it" if something urgent or complex comes my way. Also I still like to do things by hand just because I still want to learn and maintain my skills. I feel that I'm not learning anything by using claude, that's a real thing.

In the end I feel it's a powerful tool that is here to stay and I would be upset if I wouldn't have access to it anymore, it's very good. I recently subscribed to it and use it on my free time just because it's a very fun technology to play with. But it's a tool. I'm paid because I take responsability that my work will be delivered on time, working, tested, with code on par with the org quality standards. If I do it by hand or with claude is irrelevant. If i can do it faster it will likely mean I will receive more work to do. Somebody still has to operate Claude and it's not going to be non-technical people for sure.

I genuinely think that if anyone still believes today that this technology is only hype or a slop machine, they are in denial or haven't tried to use a recent frontier model with the correct setup (mostly giving the agent a way to autonomously validate it's changes).

Very much mixed. I've used Claude to generate small changes to an existing repo, asking it to create functions or react template in the style of the rest of the file its working in, and thats worked great. I still do a lot of the fine tuning there, but if the codebase isn't one I am overly familiar with this is a good way to ensure my work doesn't conflict with the core team's.

I have also done the agentic thing and built a full CLI tool via back-and-forth engagement with Claude and that worked great - I didn't write a single line of code. Because the CLI tool was calling an API, I could ask Claude to run the requests it was generating and adjust based on the result - errors, bad requests etc, and it would fairly rapidly fix and coalesce on a working solution.

After I was done though, I reckon that if instead of this I had just done the work myself I would have had a much smaller, more reliable project. Less error handling, no unit tests, no documentation sure, but it would have worked and worked better - I wouldn't need to iterate off the API responses because I would have started with a better contract-based approach. But all of that would have been hard, would have required more 'slow thinking'. So... I didn't really draw a clean conclusion from the effort.

Continuing to experiment, not giving up on anything yet.

I use Claude code for my research projects now, it’s incredible tbh. I’m not writing production code for millions of users I need to do data science stuff and write lots of code to do that and AI lets me focus on the parts of my research that I want to do and it makes me a lot more productive.

Things I’ve learned:

Claude Code is the best CLI tool by a mile.

Even at its best it’s wildly inconsistent from session to session. It does things differently every time. Sometimes I get impressed with how it works, then the next day, doing the exact same thing, and it flips out and goes nuts trying to do the same thing a totally different, unworkable way.

You can capture some of these issues in AGENTS.md files or the like, but there’s an endless future supply of them. And it’s even inconsistent about how it “remembers” things. Sometimes it puts in the project local config, sometimes in my personal overall memory files, sometimes instead of using its internal systems, it asks permission to search my home directory for its memory files.

The best way to use it is for throwaway scripts or examples of how to do something. Or new, small projects where you can get away with never reading the code. For anything larger or more important, its inconsistencies make it a net time loser, imo. Sure, let it write an annoying utility function for you, but don’t just let it loose on your code.

When you do use it for new projects, make it plan out its steps in advance. Provide it with a spec full of explicit usage examples of the functionality you want. It’s very literal, so expect it to overindex on your example cases and treat those as most important. Give it a list of specific libraries or tools you want it to use. Tell it to take your spec and plan out its steps in a separate file. Then tell it to implement those steps. That usually works to allow it to build something medium-complex in an hour or two.

When your context is filling up in a session in a particular project, tell it to review its CLAUDE.md file and make sure it matches the current state of the project. This will help the next session start smoothly.

One of the saddest things I’ve found is when a whole team of colleagues gets obsessed with making Claude figure something out. Once it’s in a bad loop, you need to start over, the context is probably poisoned.

Great! I ask it questions and still type every line of code by hand. LLM's are just a tool and nothing more to me.

For those of you for who it is working: show your code, please.

More work, shorter deadlines, smaller headcount, higher expectations in terms of adaptability/transferability of people between projects (who needs knowledge transfer, ask the AI!).

But in the end, the thing that pisses me off was a manager who used it to write tickets. If the product owner doesn't give a shit about the product enough to think and write about what they want, you'll never be successful as a developer.

Otherwise it's pretty cool stuff.

I use Cursor and have been pretty happy with the Plan -> Revise -> Build -> Correct flow. I don't write everything with it, but the planning step does help me clarify my thoughts at times.

One of the things that has helped the most is all the documentation I wrote inside the repository before I started using AI. It was intended for consumption by other engineers, but I think Cursor has consumed it more than any human. I've even managed to make improvements not by having AI update it, but asking AI "What unanswered questions do you have based on reading the documentation?" It has helped me fill in gaps and add clarity.

Another thing I've gotten a ton of value with is having it author diagrams. I've had it create diagrams with both the mermaid syntax and AWSDAC (Diagram-as-Code). I've always found crafting diagrams a painstaking process. I have it make a first pass by analyzing my code + configuration, then make corrections and adjustments by explaining the changes I want.

In my own PRs, I have been in the habit of posting my Cursor Plan document and Transcript so that others can learn from it. I've also encouraged other team members to do the same.

I feel bad for any teams that are being mandated to use a certain amount of AI. It seems to me that the only way to make it work is by having teams experiment with it and figure out how to best use it given their product and the team's capacity. AI is like a pair of Wile-E-Coyote rocket skates. It'll get you somewhere fast, but unless you've cleared the road of debris and pointed in exactly the right direction, you're going to careen off a cliff or into a wall.

I work in the research space so it's mostly prototype code. I have unlimited access to codex 5.x-xhigh. I rarely directly alter the code codex generates at this point. My productivity has significantly increased.

It is great to solve "puzzle" problems and remove road blocks. In the past, whenever I got stuck, I often got frustrated and gave up. In so many cases AI hints to the corret solution and helps me continue. It's like a knowledgeable colleague that you can ask for help when you get stuck.

Another thing is auditing and code polishing. I asked Claude to polish a working, but still rough browser pluging, consisting of two simple Javascript files. It took ten iterations and a full day of highly intensive work to get the quality I wanted. I would say the result is good, but I could not do this process vey often without going insane. And I do not want to do this with a more complex project, yet.

So, yes, I am using it. For me it's a tool, knowledge resource, puzzle solver, code reviewer and source for inspiration. It's not a robot to write my code.

And never trust it blindly!

AI has helped me break through procrastination by taking care of tedious tasks that beforehand had a low ROI (boilerplate, CI/CD configs, test coverage, shell scripting/automation).

- create unit tests and benchmark tests that required lots of boiler plate , fixtures

- add CI / CD to a few projects that I didn't have motivation to

- freshen up old projects to modern standards (testing, CI / CD, update deps, migrations/deprecations)

- add monitoring / alerting to 2 projects that I had been neglecting. One was a custom DNS config uptime monitor.

- automated backup tools along with scripts for verifying recovery procedure.

- moderate migrations for deprecated APIs and refactors within cli and REST API services

- auditing GCP project resources for billing and security breaches

- frontend, backend and offline tiers for cloud storage management app

I wrote a blog post over the New Year's of my experience at a company where AI coding was widely used and developer skill wasn't particularly high.

https://burakku.com/blog/tired-of-ai-coders/

I think the addendum to that is that I've since left.

Love it. I can create closer to the speed of decision making.

AI has definitely shifted my work in a positive way, but I am still playing the same game.

I run a small lab that does large data analytics and web products for a couple large clients. I have 5 developers who I manage directly, I write a lot of code myself and I interact directly with my clients. I have been a web developer for long enough to have written code in coldfusion, php, asp, asp.net, rails, node and javascript through microsoft frontpage exports, to jquery,to backbone, angular and react and in a lot of different frameworks. I feel this breadth of watching the internet develop in stages has given me a decent if imperfect understanding of many of the tradeoffs that can be made in developing for the web.

My work lately is on an analytics / cms / data management / gis platform that is used by a couple of our clients and we've been developing for a couple of years before any ai was used on it all. Its a react front end built on react-router-7 that can be SPA or SSR and a node api server.

I had tried AI coding a couple times over the past few years both for small toy projects and on my work and it felt to me less productive than writing code by hand until this January when I tried Claude Code with Opus 4.5. Since then I have written very few features by hand although I am often actively writing parts of them, or debugging by hand.

I am maybe in a slightly unique place in that part of my job is coming up with tasks for other developers and making sure their code integrates back, I've been doing this for 10 years plus, and personally my sucess rate with getting someone to write a new feature that will get use is maybe a bit over 50%, that is maybe generous? Figuring out what to do next in a project that will create value for users is the hard part of my job whether I am delegating to developers or to an AI and that hasn't changed.

That being said I can move through things significantly faster and more consistently using AI, and get them out to clients for testing to see if they are going to work. Its also been great for tasks which I know my developers will groan if I assign to them. In the last couple months I've been able to

- create a new version of our server that is free from years of cruft of the monorepo api we use across all our projects. - implement sqlite compatablity for the server (in addition to original postgres support) - Implement local first sync from scratch for the project - Test out a large number of optimization strategies, not all of which worked out but which would have taken me so much longer and been so much more onerous the cost benefit ratio of engaging them would have been not worth it - Tons of small features I would have assigned to someone else but are now less effort to just have the AI implement.

  I think the biggest plus though is the amount of documentation that has accrued in our repo since using starting to use these tools. I find AI is pretty great at summarizing different sections of the code and with a little bit of conversation I can get it more or less exactly how I want it. This has been hugely useful to me on a number of occasions and something I would have always liked to have been doing but on a small team that is always under pressure to create results for our clients its something that didn't cross the immediate threshold of the cost benefit ratio. 

I have encouraged my team to use these tools but I am not forcing it down anyone's throat, although its interesting to give people tasks that I am confident I could finish much quicker and much more to my personal taste than assigning it. The reactions from my team are pretty mixed, one of the strongest contributors doesn't find a lot of gains from it. One has found similar productivity gains to myself, others are very against it and hate it.

I think one of the things it will change for me is, I can no longer just create the stories for everyone, learning how to choose on what to work on is going to be the most important skill in my opinion so over the next couple months I am going to be shifting so everyone on my team has direct client interactions and I am going to try to shift away from writing stories to having meetings where I help them decide on their own what to work on. Still part of the reason that I can afford to do this is because I can now get as much or more work done than I was able to with my whole team at this time last year.

That's a big difference in one way, and I am optimistic that the platform I am working on will be a lot better and able to compete with large legacy platforms that it wouldn't have been able to compete with in the past, but still it just tightens the loop of trying new things and getting feedback and the hardest part of the business is still communication with clients and building relationships that create value.

I've been using opencode and oh-my-opencode with Claude's models (via github Copilot). The last two or three months feel like they have been the most productive of my 28-year career. It's very good indeed with Rails code, I suspect it has something to do with the intentional expressiveness of Ruby plus perhaps some above-average content that it would be trained on for this language and framework. Or maybe that's just my bias.

It takes a bit of hand holding and multiple loops to get things right sometimes, but even with that, it's pretty damn good. I don't usually walk away from it, I actively monitor what it's doing, peek in on the sub-agents, and interject when it goes down a wrong path or writes messy code. But more often than not, it goes like this:

  - Point at a GH issue or briefly describe the task
  - Either ask it to come up with a plan, or just go straight to implementation
  - When done, run *multiple* code review loops with several dedicated code review agents - one for idiomatic Rails code, one for maintainabilty, one for security, and others as needed

I've been using this approach on a side project, and even though it's only nights an weekends, it's probably the most robust, well-tested and polished solo project I've ever built. All those little nice-to-have and good-to-great things that normally fall by the wayside if you only have nights and weekends - all included now.

And the funny thing is - I feel coding with AI like this gets me in the zone more than hand-coding. I suspect it's the absence of all those pesky rabbit holes that tend to be thrown up by any non-trivial code base and tool chain which can easily distract us from thinking about the problem domain and instead solving problems of our tools. Claude deals with all that almost as a side effect. So while it does its thing, I read through it's self-talk while thinking along about the task at hand, intervening if I disagree, but I stay at the higher level of abstraction, more or less. Only when the task is basically done do I dive a level deeper into code organisation, maintainability, security, edge cases, etc. etc.

Needless to say that very good test coverage is essential to this approach.

Now, I'm very ambiguous about the AI bubble, I believe very firmly that it is one, but for coding specifically, it's a paradigm shift, and I hope it's here to stay.

It solves no actual problem I have. Yet introduces many new ones. Its a trap. So I don't use it and have a strong policy against using it or allowing others to use it on things I work on. BATNA is key.

I'm not explicitly authorised to speak about this stuff by my employer but I think it's valuable to share some observations that go beyond "It's good for me" so here's a relatively unfiltered take of what I've seen so far.

Internally, we have a closed beta for what is basically a hosted Claude Code harness. It's ideal for scheduled jobs or async jobs that benefit from large amounts of context.

At a glance, it seems similar to Uber's Minion concept, although we weren't aware of that until recently. I think a lot of people have converged on the same thing.

Having scheduled roundups of things (what did I post in Slack? what did I PR in Github etc) is a nice quality of life improvement. I also have some daily tasks like "Find a subtle cloud spend that would otherwise go unnoticed", "Investigate an unresolved hotfix from one repo and provide the backstory" and "Find a CI pipeline that has been failing 10 times in a row and suggest a fix"

I work in the platform space so your mileage may vary of course. More interesting to me are the second order effects beyond my own experience:

- Hints of engineering-adjacent roles (ie; technical support) who are now empowered to try and generate large PRs implementing unscoped/ill-defined new internal services because they don't have any background to know is "good" or "bad". These sorts of types have always existed as you get people on the edge of technical-adjacent roles who aspire to become fully fledged developers without an internal support mechanism but now the barrier is a little lower.

- PR review fatigue: As a Platform Engineer, I already get tagged on acres of PRs but the velocity of PRs has increased so my inbox is still flooded with merged PRs, not that it was ever a good signal anyway.

- First hints of technical folk who progressed off the tools who might now be encouraged to fix those long standing issues that are simple in their mind but reality has shifted around a lot since. Generally LLMs are pretty good at surfacing this once they check how things are in reality but LLMs don't "know" what your mental model is when you frame a question

- Coworkers defaulting to asking LLMs about niche queries instead of asking others. There are a few queries I've seen where the answer from an LLM is fine but it lacks the historical part that makes many things make sense. As an example off the top of my head, websites often have subdomains not for any good present reason but just because back in the day, you could only have like 6 XHR connections to a domain or whatever it was. LLMs probably aren't going to surface that sort of context which takes a topic from "Was this person just a complexity lover" to "Ah, they were working around the constraints at the time".

- Obviously security is a forever battle. I think we're more security minded than most but the reality is that I don't think any of this can be 100% secure as long as it has internet access in any form, even "read only".

- A temptation to churn out side quests. When I first got started, I would tend to do work after hours but I've definitely trailed off and am back to normal now. Personally I like shipping stuff compared to programming for the sake of it but even then, I think eventually you just normalise and the new "speed" starts to feel slow again

- Privileged users generating and self-merging PRs. We have one project where most everyone has force merge and because it's internal only, we've been doing that paired with automated PR reviews. It works fairly well because we discuss most changes in person before actioning them but there are now a couple historical users who have that same permission contributing from other timezones. Waking up to a changed mental model that hasn't been discussed definitely won't scale and we're going to need to lock this down.

- Signal degradation for PRs: We have a few PRs I've seen where they provide this whole post-hoc rationalisation of what the PR does and what the problem is. You go to the source input and it's someone writing something like "X isn't working? Can you fix it?". It's really hard to infer intent and capability from PR as a result. Often the changes are even quite good but that's not a reflection of the author. To be fair, the alternative might have been that internal user just giving up and never communicating that there was an issue so I can't say this is strictly a negative.

All of the above are all things that are actively discussed internally, even if they're not immediately obvious so I think we're quite healthy in that sense. This stuff is bound to happen regardless, I'm sure most orgs will probably just paper over it or simply have no mechanism to identify it. I can only imagine what fresh hells exist in Silicon Valley where I don't think most people are equipped to be good stewarts or even consider basic ethics.

Overall, I'm not really negative or positive. There is definitely value to be found but I think there will probably be a reckoning where LLMs have temporarily given a hall pass to go faster than the support structures can keep up with. That probably looks like going from starting with a prompt for some work to moving tasks back into ticket trackers, doing pre-work to figure out the scope of the problem etc. Again, entirely different constraints and concerns with Platform BAU than product work.

Actually, I should probably rephase that a little: I'm mostly positive on pure inference while mostly negative on training costs and other societal impacts. I don't believe we'll get to everyone running Gas Town/The Wasteland nor do I think we should aspire to. I like iterating with an agent back and forth locally and I think just heavily automating stuff with no oversight is bound to fail, in the same way that large corporations get bloated and collapse under their own weight.

Replying before reading anyone else's responses because I want to provide an honest response. I absolutely love it. I've spent my career as a generalist focusing on architecture and plumbing problems, mostly on Linux and embedded. Coding was something I did to get things done, now I can get things done in new languages incredibly fast, debug annoying problems rapidly, and work on new architectures very rapidly. It does a lot of the annoying research work: interpreting novel build chain failures, tracking down version-related API changes, gathering evidence of popular reports on the large plurality of Apple kernel lockdown changes that perenially break embedded work, etc. I'm working in hardware. Electronics. Physics. Mechanical. Supply chain. Software. EVERYTHING. It's a goddamn superpower. I can't get enough of it. It's like every teacher you ever wanted always available with infinite patience. I've stopped typing a lot of prompts now and started using local voice transcription. It's fantastic.

Honestly, the question may have been a bit more on the programming (generating lines) side, but I've always described programming as a lot like cleaning. You enter the room, figure out the nature of the mess (the interesting part) and come up with your strategy for solving it, then spend ages cleaning, sweeping or mopping up which is largely boring. Now you don't have to bother. Thanks, LLMs.

>"How is AI-assisted coding going for you professionally?"

For me personally - beautifully. Saves me a ton of time. Keep in mind however that I am an old fart who was originally scientist in physics, started programming with entering machine codes and designed electronics to facilitate research and after moving to Canada switching to programming completely. So I understand how everything works starting from the very bottom and am able to see good stuff from the bullshit in what I get from AI.

I however have no idea how would youngsters train their brains when they would not have any solid foundations. I think there is a danger of collapse with people having answers to all the questions but with zero ability to validate those and the AI itself degenerating into noise as a result of more and more being able to train off it's own results.

Or the AI will eventually have intelligence, motivation and agency.

Either way we are fucked.

For me the AI is just okay. Invaluable for personal projects but a little bit take or leave at work. It just makes too many little mistakes, i still have to babysit it, it's too much effort.

Sadly though my manager uses Claude for EVERYTHING and is completely careless with it. Hallucinations in performance reviews, hallucinations in documentation, trash tier PRs. He's so gung-ho that some of my peers are now also submitting Claude written PRs that they haven't even bothered to check whether they build correctly.

So the social aspect is very bad. I'm stuck correcting other people's slop and reading nonsense PRs a few times a week.

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[flagged]