The role of developer skills in agentic coding

3/26/2025 at 3:53:05 PM

I use Cursor for most of my development these days. This article aligns pretty closely with my experiences. A few additional observations:

1. Anecdotally, AI agents feel stuck somewhere circa ~2021. If I install newer packages, Claude will revert to outdated packages/implementations that were popular four years ago. This is incredibly frustrating to watch and correct for. Providing explicit instructions for which packages to use can mitigate the problem, but it doesn't solve it.

2. The unpredictability of these missteps makes them particularly challenging. A few months ago, I used Claude to "one-shot" a genuinely useful web app. It was fully featured and surprisingly polished. Alone, I think it would've taken a couple weeks or weekends to build. But, when I asked it to update the favicon using a provided file, it spun uselessly for an hour (I eventually did it myself in a couple minutes). A couple days ago, I tried to spin up another similarly scoped web app. After ~4 hours of agent wrangling I'm ready to ditch the code entirely.

3. This approach gives me the brazenness to pursue projects that I wouldn't have the time, expertise, or motivation to attempt otherwise. Lower friction is exciting, but building something meaningful is still hard. Producing a polished MVP still demands significant effort.

4. I keep thinking about The Tortoise and The Hare. Trusting the AI agent is tempting because progress initially feels so much faster. At the end of the day, though, I'm usually left with the feeling I'd have made more solid progress with slower, closer attention. When building by hand, I rarely find myself backtracking or scrapping entire approaches. With an AI-driven approach, I might move 10x faster but throw away ~70% of the work along the way.

> These experiences mean that by no stretch of my personal imagination will we have AI that writes 90% of our code autonomously in a year. Will it assist in writing 90% of the code? Maybe.

Spot on. Current environment feels like the self-driving car hype cycle. There have been a lot of bold promises (and genuine advances), but I don't see a world in the next 5 years where AI writes useful software by itself.

by ikerino

3/27/2025 at 5:22:04 AM

#1 has an easy fix.

Clone the dependency you want to use in the directory of your code.

Instruct it to go into the directory and look at that code in order to complete task X: "I've got a new directory xyz, in it contains a library to do feature abc. I'll need to include it here to do A to function B and so on"

The weird version mixing bug will disappear. If it's closed source, then just do the documentation.

You need to line up the breadcrumbs right.

#2 is "create a patch file that does X. Do not apply it". Followed by "apply the previous patch file". Manually splitting the task fixes the attention.

Another method is to modify the code. Don't use "to-do" it will get confused. Instead use something meaningless like 1gwvDn, then at the appropriate place

[1gwvDn: insert blah here]

Then go to the agent and say

"I've changed the file and given you instructions in the form [1gwvDn:<instructions>]. Go through the code and do each individually.

Then the breadcrumbs are right and it doesn't start deleting giant blocks of code and breaking things

#3 You will never start anything unless you convince yourself it's going to be easy. I know some people will disagree with this. They're wrong. You need to tell yourself it's doable before you attempt it.

#4 is because we lose ownership of the code and end up playing manager. So we do the human thing of asking the computer to do increasingly trivial things because it's "the computer's" code. Realize you're doing that and don't be dumb about it.

by kristopolous

3/27/2025 at 8:55:29 AM

This is a very typical reply when we see someone pointing out the flaws of AI coding tools. "You are using it wrong, AI can do everything if you properly prompt it"

Yes, it can write everything if I provide enough context, but it ain't 'Intelligence' if context ~= output.

The point here is providing enough context itself is challenging and requires expertise, this makes AI ides unusable for many scenarios.

by moqizhengz

3/27/2025 at 5:37:47 PM

We already have a term for prompting a computer in a way that causes it to predictably output useful software; we called that programming, and people on this website used to think that knowing how to do that was a worthwhile field of study.

by amputect

3/28/2025 at 9:06:56 AM

The obligatory CommitStrip: https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...

by BerislavLopac

3/27/2025 at 3:06:37 PM

It's a piece of software, not a magical wand

by kristopolous

3/27/2025 at 3:29:17 PM

In terms of use it's closer to a magic wand than traditional software.

by rafaelmn

3/28/2025 at 10:03:17 AM

It's more like a genie, you tell it your wish and hope it doesn't get it all twisted.

by dandellion

3/27/2025 at 12:16:24 PM

This is a very typical reply when we see someone excited about AI and then a luddite needs to come along and tell them why they should not be so excited and helpful.

I mostly jest but your comment comes off quite unhelpful and negative. The person you replied to wasn’t blaming the parent comment, just offering helpful tips. I agree that today’s AI tools aren’t perfect, but I also think it’s important for developers to invest time refining their toolset. It’s no different from customizing IDE shortcuts. These tools will improve, but if devs aren’t willing to tinker with what they use, what’s the point?

by infecto

3/27/2025 at 1:57:37 PM

I think your reply is a bit unfair. The first problem of the AI using outdated libraries sure it can be fixed if you are a competent developer who keeps up with industry standards. But if you need someone like that to guide an AI, then "agentic" coding loses a lot of its "agentic" ability which is what the article is talking about. If you need enthusiasts and experts to steer the AIs, they are a bit like "full self driving" where you are still asked to touch the steering wheel if it thinks you're not paying attention to the road.

by aprilthird2021

3/27/2025 at 4:53:47 PM

I don't see how it's unfair at all. This is novel technology with rough edges. Sharing novel techniques for working around those rough edges is normal. Eventually we can expect them to be built-in to the tools themselves (see MCP for how you might inject this kind of information automatically.) A lot of development is iterative and LLMs are no exception.

by johnmaguire

3/27/2025 at 6:17:51 PM

Sure it is normal, but the reply was also a normal reply because, as you said it's a product with rough edges advertised as if it's completely functional. And the comment I replied to, criticizing the other reply, was not fair because he's only giving a normal reply, imo

by aprilthird2021

3/27/2025 at 7:52:22 PM

I don't believe it is a normal reply on HN, or at least it shouldn't be.

We all know that this technology isn't magic. In tech spaces there are more people telling you it isn't magic than it is. The reminder does nothing. The contextual advice on how to tackle those issues does. Why even bother with that conversation, you can just take the advice or ignore it until the technology improves since you've already made up your mind about the limit you or others should be willing to go.

If it doesn't meet the standard of what you believe is advertised than say that. Not, "workarounds" are problematic because they obfuscate how someone should feel about how the product is advertised. Maybe you are an advertising purist and it bothers you, but why invalidate the person providing the context into how to utilize those tools in their current state better?

by yamazakiwi

3/27/2025 at 11:57:45 PM

> We all know that this technology isn't magic.

I didn't say it's magic. I said what it is advertised as.

> The reminder does nothing. The contextual advice on how to tackle those issues does.

No, the contextual advice doesn't help because it doesn't tackle the issue because the issue is "It doesn't work as advertised". We are in a thread of an article whose main thesis is "We’re still far away from AI writing code autonomously for non-trivial tasks." Giving advice that doesn't achieve autonomous writing code for non-trivial tasks doesn't help achieve that goal.

And if you want to talk about replies that do nothing. Calling the guy a Luddite for saying that the tip doesn't help him use the agent as an autonomous coder, is a huge nothing.

> since you've already made up your mind about the limit you or others should be willing to go.

Please read the article and understand what the conversation is about. We are talking about the limits that the article outlined, and the poster is saying how he also hit those limits.

> If it doesn't meet the standard of what you believe is advertised than say that.

The article says this. The commenter must have assumed people here read the articles.

> why invalidate the person providing the context into how to utilize those tools in their current state better?

Because that context is a deflection from the main point of the comment and conversation. It's like in a thread of mechanics talking about how an automatic tire balancer doesn't work well, and someone comes in saying "Well you could balance the tires manually!" How helpful is that?

by aprilthird2021

3/28/2025 at 10:30:06 AM

I disagree. It’s unfair to put words in other people’s mouth which is who I was replying to.

by infecto

3/27/2025 at 2:12:27 PM

It is definitely not unfair. #2 is a great strategy, I'm gonna try in my agentic tool. We obviously need experts to steer the AIs in this current phase, who said we don't?

by owebmaster

3/27/2025 at 2:29:18 PM

> We obviously need experts to steer the AIs in this current phase, who said we don't?

I don't know if it's explicitely said but if you call it agentic, it sounds like it can do stuff independently (like an agent). If I still need to hand feed it everything, I wouldn't really call it agentic.

by echoangle

3/27/2025 at 3:34:10 PM

There are two different roles here, the dev that creates the agent and the user that uses the agent. The user should not need to adapt/edit prompts but the dev definitely should for it to evolve. Agents aren't AGI, after all.

by owebmaster

3/27/2025 at 6:19:56 PM

> We obviously need experts to steer the AIs in this current phase, who said we don't?

Much of the marketing around agents is about not needing them. Zuck said Meta's internal agent can produce the code of an average junior engineer in the company. An average junior engineer doesn't need this level of steering to know to not include a 4 year old outdated library in a web project.

by aprilthird2021

3/27/2025 at 3:43:12 PM

Where are the goalposts then? If the answer is always "you are prompting it wrong" then there are no goalposts for agentic development.

Where is the consensus position that is demonstrably more effective than traditional development?

My observation is that it's somewhere close to "start this project and set an overall structure", after that nobody seems to agree.

by beardedwizard

3/27/2025 at 5:55:40 PM

> You need to line up the breadcrumbs right.

And in the time I line up the breadcrumbs to help this thing to emulate an actual thought process, I would probably alrady have finshed doing it myself, especially since I speed up the typing-it-all-out part using a much less "clever" and "agentic" AI system.

by usrbinbash

3/27/2025 at 9:01:52 AM

We do this not because it is easy, but because we thought it would be easy.

by andai

3/27/2025 at 2:59:50 PM

I need that on a shirt

by airstrike

3/27/2025 at 5:04:31 PM

Finding a way to convince yourself something is easy is the best trick to unblocking yourself and stopping distractions. This is the closest thing I know to the "1 simple trick" thing.

by kristopolous

3/28/2025 at 12:51:47 AM

Just so you know, none of what you said sounds easy and I'm a fairly technical person that uses Cursor and other AI tools all day.

by dimitri-vs

3/27/2025 at 1:38:44 PM

This feels like when I explain to a layperson cool dev tool like GIT.

They just roll eyes and continue to do copies of the files they work on.

I just roll eyes on that explanation because it exactly feels like additional work I don’t want to do. Doing my stuff the old way works right away without having to do some explanation tricks and setting up context for the tool I expect to do correct thing on the first go.

by ozim

3/27/2025 at 3:53:40 PM

it's clearly a preference I feel strongly about. I've been programming for over 30 years btw - I can manually do this. It's a new tool I'm trying to learn.

I was personally clocking in about 1% of the openrouter token count last year every day. openrouter has grown quite a bit, but I realize I'm certainly in the minority/on the edge here.

by kristopolous

3/27/2025 at 4:46:04 AM

It's all true but I'm surprised it took so long to realize this. As someone who is not an early adopter, I decided to give AI a shot in helping with an existing project a few days ago. I immediately realized almost everything mentioned here. However, the sentiment of everything i've read before was that AI can already replace me. In reality I enjoy steering it to reach a solution.

by hnlurker22

3/27/2025 at 2:38:14 PM

> In reality I enjoy steering it to reach a solution.

That resonates with me. It actually brings back some nostalgic memories about setting up and constantly tweaking bots in World of Warcraft (sorry, I was young).

There's something incredibly engaging and satisfying about configuring them just right and then sitting back, watching your minions run around and do your bidding.

I get a similar vibe when I'm working with AI coding assistants. It's less about the (currently unrealistic) hype of full replacement and more about trying to guide these powerful, and often erratic, tools to do what they're supposed to.

For me, it taps into that same core enjoyment of automating and observing a process unfold that I got with those WoW bots. Perhaps unsurprisingly, automation is now a fairly big part of my job.

by sReinwald

3/27/2025 at 2:00:01 PM

I don’t do much development anymore, but this is always how I felt when ORM’s like Hibernate came out. At first they were amazing and were used for everything. Eventually it became obvious that as the complexity of the code went up linearly, the difficulty of troubleshooting and optimizing the code went up exponentially.

I learned to only used ORM’s for basic stuff, which they are very much useful, but when things got a little bit complicated to drop back to hand coding SQL.

by Nemi

3/29/2025 at 8:55:51 AM

One of the things I love most about AI coding tools is how they make it easier than ever to move away from complex, fragile abstractions like ORMs. The main reason we’ve often avoided writing raw SQL repositories by hand is that it’s tedious, but now, much of that boilerplate can be generated by AI.

More broadly, wherever you might have relied on a heavyweight dependency, you can often replace it with AI-generated code tailored to the task at hand. You might think this would increase the maintenance burden, but au contraire: reviewing and taking ownership of AI-generated code is often simpler and more sustainable in the long term than dealing with complex libraries you don’t fully control.

by jdkoeck

3/26/2025 at 4:45:43 PM

> It feels like my AI agents are stuck somewhere circa ~2021. If I install newer packages or more recent versions, Claude will often revert to outdated packages/implementations that were popular four years ago.

My experience is the same, though the exact dates differ.

I assume LLMs gravitate toward solutions that are most represented in their training material. It's hard to keep them pulled toward newer versions without explicitly mentioning it all the time.

by Aurornis

3/26/2025 at 9:48:23 PM

But they can't really be low-latency if they have to search for new versions ... and that makes such a big difference in how usable they are.

by spwa4

3/27/2025 at 6:16:51 AM

While you give your process feedback, here is my emotions related one. When I dev with LLM, I don't face my own limits in term of reasoning and architecturing, but I face the limit of the model to interpret prompts. Instead of trying to be a better engineer, I'm frustratingly prompting an unintelligent human-like interface.

I'm not fuding LLM, I use it everyday, all the time. But it won't make me a better engineer. And I deeply believe that becoming a good engineer helped me becoming a better human, because how the job make you face your own limits, train you to be humble and constantly learning.

Vibe coding won't lead to that same and sane mindset.

by jb_briant

3/27/2025 at 6:59:47 AM

I feel like this is the big question now. How to find the correct balance that lets you preserve and improve your skills. I haven’t yet found the answer, but I feel like it should be in being very deliberate about what you let the agent do, and what kind of work you do in the “artisanal” way, so not even AI-enabled auto-complete.

But in order to be able to find the right balance, one does need to learn fully what the agent can do, and have a lot of experience with that way of coding. Otherwise the mental model is wrong.

by jgilias

3/27/2025 at 8:04:49 AM

Agreed. Auto-complete on steroid isn't what I call using LLM for coding. It's just a convenience.

What I do is to write pure functions with LLM. Once I designed the software and I have the API, I can tell the model to write a function which does a specific job where I know the inputs and outputs but I'm lazy to write the code itself.

by jb_briant

3/27/2025 at 1:41:37 PM

it will make you a worse thinker

by liveoneggs

3/27/2025 at 10:43:24 AM

> Spot on. Current environment feels like the self-driving car hype cycle. There have been a lot of bold promises (and genuine advances), but I don't see a world in the next 5 years where AI writes useful software by itself.

My worry is that we get an overnight sea-change like 4o image generation. The current tools aren't good enough for anything other than one-shotting, and then suddenly overnight, they're good enough to put a lot of people out of work.

by petesergeant

3/27/2025 at 12:43:10 PM

Hm. The 'prompt obedience' was definitely a huge step up, but there's a huge number of acceptable results to an image generation prompt, while for coding usually there a handful, many times just one right solution. So I don't think this parallel here is telling

by impjohn

3/27/2025 at 5:38:35 AM

#1 is going to be an issue until we have another breakthrough or genuinely innovative approach.

We all know that 2 years is a lifetime in tech (for better or for worse), and we've all trained ourselves to keep up with a rapidly changing industry in a way that's more efficient than fully retraining a model with considerably more novel data.

For instance, enough people have started to move away from React for more innovative or standards-based approaches. HTML and CSS alone have come a long way since 2013 when React was a huge leap forward. But while those of us doing the development might have that realization, the training data won't reflect that for a good amount of time. So until then, trying to build a non-React approach will involve wrestling with the LLM until the point when the model has caught up.

At which point, we will likely still be ahead of the curve in terms of the solutions it provides.

by prisenco

3/27/2025 at 1:26:22 PM

But doesnt this just ultimately "solve" itself? If everybody is just going to use LLMs like this, they will keep using React longer, and 2 years is not going to feel like that much of a lifetime anymore. How would, even, a developer inside their AI ecosystem like this even know or care about new frameworks or new ways to do things?

by beepbooptheory

3/27/2025 at 2:03:26 PM

No because big companies see far more value from actually innovating and producing better technology (see Bytedance with their new cross-platform mobile framework Lynx) that speeds up things and provides better User Experience at their scale than they save in developer salaries by just using what an AI is most familiar with

by aprilthird2021

3/27/2025 at 2:00:04 PM

> A few months ago, I used Claude to "one-shot" a genuinely useful web app. It was fully featured and surprisingly polished. Alone, I think it would've taken a couple weeks or weekends to build. But, when I asked it to update the favicon using a provided file, it spun uselessly for an hour (I eventually did it myself in a couple minutes).

This reminds me of when cross-platform was becoming big for mobile apps and all of us new app developers would put up templates on GitHub which gave a great base to start on, but you really quickly realized you'd have to change a lot of it for your use case anyways.

by aprilthird2021

3/26/2025 at 4:49:34 PM

> At the end of the day, though, I'm usually left with the feeling I'd have made more solid progress with slower, closer attention

Does you think this feeling reflects the usual underestimation we're all guilty of, or do you think it's accurate?

by dkarl

3/26/2025 at 5:05:46 PM

In terms of absolute progress (e.g. towards finishing a feature or MVP) I think it it could have to do with a usual underestimation (optimism) for timelines.

I'm using Cursor mostly for exploratory/weekend projects. I usually opt for stacks/libraries I'm less familiar with, so I think there's some optimism/uncertainty to account for there.

I think there's another aspect to progress involving learning/becoming fluent in a codebase. When I build something from scratch, I become the expert, so familiar that later features become very easy/obvious to implement.

I haven't had this experience when I take a heavily agent-driven approach. I'm steering, but I'm not learning much. The more I progress, the harder new features feel to implement.

I don't think this is unique to working with AI. I guess the takeaway is that attention and familiarity matter.

by ikerino

3/27/2025 at 9:47:11 AM

I agree with all of this. I want to offer a tiny bit more hope, though:

> There have been a lot of bold promises (and genuine advances), but I don't see a world in the next 5 years where AI writes useful software by itself.

I actually think the opposite: that within five years, we will be seeing AI one-shot software, not because LLMs will experience some kind of revolution in auditing output, but because we will move the goalposts to ensure the rough spots of AI are massaged out. Is this cheating? Kind of, but any effort to do this will also ease humans accomplishing the same thing.

It's entirely possible, in other words, that LLMs will force engineers to be honest about the ease of tasks they ask developers to tackle, resulting in more easily composable software stacks.

I also believe that use of LLMs will force better naming of things. Much of the difficulty of complex projects comes from simply tracking the existence and status of all the moving parts and the wires that connect them. It wouldn't surprise me at all if LLMs struggle to manage without a clear shared ontology (that we naturally create and internalize ourselves).

by nukem222

3/27/2025 at 4:11:13 PM

It’s fascinating how the debate is going exactly as the car debate went. People were arguing for a whole spectrum of environment modifications for self driving cars.

I’ll take the other side of that bet. The software industry won’t make things easier for LLMs. A few will try, but will get burned by the tech changing too fast to target. Seeing this, people will by and large stay focused on designing their ecosystems for humans.

by tippytippytango

3/27/2025 at 12:58:34 PM

> we will move the goalposts to ensure the rough spots of AI are massaged out

Totally agree with this point. Software engineering will adapt to work better with LLMs. It will influence how we think about programming language design, as an interface to human readers/writers as well as for machines to "understand", generate, and refine.

There was a recent article about how LLMs will stifle innovation due to its cutoff point, where it's more productive using older or more mature frameworks and libraries whose documentation is part of the training data. I'm already seeing how this is affecting technical decisions at companies. But then again, it's similar to how such decisions are often made to maximize the labor pool, for example, choosing a more popular language due to availability of experts.

One thing I hope for is that we'll see more emphasis on thorough and precisely worded documentation. Similarly with API design and user interfaces in general, possibly leading to improvements in accessibility also.

Another aspect I think about is the recursive cycle of LLM-generated code and documentation being consumed by future LLMs, influencing what kinds of new frameworks and libraries may emerge that are particularly suited for this new kind of programming, purely AI or human/AI symbiosis.

by lioeters

3/27/2025 at 2:05:32 PM

> One thing I hope for is that we'll see more emphasis on thorough and precisely worded documentation.

Being on this planet long enough, I've learned this won't happen and in fact the quality of such will degrade making the AI using them degrade and we'll all have to just accept these flaws and work around them like so many myriad technical flaws in our current systems today

by aprilthird2021

3/27/2025 at 2:21:12 PM

True, that's a probable and very real risk that this recursive cycle of LLMs consuming LLM-produced content will degrade the overall quality of its "intelligence" and "creativity", maybe even the quality of literature, language, and human thought itself. By the time we collectively realize the mistake, it will be too late. Like microplastics, it will be everywhere and inside everything, and we'll just have to learn to live with it for better or worse.

by lioeters

3/27/2025 at 9:36:53 AM

I don't see the 2021 problem as much with Grok, but it is wired up to X for realtime learning, it can also fetch and crawl pages. Occasionally I'll use dev branch of some codebase, like Zig, and I just have to let it know the version I'm on and remind it to use the dev version. Occasionally I'll have to paste in the new API and then it works out what the answer should be.

A lot of the other problems mentioned still hold though.

by chrisco255

3/27/2025 at 10:44:14 AM

> Current environment feels like the self-driving car hype cycle.

Is that really hype? I mean there companies or person(s) hyping it up, but there is also Waymo and Pingshan (Baidu) for example actually rolling it out. It's a lot less hype than AI coding.

> Anecdotally, AI agents feel stuck somewhere circa ~2021.

That's only part of the problem. It's also stuck or dead set on certain frameworks / libraries where it has training data.

> I keep thinking about The Tortoise and The Hare.

This implies that AI is currently "smart". The hare is "smarter" and just takes breaks i.e. it can actually get the job done. With the current "AI" there are still quirks where it can get stuck.

by re-thc

3/27/2025 at 12:22:51 PM

> Is that really hype?

I'm thinking back to various promises self-driving would be widespread by 2016. These set a certain expectation for how our roads would look that I don't think has been realized a decade later (even as I've ridden in Waymos/FSD Teslas.)

by ikerino

3/27/2025 at 2:16:02 PM

if Elon Musk hadn't convinced the world in 2015 that self driving cars were right around the corner, that could work with just a few sensors and machine learning, maybe we'd have smart highways now. Slightly less fancy technology communicating hazards and such to cars from sensors on the road.

But no, we have Waymo, I guess, so that means Musk was right?

by dingnuts

3/27/2025 at 3:40:42 PM

The best choice is to do it right the first time, instead of spending billions in infrastructure which soon becomes obsolete.

by BigParm

3/27/2025 at 2:23:49 AM

The tortoise and the hare is an important point to raise - this is exactly how I feel.

But how long before AI is Good Enough that the point is irrelevant?

by bigs

3/27/2025 at 7:28:23 AM

Checks my notes from 3 years ago, 2.5 years ago, 2 years ago, 1.5 years ago, 1 year ago, and 6 months ago when we had this exact same discussion

It says here that it'll only be another 6 months!

by Hasu

3/26/2025 at 3:20:14 PM

Here is how I use it: As a writing assistant that lives in my IDE, and as a very very cool and sophisticated rubber duck that can answer me.

Something I do quite a lot is throwing back and forth a discussion over a particular piece of code, usually provided with little to no context (because that's my task to worry about), hammering it until we get that functionality correct, then presenting it with broader context to fit it in (or I simply do that part by hand).

Here is how I don't use it: As an agent that gets broad goals that he is supposed to fulfill on its own.

Why? Because the time and effort I have to invest to ensure that the output of an agentic system is in line with what I actually try to accomplish, is simply too much, for all the reasons outlined in this excellent article.

Ironically, this is even more true, since using AI as an incredibly capable writing assistant, already speeds up my workflow considerably. So in a way, less agentic AI empowers me in a way that makes me more critical of the additional time I'd have to invest to play around the quirks of agentic AI.

by usrbinbash

3/27/2025 at 8:24:10 PM

This doesn't parse for me:

> a discussion over a particular piece of code [...] hammering it until we get that functionality correct

Care to provide an example of sorts?

> then presenting it with broader context to fit it in

So after you have a function you might convert it to a method of a class. Stuff like that?

by kubanczyk

3/28/2025 at 4:33:03 AM

> Care to provide an example of sorts?

For example, recently I needed to revise some code I wrote a few years back, re-implementing a caching mechanism to make it work across networked instances of the same software. I had a rough idea how I wanted to do that, and used an LLM to flesh out the idea. The conversation starts with an instruction that I don't want any code written until I ask for it, then I describe the problem itself, let it list the key points, and then present my solution (all still as prose, no code so far).

Next step, I ask for its comments, and patterns/implementation details how to do that, as well as alternatives to those. This is the "design phase" of the conversation.

Once we zoom in on a concrete solution, I ask it to produce a minimal example code of what we discussed. Then we repeat the same process, this time discussing details about the code itself. During that phase I tell it what parts of the implementation it doesn't t need to worry about and what to focus on, keeping it from going off to mock-up-wonderland.

At the end it usually gets an instruction like "alright, please write out the code implementing what we discussed so far, in the same context as before".

This gives me a starting point to work from. If the solution is fairly small, I might then give it some of the context this code will live in, and ask it to "fill in the blanks" as it were...often though I do that part myself, as its mostly small refactoring and renaming.

What I find so useful about this workflow, as opposed to just throwing the thing at my project directory; it prevents the AI from getting side tracked, lost, as it were, in some detail, endlessly chasing its own tail trying to make sense of some compiler error. The human in the loop (yours truly), sets the stage, presents the focus, and the starting point is no code at all, just an ephemeral description of a problem and a discussion about it, grounding all the latter steps of the interaction.

Hope that makes sense.

by usrbinbash

3/26/2025 at 5:13:01 PM

Developer skill is obviously still essential — you can’t steer if you couldn’t drive. But what about developer energy? Before AI I could only code about 2 hours per day (actual time spent writing code) but with Claude Code I can easily code for 5 hours straight without breaking a sweat. It feels like riding an e-bike instead of a bicycle. AI genuinely feels like Steve Jobs analogy of a bicycle for the mind — it doesn’t replace me but now I can go much farther and faster.

by myflash13

3/27/2025 at 5:24:34 PM

Love the ebike analogy!

You're right though, you need to be able to steer, but you don't necessarily need to be able to map read.

Case in point, I recently stood up my first project in supabase, cursor happily created the tables, secure RLS rules etc in a fraction of the time it would take me.

To stop it getting spaghetti I had to add a rule "I'm developing a first version - add everything to an SQL file that tears down and recreates everything cleanly".

This prevented hundreds of migration files being created, allowed me to retain and context, and every now and then ask "have you just made my database insecure", which 50:50 resulted in me learning something, or a "whoopsie, let me sort that".

If I wasn't aware of this then it's highly likely my project would be full of holes.

Maybe it still is, but ignorance is bliss (and 3 different LLMs can't be wrong can they?!)

by _puk

3/28/2025 at 1:59:27 AM

I wonder how much more common vulnerabilities will be in coming years...

by Smar

3/27/2025 at 8:51:27 AM

Yeah this feels right. It helps with the bits I care about and definitely reduces friction there, but it also breaks through every wall when I’m off the happy path. I had to solve three layers of AWS bullshit yesterday to get back to training a model and if I’d had to solve them myself or bring in someone from my platform team I’d have ended up stopping short. I don’t really want to replace the parts of my job that I enjoy with AI, but I love having something to pick up the miserable bits when I’m stuck, confused, frustrated or bored. You’re absolutely right that this helps conserve energy.

by thom

3/26/2025 at 5:36:57 PM

The ebike analogy is perfect!

You still have to pedal, steer, and balance, but you're much faster overall.

by senbrow

3/27/2025 at 1:12:38 PM

I don't get it, at all.

Why are experienced developers so enthusiastic about chaining themselves to such an obviously crappy and unfulfilling experience?

I like writing code and figuring stuff out, that's why I chose a career in software development in the first place.

by codr7

3/27/2025 at 2:34:13 PM

I don't enjoy the keypresses of building useful features. I like identifying what needs to be changed, and how, in abstract terms. These tools quickly help me verify those changes are right.

If I need to call the VideoService to fetch some data, I don't want to spend time writing that and the tests that come with it. I'd rather outsource that part.

by quest88

3/28/2025 at 2:06:14 AM

I don't object to abstracting, at all; or reducing labor in general.

But this method of getting there makes me feel like I'm degraded to being the assistant and the machine is pulling my strings; and as a result I become dumber the more I do it, more dependent on crap tech.

by codr7

3/27/2025 at 4:07:13 PM

I can imagine people making the same argument decades ago about higher-level languages being "crappy and unfulfilling" compared to writing assembly. After all, you're not even writing the instructions yourself, you're just describing what you want and the computer figures out what to do.

by marcellus23

3/27/2025 at 5:35:43 PM

The (pretty substantial) difference is now the computer is telling you what to do.

by codr7

3/27/2025 at 6:22:54 PM

In what way?

by marcellus23

3/28/2025 at 2:07:48 AM

In the way that the more you do that, the less you have any clue what you're doing. Because you're not learning, you're following instructions. Being programmed, if you will.

by codr7

3/27/2025 at 1:38:49 PM

Why do we use hotkeys and snippets?

There is a lot of tedium in software development and these tools help alleviate it.

by _acco

3/27/2025 at 2:20:51 PM

If all these tools do is wipe out all the tedium in software then we are all laughing. Happy days to come.

There are tools and then there are the people holding the tools. The problem is no-one really knows which one AI is going to be.

by wrasee

3/27/2025 at 6:19:14 PM

At some point in your career you realize every line of code you write is not just an asset—it's also a liability that needs to be maintained, debugged, and understood by others.

The excitement around AI coding tools isn't about chaining yourself to a crappy experience — it's about having support to offload cognitive overhead, reduce boilerplate, and help spot potential missteps early.

Sure, the current gen AI isn't quite there yet, but it can lighten the load, leaving more space to solving interesting problems, architecting elegant solutions and "figuring stuff out".

by 6thbit

3/27/2025 at 7:05:45 PM

I really don't understand how replacing writing N lines of code by reading N lines of code reduces mental load. Reading and understanding code is generally harder than writing equivalent code.

by abenga

3/27/2025 at 10:41:06 PM

You'd still have to review code if you asked another human to write it.

That's why minimizing the generated code is important as well as working on smaller parts at once to avoid what the author refers as "too much up-front work" -- It is also easier mentally when you can iterate on this whole process in seconds rather than days in a pull request review.

by 6thbit

3/27/2025 at 4:29:20 PM

Because you'll be replaced by those engineers in N months/years when they can outperform you because they are wizards with the new tools.

It's like failing to adopt compiled code and sticking to punch cards. Or like refusing to use open source libraries and writing everything yourself. Or deciding that using the internet isn't useful.

Yes, developing as a craft is probably more fulfilling. But if you want it to be a career you have to adapt. Do the crafting on your own time. Employers won't pay you for it.

by malyk

3/27/2025 at 5:36:07 PM

Let them replace me then, it's not a job I feel like doing anyway.

And when they have forgotten all about how to actually write software, the market is mine.

by codr7

3/27/2025 at 5:20:44 PM

Instead of writing code, you can now figure out the code that your AI wrote and effectively treat everything as a legacy system.

by elric

3/28/2025 at 2:18:41 AM

How is correcting someone else's solutions even close to as fulfilling as creating your own? How can you not lose something by choosing that method?

by codr7

3/27/2025 at 7:56:03 PM

> I like writing code and figuring stuff out, that's why I chose a career in software development in the first place.

That's not why I got into software development. I got into it to make money. I think most people in Silicon Valley these days are the same mentality. How else could you tolerate the level of abuse you experience in the workplace and how little time you get to really dig on that particular aspect of the job?

This is a website that is catered to YC/Silicon Valley. My perspective is going to be common here.

by bradlys

3/28/2025 at 2:25:50 AM

I guess there were always two kinds, Bill Gates doesn't strike me as a person who loves technology. Compared to, say Dennis Ritchie or Wozniak.

I'm firmly in the problem solver/hacker/artist camp.

Which I guess is why we're more concerned about the current direction. Because we value those aspects more than anything; consider them essential to creating great software/technology, to staying human; and that's exactly what GenAI takes away.

I see how not giving a crap about anything but money means you don't see many problems with GenAI.

by codr7

3/27/2025 at 3:48:44 PM

Because on net it often saves tons and tons of time and effort if you know how to use it.

Luddism is a strange philosophy for a software engineer.

by meowface

3/27/2025 at 5:53:02 PM

> Luddism is a strange philosophy for a software engineer.

Luddism and critically evaluating the net benefit and cost of a piece of tech, are 2 very different things.

And the latter is not strange for a SWE at all, in fact I'd say it's an essential skill.

by usrbinbash

3/28/2025 at 12:20:44 AM

I'm referring to this part:

>I like writing code and figuring stuff out

This is an alien mentality to me.

by meowface

3/28/2025 at 2:10:56 AM

Problem solving, I'm pretty sure it's the driving motivation for many/most coders.

I find pleasure in crafting the solution, sculpting it by hand; putting everything I've got into making it fit the problem like a glove. Coding to me is an artistic way of expressing myself, exploring, always improving; it's part of the fun to me.

And I don't like following instructions in general, don't like being programmed.

So what's in it for you then, if not the problem solving?

by codr7

3/28/2025 at 4:21:44 AM

Okay...given that a SWE job is literally "take problem description, figure out way to solve problem in software", what part about this is "alien" exactly?

And yes, there already are solutions to many common problems. The task then becomes finding a best-fit, and adapting these solutions to the specific needs of the usecase...which is another instance of the same task.

by usrbinbash

3/27/2025 at 2:32:48 PM

> Example: When encountering a memory error during a Docker build, it increased the memory settings rather than questioning why so much memory was used in the first place.

AI really is just like us!

by FfejL

3/26/2025 at 3:36:07 PM

I'm surprised to not see an obvious one (for me): Use AI around the periphery.

There's very often a heap of dev tools, introspection, logging, conversion, etc tools that need to be build and maintained. I've had a lot of luck using agents to make and fix these. For example a tool that collates data and logs in a bespoke planning system.

It is a lot of generated boilerplate off the critical path to build these tools and I just don't want to do it most days.

by jvanderbot

3/27/2025 at 5:43:27 AM

In my every day experience that's pretty risky. The periphery as you call it is often an area where you lack the expertise to spot and correct AI mistakes.

I am thinking about build systems and shell scripts. I see people everyday going to AI before even looking at the docs and invariably failing with non-existent command line options, or worst options that break things in very subtle ways.

Same people that when you tell them why don't you read the f-ing man page they go to google to look it up instead of opening a terminal.

Same people that push through an unknown problem by trial and error instead of reading the docs first. But now they have this dumb counselor that steers them in the wrong direction most of the time and the whole process is even more error prone.

by aulin

3/27/2025 at 11:55:11 AM

You're wrong. I have all the expertise but none of the time to generate 100s of lines of boilerplate API calls to get the data together, and no interest in formatting it correctly for consumption, let alone doing so state fully to allow interaction. These are trivial problems to solve that are highly tedious and do not affect whatsoever the business at hand. Perfect drudgery for automation, and just scanning the result is easy to verify the output or code.

by jvanderbot

3/27/2025 at 7:15:33 PM

> . I have all the expertise but none of the time to generate 100s of lines of boilerplate API calls to get the data together, and no interest in formatting it correctly for consumption,

Time to learn some Emacs/Vim and Awk/Perl

by skydhash

3/27/2025 at 12:34:14 PM

I am not wrong. You simply are not the kind of developer I am thinking about. And believe me the other kind is way more represented.

by aulin

3/27/2025 at 5:18:19 PM

Ok, well, then you're not wrong.

by jvanderbot

3/26/2025 at 3:41:05 PM

I find that I have to steer the AI a lot, but I do have optimism that better prompting will lead to better agents.

To take an example from the article: code re-use. When I'm writing code, I subconsciously have a mental inventory of what code is already there, and I'm subconsciously asking myself "hey, is this new task super similar to something that we already have working (and tested!) code for?". I haven't looked into the details of the initial prompt that a coding agent gets, but my intuition is that an addition to the prompt instructing the agent to keep an inventory of what's in the codebase, and when planning out a new batch of code, check the requirements of the new tasks against what's already there.

Yes, this adds a bunch of compute cycles to the planning process, but we should be honest and say "that's just the price of an agent writing code". Better planning > ability to fix things.

by timdellinger

3/26/2025 at 4:07:47 PM

There are certain pieces of text that appear right before some of the greatest pieces of code ever written. For example, we've all heard of NASA code requirements. If you get the LLM into the "mindset" of a top-tier professional developer before getting it to spit out code, the code quality will reflect that. If your prompt is sloppy and poorly defined, you'll get copy-pasted StackOverflow code, since that's how most SO questions look. If it's stupid but it works, it's not stupid.

The hard part is that finding a local optimum for prompting style for one LLM may or may not transfer to another depending on personality post-training.

And whatever style works best with all LLMs must be approaching some kind of optimum for using English to design and specify computer programs. We cannot have better programs without better program specifications.

by hnuser123456

3/26/2025 at 4:12:07 PM

Can you share some examples of these certain pieces of text and greatest pieces of code?

by yaj54

3/26/2025 at 4:26:56 PM

Well, if you want safety-critical code, you could have the LLM read this before asking it to write its own code: https://ieeexplore.ieee.org/document/1642624

GP was pondering about code re-use. My typical use involves giving an entire file to the LLM and asking the LLM to give the entire file back implementing requested changes, so that it's forced to keep the full text in context and can't get too off-track by focusing on small sections of code when related changes might be needed in other parts of the file.

I think all of this is getting at the fact that an LLM won't spit out perfect code in response to a lazy prompt unless it's been highly post-trained to "reinterpret" sloppy prompts just as academically as academic prompts. Just like a human programmer, you can just give the programmer project descriptions and wait for the deliverable and accept it at face value, or you can join the programmer along their journey and verify their work is according to the standards you want. And sometimes there is no other way to get a hard project done.

Conversely, sometimes you can give very detailed specifications and the LLM will just ignore part of them over and over. Hopefully the training experts can continue to improve that.

by hnuser123456

3/27/2025 at 2:20:37 PM

Horrible, terrifying advice. If you want safety critical code, DON'T USE AN LLM AT ALL. Use formal verification methods!

This is a solved problem!

by dingnuts

3/26/2025 at 4:16:49 PM

This is one of the reasons I never needed to use LLMs. In any given codebase where you're experienced enough in the language and the framework/platform/libraries, more often than not, you're just copy-pasting code, or tab-completing (if you're in an IDE). The actual problems are more often solved on the sofa and with a lot of reading, then trying out hypothetical solutions.

by skydhash

3/26/2025 at 5:03:24 PM

i have mentored a few people to become Programmers. Some for months, some for years. It's like teaching someone to ride a bycicle. Hand-holding first, then hand-guiding, then short flights, then longer... Different people pick stuff at different pace and shape.. but they do learn.. if they want to.

What i completely miss in these LLM parrots-agents-generators, is the learning. You can't teach them anything. They would not remember. Tabula rasa / Clean slate, every time. They may cite Shakespeare - or whatever code scrubbed from github - and concoct it to unrecognizability - but that's it. Hard rules or guardrails for every-little-thing are unsustainable to keep (and/or create) - expert-systems, rule-based no-code/low-code.. has been unsuccessful for decades).

Maybe, next AI wave.

And, there's no understanding. But that also applies to quite some people :/

by svilen_dobrev

3/26/2025 at 5:35:54 PM

Consider rules for projects. It's not always perfect, but it does adapt based on my instructions.

For example, I have had good success in test first development as a rule. That means that I can make sure it has the specifications correct first.

by ebiester

3/26/2025 at 10:49:37 PM

LLMs don't learn but agents do. You just need to insert that new knowledge in the prompt.

by owebmaster

3/27/2025 at 4:00:22 AM

Agents are still LLMs. LLMs also have prompts. There's no difference!

by achierius

3/27/2025 at 2:21:05 PM

LLMs don't have prompts, you can use prompts to query LLMs.

Agents are a mix of models, prompts, RAG and an event loop.

by owebmaster

3/27/2025 at 12:32:18 PM

Agents HAVE Models. There is a big difference if you give a model access to tools and perhaps some form of memory.

by trash_cat

3/27/2025 at 7:00:41 AM

Literally all of this is easy to solve if you actually tried. Developers are literally too lazy to write their own AI tooling, it’s bizarre to me.

by cheevly

3/27/2025 at 10:56:24 AM

The goal isn't to use AI, though, it's to be productive. Maybe for you AI + writing support tools to improve your workflow makes you more productive and that's great! For me, for the kind of work I'm currently doing, I'm more productive in other ways.

by danmur

3/26/2025 at 4:15:28 PM

Is Martin Fowler now just renting out space on his website?

by osigurdson

3/27/2025 at 10:03:10 AM

Martin Fowlers page is basically the place where Thoughtworks [1] places their articles. A lot of good stuff there on many different topics.

1: https://www.thoughtworks.com/

by Cupprum

3/26/2025 at 4:34:14 PM

right!? It was a little misleading that the article was written by someone else. (Birgitta Böckeler)

by onionbagle

3/27/2025 at 3:30:25 PM

yeah, confusing. URL literally says martinfowler, and article written by someone else. what... :/

by nikolayasdf123

3/26/2025 at 4:26:38 PM

What are you referring to?

by Apocryphon

3/26/2025 at 4:29:38 PM

GP was apparently unaware until now that martinfowler.com has basically been a blog/article hosting site (though more in the highly curated sense than a generic hosting site, more akin to a trade publication) for the last couple decades and that not all the content is written by Martin Fowler himself. The author of this piece is Birgitta Böckeler.

by Jtsummers

3/27/2025 at 6:19:59 AM

Kinda like rogerebert.com, even before the esteemed film critic's death.

by bitwize

3/26/2025 at 4:28:47 PM

    Lack of reuse
    AI-generated code sometimes lacks modularity, making it difficult to apply the same approach elsewhere in the application.

    Example: Not realising that a UI component is already implemented elsewhere, and therefore creating duplicate code.

    Example: Use of inline CSS styles instead of CSS classes and variables

This is the big one I hit for sure. I think it's a problem with agentic RAG, where it only knows the files it's looked in and not the overall structure or where to look for things, so it just recreates them.

by adamgordonbell

3/27/2025 at 3:33:01 PM

yep. noticed this too. but I think this is due to short context LLMs have. now my tools, mostly browser LLMs copy-paste code, are analysing small sub-problem at time. once LLMs will see whole repository + history of that repository, likely they will write abstractions that can be reused

by nikolayasdf123

3/26/2025 at 4:43:48 PM

I don't really like AI in IDE. I don't want them to think for me. Code completion and Intellisense is good enough.

That said, I think there are 3 items that are important:

- Quickly grasp a new framework or a new language. People might expect you to do so because of AI's help. 2 weeks might be the maximum, instead of the minimum. The same for juniors.

- Focus on the real important things. So instead of trying to memorize a shell script you are going to use a couple of times per year, maybe use the time to learn something more fundamental. You can also use AI to help you to bootstrap the learning. If you need something for interviews, spend a week to memorize them.

- Be willing to exclude AI from your thought process. If you rely AI on everything, including algorithms and designs, this might impact your understanding.

by ferguess_k

3/26/2025 at 4:49:42 PM

    - Be willing to exclude AI from your thought process. If you rely AI on everything, including algorithms and designs, this might impact your understanding.

Most of the time I'm using AI for problem space mapping (I'm doing dirt simple CRUD dev right now) and decomposition. It's ok at that, but even the deep research mode of Claude leaves some things to be desired.

I feel like an editor now, more than an engineer. I know the kinds of things I'm looking for, and I use AI to walk a solution in. Either I use the output of the LLM as-is (for throwaway stuff) or I use it as a jumping off point for my own work _without_ the AI.

by all2

3/26/2025 at 4:59:12 PM

>I feel like an editor now, more than an engineer. I know the kinds of things I'm looking for, and I use AI to walk a solution in.

I agree. I think it's fine to do so. I usually prefer to write my code without AI (except for bootstrapping it).

In my work as a DE, I mostly use AI to write scripts for me. For example, how to do this in PySpark? I kinda refused to memorize any of these because I'm simply not very interested, and I can always spend a week to memorize the fundamentals if I need.

In my side projects, I use AI extensively. Same as you, I use AI for problem space mapping, or sort of. For example, I have some source code, how do I structure them better? I have read the MIDI standard and thought this piece of binary code means blah, can you please confirm for me? Well AI is OK for these kinds of work.

by ferguess_k

3/26/2025 at 5:12:37 PM

Even code completion has issues. It might get the structure right, but it usually doesn't understand the business logic and I end up switching out what codes/vars are being used.

by giantg2

3/26/2025 at 5:29:27 PM

It's definitely possible. But in my case so far it's fine. I work as a DE so I only need the auto-completion to remind me what the column name is once I typed out the first few characters, because there are so many columns.

In my side projects I mostly use C/C++ so auto-completion helps me to find a struct member or something similar.

I guess it can become quite complicated when the projects becomes very large.

by ferguess_k

3/27/2025 at 3:29:37 PM

For me I have two extremes:

1. Complete Vibe coding -- greenfield and just playing or doing a small quick prototype

2. Get out of my IDE, but know my code base -- small snippets, methods, classes that add desired functionality but off to the side completely -- and don't run things in my shell that's just wrong

What I don't like it current codebases getting whacked because it decided to downgrade a dependency or lie about a function signature.

by tomrod

3/26/2025 at 4:29:24 PM

I use LLMs for various purposes in day to day development. I don't use any of the tools mentioned in the article because I'm using intellij and don't want to replace a tool that has lots of stuff that I use all the time. But aside from that, it's good advice and matches my experience.

I've dabbled with plugins for intellij but wasn't really happy with those. But ever since chat gpt for desktop started interfacing directly with jetbrains products (and vs code as well), that's my goto tool. I realized that I like being able to pull that up with a simple keybinding and it auto connects to the IDE when I do. I don't need to replace my tools and I get to have AI support ready to go. Most of the existing plugins seem to insist on some crappy auto complete, which in a tool that offers a lot of auto complete features already is a bit of an anti feature. I don't need clippy style autocomplete.

What matters here is the tool integration, not the model quality. Better tool integration means better prompts with less work and getting better answers that way.

Example: I run a test, it fails with some output. I had this yesterday. So I asked, "why is this failing" and had a short discussion about what could be wrong. No need for me to specify any detail; all extracted from the IDE. We ticked off a few possible causes, I excluded them. And then it noticed a subtle change in the log messages that I had not noticed (a co-routine context switch) that turned out to be the root cause.

That kind of open ended debugging is a bit of a mixed bag. Sometimes it finds stuff. Mostly it just starts proposing solutions based on a poor analysis of the problem.

What works pretty reliably is:

- address the TODOs / FIXMEs, especially if you give it some examples of what you expect

- write documentation (very good for this)

- evaluate if I covered all the edge cases (often finds stuff I want to fix)

- simple code transformations (rewrite this using framework X instead of Y)

I don't trust it blindly. But it's generally giving me good code and feedback. And I get to outsource a lot of the boring crap.

by jillesvangurp

3/26/2025 at 5:10:55 PM

Yes I find chatGPT/Jetbrains (RubyMine) in my case is the most usable setup I've encountered.

It's like Rubymine is "home" for me - and chatGPT's macOS client has become another "home" for me so it's quite convenient that they talk to each other now.

I have a little FOMO about Cursor though. ChatGPT will automatically apply its suggested changes to my open editor - but I have the sense Cursor will do a bit more? Apply changes to multiple files? And have knowledge of your whole project, not just open files? Can someone fill me in

by marstall

3/27/2025 at 3:36:03 PM

this. very similar experience. but toolset is rather different.

by nikolayasdf123

3/27/2025 at 5:59:21 PM

This diagram is painfully relatable — my team checks every single box here, and we don’t even use AI yet! Imagine when we finally do...

"Misunderstood requirements" and "overly complex implementations" are practically our mascots at this point. We're slowly untangling this chaos through better upfront convos and iterative reviews, but man, habits die hard. Anyone else navigating these pitfalls totally unaided by AI?

by 6thbit

3/26/2025 at 4:47:55 PM

I've been using Claude to help write a complex prototype for game dev. Overall it's been a big productivity boost. However as the project has grown Claude has gotten much worse. I'm nearing 15k lines and it's borderline more trouble than it's worth. Even when it was helpful, it needed a _lot_ of guidance from me. Almost more helpful as a "rubber ducky" and for the fact that it kept me from deadlocking on analysis. That said, discussing problems and solutions with Claude often does keep things moving and sometimes reveals unexpected solutions.

If Claude could write the code directly unsupervised, it would go wild and produce a ton of garbage. At least if the code it writes in the browser is any indication. It's not that it's all bad, but it's like a very eager junior dev -- potentially dangerous!

Imagining a codebase that is one or two orders of magnitude larger, I think Claude would be useless. Imagining a non-expert driving the process, I think Claude would generate a very rickety proof of concept then fall over. All that said, I wish I had this tool when developing my previous game. Especially for a green field project, it feels like having access to the internet versus pulling reference manuals -- a big force multiplier.

by aschearer

3/27/2025 at 1:09:34 PM

> Overall it's been a big productivity boost. However as the project has grown Claude has gotten much worse. I'm nearing 15k lines

I've read comments like this many times and I'm genuinely surprised at the coexistence of "productivity boost" and "15k lines".

Am I the only one that feels like 15k is a tiny project even in non-boilerplatey languages? That's not even past the prototyping stage of a small project.

Am I completely out of touch with a modern project's scale?

by kaoD

3/27/2025 at 6:27:08 AM

Why not just split the tasks, and have different projects only house a portion of the code?

by AndyNemmity

3/27/2025 at 10:49:28 AM

Why dumb down your work worse because the machine can't understand it?

by danmur

3/27/2025 at 12:48:26 PM

Seems like the code is designed poorly if it can't be worked on in small chunks

by ChromaticPanic

3/27/2025 at 1:10:28 PM

Seems like you're dismissing the cost of artificially splitting what should be a monolith.

It outweighs the supposed productivity boost of LLMs by at least one order of magnitude if not more.

by kaoD

3/27/2025 at 3:31:00 PM

Most people have a smaller context window than LLMs.

by tomrod

3/27/2025 at 3:27:51 PM

> I want to preface this by saying that AI tools are categorically and always bad at the things that I’m listing.

I think there's a not missing there. Why would you preface that they are categorically and always bad? Makes more sense the other way round.

Also grammar error "effected" instead of "affected" in the footer.

by croemer

3/26/2025 at 4:28:39 PM

I actually think that most problems that took 5-20 mins are now a few minutes and it’s more about how many of those intense minutes and loops you’re going through.

Also, right now engineers are hyper optimized in the code aspects but not thinking about the context into cursor and context out of cursor.

Like the amount of copy paste from Notion / JIRA / Sentry and the amount of output like summarizing the git commits and PRs, slack and other “over communication” you have to do these days. This is the area I think we can more easily automate away.

by johnjungles

3/26/2025 at 4:37:59 PM

I've been playing around with vibe coding and I think a lot of the issues brought up could be fixed by an architecture abstraction layer that does not exist today. My idea would be something like an architecture-graph (Archigraph working title) that would recursively describe how an application works or should work. Then when an agentic coder is doing a task they can easily see the bigger picture of how an application works and hopefully writing better code. Anyone interested in working on this with me?

by fasteddie31003

3/27/2025 at 5:22:38 AM

That abstraction layer that does not exist today looks a lot like the many high level architectural design languages that were hot in the 90s. Never heard of UML?

by rixed

3/27/2025 at 11:57:47 AM

I bet there is an LLM based version of Rational Rose currently under development somewhere.

by dagw

3/27/2025 at 5:02:59 AM

I'd be interested to see how tools like Cursor/Windsurf and even Copilot are modeling this internally. This idea seems to be a natural extension to having a hierarchy/team of agents all working on a common goal. In this case I would imagine one agent serves as the architect or reviewer, and another generates code to meet spec, and they fight back and forth until converging/diverging.

by reztip

3/27/2025 at 6:21:18 AM

I've been thinking about this myself, although just planning to reuse what's already there.

How do you picture the human in the loop?

by rixed

3/27/2025 at 8:12:00 AM

"Vibe Coding" is not Software Engineering.

It is "Slopware Engineering".

by rvz

3/27/2025 at 5:35:42 AM

I was playing with the idea about setting up something like this!

by rage4774

3/27/2025 at 6:43:04 AM

Give me a shot

by siva7

3/27/2025 at 4:32:26 AM

I see jr developers and managers not able to make the assessment the authors insight and experience provide and just checking in gobs of stuff they don’t understand

It’s frustrating

by zombiwoof

3/27/2025 at 10:19:40 AM

Imo, AI implements something useful 20% of the time while breaking existing code 80% of the time.

by DeathArrow

3/27/2025 at 3:51:41 PM

For me it's more like useful 70% of the time horrible 30% of the time. Overall a big boon but can be frustrating.

by meowface

3/27/2025 at 3:34:14 PM

which AIs are you using? do you edit what they suggest yourself or just blindly copy-paste and hit run? do you ask them to write unit-tests + self-fix for what they written?

by nikolayasdf123

3/28/2025 at 11:20:00 AM

I used Cursor, Augment Code, Roo Code, Aider, Cline, Github Copilot. With Claude and Deepseek and OpenAI backends. I let AI to modify files and I ask to write tests and fix them. Some tools can also run them.

I am fiddling with tools like Cursor, Aider, Augment Code, Roo Code and LLMs like GPT, Sonnet, Grok, Deepseek to try to decide whether I can use AI for what I need, and if yes, identify some good workflows. I've read experiences of other people and tried my own ideas. I've burnt countless tokens, fast searches and US dollars. Working with AI for writing code is painful. It can break the code in ways you've never imagined and introduce bugs you never thought are possible. Unit testing and integration testing doesn't help much, because AI can break those, too.

You can ask AI to run in loop, fixing compile errors, fixing tests, do builds, run the app and do API calls, to have the project building and tests passing. AI will be happy to do that, burning lots of dollars while at it.

And after AI "fixes" the problem it introduced, you will still have to read every goddam line of the code to make sure it does what is supposed to.

For greenfield projects, some people recommended crafting a very detailed plan with very detailed description and very detailed specs and feed that into the AI tool.

AI can help with that, it asks questions I would never ask for an MVP and suggests stuff I would never implement for an MVP. Hurray, we have a very, very detailed plan, ready to feed into Cursor & Friends.

Based on the very detailed plan, implementation takes few hours. Than, fixing compile errors and fixing failing tests takes a few more days. Then I manually test the app, see it has issues, look in the code to see where the issues can be. Make a list. Ask Cursor & Friends to fix issues one by one. They happily do it and they happily introduce compilation errors again and break tests again. So the fixing phase that last days begins again.

Rinse and repeat until hopefully we spend a few weeks together (AI and I) instead on me building the MVP myself in half time.

One tactic which seems a bit faster, is to just make a hierarchical tree of features, ask Cursor & Friends to implement a simple skeleton, then ask them to implement each feature, verifying myself the implementation after each step. For example, if I need to log in users, just ask to add logging in code, the ask to add an email sender service, then ask to add email verification code.

Structuring the project using Vertical Slice Architecture and opening each feature folder in Cursor & Friends seems to improve the situation as the AI will have just enough context to modify or add something but can't break other parts of the code.

I dislike that AI can introduce inconsistencies in code. I had some endpoint which used timestamps and AI used three different types for that DateTime, DateTimeOffset and long (UNIX time). It also introduced code to convert between the types and lots of bugs. The AI uses some folder structure for a part of the solution and other structure for other parts. It uses some naming conventions in some parts and other naming conventions in other parts. It uses multiple libraries for the same thing, like multiple JSON serializing libraries. It does things in a particular way in some parts of the application and in another way in other parts. It seems like tens of people are working in the same solution without anyone reading the code of the others.

While asking AI to modify something, it will be very happy to modify things that you didn't ask to.

I still need to figure out a good workflow, to reduce time and money spent, to reduce or eliminate inconsistency, to reduce bugs and compile errors.

As an upside using AI to help with planning seems to be good, if I want to write the code myself, because the plan can be very thorough and I usually lack time and patience to make a very detailed plan.

by DeathArrow

3/27/2025 at 3:27:19 PM

is this just me, or none of this happens when using LLMs/AIs/Agents while coding? my experiences is overwhelmingly useful and positive, hard to imagine building software without LLM support anymore. I am literally 5~10x more productive.

by nikolayasdf123

3/26/2025 at 3:40:32 PM

> 15k LOC codebase

I wish articles about AI assistance would caveat this at the start. 15k LOC is a weekend hackathon project, which is all well and good, but not reflective of the work that 99% of developers are doing in their day jobs.

by mjr00

3/26/2025 at 3:42:54 PM

I, too, habitually write 7500 lines of code per day.

by jstanley

3/26/2025 at 3:44:26 PM

For a brand new project that you're trying to get done in a weekend--aka a weekend hackathon project--it's very doable. Would not recommend committing 7500 lines of code per day at your day job though.

by mjr00

3/26/2025 at 3:48:11 PM

If you work 8 hours a day on Saturday and Sunday and each line has on average 40 characters, then on average you have to type about 5 characters a second to hit 7000 lines of code.

There's some heavy assumptions about boilerplate or autogenerated code going on in that estimate, as I don't think very many average 5 characters a second over 16 hours.

by ariwilson

3/26/2025 at 4:23:54 PM

Haha, I appreciate the math, fair enough. We can change the caveat to "it's a project you worked on every weekend for a few months" if that helps. The point still stands that 15k LOC doesn't represent the type of codebases worked on by companies that employ multiple full-time software developers, much less long-lived enterprise codebases (which is Fowler's famed area of expertise, ironically).

by mjr00

3/26/2025 at 4:07:59 PM

The two assumptions that aren't quite right are the number of characters per line and the number of hours per day. For most work it's hard to spend more than four to six good hours per day just doing actual work; but when kicking tires on a hobby project, it is easily possible to stay engaged for an unhealthy amount of hours in a row.

by jchw

3/26/2025 at 4:20:28 PM

I write 1000 lines of code per second, bud. It's called ctrl+c and ctrl+v. In all seriousness, with autocompletion, snippets, and AI, I don't think you can measure this accurately in the way you're doing it.

by drbojingle

3/26/2025 at 4:05:16 PM

In English, the average word length is 5 characters. If you can type 60 WPM that means you're typing on average at least 300 characters per minute or at least 5 characters per second (at least because this is not counting the needed whitespace and punctuation). That makes it technically possible for a moderately capable typist to pull off 7000 lines in a day using your numbers. Pair that with IDEs and autocomplete and it becomes much more feasible, if you have a solid understanding of the objective for your code.

by Jtsummers

3/26/2025 at 3:57:09 PM

40 seems way too much. “}” alone probably makes up a significant portion of lines. Another thing is auto-complete that does the majority of typing anyway.

by Zanfa

3/26/2025 at 3:49:00 PM

"all work and no play makes jack a dull boy" x5 = 30 secs. x7500 = 12.5 hours.

honestly, i don't see it. don't you stop to pee?

by flir

3/26/2025 at 3:57:07 PM

I'm sorry but unless you count framework bootstraps for models and configs and stuff like that as "coding" nobody is legitimately writing 7500 lines in a day. At my most productive, powering through real problems, debugging issues and making stuff solid, I've hit ~3500 with marathon code sessions and ChatGPT. I've seen industry leaders and competitive coders in action, and none of them were significantly faster - any speed difference is more due to taking fewer incorrect solution paths.

by CuriouslyC

3/26/2025 at 4:42:20 PM

Everyone is missing the point. Fine, maybe the math is off and it took 3 days instead of 2.

The issue is that Cursor tends to be demoed for incredibly small, green, and simple projects.

Most of us are working on codebases with at least over 10 million lines. I would love an AI agent that can massive infrastructure migrations with only a bit of oversight. Didn’t Shopify do something like that recently?

I think this is still an area that needs a lot of work.

by materielle

3/27/2025 at 12:55:46 PM

I've been personally surprised that this doesn't come up more often. Most mature codebases span a decade or more, and especially in the web, there's so many layers of evolving technologies that were introduced during this time, resulting in complex geological layers forming in the codebase as the patterns evolved. That is not only a lot of lines of code, but a lot of nuance as well. Even a basic problem like routing can make these AIs fall flat on their face because of the sheer context and complexities involved

by impjohn

3/27/2025 at 3:37:27 PM

what are you guys writing? is this like unit tests/generated files or something? or some non-reusable constant definitions(CSS/JSON/YAML)?

by nikolayasdf123

3/26/2025 at 4:25:40 PM

Post your github

by CyberDildonics

3/26/2025 at 5:22:23 PM

The message you're replying to is sarcasm.

by orphea

3/26/2025 at 5:24:22 PM

[dead]

by totalkikedeath

3/26/2025 at 4:07:21 PM

Yeah especially in the context of multiple contributors, 15k is so small it's almost hard to do collaborative coding (apart from pair programming).

by marginalia_nu

3/26/2025 at 4:01:56 PM

15k LOC is an entire enterprise SaaS product in the ecosystems I frequent.

by bob1029

3/26/2025 at 5:28:21 PM

Maybe 2-3 week project would be better to say. But yeah it’s quite small.

The industry average seems to be around 100 LOC per day per developer. So if you have a team of 10 that’s only 15 days of work. Once you’re involved in some existing legacy code base it’s likely in the millions.

by zeroonetwothree

3/26/2025 at 4:10:56 PM

you seem to be projecting your own experience rather than giving an accurate representation of developer productivity - 15k is not the norm at all or even close to it.

by 38

3/26/2025 at 3:17:20 PM

> supervised agent

This is the trick. Human in the loop, not human hiding in an ivory tower after uttering a single command. This is ~effectively what I see a lot of shops doing right now:

"Clean up the codebase please. Apply best practices :D. OH. By the way, heres a laundry list of 100 things to NOT do: <list begins>".

I get a lot more uplift out of use cases like:

"Please generate a custom Stream implementation that is read-only and sources bytes from an underlying chunked representation. Mock the chunk loading part. Primarily demonstrate the ReadAsync method and transition logic between chunks."

by bob1029

3/27/2025 at 8:38:37 AM

Does anyone post articles about using these LLMs on non web dev?

The internet is full of javascript/html/css info. Some wrong some obsolete some right and current, but there is data.

How about the more peasant languages?

by nottorp

3/27/2025 at 11:50:24 AM

Anecdotally, it does somewhat fine with C++ and OpenCV. Python is great, though PySide much less so. QML is almost useless. GLSL is OK, but not great. It generally can't reason well across language barriers, although it's great at converting between languages.

The deeper into a nerdy domain I go, the less likely it is to understand what's going on. And more broadly, it seems that usefulness steeply declines for larger files and projects. It just can't fit enough context into its window to make sense of complicated things.

As an extreme example, I told it to average two angles, and it just took the mean of them. Even after prompting, it thought nothing wrong of that. (The average of 1° and 359° is 0°, not 180°.) So it goes for many domains outside of webdev, UI, data science, scripting.

by Derbasti

3/27/2025 at 4:11:09 PM

Even Python gets a bit touchy if you ask it to avoid common packages.

An example is asking for simple Kalman filter, limiting to 2x2 matrix to avoid the need for LU decomposition. If you ad to the prompt a constraint to not use Numpy, which almost everything in the corpus does.

Even with LRM's having a high enough top-k accuracy, so that at least one correct solution given in k guesses seems to be the trick.

Perhaps Pyhon+Numpy is a language barrier but the errors without Numpy seem really trivial, similar to what one would see on an obscure language. It is different across different models, but getting stuck generating verification code with divide by zero to giving up and producing code that uses numpy are failure modes I have seen.

Professor Subbarao Kambhampati's explanation really helps here IMHO.

https://bsky.app/profile/rao2z.bsky.social/post/3lkjnrrv2qk2...

"Compiling the signal verifier" in, at least superficially to me, is a good intuition on where these fail.

The limits of Top-K and heavy tail dependance in many tasks will be something painful, I think we will need more expertise and not less among programers just due to the failings of us humans and our over trust of automation etc...

How we change the career path to develop tacit and technical abilities is a big question personally.

by nyrikki

3/27/2025 at 3:35:07 PM

LLMs writing Go is so hot right now

by nikolayasdf123

3/27/2025 at 5:19:03 PM

I'm already seeing developers spending more time communicating with their AI than with their team. I don't think that's a good evolution. Many of us aren't the best communicators, but it's a skill we typically polish as we become more senior. I worry about what will happen to junior devs who spend more time talking to/pairing with AI tham their human coworkers.

by elric

3/27/2025 at 5:23:49 PM

Upfront context, precise statements of what is required, immediate constructive feedback? What's not to like?

by globalise83

3/27/2025 at 7:18:52 PM

Misunderstandings of specifications, lack of best or common practices, redoing stuff that was already tried by the team.

by skydhash

3/27/2025 at 8:37:58 PM

> junior devs

Are there any? Honest question.

by kubanczyk

3/26/2025 at 9:01:44 PM

The opposite of vibe coding, when the agent craps out and you just do it manually = Artisanal coding. Yeah I can get on board with that.

by ENGNR

3/27/2025 at 7:38:26 AM

My central question after reading the article:

Why did they choose a circle diagram over a pyramid?

by Garlef

3/27/2025 at 12:52:03 PM

I believe impact relates to area of circle as defined by the radius. A pyramid is a more hierarchical approach that perhaps was not suited. My 0.02$

by impjohn

3/27/2025 at 9:10:44 AM

>Complicated build setups that confused both me and the AI itself.

I noticed that I am capable of producing software beyond my own understanding. It wouldn't surprise me if the same is true of AI!

by andai

3/26/2025 at 11:57:35 PM

Along these lines, one thing Claude Code does consistently is to see a failing test and then add a conditional in the actual code to satisfy the test.

I'm typically pretty gentle in real code reviews but that one is a serious "what the fuck are you even doing" if it were a human.

Adding a top-level context-rule in claude.md doesn't fix it reliably.

by lukev

3/27/2025 at 1:41:37 PM

My solution to the authors babysitting problems is to close the iteration loop instead of embedding humans into it.

Agent generated broken code? An agent can discover that, provide feedback on the pull request, and close it, forcing the coding agent to respond to the feedback.

As long as you have 10 agents doing software engineering analysis for every 1 agent you have writing code, my suspicion is that a lot of this babysitting can be avoided.

At least theoretically.. I haven't got all of this infrastructure linked myself to try.

by elif

3/27/2025 at 6:53:13 AM

> During refactoring, it failed to recognize the existing dependency injection chain

Not sure if this is an argument against atheism or foxholes.

by jgilias

3/27/2025 at 5:26:00 AM

“Agentic” coding?

I suppose it is Thoughtworks after all working to expand mindshare by defining buzzwords.

by andrewstuart

3/26/2025 at 3:25:30 PM

I think of the modern developer being more like a shepherd rather than a builder now. You have to vibe with the machine, but you need to make sure they stay on easy terrain and give them structure instead of letting them simply free graze.

by decompiled_dev

3/27/2025 at 7:14:48 PM

Big words from one who does not code.

by npn

3/27/2025 at 8:25:12 PM

This article does not line up with my experiences at all. Sometimes I wonder if it's something to do with prompting or model selection.

I recently built out a project where I was able to design 30+ modules and only had 4 generation errors. These were decent size modules of 700-5000 lines each. I would classify the generation errors as related to missing specification -- i.e., no you may not take an approach where you import another language runtime into memory to hack a solution.

Sure, in the past, AI would lead me on goose chases, produce bad code, or otherwise fail. AI in 2025 though? No. AI has solved many quirky or complex headscratchers, async and distributed runtime bugs, etc.

My error rate with Claude-3.7-sonnet and OpenAI's O3-mini has dropped to nearly zero.

I think part of this is how you transfer your expert knowledge into the AI's "mindspace".

I tend to prompt a paragraph which represents my requirements and constraints. Use this programming language. Cache in this way. Encrypt in this way. Prefer standard library. Use this or that algorithm. Search for the latest way to use this API and use it. Have this API surface. Etc. I'm not particularly verbose either.

The thinking models tend to unravel that into a checklist, which they then run through and write a module for. "Ok, the user wants me to create a module that has these 10 features with these constraints and using these libraries."

Maybe that's a matter of 25yrs of coding and being able to understand and describe the problem and all of its limits and constraints quickly but I find that I get one-shot success nearly every time.

I'm not only laying out the specification, but I also have the overall spec in my mind and limit the AI to building modules to my specifications (apis/etc) rather than trying to shove all of this into context. Maybe that is the issue that some people have. Trying to shove everything (prior versions of the same code, etc) into one session.

I always start brand new sessions for every core task or refactoring. "Let's add caching to this class that expires at X interval and is configurable from Y file and dependency injected to the constructor". So perhaps I'm unintentionally optimizing for AI but this fairly easy to do and has probably led to a 5-10x increase in code I'm pushing.

Huge caveat here though, I mostly operate on service/backend/core lib/api code which is far less convoluted than web front-ends.

It's kind of sad that front-end dev will require 100x context tokens due to intermingling of responsibilities, complex frameworks, etc. I don't envy people doing front-end dev work with AI.

by dudeinhawaii

3/26/2025 at 4:19:31 PM

Great, so now instead of spending 8 hours writing code, I spend 8 hours "steering" an AI to write the same code. What a fucking win (for the AI companies and no one else.)

by GiorgioG

3/26/2025 at 4:31:14 PM

Then don't

by woah

3/27/2025 at 12:48:07 AM

One thing that struck me after reading this article as well as all the comments here - we are providing excellent free training for the next generation of agents coming up. We are literally training our replacements!

Like others I agree humans are not getting replaced anytime soon though. For all the current hype current AI technology is pretty dumb. Give it a decade or so though and everything we are currently doing will seem like Stone Age technology.

Aside: sometimes I really wonder if humanity is trying to automate itself out of existence.

by kunzhi

3/27/2025 at 11:36:55 AM

[flagged]

by securemepro