Around the time GPT-4 was released in early 2023, a similar issue arose with another profession: translation. It was at that point that machine translation between languages like English and Japanese (the language pair I have worked with) started to approach human level for the first time.
I took part in a lot of discussions then with other professional translators, and the reaction of many was similar to that of some of the commenters here: not only were they discouraged because their hard-earned language and translation skills no longer seemed needed, but using LLMs as assistants took the enjoyable challenge out of the translation process.
Nearly everyone I spoke with then worked from home as a freelancer, carefully crafting one translation at a time. They didn’t like the idea of becoming managers of large-scale translation projects, even if it meant they would be able to apply their higher-order intercultural communication skills.
I do only a little professional translation myself now, but I try to keep up with AI developments and I often use translation tasks to test the latest models and frameworks. Over the past few months, I have vibe-coded some multi-LLM translation systems where texts were passed through multiple models that checked, critiqued, and improved each other’s translations. For the texts I tried them on, the results were much better than any single-LLM translation, approaching the level of the very best human translation. The API calls weren’t cheap, but for high-stakes translations such a system would more than pay for itself.
When designing that “vibe translation” system, I did apply my experience as a translator, similarly to what Simon is recommending programmers do now with vibe engineering. At this stage in my life (I’m sixty-eight), I am fine with that. But if LLMs had arrived when I was, say, just five or ten years into my translation career and still proud of my nuts-and-bolts skills, I might very well have looked for another career rather than becoming a vibe translator.
Translation is great to discuss LLMs. Thanks for sharing your experience.
On one side translation is not very valued by most people. It is rare that people know who translated a book, for example. It is a pity but people do not read much these days.
Additionally, or maybe because of the above, translation is often paid in terms of number of lines or words, even before AI. A bit like software security, it is often sadly just a check at the end.
IMHO the only future-proof translation fields are legal (because a human can be put in prison or pay a fine) or live translation/interpretation (because a human can go in front of people, meet them at an event, etc.).
I spoke with some professional translators early on and they were just in denial, getting even upset at the idea that an AI could replace them. I didn't push too much but felt bad for them, as they couldn't realize what was going to happen to their field. I really think that translation must be the most impacted field by AI.
Software engineers are the translators. We (as a metaphorical community are in denial). Read the 100s of comments on this post: either (AI code is wrong or this isn’t correct or it’s not effective or some other justification). At the end of the day it’s really hard to accept the change.
This is a really great comparison to draw. This actually made me think that this feeling of going from mastering a craft to working on large scale systems is probably how someone who was passionate about cars felt when they went from building cars one by one, knowing how the whole machine works to then having to take a job on an assembly line.
Fortunately I think anything pertaining to vibe coding/engineering/analytics is still more enjoyable and less grim than working on an assembly line, but the human feelings remain nonetheless.
A better term is agentic coding, agentic software engineering, etc. rather than being vibe based.
My process starts from a Claude Code plan, whose first step is to write a spec. I use TDD, and enforce my "unspoken rules of code quality" using a slew of generated tools. One tiny tool blocks code which violates our design system. Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer. Watching the transcript I have to occasionally remind the model to use TDD, but once it's been reminded it doesn't need reminding again until compaction. Claude 4.5 is far better at remembering to do TDD than 4.1 was.
Code reviews are super simple with TDD due to the tests mirroring the code. I also create a simple tool which hands the PR and spec to Gemini and has it describe any discrepancies: extra stuff, incorrect stuff, or missing stuff. It's been great as a backup.
But ultimately there's no substitute for knowing what you want, and knowing how to recognize when the agent is deviating from that.
The opposite of "garbage-in garbage-out" is quality in => quality out.
I spent some time trying to think of a better term because I also think "vibe" detracts from the intent, and I think you nailed it with "agentic coding". Ill do my part by using that term now, hopefully it catches on : D
I was writing up some recommendations to my team for using Github Copilot in its different modes + Roo Code/Cline and tried so hard to avoid using “vibe coding” in a professional context. For sake of clarity I ended up including it once in a “you may have heard the term…” style reference but it just comes across as so deeply unserious and felt ridiculous being forced to use it at all.
I also landed on “agentic coding” FWIW. It’s a bit clunky but didn’t feel like an embarrassment to the entire software industry typing it so I’ll happily use it over the alternative.
> Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer.
Is that an llm agent or some other type of tool (e.g. language service or build toolset)?
When I say "tool" I really mean a python script. This particular one is ~100 lines of python with a main() method, that Claude Code wrote in a single shot, that I then committed to the repo in a scripts/ directory. That lets me include it in pre-commit hooks, run it when I run the tests, and have it run during CI.
A 100 line script finishes in milliseconds and burns no tokens. So you can run it hundreds of times per day.
The mindset is: will you need repeatability? If so, have the LLM write code, because code gives you determinism.
I don't know how vibe coding works, but how does this work - is the agent actually engaging in the red-green-refactor loop, or does it just generate the result all at once?
I just feel so discouraged reading this somehow. I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart. But now with these people like Simon Willison writing about the new way of coding with these agents and multiple streams of work going on at a time and it sounding like this is the future, I just feel discouraged because it sounds like so much work and I've tried using coding agents and they help a bit, but I find it way less fun to be waiting around for agents to do stuff and it's way harder to get into flow state managing multiple of these things. It makes me want to move into something completely different like sales
I'm really sorry to hear this, because part of my goal here is to help push back against the idea that "programming skills are useless now, anyone can get an LLM to write code for them".
I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of tools.
I said a version of this in the post:
> AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents.
A brand new vibe coder may be able to get a cool UI out of ChatGPT, but they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere. They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills. It doesn't work like tools developers use and it doesn't work like people developers work with. Furthermore, techniques of working with agents today may be completely outdated a year from now. The acceleration is also inconsistent: sometimes there's an acceleration, sometimes a deceleration.
Generative AI is at the same time incredibly impressive and completely unreliable. This makes it interesting, but also very uncertain. Maybe it's worth my investment to learn how to master today's agents, and maybe I'd be better off waiting until these things become better.
You wrote:
> Getting good results out of a coding agent feels uncomfortably close to getting good results out of a human collaborator. You need to provide clear instructions, ensure they have the necessary context and provide actionable feedback on what they produce.
That is true (about people) but misses out the most important thing for me: it's not about the information I give them, but about the information they give me. For good results, regardless of their skill level, I need to absolutely trust that they tell me what challenges they've run into and what new knowledge they've gained that I may have missed in my own understanding of the problem. If that doesn't happen, I won't get good results. If that kind of communication only reliably happens through code I have to read, it becomes inefficient. If I can't trust an agent to tell me what I need to know (and what I trust when working with people) then the whole experience breaks down.
While this is true, I definitely find that the style of the work changes a lot. It becomes much more managerial, and less technical. I feel much more like a mix of project and people manager, but without the people. I feel like the jury is still out on whether I’m overall more productive, but I do feel like I have less fun.
> They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
I wonder what the practical limits are.
As a senior dev on a greenfield solo project it's too exhausting for me to have two parallel agents (front/back), most of the time they're waiting for me to spec, review or do acceptance test. Feels like sprinting, not something I could do day in and day out.
Might be due to tasks being too fine grained, but assuming larger ones are proportionally longer to spec and review, I don't see more than two (or, okay, three, maybe I'm just slow) being a realistic scenario.
More than that, I think we're firmly in the vibe coding (or maybe spec-driven vibe coding) territory.
I really don't get the idea that LLMs somehow create value. They are burning value. We only get useful work out of them because they consume past work. They are wasteful and only useful in a very contrived context. They don't turn electricity and prompts into work, they turn electricity, prompts AND past work into lesser work.
How can anyone intellectually honest not see that? Same as burning fossil fuels is great and all except we're just burning past biomass and skewing the atmosphere contents dangerously in the process.
I don't think OP thinks his skills are useless per se now, but that the way to apply those skills now feels less fun and enjoyable.
Which makes perfect sense - even putting aside the dopamine benefits of getting into a coding flow state.
Coding is craftsmanship - in some cases artistry.
You're describing Vibe Engineering as management. And sure, a great manager can make more of an impact increasing the productivity of an entire team than a great coder can make by themselves. And sure, some of the best managers are begrudging engineers who stepped up when needed to and never stepped down.
But most coders still don't want to be managers - and it's not from a lack of skill or interest in people - it's just not what they chose.
LLM-based vibe coding and engineering is turning the creative craftsmanship work of coding into technical middle management. Even if the result is more "productivity", it's a bit sad.
I'm getting really great results in a VERY old (very large) codebase by having discussion with the LLM (I'm using Claude code) and making detailed roadmaps for new features or converting old features to new more useable/modern code. This means FE and BE changes usually at the same time.
I think a lot of the points you make are exactly what I'm trying to do.
- start with a detailed roadmap (created by the ai from a prompt and written to a file)
- discuss/adjust the roadmap and give more details where needed
- analyze existing features for coding style/patterns, reusable code, existing endpoints etc. (write this to a file as well)
- adjust that as needed for the new feature/converted feature - did it miss something? Is there some specific way this needs to be done it couldn't have known?
- step through the roadmap and give feedback at each step (I may need to step in and make changes - I may realize we missed a step, or that there's some funky thing we need to do specifically for this codebase that I forgot about - let the LLM know what the changes are and make sure it understands why those changes were made so it won't repeat bad patterns. i.e. write the change to the .md files to document the update)
- write tests to make sure everything was covered... etc etc
Basically all the things you would normally WANT do but often aren't given enough time to do. Or the things you would need to do to get a new dev up to speed on a project and then give feedback on their code.
I know I've been accomplishing a lot more than I could do on my own. It really is like managing another dev or maybe like pair programming? Walk through the problem, decide on a solution, iterate over that solution until you're happy with the decided path - but all of that can take ~20 minutes as opposed to hours of meetings. And the end result is factors of time less than if I was doing it on my own.
I recently did a task that was allotted 40 hours in less than 2 working days - so probably close to 10-12 hours after adjusting for meetings and other workday blah blah blah. And the 40 hour allotment wasn't padded. It was a big task, but doing the roadmap > detailed structure including directory structure - what should be in each file etc etc cut the time down dramatically.
I would NOT be able to do this if I the human didn't understand the code extremely well and didn't make a detailed plan. We'd just end up with more bad code or bad & non-working code.
I remember reading a sci-fi book, where time was.. sharded? And people from different times were thrust together. I think it was a Phoenician army, which had learned to ride and battle bareback.
And were introduced to the stability of stirrups and saddle.
They were like daemons on those stirrup equipped horses. They had all the agility of wielding weapons and engaging in battle by hanging onto mane, and body with legs, yet now had (to them) a crazy easy and stable platform.
When the battle came, the Phoenicians just tore through those armies who had grown up with the stirrup. There was no comparison in skill or capability.
(Note: I'm positive some of the above may be wrong, but can't find the story and so am just stating it as best able)
My point is, are we in that age? Are we the last skilled, deeply knowledgeable coders?
I grew up learning to write eeproms on burners via the C64. Writing machine language because my machines were too slow otherwise. Needing to find information from massive paper manuals. I had to work it all out myself often, because no internet no code examples, just me thinking of how things could be done. Another person who grew up with some of the same tools and computers, once said we are the last generation to understand the true, full stack.
> they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere.
Honestly, I have a ton of experience in system administration, and I'm super comfortable at a command line and using AWS tooling.
But, my new approach is to delegate almost all of that to Claude, which can access AWS via the command-line interface and generate configuration files for me and validate that they work correctly. It has dramatically reduced the amount of time that I spend fiddling with and understanding the syntax of infra config files.
I appreciate what you're trying to do, but for myself, I'm not depressed because my skills are less valuable. I enjoyed the money but it was never about that for me. I'm depressed because I don't like the way this new coding feels in my brain. My focus and attention are my most precious resources and vibe coding just shatters them. I want to be absorbed in a coding flow where I see all the levels of the system and can elegantly bend the system to my will. Instead I'm stuck reviewing someone/something else's code which is always a grind, never a flow. And I can feel something terrible happening in my brain, which at best can be described as demotivation, and at worst just utter disinterest.
It's like if I were a gardener and I enjoyed touching dirt and singing to plants, and you're here on Gardener News extolling the virtues of these newfangled tractors and saying they'll accelerate my impact as a gardener. But they're so loud and unpleasant and frankly grotesque and even if I refrain from using one myself, all my neighbors are using them and are producing all their own vegetables, so they don't even care to trade produce anymore--with me or anyone else. So I look out at my garden with sadness, when it gave me such joy for so many decades, and try to figure out where I should move so I can at least avoid the fumes from all the tractors.
> They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
Neither can I, sadly. I have one brain cell and I can only really do one thing at a time. Doing more than one leads to a corrupted stack and I make exponentially more mistakes.
>accelerate the impact you can have with this new family of tools.
Tech spent the last 10 years drilling into engineers' heads that scaling your impact is not about writing more or better code, but about influencing the work of other engineers through collaboration, process, documentation, etc. Even the non-managerial "senior IC" tracks are mostly about doing this with greater and and greater numbers of people. I wonder if we will start to see recognition in career tracks for people who are actually just extraordinarily productive by themselves or in small groups, or if you'll pretty much just have to be a startup founder to get paid for that.
This has been experience as well. If there is a hard problem which needs to be addressed, generative code helps me break the inertia by generating the first draft and then I get really curious to poke holes in the generated code. I tend to procrastinate when I come across a gnarly issue or something I am not really familiar with, justifying by saying I need a big block of time to work on it. I use generative code as a pushy "mom/boss/coworker/spouse" to get stuff done.
I really hope you are right here, and to be honest it does reflect my limited experience with where I've used AI so far.
But I'm also not ready to bet the farm on it. Seriously considering taking our savings and equity out of our house in a London adjacent area, and moving to a lower cost of living area, so that we're practically debt free. At that point we can survive on a full time minimum wage job, anything more than that is a bonus.
I still haven't seen any evidence to match these repeated claims of increased efficiency. What I have seen is reports that makes a lot of sense to me claiming it's all in the user's head.
Of course the devil is in the details. What you say and the skills needed make sense. It's unfortunately also the easiest aspects to dismiss either under pressure as there is often little immediate payoff, or because it's simply the hard part.
My experience with llms in general is that sadly, they're mostly good bullshitters. (current google search is the epitome of worthlessness, the AI summary so hard tries to make things balanced, that it just dreams up and exaggerates pros en cons for most queries). In a same way platforms like perplexity are worthless, they seem utterly unable to assign the proper value to sources they gather.
Of course that doesn't stop me from using llms where they're useful; it's nice to be able to give the architecture for a solution and let the llm fill the gaps than to code the entire thing by hand. And code-completion in general is a beautiful thing (sadly not a thing where much focus is on these days, most is on getting the llm create complete solutions while i would be delighted by even better code completion)
Still all in all, the more i see llms used (or the more i see (what i assume) well willing people copy/paste llm generated responses in favor of handwritten responses) on so much of the internet, resulting in a huge decline of factualness and reproducibility (in he sense, that original sources get obscured), but an increase of nice full sntences and proper grammar, the more i'm inclined to belief that in the foreseeable future llm's aren't a net positive.
(in a way it's also a perfect storm, the last decade education unprioritised teaching skills that would matter especially for dealing with AI and started to educate for use of tools instead of educate general principles. The product of education became labourers for a specific job instead of higher abstract level reasoning in a general area of expertise)
What about the accessibility of software development? Its completely vanishing for people that can not afford to pay for these agents. It used to be a field where you could get a laptop from the scrapyard and learn from there. It feels pointless. Also agents do not invent things, the creativity part is gone with them. They simply use what they've already seen, repeat the same mistakes a person made a few years ago. Its a dystopian way of working. Sure it enables one to spew out slop that might make companies money, but there is no passion, sense of exploration, personal growth. Its all just directing parrots with thumbs...
The "manage a fleet of massively parallelized agents" gets me uneasy too. It sounds uber powerful on its face. And where all the nerd interest lies.
It sounds stressful, like the ultimate manager job. Not what I signed up for.
But I also still hold onto this idea that shipping tons of iterations of "stuff" was never really the problem. Early in my dev experience I wanted to code everything all day every day. And I did and that's how I learned. And now in my second decade I switched to "why code anything?". In a business sense I mean, coding the thing is almost never the missing piece.
I joke in meetings that the answer is always "yes" whenever cross-functional teams ask "can we do this?". "How hard would x be?". For tech teams the answer _is_ always YES! I get that out of the way because that's never the right question to ask.
Absolutely this. LLM assistance means we can work faster, and that we can build things that previously weren't feasible given the available time and resources.
Which makes the hardest problem in software even harder: what should we build? It doesn't matter how fast you can move if you're consistently solving the wrong problems.
> The "manage a fleet of massively parallelized agents" gets me uneasy too
It shouldn't. The agents are not good enough to be used in a fleet.
I have Claude. It's fine, but I'm pretty confident that my low usage of Claude would out-compete a fleet of agents, because it feels like there's an inverse correlation between the number of tokens you spend and the quality of the resulting code (more tokens = more code to review, more bad code slips through)
I think people underestimate the degree to which fun matters when it comes to productivity. If something isn’t fun then I’ll likely put it off. A 15 minute task can become hours, maybe days long, because I’m going to procrastinate on doing it.
If managing a bunch of AI agents is a very un-fun way to spend time, then I don’t think it’s the future. If the new way of doing this is more work and more tedium, then why the hell have we collectively decided this is the new way to work when historically the approach has been to automate and abstract tedium so we can focus on what matters?
The people selling you the future of work don’t necessarily know better than you.
I think some people have more fun using LLM agents and generative AI tools. Not my case, but you can definitely read a bunch of comments from people using the tools and having fun/experience a state of flow like they have never had before
I’ll be that voice I guess - I have fun “vibe coding”.
I’m a professional software engineer in Silicon Valley, and I’m fortunate to have been able to work on household-name consumer products across my career. I definitely know how to do “real” professional work “at scale” or whatever. Point is, I can do real work and understand things on my own, and I can generally review code and guide architecture and all that jazz. I became a software engineer because I love creating things that I and others could use, and I don’t care about “solving the puzzle” type satisfaction from writing code. In engineering school, software had the fastest turnaround time from idea in my head to something I could use, and that’s why I became a software engineer.
LLM assisted coding accelerates this trend. I can guide an LLM to help me create things quickly and easily. Things I can mostly create myself, of course, but I find it faster for a whole category of easy tasks like generating UIs. It really lowers the “activation energy” to experiment. I think of it like 3D printing, where I can prototype ideas in an afternoon instead of long weekend or a few weeks.
I feel the same way. It also appears to be a lot more difficult to actually find jobs, though that's probably just the general state of the job market and less specifically AI related. All of it is thoroughly discouraging, demotivating, and every week this goes on the less I want to do it. So for me as well it might be time to try to look beyond software, which will also be difficult since software is what I've done for all my life, and everything else I can do I don't have any formal qualifications for, even if I am confident I have the relevant skills.
It's not even just that. Every single thing in tech right now seems to be AI this, AI that, and AI is great and all but I'm just so tired. So very tired. Somehow even despite the tools being impressive and getting more impressive by the day, I just can't find it in me to be excited about it all. Maybe it's just burnout I'm not sure, but it definitely feels like a struggle.
Keep your head up, the gravy train is not gonna run forever, and they will need serious engineers to untangle the piles of bullshit creates in these past few years.
But also yes, look into moving into a different field. Professional software engineering is gonna be infected with AI bullshit for a long while. Move into a field where hand-crafted code can make a difference, but not where you're paid for the line committed or have to compete with "vibe coding" KPIs.
I don't really agree. The writing is on the wall, if not now then in 2 years or 4 years. I arrive at this view not so much based on the capabilities of the tools right now, but based on the property of software being verifiable, which like mathematics, makes it amenable to synthetic data pipelines, with only relatively small remaining details needing to be worked out (such as how to endow architectural taste). This is not nearly the first industry where 'artisans' have been initially augmented by innovation, only to be eventually replaced by it, which in my view will occur likely within my own career-span.
If you're genuinely already good at coding, use the LLM to go horizontal into other complementary verticals that were too expensive to enter prior. Do the same thing that the other professions would do unto yours.
As an example, I would have never considered learning to use blender for 3d modeling in a game before having access to an LLM. The ability to quickly iterate through plausible 3d workflows and different design patterns is a revelation. Now, I can get through some reasonably complex art pipelines with a surprising amount of confidence. UV mapping I would have never learned without being able to annoy one of OAI's GPUs for a few hours. The sensation of solving a light map baking artifact on a coplanar triangle based upon principles developed from an LLM conversation was one of the biggest wins I've had in a long time.
The speed with which you can build confidence in complementary skills is the real super power here. Clean integration of many complex things is what typically brings value. Obsession with mastery in just one area (e.g. code) seems like the ultimate anti-pattern when working with these tools. You can practically download how to fly a helicopter into your brain like it's the matrix now. You won't be the best pilot on earth, but it might be enough to get you to the next scene.
If it's any consolation, I do think the non-technical users have a bigger hill to climb than the coders in many areas. Art is hard, but it is also more accessible and robust to failure modes. A developer can put crappy art in a game and ship it to steam. An artist might struggle just to get the tooling or builds working in the first place. Even with LLM assistance there is a lot to swim through. Getting art from 5% to 80% is usually enough to ship. Large parts of the code need to be nearly 100% correct or nothing works.
Thanks for this, I like your idea about breaking into areas I don't have experience with. E.g. in my case I might make a mobile app which I've never done before, and in theory it should be a lot easier with Claude than it would've been with just googling and reading documentation. Although I did kind of like that process of reading documentation and learning something new but you can't learn everything, you only have so much time on this planet
I can confirm this. My datapoint: I was mostly a web developer but using these "vibe" tooling I am making my own hardware board and coding for embedded, which includes writing drivers from datasheets, doing SIMD optimizations, implementing newer research papers into my code, etc.
You word quite well how I feel about it.
On top of not really liking babysitting an AI , I'm also very afraid of the way this whole AI coding business normalizes needing an account with some nebulous evil empire to even be able to do your work. Brrr.
100%. Imagine how young people feel. When they’re still trying to figure things out, their parents and teachers just as clueless as they are, and at the same time the expectations of them are infinitely higher. “You’re pretty good, but chatgpt is still better. Try harder.”
Have you ever interacted with any "vibe"-based systems of agents in a production environment? Beyond just cool demos online?
My experience with them is they are fragile monstrosities, that are only permitted to exist at all because leadership is buying into the same hype that is irrationally propping up the companies running the models that make these things possible.
To be clear, my experience hasn't been that I don't like them, it's that they don't really work at all. They're constantly under development (often in the dark) and when a ray of light is cast on them they never successfully do the thing promised.
Cleaning up the messes left behind by these has my skills feeling more valuable then ever before.
I can relate with you. I love programming and building things, gives a different kind of rush when you finally figure out something. I've done vibe coding and don't enjoy it at all. I always thought my love for coding gives me an edge over other engineers who just want to get the job done. Now it's holding me back and I'm not sure if I should continue working in this field or if start doing wood working or something.
I still do all the stuff by hand, but ask the AI to review my work, provide suggestions, and occasionally write the tests (especially if it points out a bug that I disagree with). Its really good at pointing out typos (accidentally using the wrong variable of the same type, and stuff like that) that are also traditionally hard to spot during review.
Do not worry, I am mentoring a young engineer in my team. It is painfully hard to get him to improve his code, because it works. It is badly structured, lot of small "impedance mismatches", lot of small security issues, all that in 3 Python files.
I have a team of 10 engineers, the quality of the code they produce together with the LLM of the day correlates even more with the experience.
My impression over the past 6 months - before we had no "official" access to LLM, is that they increase the gap between junior and experienced developers.
Note that this is my limited impression from a team of 10 engineers. This matches with Simon's feeling in a good way for you!
You were never paid to type. You were paid to solve problems. And big part of this is being able to ask the right questions and framing of the problems. The rest were just tools.
There are exceptions of course - where you need to squeeze wonders from the hardware - but the majority of dev works boils to understanding the problem and finding the right answers.
You say this because you are on HN, very senior and/or living in a bubble.
In the vast majority of programming jobs out there you are not paid to solve problems: you are told very clearly what to do, how to do it and what technology you have to use for the job.
People don't hire analysts they hire "Java programmers".
People keep comparing LLMs to automated looms, but I find them more comparable to cruise control than autopilot.
I've been working on a character sheet application for a while, and decided to vibe-code it with Spec-kit to help me write up a specification, and for things I know it's been great.
I tried using Claude to make it into a PWA (something I don't know very well) as an experiment, and I've found the nanosecond the model strays out of my experience and knowledge everything goes straight to Hell. It wraps my codebase around a tree as if I'm not paying attention while driving.
It's a tool you'll have to learn to use, but I can say with absolute confidence it's no replacement for actual skills, if anything it highlights the gulf between people who know what they're doing and people who don't, for better and worse.
It sacrifices some of the 'code under your fingers' feeling for management tasks, which I personally really like, as I've always wanted to document/test/code review/spec things out better, and I now understand the pain of people who'd rather not do that sort of thing.
The difference is that you can trust cruise control to do whatever limited job it knows how to do; you can't trust an LLM to do anything. That makes it, I think, hard to compare to anything we're used to (happily) working with.
Cruise control is a useful technology, that once you learn to use, it's automatic (somethingsomething pun something). LLMs on the other hand - well, yeah - if you like playing chess with pieces and board made out of smoke (to paraphrase Jerry Seinfeld), sure you'll probably figure it out...some day...
It kinda feels like you turn from a software engineer to an offshoring manager.
Offshoring software development means letting lower-payed software developers from somewhere far away do the actual programming, but they have a very different culture than you, and they typically don't share your work context, don't really have a feeling for how the software is used -- unless you provide that.
Now we're offshoring to non-sentient, mostly stateless instances of coding agents. You still have to learn how to deal with them, but you're not learning about a real human culture and mindset, you learn about something that could be totally changed with the next release of the underlying model.
My rule of thumb, and its likely not the industry standard is, if I cannot maintain the code should all AI disappear, I don't use the code. I am able to tackle impostor syndrome that sometimes hits when I touch things that are new or unknown to me, and ask an LLM to give me sources and reasons and even explain it like I'm a five year old.
The LLM will not save you when everything is on fire and you need to fix things. The context window is simply not big enough. It could be your last change, it could also be a change six months ago that is lost in the weeds.
There are a ton of them already in game dev but they produce unfun games so you don’t hear about them. The hard part of game dev is designing actually fun experiences.
I can't even begin to imagine how a 12-year old who discovered how empowering bending the machine to do your will through code feels when, over time, realize that their dream career has been reduced to being an LLM middleman.
>I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart.
Tools always empower those with knowledge further than those without knowledge.
Don't worry, it's probably only the impostor syndrome. Your development skills are still relevant. Think of agents as junior developers that assist you in coding tasks, whom you constantly need to mentor, review, and correct.
Junior developers or maybe even better, outsourced developers - there's a big segment of software engineering that involves writing requirements and checking the work of an external software development company, with many companies heavily dependent on it (as they outsourced part of their core business, e.g. mainframes, SAP, whatever).
As for flow state managing multiple things, I've found this is a useful skill to train even without AI - if you have a workplace with lots of interruptions and shifting priorities.
I've found two things useful:
1) Keep a personal work log, where you - in short bullet points - can document the progress of the task you were last working on, and can keep track of how many parallel tasks there are currently going on. If you can match it with Jira tickets, all the better, but as this is for personal use only, you can also add tasks that are not tracked in Jira at all.
2) If you cannot avoid context switches, make them explicit: Instead of trying to hold 3 tasks in your head at the same time, decide consciously if you want to switch what you're currently working on. If yes, take a few minutes to "suspend" the current task by saving and committing everything (as WIP commits if necessary) and writing all you need to remember into the worklog.
Be mindful of the context these posts are created in. Don't take the current echo chamber to heart.
For decades now, we are trying to lower the barrier to entry in software development.
We created Python, web frameworks and mobile development so easily accessible that you can become software developer by completing a short online boot camp. There is a lot of software developers posting here now who, 20 years ago, would not even consider this job because it would be way over their abilities.
This forum is equivalent if you had a forum about civil transportation that gathers airline pilots and uber drivers. Technically, they both do the same work. Just like in that forum, uber drivers would outnumber airline pilots and skew the topics related to their experience, here we get pushed topics about new frameworks, and AI assisted tools.
When I started working professionally 20 years ago, you could only get job in big companies working on big projects. No one else could afford a cost of custom software. Today, we reduced development costs and we have a huge pool of potential customers who can now afford services of software developers. Web shops, gambling sites, porn sites... This is the majority of software development work today. Boring repetitive tasks of gluing some imported modules together.
Serious development work didn't disappear. It is just not talked about here. There is still a need people who know what they are doing.
My advise is that if you want a satisfying development career, steer clear of latest hypes and don't go blindly following techbro lemmings. And most importantly, don't take career advice from anyone who finds his job so unsatisfying and tedious that he is trying to make AI do it for him. That's a major red flag.
I think the key is remind yourself is that an engineer is supposed to solve business problems. So use these new tools to be more effective in doing so.
An analogy is that people used to spend tons of time building out web server code but something like Django added tremendously useful abstractions and patterns to doing so, which allowed people to more productively add business value
You shouldn't be discouraged. Now is the best time to create software. You have advantage that very few people have.
Its industry own fault that it is in the position that it is right now, and it will shift and change embrace it. I only wish I had your experience building software in professional environment.
You can literally build anything right now if you have the experience, I personally can't understand if the models are hallucinating hence the lack of experience writing and understanding code. However I always wanted to pivot into the industry but couldn't, hiring practices are brutal, internships are non-existent, junior roles are I think what senior used to be and the whole hr process is I don't know how to put it.
By using LLMs I can now build UIs, build functionality, iterate over design choices, learn about database design, etc. hopefully I will escape the tutorial hell and have my own working full stack web app soon.
LLMs are very much like WYSIWYG web editors of the early 2000s like Dreamweaver. They provide a human interface layer that abstracts away the coding, and neither does a particularly good job of it. When WYSIWYG first became a thing, there was talk that it would upend the web development industry. It did not.
One of the main points of my article was meant to be that LLMs don't abstract away the code, at least not if you're trying to use them for professional software development work as opposed to vibe coded prototypes and toy projects.
> It makes me want to move into something completely different like sales
I'm feeling the same. The moves I'm considering are
1. Landscaping
2. Carpentry
3. Small scale agriculture
(All made easier by a cushion of investments that are most of the way to passive income, so the new thing doesn't really have to make me that much money.)
My father runs a commercial landscaping company with 15 employees. His truck fleet insurance went up 35% just this year. His light industrial facility that he operates out of property taxes went up 55% last year. All of his commercial clients are cheaping out on all the little things that used to make extra money (pine straw, seasonal flowers, etc.). He’s having to deal with poorly educated staff who are constantly breaking equipment and doing stupid dangerous things. He’s so burned out by it all, and the fact that his actual salary is less than several of his top staff that he’s thinking about just shutting it all down. When I was working as a software developer, my income was probably twice as much as his without any of the risk or headache.
Yes and especially with new developments, like "$Framework now has Signals!", my thought is "I don't really care since in some years, it won't matter anyways". I don't see how I can build this lower level knowledge by almost never actually using it. I don't even want to think about job-interviews after a year+ of vibing and then being asked how RxJS works.
I'm preparing mentally for my day-job to stop being fun (it still beats most other occupations I guess), and keep my side/hobby-projects strictly AI-free, to keep my sanity and prevent athropy.
I just hope we'll get out of this weird limbo at some time, where AI is too good to ignore, but too unreliable to be left alone. I don't want to deal with two pressures at work.
Something I really appreciate about LLMs is that they make a whole bunch of much more sophisticated reliable tooling acceptable to me.
I've always been fascinated by AST traversal and advanced refactoring tools - things like tree-sitter or Facebooks's old codemod system https://github.com/facebookarchive/codemod
I never used them, because the learning curve in them was steep enough that I never found the time to climb it to the point that I could start solving problems.
Modern LLMs know all of these tools, which flattens that curve for me - I find it much easier to learn something like that if I can start from semi-working examples directly applicable to what I'm trying to do.
I feel the opposite. I get to sit down and think about problems, expressing them in words as best I can, and then review the code, make sure that I understand it and it works as it should, all in a fraction of the time it used to take me. I like that I don't have to google APIs as much as I did before, and instead I can get a working thing much faster.
I can focus on actually solving problems rather than on writing clever and/or cute-looking code, which ironically also gives me more time later to over-optimize stuff at my leisure.
I feel this way with some of the work I've pushed through an LLM, but part of the time I'm left wondering what kind of Mickey Mouse problems people are working on where they are able to form up tidy English descriptions in complicated domains to capture what they're trying to achieve.
If I have a clear idea of some algorithm I am trying to write, I have a concise method for expressing it already, and it ain't English.
I suppose the other thing I would say is that reading code and understanding is definitely not the same as writing code and understanding it in terms of depth of understanding, and I think this notion that reviewing the outputs ought to be enough fails to capture the depth of understanding that comes with actually crafting it. You may not think this matters, but I'm pretty sure it does.
I have a relative who's in her 70s and used to be a coder. She told me she gave up coding when people introduced computers with terminals. She was used to filling out punch cards and felt like the way she worked, although constantly evolving, was something she could keep up with. When the new stuff came, with virtual programs and you just typing on a computer and no way to properly debug by shuffling the cards around, she ended up moving to something completely different...
Don't worry about it. Don't let anyone else tell you how best to use AI, use AI in a way that suits YOU, then it is so much fun. I would go crazy if I had multiple streams simultaneously working on stuff that need constant supervision (that would be different if I could trust they do 100% what I intend them to do), but AI is still very helpful in other ways (research, exploration, and writing tests).
This line really hit me. I used to think that mastering one advanced skill would be enough to rely on for life, but it seems that’s no longer the case.
I’m sorry you feel that way but that’s a surprising experience, I find flow states easier managing agents than actually coding. Each of course, to their own. Is it possible you were reaching the end of your tether anyway in the coding space? Feel free to slap that accusation down if it’s unfair.
I wonder how this will affect the burnout rate among IT workers in the long-term, which already was quite high. I guess a lot of people force themselves (or are forced to by their company) to use LLM in fear of being left behind, even if they don't enjoy the process, but sooner or later the fatigue will catch up.
> It makes me want to move into something completely different like sales
Aaand that's startup founder life :)
Intense multitasking, needing to accept a lower engineering quality bar, and ignoring scale problems because you don't know if anyone will actually buy the thing you're building yet.
Engineering something that you know you'll redo in 1 month is very different from engineering something that you intend to last for 5+ years, but it's still a fun challenge picking the right tradeoffs and working under different constraints.
it's taken programming from being fully waiting on compilations to being incrementally compiled and productive back to waiting on the compiler all over again.
The experience you have is something most youngsters won't ever get, because they won't have the time. You've become more valuable than you used to be, because you know exactly what works when and what doesn't. The hard part is being able to find the joy in making agents do what you want achieved instead of building it yourself. I think it actually isn't too hard once you get up to speed with managing multiple agents - efficiently juggling them feels like an art performance sometimes.
This is going to sound harsh, but welcome to the real world, I guess. Being in IT is pretty much the only job I know of today that is stable, pays well, is enjoyable, feels like it affects the world, personally engaging and challenging, etc. Being not in IT (it's just a hobby of mine) your comment sounds like "Well I had absolutely everything, and I still do but now it's not as fun anymore!"
Well-put. Sw eng is so much better, assuming you are comfortable in the role, for types who want to punch a clock doing something they don't hate.
Sales is the definition of high-pressure, and your output is always threatened by forces beyond your control. It doesn't consistently reward intelligence or any particular skill other than hustle.
There's nothing like sw dev that lets you sit at your desk and ignore the outside world while getting paid for delivering biz-critical milestones. Even creatives don't have this kind of potential autonomy.
It is just a new way of coding. And indeed what the blog post said, if you are experienced, you will benefit the most as the AI agent will make similar mistakes as a junior and you will be able to recognize them.
But indeed, the fun part of coding a couple of routines is gone. That is history.
I don't get the obsession some tech people have to push the idea that this stuff accelerate your coding, increase your productivity. It's all about fast and faster output. In my experience LLMs have mostly produced gibberish oververbose code, surely faster than me, but my lower speed usually produce better code. I don't like this present state of things where we need to chat faster to quickly get out results and go fast in production... that is the kind of mentality that pushed subpar products on the web for so many years. Instead of dropping names lile vibe coding/engineering whatever comes next, let's have a serious discussion why we need faster low quality and we can't just improve automation and processes. Eg I can get unit test generated very fast sure, but my question is: why do we need all these unit tests in the first place? Dont get me wrong they're useful, but I feel like we're advancing higher abstraction instead of advancing lower level tools
> that is the kind of mentality that pushed subpar products on the web for so many years
Famously, some of those subpar products are now household names who were able to stake out their place in the market because of their ability to move quickly and iterate. Had they prioritized long-maintainable code quality rather than user journey, it's possible they wouldn't be where they are today.
"Move fast and break things" wasn't a joke; Mark really did encourage people to build faster and it helped cement their positioning. Think of the quantity of features FB shoveled out between 2009-2014 or so, that just wouldn't have been possible if their primary objective was flawless code.
The code isn't the product, the product is the product. In all my years of engineering I've yet to have an end-user tell me they liked my coding style, they've always been more concerned with what I'd built them.
Earlier than that, Facebook became ascendent because of quality. It was better than MySpace, the only real competitor at the time. The issue here is Facebook is not primarily a software product. It's a community, and the community was better than MySpace because it was restricted to pre-existing networks rather than taking any comer. I don't think Mark did that on purpose as a calculated decision. He just got lucky. When they eventually opened up and became just as shitty as MySpace had been, they were big enough to simply acquire better products that might have been competitors, and network effects locked them in for probably decades until their users die off and don't get replaced by younger people who never used Facebook.
I don't really see it as an example of what you're saying so much as an example of success as a product having to do with far more than explicit product features. You can see a similar dynamic in other natural monopoly markets. The NBA didn't necessarily do anything particularly right product wise, for instance. They just got the best players because basketball was historically more popular in the US than other countries, and the ABA made some stupid decisions that let the NBA win out in the US.
Hell, the US itself didn't do a whole lot "right" aside from not being in Europe when Europe decided to destroy itself, being better-positioned than other potential competitors like Canada, Mexico, and Australia simply because North America is best positioned to trade with both Europe and Asia and the US is more temperate than Canada or Mexico. But we sure like to tell ourselves stories about everything we did right.
Total side note, it's interesting seeing "Move fast and break things" become the dominant phrase vs what I remember initially as the "MIT vs New Jersey methods". Both describe the same thing where fast and sloppy wins vs slow and clean.
I think the general issue with software engineering discourse is that while our tools and languages may be the same, there's a massive gradient in tolerance for incorrectness, security, compliance, maintainability.
Some of us are building prototypes, and others are building software with a 10 year horizon or work with sensitive personal data.
So on the one side you get people that are super efficient cranking things out, and others that read this and feel appalled anyone would be comfortable with this and see software engineering as theory building. Neither are really wrong here, but the context / risk of what people are working on always seems to be missing when people talk about this.
I have yet to see in my life a prototypes that doesn't become production :) Btw my whole point wasn't on security and can't find a compelling reason to talk about it, it rather questions "faster results" as "better productivity" it isn't, and imo we should pause for a moment and focus on better tooling
We live in an objective reality. LLM's help a damn lot in speed of development. As someone who has been coding since 5th grade for over 20 years who is known to be a LIGHTNING FAST implementor by many people I have been scaled ridiculously with LLM's. Genie is out of the bag, you have to go with the flow, adapt or else....
I am just as pissed as anybody else at the lack of certainty in the future.... Thought I had my career made. So it's not that I don't emphatize with engineers in my shoes.
Good lord I wish I could have as many certainties as well, one point at a time:
* There is no objective reality, there isn't one in physics, it's just a non argument
* "LLM's help a damn lot in speed of development" That may be your experience and my whole point was arguing that speed may not matter
* "Genie is out of the bag, you have to go with the flow, adapt or else" I choose else
if this the apex of the argument
> why do we need all these unit tests in the first place?
The same reason we've always needed them:
1: They prevent regressions. (IE, bugs in features that were shipped and already working.)
2: They are very easy to run at the push of a button in your IDE. (But in this context the LLM runs them.)
3: They run in CI. This is an important line of defense in making sure a pull request doesn't introduce a bug.
Now, depending on what you're writing, you might not need unit tests! Perhaps you're trying to get a minimum viable product out the door? Perhaps you're trying to demo a feature to see if it's worth building? Perhaps you're writing a 1-off tool that you'll run a few times and throw away?
But, understand that if you're writing an industrial-strength program, your unit tests help you ship bug-free software. They allow you to do some rather major refactors, sometimes touching areas of the codebase that you only lightly understand, without needing to manually test everything.
(And, to keep it in context,) your LLM will also have the same benefits from this tired-and-true process.
Thanks for the non solicited lesson, I learned basically nothing new. That unit tests ships bug free software is such an overstatement... Btw please go re read my comment and try to understand what I was actually trying to argue about, and I also wrote that I think they can be useful...
You aren’t entertaining the possibility that some experienced engineerings are using these tools to produce incredibly high quality code, while still massively increasing productivity. With good prompting and “vibe engineering” practices, I can assure you: the code I get Claude Code to produce is top notch.
I'm experienced, I don't accept the implication that I might not be able to use these tools are their full potential and you won't convince me only because you mention an anecdotical example
You see a large % of failures, but you're drawing an unsupported conclusion.
We all agree, the people that _feel_ the most productivity spike are the sub-par engineers. That shouldn't be controversial, and it's even predictable.
But their volume can't be taken as an argument one way or the other.
The question is, are there _any_ good engineers that don't just feel more productive, but objectively are.
People are constantly looking for definite tendencies and magic patterns so they can abdicate situational awareness and critical thinking. We observe that fast delivery has often correlated with success in software and we infer that fast delivery is a factor of success. Then it becomes about the mindless pursuit of the measure, speed of delivery, as Goodhart's law predicts.
Let's even concede that speed of delivery indeed is an actual factor, there has to be a threshold. There's a point where people just don't care how fast you're putting out features, because your product has found its sweet spot and is perfectly scratching its market's itch. A few will clearly notice when the line of diminishing returns is crossed and if they can reset their outlook to fit the new context, a continuous focus on speed of delivery will look increasingly obsessive and nonsensical.
But that's the reality of the majority of the software development world. Few of us work on anything mission critical. We could produce nice sane software at a reasonable pace with decent output, but we're sold the idea that there's always more productivity to squeeze and we're told that we really really want that juice.
That all things develop only so much before they degrade into overdevelopment was a very well understood phenomenon for ancient Taoists, and it will be the death of the modern Blackrock/Vanguard owned world which is absolutely ignorant of this principle.
I'll attempt to provide a reasonable argument for why speed of delivery is the most important thing in software development. I'll concede that I don't know if the below is true, and haven't conducted formal experiments, and have no real-world data to back up the claims, nor even define all the terms in the argument beyond generally accepted terminology. The premise of the argument therefore may be incorrect.
Trivial software is software for which
- the value of which the software solution is widely accepted and widely known in practice and
- formal verification exists and is possible to automate or
- only has a single satisfying possible implementation.
Most software is non-trivial.
There will always be:
- bugs in implementation
- missed requirements
- leaky abstractions
- incorrect features with no user or business value
- problems with integration
- problems with performance
- security problems
- complexity problems
- maintenance problems
in any non-trivial software no matter how "good" the engineer producing the code is or how "good" the code is.
These problems are surfaced and reduced to lie within acceptable operational tolerances via iterative development. It doesn't matter how formal our specifications are or how rigorous our verification procedures are if they are validated against an incorrect model of the problem we are attempting to solve with the software we write.
These problems can only be discovered through iterative acceptance testing, experimentation, and active use, maintenance, and constructive feedback on the quality of the software we write.
This means that the overall quality of any non-trivial software is dominated by the total number of quality feedback loops executed during its lifetime. The number of feedback loops during the software's lifetime are bound by the time it takes to complete a single synchchronous feedback loop. Multiple feedback loops may be executed in parallel, but Amdahl's law holds for overall delivery.
Therefore, time to delivery is the dominant factor to consider in order to produce valuable software products.
Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.
>> Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.
I'll reply just to that as it being the tldr. First of all tech debt is a thing and it's the thing that accumulates mostly thanks to fast feedback iterations. And in my experience the better the comunication, to get the implementation right, and the better the implementation and it happens that you can have solid features that you'll unlikely ever touch again, user base habit is also a thing, continuing on interating on something a user knows how to use and changing it is a bad thing. I'd also argue it's bad product/project management. But my whole original argument was why we'd need to have a greater speed in the first place, better tooling doesn't necessarily means faster output, productivity as well isn't measured as just faster output. Let me make a concrete example, if you ask an LLM X to produce a UI with some features, most of them will default to using React, why? Why can't we question the current state of web instead of continue to pile up abstractions over abstractions? Even if I ask the LLM to create a vanilla web app with HTML, why can't we have better tooling for sharing apps over the internet? The web is stagnant and instead of fixing it we're building castles over castles over it
When pigeons are offered random rewards from a treat dispenser, they start doing all kinds of funny little dances and movements because they think the rewards are in response to their actions.
This is my favorite thing about this whole situation. I spend years trying to get teams to follow best practices. And then suddenly if you follow them the LLM is more effective so now they follow them ignoring that they could have been more effective this whole time.
I’m critiquing the term “vibe engineering” by highlighting that because of the random, chaotic, black box nature of LLMs it is very difficult to distinguish valid techniques from superstitions.
Thus what you are doing is closer to pigeons bobbing their heads to attempt to influence the random reward machine than it is to engineering.
For example saying things like “It is critical that you don’t delete working code” might actually be a valid general technique, or it might have just been something that appeared to work because of randomness, or it might be something that is needed for current models but won’t be necessary in a few months.
The nature of LLMs makes correctly identifying superstition nearly impossible. And the speed with which new models are released makes trying to do so akin to doing physics in a universe where the laws of nature are constantly changing.
You’re an alchemist mixing gunpowder and sacrificing chickens to fire spirits, not an engineer, and for the foreseeable future you have no hope of becoming an engineer.
I’m also highlighting the insanely addictive nature of random rewards.
“One bird was conditioned to turn counter-clockwise about the cage, making two or three turns between reinforcements. Another repeatedly thrust its head into one of the upper corners of the cage. A third developed a 'tossing' response, as if placing its head beneath an invisible bar and lifting it repeatedly. Two birds developed a pendulum motion of the head and body, in which the head was extended forward and swung from right to left with a sharp movement followed by a somewhat slower return.”
“The experiment might be said to demonstrate a sort of superstition. The bird behaves as if there were a causal relation between its behavior and the presentation of food, although such a relation is lacking.”
I think we should just accept that vibe-coding has now semantically shifted to mean all AI-assisted coding. Actually, it makes sense to me even when a human is interacting directly with the code, because it feels a lot like pair-programming. As such, I really am "vibing" with the AI.
But then the original meaning of vibe-coding -- as in, "Take the wheel, LLama of God" -- does need a new term, because that will also be a lasting phenomenon. I propose "Yolo-Coding" -- It fits in nicely with the progression of No-Code, Low-Code, Yolo-Code.
Disagree, I think vibe coders should become synonymous with no-code and continue to be somewhat of a pejorative.
I don't like the term vibe engineer, but do agree there needs to be a term to signifiy the difference.
It's also possible in the future just being called a developer/engineer already implies you use coding agents and the people who do it "by hand" will not be the norm.
At $enterprise, we were just looking for a proper term that sets "responsible vibing" apart from "YOLO vibe coding". We landed on "agent assisted coding".
It's a bit more technical. And it has a three-letter acronym. Gotta have a three letter acronym.
I really like "agent assisted coding". I think the word "vibe" is gonna always swing in a yolo direction, so having different words is helpful for differentiating fundamentally different applications of the same agentic coding tools.
Wasn't the original meaning of "vibe coding", as posted by Ilya Sutskever on twitter, that you just feed the model prompts and blindly run whatever results you get. No analysis or review, just copy/paste and hit run.
> now semantically shifted to mean all AI-assisted coding.
News to me. AI-assisted coding is more auto-complete or having it trying to make sense of awful documentation.
Vibe coding to means a number of things.
- The person has no skill in understanding what the LLM wrote.
- The code created hasn't been reviewed in any way to look for possible future issues.
- Technical debt from the get go.
- Legally your application is screwed.
For me the single killer of vibe coding is that anything the LLM creates cannot be protected/copyrighted. UK has some laws that might offer a little protection, but EU/US you are pretty much screwed.
A better term would be “Augmented Engineering” (AE).
You want something to inspire engineers to do their best work.
When you can expand your capabilities using the power of AI, then yeah, you can do your best work; hence augmented engineering.
But vibing? Not so much.
I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
I wouldn't worry too much about what to call it. Assigning a distinct label separates it from traditional engineering in a way that it assumes AI-assisted coding is only for a subset of developers. At some point the unusual approach will be writing code without any AI assistance. So the transition will leave the "vibe" behind.
> gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
Gives you access to the power to access and {mis}understand the {most repaeted over the last 1-10 years} engineering {errors, myths, misunderstandings, design flaws}, on demand, which you then can apply to your work {to further bias the dataset for future models to perpetuate the slop}.
Do NOT trust AI agents. Check their work at every level, find any source they claim to use, and check its sources to ensure that itself isn't AI too. They lie beyond their datasets, and their datasets are lying more for every minute that pass.
Now, seriously though, no tools is perfect, and I agree we should not trust it blindly, but leaving aside AI Agents, LLMs are very helpful in illuminating one's path, by consulting a large body of knowledge on demand, particularly when dealing with problems which might be new to you, but which have already been tackled one way or another by other people in the industry (provided they're in the training set of course).
Yes, there's always the risk of perpetuating existing slop. But that is the risk in any human endeavor. The majority of people mostly follow practices and knowledge established by the few. How many invent new things?
To be honest, I haven't yet used AI agents, I'm mostly just using LLMs as a dialogue partner to further my own understanding and to deepen my knowledge. I think we're all still trying to figure it out how to best use it.
> A better term would be “Augmented Engineering” (AE).
I don't think it necessarily deserves a special name. It is just engineering. You don't say book assisted engineering when you use a book as a reference. It is just engineering.
> But vibing? Not so much.
Just call it yolo engineering. Or machine outsourced irresponsible lmao engineering.
> I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
These seem like a lot of great ways to work around the limitations of LLMs. But I'm curious what people here think. Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
I see how if you can't really code, or you're new to a domain, then it can make a huge difference getting you started, but if you know what you're doing I find you hit a wall pretty quickly trying to get it to actually do stuff. Sometimes things can go smoothly for a while, but you end up having to micromanage the output of the agent too much to bother. Or sacrifice code quality.
They're so nice for prototyping ideas and not becoming attached to the code due to sunken cost. I was playing around with generating intelligent diffs for changelogs for a game. I wasn't sure what approach to highlighting changes I wanted to take without being able to see the results.
Prior to vibe-coding, it would've been an arduous enough task that I would've done one implementation, looked at the time it took me and the output, and decided it was probably good enough. With vibe-coding, I was able to prototype three different approaches which required some heavy lifting that I really didn't want to logic out myself and get a feel for if any of the results were more compelling than others. Then I felt fine throwing away a couple of approaches because I only spent a handful of minutes getting them working rather than a couple of hours.
For stuff that I’m bad at? Probably more than 1000%. I’ve used it to make a web app, write some shader code, and set up some rtc streaming from unreal engine to the browser. I doubt I would have done them at all otherwise tbh. I just don’t have the energy and interest to conclude that those particular ventures were good uses of my time.
Yeah I couldn't put it better myself. It's obscene how much more productive you become in new domains. And sure, you eventually hit a wall where you gotta understand it for real. But now you have a working example of your project, plus a genius who will answer unlimited questions and clarifications.
I would say I get more (I've been coding 40+ years). I get pretty good results, I find a lot has to do with crafting your prompts well. I think knowing what the outcome should be, technically, makes a big difference. It's getting less and less where I have to argue with the AI / do it myself. Not to mention the amount of little productivity / quality of life scripts I get it to create. They really smooth out a lot of things. I feel like its more heading towards "solution engineering" rather than coding where I'm getting a lot more time to think about the solution and play with different ideas.
My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
But if I give it a code example that was written by humans and ask it to explain the code, it gives pretty good explanations.
It's also good for questions like "I'm trying to accomplish complicated task XYZ that I've never done before, what should I do?", and it will give code samples that get me on the right path.
Or it'll help me debug my code and point out things I've missed.
It's like a pair programmer that's good for bouncing ideas, but I wouldn't trust it to write code unsupervised.
> My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
> […]
> Or it'll help me debug my code and point out things I've missed.
I made both of these statements myself and later wondered why I had never connected them.
In the beginning, I used AI a lot to help me debug my own code, mostly through ChatGPT.
Later, I started using an AI agent that generated code, but it often didn’t work perfectly. I spent a lot of time trying to steer the AI to improve the output. Sometimes it worked, but other times it was just frustrating and felt like a waste of time.
At some point, I combined these two approaches: I cleared the context, told the AI that there was some code that wasn’t working as expected, and asked it to perform a root cause analysis, starting by trying to reproduce the issue. I was very surprised by how much better the agent became at finding and eventually fixing problems when I framed the task from this different perspective.
Now, I have commands in Claude Code for this and other due diligence tasks, and it’s been a long time since I last felt like I was wasting my time.
> Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
I know it'll be touted as rhetoric but I have seen an order of magnitude of difference in my ability to ship things. Thankfully I don't work for a large enterprise so I don't have a multi-million line codebase to contend with or anything like that. I also, thankfully, ship projects using languages and libs that are very well represented in LLM corpuses, like TypeScript, NextJS, Postgres, though I have also found a lot of success in less popular things like Neo4j's Cypher.
I also have been massively enabled to do lots more 'ops' stuff. Being a pretty average full-stack eng means I have no experience of running sys/ops monitoring systems but LLMs only recently helped me with a bunch of docker-routing issues I was having, teaching me about Traefik, which I'd never heard of before.
Side-point: I have felt so grateful to these LLMs for freeing up a bunch of my brain space, enabling me to think more laterally and not relying so much on my working memory, severely limited now due to historic brain injury. Often people forget how massively enabling these tools can be for disabled people.
I can definitely see the 10% boost being accurate. Keep in mind, its not about doing everything 10% faster, its about being able to put out 10% more results by leveraging agentic coding when it makes sense.
This week I was able to tackle two long-standing bug fixes I've been noodling on and had a rough idea of what I needed to do but had competing priorities and a lack of time to sit down and really internalize the system to figure them out. I brain dumped the issue and my current thoughts and had claude formulate a plan. It solved each in less than 30 minutes of very light effort on my part. I was able to tack these onto larger work I'm doing basically seamlessly.
The other thing that I've found to be an insane benefit is filesystem-backed context switching. If your agentic workflow involves dumping your plan and progress to files in the filesystem, you can pause and restart work at any time by pointing at those files and saying "continue where you last left off". You can even take a `git diff > that-one-bug.patch` of edits made up to that point, copy that alongside the other files, and have a nice-and-neat folder of a unit of work that is ready to pick back up in the future as time permits.
Yes, most days I’m 2x as productive. I’m using Claude Code to produce extremely high quality code that closely follows my coding standards and the architecture of my app.
I don’t think people are good at self-reporting the “boost” it gives them.
We need more empirical evidence. And historically we’re really bad at running such studies and they’re usually incredibly expensive. And the people with the money aren’t interested in engineering. They generally have other motives for allowing FUD and hype about productivity to spread.
Personally I don’t see these tools going much further than where they are now. They choke on anything that isn’t a greenfield project and consistently produce unwanted results. I don’t know what magic incantations and combinations of agents people have got set up but if that’s what they call “engineering,” these days I’m not sure that word has any meaning anymore.
Maybe these tools will get there one day but don’t go holding your breath.
> They choke on anything that isn’t a greenfield project and consistently produce unwanted results.
That was true 8 months ago. It's not true today, because of the one-two punch of modern longer-context "reasoning" models (Claude 4+, GPT-5+) and terminal-based coding agents (Claude Code, Codex CLI).
Setting those loose an an existing large project is a very different experience from previous LLM tools.
I've watched Claude Code use grep to find potential candidates for a change I want to make, then read the related code, follow back the chain of function calls, track down the relevant tests, make a quick detour to fetch the source code of a dependency directly from GitHub (by guessing the URL to the raw file) in order to confirm a detail, make the change, test the change with an ad-hoc "python -c ..." script, add a new automated test, run the tests and declare victory.
That's a different class entirely from what GPT-4o was able to do.
All I've found is the LLM just makes me work more. It's hard to talk about % boost when you're just simply working more hours.
It's like having a faster car with a bigger engine. Big deal. I want a faster car with a smaller engine. My ideal is to actually go home and stop working at the end of the day.
I also don't want to use it for my day job because I'm afraid my brain will atrophy. You don't really need to think when something is already done for you. I don't want to become someone who can only join together LLM output. I don't feel like I'll miss out on anything by not jumping on now, but I do feel like I'll lose something.
At this point I'd say that I'm 1000% more productive in the aspects that I use it for. I rarely hit any walls, and if I do its absolutely always down to an unclear or incomplete thought progress or lack of clarity in prompting.
There's a lot of annoying stuff it can do fairly well without many guardrails. It's a minor productivity boost but it's nice not to have to do.
Doc comments for example. Today I had it generate doc comments for a class I wrote. I had to go and fix every single one of them because it did some dumb shit, but it out all the scaffolding in place and got the basics there so it was a lot quicker.
I also used it to generate json schemas from Python a couple of Python classes the other day. Highly structured inputs, highly structured output, so there wasn't much for it to fuck up. Took care of the annoying busy work I didn't want to do (not that schemas are busy work, but this particular case was).
Still haven't seen a use case that justifies the massive cost, or all the blatant theft and copy right infringement, or the damage to the environment...
Readit News
I took part in a lot of discussions then with other professional translators, and the reaction of many was similar to that of some of the commenters here: not only were they discouraged because their hard-earned language and translation skills no longer seemed needed, but using LLMs as assistants took the enjoyable challenge out of the translation process.
Nearly everyone I spoke with then worked from home as a freelancer, carefully crafting one translation at a time. They didn’t like the idea of becoming managers of large-scale translation projects, even if it meant they would be able to apply their higher-order intercultural communication skills.
I do only a little professional translation myself now, but I try to keep up with AI developments and I often use translation tasks to test the latest models and frameworks. Over the past few months, I have vibe-coded some multi-LLM translation systems where texts were passed through multiple models that checked, critiqued, and improved each other’s translations. For the texts I tried them on, the results were much better than any single-LLM translation, approaching the level of the very best human translation. The API calls weren’t cheap, but for high-stakes translations such a system would more than pay for itself.
When designing that “vibe translation” system, I did apply my experience as a translator, similarly to what Simon is recommending programmers do now with vibe engineering. At this stage in my life (I’m sixty-eight), I am fine with that. But if LLMs had arrived when I was, say, just five or ten years into my translation career and still proud of my nuts-and-bolts skills, I might very well have looked for another career rather than becoming a vibe translator.
On one side translation is not very valued by most people. It is rare that people know who translated a book, for example. It is a pity but people do not read much these days.
Additionally, or maybe because of the above, translation is often paid in terms of number of lines or words, even before AI. A bit like software security, it is often sadly just a check at the end.
IMHO the only future-proof translation fields are legal (because a human can be put in prison or pay a fine) or live translation/interpretation (because a human can go in front of people, meet them at an event, etc.).
This is a common belief, but it's just not true. The book industry is healthier than ever.
Fortunately I think anything pertaining to vibe coding/engineering/analytics is still more enjoyable and less grim than working on an assembly line, but the human feelings remain nonetheless.
My process starts from a Claude Code plan, whose first step is to write a spec. I use TDD, and enforce my "unspoken rules of code quality" using a slew of generated tools. One tiny tool blocks code which violates our design system. Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer. Watching the transcript I have to occasionally remind the model to use TDD, but once it's been reminded it doesn't need reminding again until compaction. Claude 4.5 is far better at remembering to do TDD than 4.1 was.
Code reviews are super simple with TDD due to the tests mirroring the code. I also create a simple tool which hands the PR and spec to Gemini and has it describe any discrepancies: extra stuff, incorrect stuff, or missing stuff. It's been great as a backup.
But ultimately there's no substitute for knowing what you want, and knowing how to recognize when the agent is deviating from that.
The opposite of "garbage-in garbage-out" is quality in => quality out.
I also landed on “agentic coding” FWIW. It’s a bit clunky but didn’t feel like an embarrassment to the entire software industry typing it so I’ll happily use it over the alternative.
Is that an llm agent or some other type of tool (e.g. language service or build toolset)?
A 100 line script finishes in milliseconds and burns no tokens. So you can run it hundreds of times per day.
The mindset is: will you need repeatability? If so, have the LLM write code, because code gives you determinism.
I don't know how vibe coding works, but how does this work - is the agent actually engaging in the red-green-refactor loop, or does it just generate the result all at once?
Deleted Comment
if you don't ask, it's much more likely to just one shot the whole thing, and may or may not get it right first time.
I prefer slop-coding.
I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of tools.
I said a version of this in the post:
> AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents.
A brand new vibe coder may be able to get a cool UI out of ChatGPT, but they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere. They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
Generative AI is at the same time incredibly impressive and completely unreliable. This makes it interesting, but also very uncertain. Maybe it's worth my investment to learn how to master today's agents, and maybe I'd be better off waiting until these things become better.
You wrote:
> Getting good results out of a coding agent feels uncomfortably close to getting good results out of a human collaborator. You need to provide clear instructions, ensure they have the necessary context and provide actionable feedback on what they produce.
That is true (about people) but misses out the most important thing for me: it's not about the information I give them, but about the information they give me. For good results, regardless of their skill level, I need to absolutely trust that they tell me what challenges they've run into and what new knowledge they've gained that I may have missed in my own understanding of the problem. If that doesn't happen, I won't get good results. If that kind of communication only reliably happens through code I have to read, it becomes inefficient. If I can't trust an agent to tell me what I need to know (and what I trust when working with people) then the whole experience breaks down.
I wonder what the practical limits are.
As a senior dev on a greenfield solo project it's too exhausting for me to have two parallel agents (front/back), most of the time they're waiting for me to spec, review or do acceptance test. Feels like sprinting, not something I could do day in and day out.
Might be due to tasks being too fine grained, but assuming larger ones are proportionally longer to spec and review, I don't see more than two (or, okay, three, maybe I'm just slow) being a realistic scenario.
More than that, I think we're firmly in the vibe coding (or maybe spec-driven vibe coding) territory.
How can anyone intellectually honest not see that? Same as burning fossil fuels is great and all except we're just burning past biomass and skewing the atmosphere contents dangerously in the process.
Which makes perfect sense - even putting aside the dopamine benefits of getting into a coding flow state.
Coding is craftsmanship - in some cases artistry.
You're describing Vibe Engineering as management. And sure, a great manager can make more of an impact increasing the productivity of an entire team than a great coder can make by themselves. And sure, some of the best managers are begrudging engineers who stepped up when needed to and never stepped down.
But most coders still don't want to be managers - and it's not from a lack of skill or interest in people - it's just not what they chose.
LLM-based vibe coding and engineering is turning the creative craftsmanship work of coding into technical middle management. Even if the result is more "productivity", it's a bit sad.
I think a lot of the points you make are exactly what I'm trying to do.
- start with a detailed roadmap (created by the ai from a prompt and written to a file)
- discuss/adjust the roadmap and give more details where needed
- analyze existing features for coding style/patterns, reusable code, existing endpoints etc. (write this to a file as well)
- adjust that as needed for the new feature/converted feature - did it miss something? Is there some specific way this needs to be done it couldn't have known?
- step through the roadmap and give feedback at each step (I may need to step in and make changes - I may realize we missed a step, or that there's some funky thing we need to do specifically for this codebase that I forgot about - let the LLM know what the changes are and make sure it understands why those changes were made so it won't repeat bad patterns. i.e. write the change to the .md files to document the update)
- write tests to make sure everything was covered... etc etc
Basically all the things you would normally WANT do but often aren't given enough time to do. Or the things you would need to do to get a new dev up to speed on a project and then give feedback on their code.
I know I've been accomplishing a lot more than I could do on my own. It really is like managing another dev or maybe like pair programming? Walk through the problem, decide on a solution, iterate over that solution until you're happy with the decided path - but all of that can take ~20 minutes as opposed to hours of meetings. And the end result is factors of time less than if I was doing it on my own.
I recently did a task that was allotted 40 hours in less than 2 working days - so probably close to 10-12 hours after adjusting for meetings and other workday blah blah blah. And the 40 hour allotment wasn't padded. It was a big task, but doing the roadmap > detailed structure including directory structure - what should be in each file etc etc cut the time down dramatically.
I would NOT be able to do this if I the human didn't understand the code extremely well and didn't make a detailed plan. We'd just end up with more bad code or bad & non-working code.
And were introduced to the stability of stirrups and saddle.
They were like daemons on those stirrup equipped horses. They had all the agility of wielding weapons and engaging in battle by hanging onto mane, and body with legs, yet now had (to them) a crazy easy and stable platform.
When the battle came, the Phoenicians just tore through those armies who had grown up with the stirrup. There was no comparison in skill or capability.
(Note: I'm positive some of the above may be wrong, but can't find the story and so am just stating it as best able)
My point is, are we in that age? Are we the last skilled, deeply knowledgeable coders?
I grew up learning to write eeproms on burners via the C64. Writing machine language because my machines were too slow otherwise. Needing to find information from massive paper manuals. I had to work it all out myself often, because no internet no code examples, just me thinking of how things could be done. Another person who grew up with some of the same tools and computers, once said we are the last generation to understand the true, full stack.
Now I wonder, is it the same with coding?
Are we it?
The end?
Honestly, I have a ton of experience in system administration, and I'm super comfortable at a command line and using AWS tooling.
But, my new approach is to delegate almost all of that to Claude, which can access AWS via the command-line interface and generate configuration files for me and validate that they work correctly. It has dramatically reduced the amount of time that I spend fiddling with and understanding the syntax of infra config files.
And unfortunately people who get to architect anything are a small subset of developers.
It's like if I were a gardener and I enjoyed touching dirt and singing to plants, and you're here on Gardener News extolling the virtues of these newfangled tractors and saying they'll accelerate my impact as a gardener. But they're so loud and unpleasant and frankly grotesque and even if I refrain from using one myself, all my neighbors are using them and are producing all their own vegetables, so they don't even care to trade produce anymore--with me or anyone else. So I look out at my garden with sadness, when it gave me such joy for so many decades, and try to figure out where I should move so I can at least avoid the fumes from all the tractors.
Neither can I, sadly. I have one brain cell and I can only really do one thing at a time. Doing more than one leads to a corrupted stack and I make exponentially more mistakes.
I was in the first batch last year where they introduced it and going to do the second one too.
It´s a very different kind of beast to what is currently being discussed.
Tech spent the last 10 years drilling into engineers' heads that scaling your impact is not about writing more or better code, but about influencing the work of other engineers through collaboration, process, documentation, etc. Even the non-managerial "senior IC" tracks are mostly about doing this with greater and and greater numbers of people. I wonder if we will start to see recognition in career tracks for people who are actually just extraordinarily productive by themselves or in small groups, or if you'll pretty much just have to be a startup founder to get paid for that.
Non developers can go from 0x to 1x. And I'm happy for people finally being able to learn about building software one way.
And then learn why vibe coding often creates more quickly disposable code.
But I'm also not ready to bet the farm on it. Seriously considering taking our savings and equity out of our house in a London adjacent area, and moving to a lower cost of living area, so that we're practically debt free. At that point we can survive on a full time minimum wage job, anything more than that is a bonus.
My experience with llms in general is that sadly, they're mostly good bullshitters. (current google search is the epitome of worthlessness, the AI summary so hard tries to make things balanced, that it just dreams up and exaggerates pros en cons for most queries). In a same way platforms like perplexity are worthless, they seem utterly unable to assign the proper value to sources they gather.
Of course that doesn't stop me from using llms where they're useful; it's nice to be able to give the architecture for a solution and let the llm fill the gaps than to code the entire thing by hand. And code-completion in general is a beautiful thing (sadly not a thing where much focus is on these days, most is on getting the llm create complete solutions while i would be delighted by even better code completion)
Still all in all, the more i see llms used (or the more i see (what i assume) well willing people copy/paste llm generated responses in favor of handwritten responses) on so much of the internet, resulting in a huge decline of factualness and reproducibility (in he sense, that original sources get obscured), but an increase of nice full sntences and proper grammar, the more i'm inclined to belief that in the foreseeable future llm's aren't a net positive.
(in a way it's also a perfect storm, the last decade education unprioritised teaching skills that would matter especially for dealing with AI and started to educate for use of tools instead of educate general principles. The product of education became labourers for a specific job instead of higher abstract level reasoning in a general area of expertise)
I’ll find the link in the morning, but I kinda joke - it’s vibe coding for people who know how to define a problem and iterate on it.
I’ve got a project reimplementing a service I want to make more uniform. Claude has produced a lot of stuff that would have taken me weeks to do.
It sounds stressful, like the ultimate manager job. Not what I signed up for.
But I also still hold onto this idea that shipping tons of iterations of "stuff" was never really the problem. Early in my dev experience I wanted to code everything all day every day. And I did and that's how I learned. And now in my second decade I switched to "why code anything?". In a business sense I mean, coding the thing is almost never the missing piece.
I joke in meetings that the answer is always "yes" whenever cross-functional teams ask "can we do this?". "How hard would x be?". For tech teams the answer _is_ always YES! I get that out of the way because that's never the right question to ask.
Which makes the hardest problem in software even harder: what should we build? It doesn't matter how fast you can move if you're consistently solving the wrong problems.
It shouldn't. The agents are not good enough to be used in a fleet.
I have Claude. It's fine, but I'm pretty confident that my low usage of Claude would out-compete a fleet of agents, because it feels like there's an inverse correlation between the number of tokens you spend and the quality of the resulting code (more tokens = more code to review, more bad code slips through)
This is where we should be. Using computers to solve problems. Not just "doing programming".
Raise your head, look towards the horizon.
If managing a bunch of AI agents is a very un-fun way to spend time, then I don’t think it’s the future. If the new way of doing this is more work and more tedium, then why the hell have we collectively decided this is the new way to work when historically the approach has been to automate and abstract tedium so we can focus on what matters?
The people selling you the future of work don’t necessarily know better than you.
I’m a professional software engineer in Silicon Valley, and I’m fortunate to have been able to work on household-name consumer products across my career. I definitely know how to do “real” professional work “at scale” or whatever. Point is, I can do real work and understand things on my own, and I can generally review code and guide architecture and all that jazz. I became a software engineer because I love creating things that I and others could use, and I don’t care about “solving the puzzle” type satisfaction from writing code. In engineering school, software had the fastest turnaround time from idea in my head to something I could use, and that’s why I became a software engineer.
LLM assisted coding accelerates this trend. I can guide an LLM to help me create things quickly and easily. Things I can mostly create myself, of course, but I find it faster for a whole category of easy tasks like generating UIs. It really lowers the “activation energy” to experiment. I think of it like 3D printing, where I can prototype ideas in an afternoon instead of long weekend or a few weeks.
It's not even just that. Every single thing in tech right now seems to be AI this, AI that, and AI is great and all but I'm just so tired. So very tired. Somehow even despite the tools being impressive and getting more impressive by the day, I just can't find it in me to be excited about it all. Maybe it's just burnout I'm not sure, but it definitely feels like a struggle.
But also yes, look into moving into a different field. Professional software engineering is gonna be infected with AI bullshit for a long while. Move into a field where hand-crafted code can make a difference, but not where you're paid for the line committed or have to compete with "vibe coding" KPIs.
code is code. if it works, nobody gives a shit. Market will adapt to be fault-tolerant. Look at all the value created by javascript.
Also, FYI, I am writing some of most efficient code using AI.
As an example, I would have never considered learning to use blender for 3d modeling in a game before having access to an LLM. The ability to quickly iterate through plausible 3d workflows and different design patterns is a revelation. Now, I can get through some reasonably complex art pipelines with a surprising amount of confidence. UV mapping I would have never learned without being able to annoy one of OAI's GPUs for a few hours. The sensation of solving a light map baking artifact on a coplanar triangle based upon principles developed from an LLM conversation was one of the biggest wins I've had in a long time.
The speed with which you can build confidence in complementary skills is the real super power here. Clean integration of many complex things is what typically brings value. Obsession with mastery in just one area (e.g. code) seems like the ultimate anti-pattern when working with these tools. You can practically download how to fly a helicopter into your brain like it's the matrix now. You won't be the best pilot on earth, but it might be enough to get you to the next scene.
If it's any consolation, I do think the non-technical users have a bigger hill to climb than the coders in many areas. Art is hard, but it is also more accessible and robust to failure modes. A developer can put crappy art in a game and ship it to steam. An artist might struggle just to get the tooling or builds working in the first place. Even with LLM assistance there is a lot to swim through. Getting art from 5% to 80% is usually enough to ship. Large parts of the code need to be nearly 100% correct or nothing works.
My experience with them is they are fragile monstrosities, that are only permitted to exist at all because leadership is buying into the same hype that is irrationally propping up the companies running the models that make these things possible.
To be clear, my experience hasn't been that I don't like them, it's that they don't really work at all. They're constantly under development (often in the dark) and when a ray of light is cast on them they never successfully do the thing promised.
Cleaning up the messes left behind by these has my skills feeling more valuable then ever before.
I have a team of 10 engineers, the quality of the code they produce together with the LLM of the day correlates even more with the experience.
My impression over the past 6 months - before we had no "official" access to LLM, is that they increase the gap between junior and experienced developers.
Note that this is my limited impression from a team of 10 engineers. This matches with Simon's feeling in a good way for you!
There are exceptions of course - where you need to squeeze wonders from the hardware - but the majority of dev works boils to understanding the problem and finding the right answers.
In the vast majority of programming jobs out there you are not paid to solve problems: you are told very clearly what to do, how to do it and what technology you have to use for the job.
People don't hire analysts they hire "Java programmers".
I've been working on a character sheet application for a while, and decided to vibe-code it with Spec-kit to help me write up a specification, and for things I know it's been great. I tried using Claude to make it into a PWA (something I don't know very well) as an experiment, and I've found the nanosecond the model strays out of my experience and knowledge everything goes straight to Hell. It wraps my codebase around a tree as if I'm not paying attention while driving.
It's a tool you'll have to learn to use, but I can say with absolute confidence it's no replacement for actual skills, if anything it highlights the gulf between people who know what they're doing and people who don't, for better and worse. It sacrifices some of the 'code under your fingers' feeling for management tasks, which I personally really like, as I've always wanted to document/test/code review/spec things out better, and I now understand the pain of people who'd rather not do that sort of thing.
https://github.com/github/spec-kit
I don't want it, I don't use it, I carry on as if it never existed, and they still pay me a lot.
If I really need to use agents some day I will bite the bullet, but, not today.
Literally all I use LLMs for is to ask ChatGPT about some dumb thing or two instead of asking StackOverflow as I did 5 years ago. Works for me.
Offshoring software development means letting lower-payed software developers from somewhere far away do the actual programming, but they have a very different culture than you, and they typically don't share your work context, don't really have a feeling for how the software is used -- unless you provide that.
Now we're offshoring to non-sentient, mostly stateless instances of coding agents. You still have to learn how to deal with them, but you're not learning about a real human culture and mindset, you learn about something that could be totally changed with the next release of the underlying model.
The LLM will not save you when everything is on fire and you need to fix things. The context window is simply not big enough. It could be your last change, it could also be a change six months ago that is lost in the weeds.
Like, where are all the amazing vibe-coded games we were promised? These guys should be eating my lunch, but they're not.
Tools always empower those with knowledge further than those without knowledge.
LLMs are a force multiplier
I'm currently looking into other professions, but the future looks bleak for most kinds of knowledge work.
The reason we invest this time in Junior devs is so they improve. LLMs do not
I've found two things useful:
1) Keep a personal work log, where you - in short bullet points - can document the progress of the task you were last working on, and can keep track of how many parallel tasks there are currently going on. If you can match it with Jira tickets, all the better, but as this is for personal use only, you can also add tasks that are not tracked in Jira at all.
2) If you cannot avoid context switches, make them explicit: Instead of trying to hold 3 tasks in your head at the same time, decide consciously if you want to switch what you're currently working on. If yes, take a few minutes to "suspend" the current task by saving and committing everything (as WIP commits if necessary) and writing all you need to remember into the worklog.
For decades now, we are trying to lower the barrier to entry in software development. We created Python, web frameworks and mobile development so easily accessible that you can become software developer by completing a short online boot camp. There is a lot of software developers posting here now who, 20 years ago, would not even consider this job because it would be way over their abilities.
This forum is equivalent if you had a forum about civil transportation that gathers airline pilots and uber drivers. Technically, they both do the same work. Just like in that forum, uber drivers would outnumber airline pilots and skew the topics related to their experience, here we get pushed topics about new frameworks, and AI assisted tools.
When I started working professionally 20 years ago, you could only get job in big companies working on big projects. No one else could afford a cost of custom software. Today, we reduced development costs and we have a huge pool of potential customers who can now afford services of software developers. Web shops, gambling sites, porn sites... This is the majority of software development work today. Boring repetitive tasks of gluing some imported modules together.
Serious development work didn't disappear. It is just not talked about here. There is still a need people who know what they are doing.
My advise is that if you want a satisfying development career, steer clear of latest hypes and don't go blindly following techbro lemmings. And most importantly, don't take career advice from anyone who finds his job so unsatisfying and tedious that he is trying to make AI do it for him. That's a major red flag.
Its industry own fault that it is in the position that it is right now, and it will shift and change embrace it. I only wish I had your experience building software in professional environment.
You can literally build anything right now if you have the experience, I personally can't understand if the models are hallucinating hence the lack of experience writing and understanding code. However I always wanted to pivot into the industry but couldn't, hiring practices are brutal, internships are non-existent, junior roles are I think what senior used to be and the whole hr process is I don't know how to put it.
By using LLMs I can now build UIs, build functionality, iterate over design choices, learn about database design, etc. hopefully I will escape the tutorial hell and have my own working full stack web app soon.
Pivot to creating and then sale your product.
I'm feeling the same. The moves I'm considering are
1. Landscaping 2. Carpentry 3. Small scale agriculture
(All made easier by a cushion of investments that are most of the way to passive income, so the new thing doesn't really have to make me that much money.)
I'm preparing mentally for my day-job to stop being fun (it still beats most other occupations I guess), and keep my side/hobby-projects strictly AI-free, to keep my sanity and prevent athropy.
I just hope we'll get out of this weird limbo at some time, where AI is too good to ignore, but too unreliable to be left alone. I don't want to deal with two pressures at work.
I want tools that are smarter, but still 100% correct at what they do.
Any tools/languages that address this gap?
I've always been fascinated by AST traversal and advanced refactoring tools - things like tree-sitter or Facebooks's old codemod system https://github.com/facebookarchive/codemod
I never used them, because the learning curve in them was steep enough that I never found the time to climb it to the point that I could start solving problems.
Modern LLMs know all of these tools, which flattens that curve for me - I find it much easier to learn something like that if I can start from semi-working examples directly applicable to what I'm trying to do.
I can focus on actually solving problems rather than on writing clever and/or cute-looking code, which ironically also gives me more time later to over-optimize stuff at my leisure.
If I have a clear idea of some algorithm I am trying to write, I have a concise method for expressing it already, and it ain't English.
I suppose the other thing I would say is that reading code and understanding is definitely not the same as writing code and understanding it in terms of depth of understanding, and I think this notion that reviewing the outputs ought to be enough fails to capture the depth of understanding that comes with actually crafting it. You may not think this matters, but I'm pretty sure it does.
Deleted Comment
Aaand that's startup founder life :)
Intense multitasking, needing to accept a lower engineering quality bar, and ignoring scale problems because you don't know if anyone will actually buy the thing you're building yet.
Engineering something that you know you'll redo in 1 month is very different from engineering something that you intend to last for 5+ years, but it's still a fun challenge picking the right tradeoffs and working under different constraints.
Deleted Comment
Sales is the definition of high-pressure, and your output is always threatened by forces beyond your control. It doesn't consistently reward intelligence or any particular skill other than hustle.
There's nothing like sw dev that lets you sit at your desk and ignore the outside world while getting paid for delivering biz-critical milestones. Even creatives don't have this kind of potential autonomy.
it does awesome in demos. it has a real use.
but
it gets a long training period when one makes mistakes with it, it is big mistakes that take long to fix
Dead Comment
But indeed, the fun part of coding a couple of routines is gone. That is history.
Famously, some of those subpar products are now household names who were able to stake out their place in the market because of their ability to move quickly and iterate. Had they prioritized long-maintainable code quality rather than user journey, it's possible they wouldn't be where they are today.
"Move fast and break things" wasn't a joke; Mark really did encourage people to build faster and it helped cement their positioning. Think of the quantity of features FB shoveled out between 2009-2014 or so, that just wouldn't have been possible if their primary objective was flawless code.
The code isn't the product, the product is the product. In all my years of engineering I've yet to have an end-user tell me they liked my coding style, they've always been more concerned with what I'd built them.
Famously gmail was very good quality web app and code(can't say the same today) surely not the product of today's "fast iteration" culture
I don't really see it as an example of what you're saying so much as an example of success as a product having to do with far more than explicit product features. You can see a similar dynamic in other natural monopoly markets. The NBA didn't necessarily do anything particularly right product wise, for instance. They just got the best players because basketball was historically more popular in the US than other countries, and the ABA made some stupid decisions that let the NBA win out in the US.
Hell, the US itself didn't do a whole lot "right" aside from not being in Europe when Europe decided to destroy itself, being better-positioned than other potential competitors like Canada, Mexico, and Australia simply because North America is best positioned to trade with both Europe and Asia and the US is more temperate than Canada or Mexico. But we sure like to tell ourselves stories about everything we did right.
Some of us are building prototypes, and others are building software with a 10 year horizon or work with sensitive personal data.
So on the one side you get people that are super efficient cranking things out, and others that read this and feel appalled anyone would be comfortable with this and see software engineering as theory building. Neither are really wrong here, but the context / risk of what people are working on always seems to be missing when people talk about this.
I am just as pissed as anybody else at the lack of certainty in the future.... Thought I had my career made. So it's not that I don't emphatize with engineers in my shoes.
* There is no objective reality, there isn't one in physics, it's just a non argument * "LLM's help a damn lot in speed of development" That may be your experience and my whole point was arguing that speed may not matter * "Genie is out of the bag, you have to go with the flow, adapt or else" I choose else if this the apex of the argument
Dead Comment
The same reason we've always needed them:
1: They prevent regressions. (IE, bugs in features that were shipped and already working.)
2: They are very easy to run at the push of a button in your IDE. (But in this context the LLM runs them.)
3: They run in CI. This is an important line of defense in making sure a pull request doesn't introduce a bug.
Now, depending on what you're writing, you might not need unit tests! Perhaps you're trying to get a minimum viable product out the door? Perhaps you're trying to demo a feature to see if it's worth building? Perhaps you're writing a 1-off tool that you'll run a few times and throw away?
But, understand that if you're writing an industrial-strength program, your unit tests help you ship bug-free software. They allow you to do some rather major refactors, sometimes touching areas of the codebase that you only lightly understand, without needing to manually test everything.
(And, to keep it in context,) your LLM will also have the same benefits from this tired-and-true process.
We all agree, the people that _feel_ the most productivity spike are the sub-par engineers. That shouldn't be controversial, and it's even predictable. But their volume can't be taken as an argument one way or the other.
The question is, are there _any_ good engineers that don't just feel more productive, but objectively are.
Let's even concede that speed of delivery indeed is an actual factor, there has to be a threshold. There's a point where people just don't care how fast you're putting out features, because your product has found its sweet spot and is perfectly scratching its market's itch. A few will clearly notice when the line of diminishing returns is crossed and if they can reset their outlook to fit the new context, a continuous focus on speed of delivery will look increasingly obsessive and nonsensical.
But that's the reality of the majority of the software development world. Few of us work on anything mission critical. We could produce nice sane software at a reasonable pace with decent output, but we're sold the idea that there's always more productivity to squeeze and we're told that we really really want that juice.
Trivial software is software for which
- the value of which the software solution is widely accepted and widely known in practice and
- formal verification exists and is possible to automate or
- only has a single satisfying possible implementation.
Most software is non-trivial.
There will always be:
- bugs in implementation
- missed requirements
- leaky abstractions
- incorrect features with no user or business value
- problems with integration
- problems with performance
- security problems
- complexity problems
- maintenance problems
in any non-trivial software no matter how "good" the engineer producing the code is or how "good" the code is.
These problems are surfaced and reduced to lie within acceptable operational tolerances via iterative development. It doesn't matter how formal our specifications are or how rigorous our verification procedures are if they are validated against an incorrect model of the problem we are attempting to solve with the software we write.
These problems can only be discovered through iterative acceptance testing, experimentation, and active use, maintenance, and constructive feedback on the quality of the software we write.
This means that the overall quality of any non-trivial software is dominated by the total number of quality feedback loops executed during its lifetime. The number of feedback loops during the software's lifetime are bound by the time it takes to complete a single synchchronous feedback loop. Multiple feedback loops may be executed in parallel, but Amdahl's law holds for overall delivery.
Therefore, time to delivery is the dominant factor to consider in order to produce valuable software products.
Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.
I'll reply just to that as it being the tldr. First of all tech debt is a thing and it's the thing that accumulates mostly thanks to fast feedback iterations. And in my experience the better the comunication, to get the implementation right, and the better the implementation and it happens that you can have solid features that you'll unlikely ever touch again, user base habit is also a thing, continuing on interating on something a user knows how to use and changing it is a bad thing. I'd also argue it's bad product/project management. But my whole original argument was why we'd need to have a greater speed in the first place, better tooling doesn't necessarily means faster output, productivity as well isn't measured as just faster output. Let me make a concrete example, if you ask an LLM X to produce a UI with some features, most of them will default to using React, why? Why can't we question the current state of web instead of continue to pile up abstractions over abstractions? Even if I ask the LLM to create a vanilla web app with HTML, why can't we have better tooling for sharing apps over the internet? The web is stagnant and instead of fixing it we're building castles over castles over it
It is imperative that you do not kill me when delivering my breakfast!
You must not make your own doors by punching holes in the wall!
It is critical that you remember that humans cannot regrow limbs!
Thus what you are doing is closer to pigeons bobbing their heads to attempt to influence the random reward machine than it is to engineering.
For example saying things like “It is critical that you don’t delete working code” might actually be a valid general technique, or it might have just been something that appeared to work because of randomness, or it might be something that is needed for current models but won’t be necessary in a few months.
The nature of LLMs makes correctly identifying superstition nearly impossible. And the speed with which new models are released makes trying to do so akin to doing physics in a universe where the laws of nature are constantly changing.
You’re an alchemist mixing gunpowder and sacrificing chickens to fire spirits, not an engineer, and for the foreseeable future you have no hope of becoming an engineer.
I’m also highlighting the insanely addictive nature of random rewards.
“One bird was conditioned to turn counter-clockwise about the cage, making two or three turns between reinforcements. Another repeatedly thrust its head into one of the upper corners of the cage. A third developed a 'tossing' response, as if placing its head beneath an invisible bar and lifting it repeatedly. Two birds developed a pendulum motion of the head and body, in which the head was extended forward and swung from right to left with a sharp movement followed by a somewhat slower return.”
“The experiment might be said to demonstrate a sort of superstition. The bird behaves as if there were a causal relation between its behavior and the presentation of food, although such a relation is lacking.”
https://en.wikipedia.org/wiki/B._F._Skinner
Dead Comment
But then the original meaning of vibe-coding -- as in, "Take the wheel, LLama of God" -- does need a new term, because that will also be a lasting phenomenon. I propose "Yolo-Coding" -- It fits in nicely with the progression of No-Code, Low-Code, Yolo-Code.
I don't like the term vibe engineer, but do agree there needs to be a term to signifiy the difference.
It's also possible in the future just being called a developer/engineer already implies you use coding agents and the people who do it "by hand" will not be the norm.
It's a bit more technical. And it has a three-letter acronym. Gotta have a three letter acronym.
Hmm another idea is "extreme vibe coding" as opposed to "extreme programming",
but those who did "extreme vibe coding" wouldn't know what it meant
(To be clear, I'm not saying the current meaning is not what you say, just that English isn't prescriptivist like this)
News to me. AI-assisted coding is more auto-complete or having it trying to make sense of awful documentation.
Vibe coding to means a number of things.
- The person has no skill in understanding what the LLM wrote. - The code created hasn't been reviewed in any way to look for possible future issues. - Technical debt from the get go. - Legally your application is screwed.
For me the single killer of vibe coding is that anything the LLM creates cannot be protected/copyrighted. UK has some laws that might offer a little protection, but EU/US you are pretty much screwed.
Deleted Comment
And, well, inventing new terms is also a popular way to get attention, which this author also did.
There's not point in trying to chase after shifting word meaning, if people are always going to try to shift it again.
You want something to inspire engineers to do their best work.
When you can expand your capabilities using the power of AI, then yeah, you can do your best work; hence augmented engineering.
But vibing? Not so much.
I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
> gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
Gives you access to the power to access and {mis}understand the {most repaeted over the last 1-10 years} engineering {errors, myths, misunderstandings, design flaws}, on demand, which you then can apply to your work {to further bias the dataset for future models to perpetuate the slop}.
Do NOT trust AI agents. Check their work at every level, find any source they claim to use, and check its sources to ensure that itself isn't AI too. They lie beyond their datasets, and their datasets are lying more for every minute that pass.
Now, seriously though, no tools is perfect, and I agree we should not trust it blindly, but leaving aside AI Agents, LLMs are very helpful in illuminating one's path, by consulting a large body of knowledge on demand, particularly when dealing with problems which might be new to you, but which have already been tackled one way or another by other people in the industry (provided they're in the training set of course).
Yes, there's always the risk of perpetuating existing slop. But that is the risk in any human endeavor. The majority of people mostly follow practices and knowledge established by the few. How many invent new things?
To be honest, I haven't yet used AI agents, I'm mostly just using LLMs as a dialogue partner to further my own understanding and to deepen my knowledge. I think we're all still trying to figure it out how to best use it.
Dead Comment
I don't think it necessarily deserves a special name. It is just engineering. You don't say book assisted engineering when you use a book as a reference. It is just engineering.
> But vibing? Not so much.
Just call it yolo engineering. Or machine outsourced irresponsible lmao engineering.
> I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
Oh god.
I see how if you can't really code, or you're new to a domain, then it can make a huge difference getting you started, but if you know what you're doing I find you hit a wall pretty quickly trying to get it to actually do stuff. Sometimes things can go smoothly for a while, but you end up having to micromanage the output of the agent too much to bother. Or sacrifice code quality.
Prior to vibe-coding, it would've been an arduous enough task that I would've done one implementation, looked at the time it took me and the output, and decided it was probably good enough. With vibe-coding, I was able to prototype three different approaches which required some heavy lifting that I really didn't want to logic out myself and get a feel for if any of the results were more compelling than others. Then I felt fine throwing away a couple of approaches because I only spent a handful of minutes getting them working rather than a couple of hours.
For stuff that I’m bad at? Probably more than 1000%. I’ve used it to make a web app, write some shader code, and set up some rtc streaming from unreal engine to the browser. I doubt I would have done them at all otherwise tbh. I just don’t have the energy and interest to conclude that those particular ventures were good uses of my time.
And you can do this for anything
But if I give it a code example that was written by humans and ask it to explain the code, it gives pretty good explanations.
It's also good for questions like "I'm trying to accomplish complicated task XYZ that I've never done before, what should I do?", and it will give code samples that get me on the right path.
Or it'll help me debug my code and point out things I've missed.
It's like a pair programmer that's good for bouncing ideas, but I wouldn't trust it to write code unsupervised.
> […]
> Or it'll help me debug my code and point out things I've missed.
I made both of these statements myself and later wondered why I had never connected them.
In the beginning, I used AI a lot to help me debug my own code, mostly through ChatGPT.
Later, I started using an AI agent that generated code, but it often didn’t work perfectly. I spent a lot of time trying to steer the AI to improve the output. Sometimes it worked, but other times it was just frustrating and felt like a waste of time.
At some point, I combined these two approaches: I cleared the context, told the AI that there was some code that wasn’t working as expected, and asked it to perform a root cause analysis, starting by trying to reproduce the issue. I was very surprised by how much better the agent became at finding and eventually fixing problems when I framed the task from this different perspective.
Now, I have commands in Claude Code for this and other due diligence tasks, and it’s been a long time since I last felt like I was wasting my time.
Have you isolated if you're properly honing in on the right breadth of context for the planned implementation?
I know it'll be touted as rhetoric but I have seen an order of magnitude of difference in my ability to ship things. Thankfully I don't work for a large enterprise so I don't have a multi-million line codebase to contend with or anything like that. I also, thankfully, ship projects using languages and libs that are very well represented in LLM corpuses, like TypeScript, NextJS, Postgres, though I have also found a lot of success in less popular things like Neo4j's Cypher.
I also have been massively enabled to do lots more 'ops' stuff. Being a pretty average full-stack eng means I have no experience of running sys/ops monitoring systems but LLMs only recently helped me with a bunch of docker-routing issues I was having, teaching me about Traefik, which I'd never heard of before.
Side-point: I have felt so grateful to these LLMs for freeing up a bunch of my brain space, enabling me to think more laterally and not relying so much on my working memory, severely limited now due to historic brain injury. Often people forget how massively enabling these tools can be for disabled people.
This week I was able to tackle two long-standing bug fixes I've been noodling on and had a rough idea of what I needed to do but had competing priorities and a lack of time to sit down and really internalize the system to figure them out. I brain dumped the issue and my current thoughts and had claude formulate a plan. It solved each in less than 30 minutes of very light effort on my part. I was able to tack these onto larger work I'm doing basically seamlessly.
The other thing that I've found to be an insane benefit is filesystem-backed context switching. If your agentic workflow involves dumping your plan and progress to files in the filesystem, you can pause and restart work at any time by pointing at those files and saying "continue where you last left off". You can even take a `git diff > that-one-bug.patch` of edits made up to that point, copy that alongside the other files, and have a nice-and-neat folder of a unit of work that is ready to pick back up in the future as time permits.
No, I just put in less effort to arrive at the same point and do no more.
We need more empirical evidence. And historically we’re really bad at running such studies and they’re usually incredibly expensive. And the people with the money aren’t interested in engineering. They generally have other motives for allowing FUD and hype about productivity to spread.
Personally I don’t see these tools going much further than where they are now. They choke on anything that isn’t a greenfield project and consistently produce unwanted results. I don’t know what magic incantations and combinations of agents people have got set up but if that’s what they call “engineering,” these days I’m not sure that word has any meaning anymore.
Maybe these tools will get there one day but don’t go holding your breath.
That was true 8 months ago. It's not true today, because of the one-two punch of modern longer-context "reasoning" models (Claude 4+, GPT-5+) and terminal-based coding agents (Claude Code, Codex CLI).
Setting those loose an an existing large project is a very different experience from previous LLM tools.
I've watched Claude Code use grep to find potential candidates for a change I want to make, then read the related code, follow back the chain of function calls, track down the relevant tests, make a quick detour to fetch the source code of a dependency directly from GitHub (by guessing the URL to the raw file) in order to confirm a detail, make the change, test the change with an ad-hoc "python -c ..." script, add a new automated test, run the tests and declare victory.
That's a different class entirely from what GPT-4o was able to do.
It's like having a faster car with a bigger engine. Big deal. I want a faster car with a smaller engine. My ideal is to actually go home and stop working at the end of the day.
I also don't want to use it for my day job because I'm afraid my brain will atrophy. You don't really need to think when something is already done for you. I don't want to become someone who can only join together LLM output. I don't feel like I'll miss out on anything by not jumping on now, but I do feel like I'll lose something.
Doc comments for example. Today I had it generate doc comments for a class I wrote. I had to go and fix every single one of them because it did some dumb shit, but it out all the scaffolding in place and got the basics there so it was a lot quicker.
I also used it to generate json schemas from Python a couple of Python classes the other day. Highly structured inputs, highly structured output, so there wasn't much for it to fuck up. Took care of the annoying busy work I didn't want to do (not that schemas are busy work, but this particular case was).
Still haven't seen a use case that justifies the massive cost, or all the blatant theft and copy right infringement, or the damage to the environment...