I committed to the fully agentic approach for a while. No code by hand!
Setting aside the "capability" of the tools, I knew it was the wrong direction after a couple months or so in. I specifically remember during a large feature implementation running out of tokens for my 5 hour window or whatever, and I just couldn't continue on my own. Mostly due to laziness (I'll just wait till tomorrow when my limit resets!), but I also picked up on my first big whiff of skill rot / atrophy brewing, and that made feel uncomfortable.
I just don't see this fully agentic approach going well long term. Talk about the ultimate dependency!! If the lights are "turned off" for whatever reason - outages, cost increases, or the agentic velocity finally reaches a complexity tipping point and you've lost control and understanding of your system to the point the agents are making things worse, whatever it is - do you really expect to be able to turn back the clock and step in to code at the productivity level and output you used to when you actually... wrote code?
There's definitely skill rot that happens -- but there are also new skills to learn. Dependency on tools is not a new problem, though, is it?
Agents definitely run amok on code bases, create bloat, needless complexity, etc. However, they enable many people to do so much more than they could without them, at least in the moment, that they're not going to go away.
Yeah, I am also feeling the rot and do not like it one bit. However, the world does not revolve around my feelings, so I have adapted and fully embraced it. That being said, I think AI took away 90% of the enjoyment I got from the job of Software Engineer. It isn't just the code writing, it was the space to go deep and immerse myself fully to solve a problem. I think there is still a need to problem solve at different levels, but with AI the velocity has increased so much - the space to focus on one thing for any amount of time has also been drastically reduced (this could be because I work for a company and may be company specific. I also do freelance dev, and find much more enjoyment there, but still not the same as pre AI).
Yup. I have embraced LLM usage since it's obvious this genie is not going back in the bottle and they are objectively force-multipliers at certain tasks. But I didn't get into software engineering to be productive, I fell into this career because I loved building things and it just sort of evolved into a pretty lucrative hobby.
AI is completely sucking the enjoyment out of my work.
It's like they invented a robot that can build whatever you want out of Legos. You'll never have to touch your Legos again! /s
The problem I'm seeing is that most of that additional output is just increasing pressure on the real bottlenecks such as design, QA, operations, support, etc. Which is why we're seeing this dual phenomenon of programmer productivity increases at the same time as the productivity of the overall business crashes out.
At my last employer we were contending with real customer fatigue and attrition. The application was changing so rapidly that it was overwhelming both our ability to uphold quality standards, and customers' ability to keep up with the feature churn.
Or, to put it more succinctly: nobody actually wants all this slop.
> The bigger cost was the typing. Every time I wanted to build something, I could see the code in my head. I just couldn’t type it out fast enough.
Facts. For me the bigger the gap between what i saw in my head and the speed with which my fingers could physically make it a reality the more stress i would feel and some marathon coding sessions would end w my back all messed up just from the tension
Disclaimer: I'm an older dev out of the game. I could definitely see the bigger picture faster than I could type it (except for challenging tasks), but that typing time was also synergistic thinking time. Not unfrequently, I'd find a better design while writing the code. Even if it didn't make it into that codebase, it could be filed away for future reference.
Edit: I recall reading somewhere that John Carmack doesn't care about which editor he uses because typing was never the bottleneck. Admittedly, he worked on some really difficult problems.
This is part of what I don't understand about the new narrative. I agree in principle that yes, the mechanical act of writing code was always the real bottleneck. But people act like all you have to do is carefully plan everything out up front, double check it at the end, and bob's your uncle.
I always found that the act of chugging the code helped to refine my thoughts along the way, including the big picture of it all. I've adapted in that I still have agents do most of the heavy lifting of code writing. But it still requires me to be invested in the details, which can't happen at the scale people discuss when they're talking about full on agentic development.
Nice to hear others are feeling this too. I started using typing websites to improve my speed a few months ago. More recently I've noticed that I'm starting to make lots of typos and use sloppy language in general because AI still understands me. That can't be healthy in the long term.
Yes, but once you have the solution crystalized in your head do you not feel some frustration in not getting it implemented as soon as possible?
I often found myself impatient in getting something I knew would work to actually work, and it was always due to the tiresome fractal of complexities that any non-trivial task involves, like looking up an API or working around the quirks of some dependency.
On a related note, this is also why I find AI-assisted coding so efficient: I have the code visualized in my head to a decent level of detail, and so reviewing the AI's output is a breeze; it's like doing a semantic diff of what I had visualized and what it produced, and so any issues are glaring and easy to spot.
I start with the first word, then move on to the second and so forth, letting the overall idea of what I am reading in my mind grow as I get further and further
It really isn't that hard. The LLM needs a few iterations of self review, and you need to ask it for an architecture up front, but from there, it's mostly manual testing to make sure the LLM didn't fuck up.
I don't think it'd take more than a few weeks for a high schooler to learn how to prompt well.
Your hypothetical high schooler would have to learn what architecture is, and then what self review is, and iteration, and manual testing... and what "code" and "software" is first.
This is something devs don’t give enough credit. You may think you’re just promoting, but ask someone outside the field to prompt their way to a feature and you will see very clearly what your experience is bringing to the table.
Yeah, but train them for a month on how to get the AI to help them prompt, and they'll do fine. AIs are extremely effective at letting you offload skill, you just need to know how to ask. This should surprise nobody, since this is what they were and built for.
I genuinely don't think you need much training for creating code any more. It's not a high skilled profession.
If it takes them more than a few weeks to figure out "Review your own output with a clean context. Check it for bugs, performance, and places where it doesn't do what the user wants", I don't know what to say. And where are you finding high schoolers that don't know what software is?
Note, people don't typically need to understand the architecture documents that the LLMs generate, and will certainly be filling in the rest of the gaps as new models come out. The function of design docs is to make the LLM ask clarifying questions and fill in the constraints.
You can get more confidence by asking the LLM about when the architecture would be appropriate than by trying to intuit it yourself. The LLM is trained on so many more architectures and stories of how they panned out than you are.
The skill is really in manually testing before handoff.
I feel a really odd dissonance with all these accounts. I have access to top models via Cursor at work. Every time I think to myself, here’s a tedious but well defined task, with clear success criteria, where you can achieve a lot with persistent iterations. I’ll give it to Claude to do.
First, it takes me ages to describe the task properly. All these clear success criteria, well, instead of writing code from a clear spec in my head, I’m writing tons of prose, and trying to make it unambiguous. I’m programming in English++.
But then, one time in 5, it produces something that kinda works. Maybe not perfect but good enough. Two times out of 5 it kind of sort of looks alright, but actually ignores 80% of the spec, or pays it minimal lip service in the comments.
And sometimes, maybe a bit less than 2/5, it just completely diverges into total shit. Starts writing scripts that load the ast of the main script and pickle it then serialise to base64 for no good reason. Encode some stuff in strings then check ord(string[i]) repeatedly for string comparison. Eventually runs out of context and develops the LLM equivalent of severe dementia.
I truly cannot reconcile my experience with people who seem to say “hey computer write this” and it’s a good use of their time.
Take a step back and give it the essential functional requirements.
Or, consider what information is driving your extremely detailed instructions and give it the raw source if you can. Meeting transcripts, messy notes on some adhoc conversation, etc.
The more you try to micromanage it, the more impossible to work with it it is.
Of course not every situation calls for just giving it high level requirements. But not every situation calls for trying to define how everything is done yourself either.
Well, quite. Recently I gave it a database dump, and told it what the processed data looks like. Since the raw data was messy, there was a lot to explain.
I've found a more productive workflow is to ask claude how it would do the task, go back and forth with it a bit until you both agree on the steps, then have it work through them. i also emphasise the need to have every step in its own commit, then go back and read through the stack suggesting code improvements and refactoring, letting the AI do the tedious work of fixing conflicts and restacking. I'm usually pretty happy with the process and the end result.
This is similar to my experience when cursor first came out. But now it's even trickier because LLM actually writes working code that pass the test. The issue is when i dig in deeper, there's often small security or design issues that will cause problem down the road when the app gets more traffic.
These issues are usually in really tedious places that I didn't bother to describe what to do to the agent
> design issues that will cause problem down the road when the app gets more traffic.
Right but that is someone else's problem. Or if that's something you will be call upon to answer, "that's just LLM did" is a fine answer in most companies where AI use has been mandated.
Writing code used to be free, anyone could do it with enough patience and knowledge, but now you have to pay hundreds of dollars to do this kind of thing with agents. It seems the barrier to entry has gotten more expensive.
Unfortunate to see an otherwise-good article padded by AI-isms ("But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.", amongst other examples).
Maisem Ali writes about how they have not stopped engineering despite handing production of code over to AI. I think that's an interesting perspective for a few reasons, but most of all, I'm not sure I agree.
First, we see a prime example of how that can blow up. "botd died this month. It crumbled under its own weight." It's hard to imagine how an agent harness (or is it an overlay on top of other harnesses?) could crumble under its own weight from sheer technical complexity. What makes a tool like this "crumble"? If properly architected, it seems that any outside change could be adaptable. Failing tests could be fixed.
This AI coding evolution has given us the ability to spin up prototypes we don't understand the inner workings of, but I believe for anything of value (and, I would argue, botd appeared to have value to Maisem) we should at the very least understand and influence the architecture and engineering of what we're building. If Maisem had done that for botd, it would not and _could not_ have "crumbled under its own weight". Whatever outside influence required change within botd would have been manageable.
Second, the off-loading of the production of this article indicates to me a lack of respect (with no offence to Maisem, because this is what much of the industry is doing today) for the value in thinking through the writing process. There's a lot that I've learned personally about software I worked on that only came to me through trying to write explainers. Taking a step back from the software we build and looking at it from a birds-eye view, to share how it is constructed or how to use it, helps develop our understanding.
Maisem's article is already very good, and I hope that is demonstrative of their own writing! I would read more! But I want to read words written by a person for other people. AI can help edit, it can help us build ideas, but in code and in our written word, AI should not be _the author_.
I've been a software dev for 25 years. In the past year I've hand written maybe 10 lines of code. For the first 2-3 months i would read it, then I figured out how to really use AI/code gen and the amount created was more than I could read. I can work on 2-3 projects at once, or 2-3 parts of a larger project at once. More than that I can't keep task switching. The speed and complexity of what I'm able to create is 10x doing it by hand. In the hands of someone that understands system design it's a great tool, but still need fundamentals. I've seen junior's build stuff that would never deploy and would crash with a handful of users.
I think you will always need a button pusher. whether it is the CEO, the product manager or the developer themselves. You will need some sort of overseer who will take accountability of the system that is generated by the AI.
Okay. Is that job going to provide a competitive salary, with good benefits? More importantly, is it going to be personally fulfilling?
Software developers who have adopted agentic coding are worse than class traitors. They are actively sabotaging the entire careers future viability, and have made me ashamed to think anyone in this industry was worthy of the title "engineer".
"Compositors who have adopted Linotype machines are worse than class traitors. They are actively sabotaging the entire trade’s future viability, and have made me ashamed to think anyone in this industry was worthy of the title “printer.”"
"Weavers who have agreed to tend a fourth loom are worse than class traitors. They are actively sabotaging the entire trade’s future viability, and have made me ashamed to think anyone in this industry was worthy of the title “weaver.”"
"Handloom weavers who have adopted power looms are worse than class traitors. They are actively sabotaging the entire trade’s future viability, and have made me ashamed to think anyone in this industry was worthy of the title “weaver.”"
> AI agents are just software, after all. I wasn’t going to understand them by reading prompt guides. I had to use them for real work, see where they failed, change the prompts, tools, or environment, and try again.
AI agents are just software, so the only way to understand them is trial and error?
Tried and true approach. Sometimes the only way to proceed if you are dealing with - embedded devices, protocols, long and deep stacktraces or freecad.
I think that's similarly in line with software; you don't really know the limitations of a library until you use it, and see that it fails for X reason at 10Hz, or 1000Hz.
> Instead of waiting, I spun up another agent to do something else. Then I did it again.
> I wasn’t intentionally building a parallel system. I was just filling the time between tasks. I have ADHD. I got distracted.
I probably have ADD or ADHD and this feels "great" at first b/c you can just jump back and forth between 2-4 agents as they need input from you.
But I noticed:
1. I was EXHAUSTED at the end of the day
2. A lot of what each agent was doing I could do faster myself. Yes, if I do 10 units of work and 4 agents do 3 units then it's faster. That being said, sometimes all of the agents pick the dumb/slow path and now it's 4 agents times -2 units
> Having other agents review the code worked surprisingly well. They occasionally caught real bugs, and it was cheap enough to run several reviews. But I couldn’t merge something just because the agents approved it. I still had to understand the change. I was still responsible for the code that got merged.
My personal opinion is that LLMs have:
- 5x increase in triaging/debugging b/c they can read code WAY faster and make connections really quickly
- 2-3x writing code if you ALREADY have great, rock solid unit tests etc
- -1x to 1.5x improvement in writing greenfield code where you have no tests
That last one is b/c you are never 100% sure that the test is doing what you expected or the LLM is "hacking the test" (unless you REALLY read the code).
I think this disparity in performance across different sub-domains of being a SWE/SRE is why you get so many different opinions on LLMs
I’m m just starting to get results on a local/cloud agent pipeline I’ve been building. I don’t think I will ever code again. Plan, review, read, architect, test, yes. Code though simply doesn’t make sense when I’m getting these results at this velocity.
Every few months it feels like I have moved further up the chain. Now I don’t even look at a PR until it’s been coded and gone through at least 2 AI reviews (always different families). Code is truly cheap. I can have the pipeline produce an entire feature as a thought experiment just to see if the shape is the right fit for the codebase. People like to throw the slop term around a lot. It feels like the opposite of slop through. I can have things written and rewritten as many times as it takes until I’m happy with them.
The weakness I see in this is there at the end. The agents never want to throw things away. They just want to keep adding and adding. I think this is my real value in the chain. That intuition built up over years that says this isn’t right yet or that little tingle in your brain that you’ve laid a landline that you are going to step on in 6 months.
It's a mindset shift from producing code to producing a product. You may look at the code and see slop but look at the product and see value.
This should be extremely intuitive. We know this already. There has always been a divergence between product value and code quality. How many codebases that are widely used are kind of a mess inside? Pretty much all of them to some degree. This is a basic reality of software engineering. Conversely a useless product could have the cleanest code in the world.
Some slop accusations are fair. Others are people essentially expressing that they dont like shifting to a product mindset.
I dont have your whole pipeline but I recently took a step back and thought about how amazing the AI is. I recently gave Fable a nice, simple open source TUI app with some Claude Design artifacts for a UI/UX facelift + some new complex feature requests and it just one shots the entire thing in 20 minutes. It works great and looks amazing. It's significantly better in terms of UX and functionality than the original. I did this on the side with about 15 minutes of active attention while I was working.
I have stopped reading blog posts for 6 months now! Since Fable-1337-B4242 agents became so good at reading that I delegated this load-bearing task. Once I became weak and read a paragraph, but I was reminded that reading is too laborious.
After reading this blog post for me, Fable-1337-B4242 asked me if I also wanted to create a load-bearing plain text website like exe.dev using agentic forces.
I honestly didn't read the whole article, but I think that this kind of experiment leads to a misleading way of seeing things.
I met a few architects/team leaders who wouldn't write almost any code and just technically oversaw things before LLMs got popular, obviously they were very experiencied.
What you have to ask yourself is whether you could oversee a swarm of bots(or people) if you didn't have any coding experience in the first place.
A lot of HN users seem to be, in my opinion, too dismissive about the complexity of creating software. It's true that we don't have to develop in assembly anymore to be a good developer and with time the general level of the entry abstractions that we deal with rises, but, in my opinion once again, it will never change the fact that you need a high number of hours of exposure to something in order to be truly competent to a professional level.
>AI agents are just software, after all. I wasn’t going to understand them by reading prompt guides. I had to use them for real work, see where they failed, change the prompts, tools, or environment, and try again.
It seems that all this knowledge would be useless with a model update...Good for the AI companies though. More tokens as users like this come upto speed with the new models, which they now are totally dependent on...
Because, if you didn't like writing code, and is now used to agents writing code, good luck going back to writing code by hand...
It’s more AI copypasta as it goes further along where it gets really into the how and not the why.
“But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.”
If I had more time, I would have written a shorter letter…
I don't understand people that say "I no longer code" as a good thing. I think it's safe to assume that if you studied computer science or similar you like to code. If not, why did you even study that?
To me it just feels like you want to be a manager not an engineer
This is like if a plumber said. I no longer do any construction, I just tell people what to do. Then you probably aren't a builder anymore, you are a foreman or a project manager.
I think your job as an engineer is to know the codebase and how it was engineered
I like to make computers do the things I want. Since I was a kid, the satisfaction from programming or any sort of "computer engineering" (using the word engineering VERY loosely here) is in making something specific happen.
Sometimes, that means understanding the correct data structure to use, picking the right algorithm, and other computer science-y things.
Other times, and more often (for me), it means death by a thousand papercuts in managing third party dependencies, boilerplate, and other tedium and minutia.
I'm not someone who is "proud" of barely coding anymore, and I'm not entirely sure how I feel about the "structural soundness" of using LLMs this way (most of my coding is personal/hobbyist work), but I can confidently say that I don't really code just because I love coding, at least necessarily. I like making stuff.
What do you mean "solve problems"? Everyone solves problems at their job. A CEO solves problems, same for a salesman.
But if you have been hired to a position that requires reading and writing assembly, then I would hope that anyone applying likes to do specifically that. I don't want to solve problems at the manager level, I want to solve problems that require coding
Some of us like the details. Bricklayers are not subhuman! You architect if you want, or manage which is what agentic <whatever> seems like to me, I'm sticking to coding until I can't any more (or get properly sick of it all, which is likely to come first given everything is getting both more and more remote and more drowned in AI and I want neither) then I'm doing something completely different because I don't want to manage (people or agents).
There is the level of understanding of the concept of a Quicksort function, how it works, when to use it.
And then there is the level of understanding gained of opening up an editor and trying to write a Quicksort function in Go or C++ or Python or whatever.
I wouldn't consider the latter to be "laying bricks".
No, but architects can’t just make the plans and never look at the output, there needs to be someone that checks that the work is done properly and fit to spec.
>"This is like if a plumber said. I no longer do any construction, I just tell people what to do."
I'm pretty sure that's the dream goal of any plumber. No one "plumbs for fun". No one wants to truly do the actual thing, they want the money that allows them to do whatever they want. It's just that doing the actual thing is the only way you can get the money at first. And being good at doing the actual thing and enjoying doing the actual thing makes doing the actual thing bareable or even fun while reaching your actual goal (the money). As soon as you can free yourself from that you will.
Some people like doing DIY plumbing and related tasks around their own homes. Work might not be "fun" in the traditional sense, but it can be satisfying to build and fix things.
This is just wrong. A lot of people take tremendous pride in their work. Particularly highly-skilled people who have been doing the work for a long time.
Joe Biden used to say this all the time - that a job is more than a paycheck, it's an identity and a sense of purpose, often a big part of our social lives as well. Or if you prefer the other side, Trump likes to say that coal miners don't want to learn computers, they want their coal mining jobs back.
I also haven't written more than a couple lines of code in months, but I definitely do read the code. You have to, or at least provide lots of Claude Rules to help steer it. AI has too many bad coding practices by default. But you don't need to modify lines of code by hand, you can just tell it what to fix.
I'm predicting a Docker for AI Coding. There really is a ton of stuff you need to set up to do AI coding/vibe coding in a way that's safe, has good results, and is fast. You don't just need a dev environment, you need a whole SDLC; codified good engineering decisions, test framework, credential management, an interactive UI and notifications, guardrails, a "waterfall" of progressive design/build/test, context management, and much more. It's too much for people to put together themselves without tons of time and experimentation. Same as containers, which is why Docker came about: to let an end user do complex things in an easy way.
AI coding is like a self-driving car. Making the car move is easy; making it get you to the destination you want safely is very hard.
> There is no one answer to agentic engineering. Everyone works differently; every model is good at different things. The key here is reps: do a lot, ask a lot, throw away a lot. You’ll learn what works for you.
That all reads to me like: The key here is: "Burn tokens as money in a bonfire, pray you typed in the right magic spell (prompt) and the ingredients (context) in the potion were right, toss away the failed elixir of life".
Instead of writing code and refactoring yourself and gaining an understanding, you're hoping that a slot machine will get luckily get the statistics right to put up code that you already need to read again.
> It’s the same loop that taught me to code, moved up a level: write, run, fail, fix. I used to iterate on code. Now I iterate on prompts, designs, whole features. A rewrite that used to cost a week costs a conversation.
And also costs you skills atrophy and however much tokens will be. Not to mention the negative externalities of using LLMs (massive increase of fraud, of disinformation, of rocketing prices in memory and in turn all electronics, massive use of energy that consumers have to also then pay extra for, environmental and noise cost of using on-site turbines, local destruction of water resources for the local community).
I committed to the fully agentic approach for a while. No code by hand!
Setting aside the "capability" of the tools, I knew it was the wrong direction after a couple months or so in. I specifically remember during a large feature implementation running out of tokens for my 5 hour window or whatever, and I just couldn't continue on my own. Mostly due to laziness (I'll just wait till tomorrow when my limit resets!), but I also picked up on my first big whiff of skill rot / atrophy brewing, and that made feel uncomfortable.
I just don't see this fully agentic approach going well long term. Talk about the ultimate dependency!! If the lights are "turned off" for whatever reason - outages, cost increases, or the agentic velocity finally reaches a complexity tipping point and you've lost control and understanding of your system to the point the agents are making things worse, whatever it is - do you really expect to be able to turn back the clock and step in to code at the productivity level and output you used to when you actually... wrote code?
There's definitely skill rot that happens -- but there are also new skills to learn. Dependency on tools is not a new problem, though, is it?
Agents definitely run amok on code bases, create bloat, needless complexity, etc. However, they enable many people to do so much more than they could without them, at least in the moment, that they're not going to go away.
Yeah, I am also feeling the rot and do not like it one bit. However, the world does not revolve around my feelings, so I have adapted and fully embraced it. That being said, I think AI took away 90% of the enjoyment I got from the job of Software Engineer. It isn't just the code writing, it was the space to go deep and immerse myself fully to solve a problem. I think there is still a need to problem solve at different levels, but with AI the velocity has increased so much - the space to focus on one thing for any amount of time has also been drastically reduced (this could be because I work for a company and may be company specific. I also do freelance dev, and find much more enjoyment there, but still not the same as pre AI).
Yup. I have embraced LLM usage since it's obvious this genie is not going back in the bottle and they are objectively force-multipliers at certain tasks. But I didn't get into software engineering to be productive, I fell into this career because I loved building things and it just sort of evolved into a pretty lucrative hobby.
AI is completely sucking the enjoyment out of my work.
It's like they invented a robot that can build whatever you want out of Legos. You'll never have to touch your Legos again! /s
The problem I'm seeing is that most of that additional output is just increasing pressure on the real bottlenecks such as design, QA, operations, support, etc. Which is why we're seeing this dual phenomenon of programmer productivity increases at the same time as the productivity of the overall business crashes out.
At my last employer we were contending with real customer fatigue and attrition. The application was changing so rapidly that it was overwhelming both our ability to uphold quality standards, and customers' ability to keep up with the feature churn.
Or, to put it more succinctly: nobody actually wants all this slop.
> The bigger cost was the typing. Every time I wanted to build something, I could see the code in my head. I just couldn’t type it out fast enough.
Facts. For me the bigger the gap between what i saw in my head and the speed with which my fingers could physically make it a reality the more stress i would feel and some marathon coding sessions would end w my back all messed up just from the tension
Disclaimer: I'm an older dev out of the game. I could definitely see the bigger picture faster than I could type it (except for challenging tasks), but that typing time was also synergistic thinking time. Not unfrequently, I'd find a better design while writing the code. Even if it didn't make it into that codebase, it could be filed away for future reference.
Edit: I recall reading somewhere that John Carmack doesn't care about which editor he uses because typing was never the bottleneck. Admittedly, he worked on some really difficult problems.
This is part of what I don't understand about the new narrative. I agree in principle that yes, the mechanical act of writing code was always the real bottleneck. But people act like all you have to do is carefully plan everything out up front, double check it at the end, and bob's your uncle.
I always found that the act of chugging the code helped to refine my thoughts along the way, including the big picture of it all. I've adapted in that I still have agents do most of the heavy lifting of code writing. But it still requires me to be invested in the details, which can't happen at the scale people discuss when they're talking about full on agentic development.
Nice to hear others are feeling this too. I started using typing websites to improve my speed a few months ago. More recently I've noticed that I'm starting to make lots of typos and use sloppy language in general because AI still understands me. That can't be healthy in the long term.
I got this way with google (when it was still good) - what nonsense can I type and still get the right result - 99% of the time it would work.
Typing it was never the work.
The research, the understanding, the planning, the design, all of it's iterations, the testing, all of it's iterations, debugging etc.
'I see the code and need to get it down' is a key thing obviously but a smaller part.
With better abstractions, we'll be putting 'architectural ideas' in our head, instead of algorithmic.
Yay!!! There are people like me in this world. :-)
I've heard this reported, but it's hard to imagine it. The biggest bottleneck for me has always been hammock time[1].
1. https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
Yes, but once you have the solution crystalized in your head do you not feel some frustration in not getting it implemented as soon as possible?
I often found myself impatient in getting something I knew would work to actually work, and it was always due to the tiresome fractal of complexities that any non-trivial task involves, like looking up an API or working around the quirks of some dependency.
On a related note, this is also why I find AI-assisted coding so efficient: I have the code visualized in my head to a decent level of detail, and so reviewing the AI's output is a breeze; it's like doing a semantic diff of what I had visualized and what it produced, and so any issues are glaring and easy to spot.
How do people read these types of post with this AI flair, I couldn't read more than a couple sentences
I start with the first word, then move on to the second and so forth, letting the overall idea of what I am reading in my mind grow as I get further and further
And before LLMs he would have slapped together a twenty-line bash script and a cron job over lunch, and spent six months working on something else.
Writing code with LLMs takes discipline and is difficult. You need to learn how to do it and how to get the best from it.
Software engineering is dead, long live software engineering!
It really isn't that hard. The LLM needs a few iterations of self review, and you need to ask it for an architecture up front, but from there, it's mostly manual testing to make sure the LLM didn't fuck up.
I don't think it'd take more than a few weeks for a high schooler to learn how to prompt well.
Your hypothetical high schooler would have to learn what architecture is, and then what self review is, and iteration, and manual testing... and what "code" and "software" is first.
This is something devs don’t give enough credit. You may think you’re just promoting, but ask someone outside the field to prompt their way to a feature and you will see very clearly what your experience is bringing to the table.
Yeah, but train them for a month on how to get the AI to help them prompt, and they'll do fine. AIs are extremely effective at letting you offload skill, you just need to know how to ask. This should surprise nobody, since this is what they were and built for.
I genuinely don't think you need much training for creating code any more. It's not a high skilled profession.
If it takes them more than a few weeks to figure out "Review your own output with a clean context. Check it for bugs, performance, and places where it doesn't do what the user wants", I don't know what to say. And where are you finding high schoolers that don't know what software is?
Note, people don't typically need to understand the architecture documents that the LLMs generate, and will certainly be filling in the rest of the gaps as new models come out. The function of design docs is to make the LLM ask clarifying questions and fill in the constraints.
Maybe - but I would argue that the skill comes in knowing if the architecture is appropriate and knowing that LLM is not screwing it up.
You can get more confidence by asking the LLM about when the architecture would be appropriate than by trying to intuit it yourself. The LLM is trained on so many more architectures and stories of how they panned out than you are.
The skill is really in manually testing before handoff.
I feel a really odd dissonance with all these accounts. I have access to top models via Cursor at work. Every time I think to myself, here’s a tedious but well defined task, with clear success criteria, where you can achieve a lot with persistent iterations. I’ll give it to Claude to do.
First, it takes me ages to describe the task properly. All these clear success criteria, well, instead of writing code from a clear spec in my head, I’m writing tons of prose, and trying to make it unambiguous. I’m programming in English++.
But then, one time in 5, it produces something that kinda works. Maybe not perfect but good enough. Two times out of 5 it kind of sort of looks alright, but actually ignores 80% of the spec, or pays it minimal lip service in the comments.
And sometimes, maybe a bit less than 2/5, it just completely diverges into total shit. Starts writing scripts that load the ast of the main script and pickle it then serialise to base64 for no good reason. Encode some stuff in strings then check ord(string[i]) repeatedly for string comparison. Eventually runs out of context and develops the LLM equivalent of severe dementia.
I truly cannot reconcile my experience with people who seem to say “hey computer write this” and it’s a good use of their time.
Take a step back and give it the essential functional requirements.
Or, consider what information is driving your extremely detailed instructions and give it the raw source if you can. Meeting transcripts, messy notes on some adhoc conversation, etc.
The more you try to micromanage it, the more impossible to work with it it is.
Of course not every situation calls for just giving it high level requirements. But not every situation calls for trying to define how everything is done yourself either.
Well, quite. Recently I gave it a database dump, and told it what the processed data looks like. Since the raw data was messy, there was a lot to explain.
It didn’t go well.
I've found a more productive workflow is to ask claude how it would do the task, go back and forth with it a bit until you both agree on the steps, then have it work through them. i also emphasise the need to have every step in its own commit, then go back and read through the stack suggesting code improvements and refactoring, letting the AI do the tedious work of fixing conflicts and restacking. I'm usually pretty happy with the process and the end result.
Yea it honestly feels like a typical meeting with colleagues, without company politics
This is similar to my experience when cursor first came out. But now it's even trickier because LLM actually writes working code that pass the test. The issue is when i dig in deeper, there's often small security or design issues that will cause problem down the road when the app gets more traffic.
These issues are usually in really tedious places that I didn't bother to describe what to do to the agent
> design issues that will cause problem down the road when the app gets more traffic.
Right but that is someone else's problem. Or if that's something you will be call upon to answer, "that's just LLM did" is a fine answer in most companies where AI use has been mandated.
[dead]
Writing code used to be free, anyone could do it with enough patience and knowledge, but now you have to pay hundreds of dollars to do this kind of thing with agents. It seems the barrier to entry has gotten more expensive.
It's still free to write code...
e.g. I can ride a bike for free compared to driving a car where I have to pay for gas.
And their are pros and cons to both.
e.g. bikes are easier to park but not great in bad weather and vice versa
Unfortunate to see an otherwise-good article padded by AI-isms ("But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.", amongst other examples).
Maisem Ali writes about how they have not stopped engineering despite handing production of code over to AI. I think that's an interesting perspective for a few reasons, but most of all, I'm not sure I agree.
First, we see a prime example of how that can blow up. "botd died this month. It crumbled under its own weight." It's hard to imagine how an agent harness (or is it an overlay on top of other harnesses?) could crumble under its own weight from sheer technical complexity. What makes a tool like this "crumble"? If properly architected, it seems that any outside change could be adaptable. Failing tests could be fixed.
This AI coding evolution has given us the ability to spin up prototypes we don't understand the inner workings of, but I believe for anything of value (and, I would argue, botd appeared to have value to Maisem) we should at the very least understand and influence the architecture and engineering of what we're building. If Maisem had done that for botd, it would not and _could not_ have "crumbled under its own weight". Whatever outside influence required change within botd would have been manageable.
Second, the off-loading of the production of this article indicates to me a lack of respect (with no offence to Maisem, because this is what much of the industry is doing today) for the value in thinking through the writing process. There's a lot that I've learned personally about software I worked on that only came to me through trying to write explainers. Taking a step back from the software we build and looking at it from a birds-eye view, to share how it is constructed or how to use it, helps develop our understanding.
Maisem's article is already very good, and I hope that is demonstrative of their own writing! I would read more! But I want to read words written by a person for other people. AI can help edit, it can help us build ideas, but in code and in our written word, AI should not be _the author_.
Don't bother with complexity metrics just use claude code to work on a code base with high coupling and low cohesion.
I've been a software dev for 25 years. In the past year I've hand written maybe 10 lines of code. For the first 2-3 months i would read it, then I figured out how to really use AI/code gen and the amount created was more than I could read. I can work on 2-3 projects at once, or 2-3 parts of a larger project at once. More than that I can't keep task switching. The speed and complexity of what I'm able to create is 10x doing it by hand. In the hands of someone that understands system design it's a great tool, but still need fundamentals. I've seen junior's build stuff that would never deploy and would crash with a handful of users.
I'm not sure how you can be confident the things "you" built won't crash if you're not at least scanning the code that you're generating.
human written code also has bugs and crashes…
>For the first 2-3 months i would read it, then I figured out how to really use AI/code gen and the amount created was more than I could read
You serve no purpose here. The AI will soon be able to prompt itself, and it will be better at system design than you.
Good job at making yourself redundant.
I think you will always need a button pusher. whether it is the CEO, the product manager or the developer themselves. You will need some sort of overseer who will take accountability of the system that is generated by the AI.
>I think you will always need a button pusher.
Okay. Is that job going to provide a competitive salary, with good benefits? More importantly, is it going to be personally fulfilling?
Software developers who have adopted agentic coding are worse than class traitors. They are actively sabotaging the entire careers future viability, and have made me ashamed to think anyone in this industry was worthy of the title "engineer".
"Compositors who have adopted Linotype machines are worse than class traitors. They are actively sabotaging the entire trade’s future viability, and have made me ashamed to think anyone in this industry was worthy of the title “printer.”"
"Weavers who have agreed to tend a fourth loom are worse than class traitors. They are actively sabotaging the entire trade’s future viability, and have made me ashamed to think anyone in this industry was worthy of the title “weaver.”"
"Handloom weavers who have adopted power looms are worse than class traitors. They are actively sabotaging the entire trade’s future viability, and have made me ashamed to think anyone in this industry was worthy of the title “weaver.”"
Tale as old as time.
Do you follow / use a specific framework? Or just ad-hoc prompts?
> AI agents are just software, after all. I wasn’t going to understand them by reading prompt guides. I had to use them for real work, see where they failed, change the prompts, tools, or environment, and try again.
AI agents are just software, so the only way to understand them is trial and error?
Building understanding through use, as opposed to reading, is not a controversial idea.
Tried and true approach. Sometimes the only way to proceed if you are dealing with - embedded devices, protocols, long and deep stacktraces or freecad.
I think that's similarly in line with software; you don't really know the limitations of a library until you use it, and see that it fails for X reason at 10Hz, or 1000Hz.
Couple points:
> Instead of waiting, I spun up another agent to do something else. Then I did it again.
> I wasn’t intentionally building a parallel system. I was just filling the time between tasks. I have ADHD. I got distracted.
I probably have ADD or ADHD and this feels "great" at first b/c you can just jump back and forth between 2-4 agents as they need input from you.
But I noticed:
1. I was EXHAUSTED at the end of the day
2. A lot of what each agent was doing I could do faster myself. Yes, if I do 10 units of work and 4 agents do 3 units then it's faster. That being said, sometimes all of the agents pick the dumb/slow path and now it's 4 agents times -2 units
> Having other agents review the code worked surprisingly well. They occasionally caught real bugs, and it was cheap enough to run several reviews. But I couldn’t merge something just because the agents approved it. I still had to understand the change. I was still responsible for the code that got merged.
My personal opinion is that LLMs have:
- 5x increase in triaging/debugging b/c they can read code WAY faster and make connections really quickly
- 2-3x writing code if you ALREADY have great, rock solid unit tests etc
- -1x to 1.5x improvement in writing greenfield code where you have no tests
That last one is b/c you are never 100% sure that the test is doing what you expected or the LLM is "hacking the test" (unless you REALLY read the code).
I think this disparity in performance across different sub-domains of being a SWE/SRE is why you get so many different opinions on LLMs
I’m m just starting to get results on a local/cloud agent pipeline I’ve been building. I don’t think I will ever code again. Plan, review, read, architect, test, yes. Code though simply doesn’t make sense when I’m getting these results at this velocity.
Every few months it feels like I have moved further up the chain. Now I don’t even look at a PR until it’s been coded and gone through at least 2 AI reviews (always different families). Code is truly cheap. I can have the pipeline produce an entire feature as a thought experiment just to see if the shape is the right fit for the codebase. People like to throw the slop term around a lot. It feels like the opposite of slop through. I can have things written and rewritten as many times as it takes until I’m happy with them.
The weakness I see in this is there at the end. The agents never want to throw things away. They just want to keep adding and adding. I think this is my real value in the chain. That intuition built up over years that says this isn’t right yet or that little tingle in your brain that you’ve laid a landline that you are going to step on in 6 months.
It's a mindset shift from producing code to producing a product. You may look at the code and see slop but look at the product and see value.
This should be extremely intuitive. We know this already. There has always been a divergence between product value and code quality. How many codebases that are widely used are kind of a mess inside? Pretty much all of them to some degree. This is a basic reality of software engineering. Conversely a useless product could have the cleanest code in the world.
Some slop accusations are fair. Others are people essentially expressing that they dont like shifting to a product mindset.
I dont have your whole pipeline but I recently took a step back and thought about how amazing the AI is. I recently gave Fable a nice, simple open source TUI app with some Claude Design artifacts for a UI/UX facelift + some new complex feature requests and it just one shots the entire thing in 20 minutes. It works great and looks amazing. It's significantly better in terms of UX and functionality than the original. I did this on the side with about 15 minutes of active attention while I was working.
I have stopped reading blog posts for 6 months now! Since Fable-1337-B4242 agents became so good at reading that I delegated this load-bearing task. Once I became weak and read a paragraph, but I was reminded that reading is too laborious.
After reading this blog post for me, Fable-1337-B4242 asked me if I also wanted to create a load-bearing plain text website like exe.dev using agentic forces.
I hope you said yes
I honestly didn't read the whole article, but I think that this kind of experiment leads to a misleading way of seeing things.
I met a few architects/team leaders who wouldn't write almost any code and just technically oversaw things before LLMs got popular, obviously they were very experiencied.
What you have to ask yourself is whether you could oversee a swarm of bots(or people) if you didn't have any coding experience in the first place.
A lot of HN users seem to be, in my opinion, too dismissive about the complexity of creating software. It's true that we don't have to develop in assembly anymore to be a good developer and with time the general level of the entry abstractions that we deal with rises, but, in my opinion once again, it will never change the fact that you need a high number of hours of exposure to something in order to be truly competent to a professional level.
>AI agents are just software, after all. I wasn’t going to understand them by reading prompt guides. I had to use them for real work, see where they failed, change the prompts, tools, or environment, and try again.
It seems that all this knowledge would be useless with a model update...Good for the AI companies though. More tokens as users like this come upto speed with the new models, which they now are totally dependent on...
Because, if you didn't like writing code, and is now used to agents writing code, good luck going back to writing code by hand...
The author also has agents write their blog posts.
The writing style really seems to rub off onto people after a while, eh.
It’s more AI copypasta as it goes further along where it gets really into the how and not the why.
“But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.”
If I had more time, I would have written a shorter letter…
I don't understand people that say "I no longer code" as a good thing. I think it's safe to assume that if you studied computer science or similar you like to code. If not, why did you even study that?
To me it just feels like you want to be a manager not an engineer
This is like if a plumber said. I no longer do any construction, I just tell people what to do. Then you probably aren't a builder anymore, you are a foreman or a project manager.
I think your job as an engineer is to know the codebase and how it was engineered
> If not, why did you even study that?
I like to make computers do the things I want. Since I was a kid, the satisfaction from programming or any sort of "computer engineering" (using the word engineering VERY loosely here) is in making something specific happen.
Sometimes, that means understanding the correct data structure to use, picking the right algorithm, and other computer science-y things.
Other times, and more often (for me), it means death by a thousand papercuts in managing third party dependencies, boilerplate, and other tedium and minutia.
I'm not someone who is "proud" of barely coding anymore, and I'm not entirely sure how I feel about the "structural soundness" of using LLMs this way (most of my coding is personal/hobbyist work), but I can confidently say that I don't really code just because I love coding, at least necessarily. I like making stuff.
> To me it just feels like you want to be a manager not an engineer
A manager has access to a larger, sloppier, and more powerful API than an engineer.
It’s like saying “I no longer read or write assembly”; you are still solving problems but you are able to work in a higher level space to do it.
What do you mean "solve problems"? Everyone solves problems at their job. A CEO solves problems, same for a salesman.
But if you have been hired to a position that requires reading and writing assembly, then I would hope that anyone applying likes to do specifically that. I don't want to solve problems at the manager level, I want to solve problems that require coding
Do architects have to like laying bricks?
Some of us like the details. Bricklayers are not subhuman! You architect if you want, or manage which is what agentic <whatever> seems like to me, I'm sticking to coding until I can't any more (or get properly sick of it all, which is likely to come first given everything is getting both more and more remote and more drowned in AI and I want neither) then I'm doing something completely different because I don't want to manage (people or agents).
There is the level of understanding of the concept of a Quicksort function, how it works, when to use it.
And then there is the level of understanding gained of opening up an editor and trying to write a Quicksort function in Go or C++ or Python or whatever.
I wouldn't consider the latter to be "laying bricks".
No, but architects can’t just make the plans and never look at the output, there needs to be someone that checks that the work is done properly and fit to spec.
Careful, LEGO style bricks were initially a product intended for professional architects. =3
Do architects start as construction workers? It's a completely different career. That's my point. OP should have studied to be a manager
>"This is like if a plumber said. I no longer do any construction, I just tell people what to do."
I'm pretty sure that's the dream goal of any plumber. No one "plumbs for fun". No one wants to truly do the actual thing, they want the money that allows them to do whatever they want. It's just that doing the actual thing is the only way you can get the money at first. And being good at doing the actual thing and enjoying doing the actual thing makes doing the actual thing bareable or even fun while reaching your actual goal (the money). As soon as you can free yourself from that you will.
Some people like doing DIY plumbing and related tasks around their own homes. Work might not be "fun" in the traditional sense, but it can be satisfying to build and fix things.
That’s also true of coding. There’s nothing that sucks the fun of it as effectively as doing it for pay.
This is just wrong. A lot of people take tremendous pride in their work. Particularly highly-skilled people who have been doing the work for a long time.
Joe Biden used to say this all the time - that a job is more than a paycheck, it's an identity and a sense of purpose, often a big part of our social lives as well. Or if you prefer the other side, Trump likes to say that coal miners don't want to learn computers, they want their coal mining jobs back.
ai;dr
Can we stop posting obviously slop articles? If you can't make the effort to write the article, I'm not going to make the effort to read it.
slop post about slop code
He closed his laptop. The work kept going.
Here's the thing, and it's a big one, the work kept going.
I also haven't written more than a couple lines of code in months, but I definitely do read the code. You have to, or at least provide lots of Claude Rules to help steer it. AI has too many bad coding practices by default. But you don't need to modify lines of code by hand, you can just tell it what to fix.
I'm predicting a Docker for AI Coding. There really is a ton of stuff you need to set up to do AI coding/vibe coding in a way that's safe, has good results, and is fast. You don't just need a dev environment, you need a whole SDLC; codified good engineering decisions, test framework, credential management, an interactive UI and notifications, guardrails, a "waterfall" of progressive design/build/test, context management, and much more. It's too much for people to put together themselves without tons of time and experimentation. Same as containers, which is why Docker came about: to let an end user do complex things in an easy way.
AI coding is like a self-driving car. Making the car move is easy; making it get you to the destination you want safely is very hard.
> There is no one answer to agentic engineering. Everyone works differently; every model is good at different things. The key here is reps: do a lot, ask a lot, throw away a lot. You’ll learn what works for you.
That all reads to me like: The key here is: "Burn tokens as money in a bonfire, pray you typed in the right magic spell (prompt) and the ingredients (context) in the potion were right, toss away the failed elixir of life".
Instead of writing code and refactoring yourself and gaining an understanding, you're hoping that a slot machine will get luckily get the statistics right to put up code that you already need to read again.
> It’s the same loop that taught me to code, moved up a level: write, run, fail, fix. I used to iterate on code. Now I iterate on prompts, designs, whole features. A rewrite that used to cost a week costs a conversation.
And also costs you skills atrophy and however much tokens will be. Not to mention the negative externalities of using LLMs (massive increase of fraud, of disinformation, of rocketing prices in memory and in turn all electronics, massive use of energy that consumers have to also then pay extra for, environmental and noise cost of using on-site turbines, local destruction of water resources for the local community).
[flagged]
[flagged]
[dead]