6 ms·

AI didn't simplify software engineering: It just made bad engineering easier

128 points by birdculture 8mo ago

woeirua 8mo ago
How many model releases are we away from people like this throwing in the towel? 2? 3?
sshine 8mo ago
It also made good engineering easier. AI is an amplifier of existing behavior.
- tinmandespot 8mo ago
  “ AI is an amplifier of existing behavior” Apropos. I’m stealing that line.
- qsera 8mo ago
  Internet enabled instant to access to all human knowledge as well as instant chit-chat across the globe. Guess what humanity choose to drown itself in? So combine both facts here in context, with human nature, and you ll see where this will go.
- genghisjahn 8mo ago
  I love that I don’t have to look thru SO looking for a problem that’s kind of like the one I’m having. I have a problem solved based on my exact code taking my entire code base into account. And if I want a biting sarcastic review of my many faults as a software developer, I can ask for that too.
  - sshine 8mo ago
    I have, in the last month, resorted to searching StackOverflow for something that works when Claude perpetually got it wrong three times in a row. It felt nostalgic that the answer was there in plain sight, and it just kept trying other things. So searching StackOverflow isn't quite dead yet.
    - genghisjahn 8mo ago
      Of course I still have times when Claude fumbles the fix. But the number of times it gets it exactly right far outnumber the times it can't get right. Compare that to the number of SO issues I've had to go through to get near a solution is night and day. I'm in no way saying you should work the way I do or that Claude would solve all your problems if you only just believe. I am saying it's been super helpful at squashing bugs for me in my circumstances with my code bases.
- staticassertion 8mo ago
  I think it's easier for good engineers to be good, perhaps. For example, I think property testing is "good" engineering. But I suspect that if you took a survey of developers the vast majority would not actually know what property testing is. So is AI really of any use then for those devs?
- keeda 8mo ago
  Yep, and recent reports from the likes of DORA and DX validate this with data: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report https://cloud.google.com/blog/products/ai-machine-learning/a...
- maplethorpe 8mo ago
  I think it depends on your process. Problems that require creative solutions are often solved through the act of doing. For me, it's the act of writing code itself that ignites the pathways and neural connections that I've built up in my brain over the years. Using AI circumvents that process, and those brain circuits go unused.
sunir 8mo ago
Simplify? It’s like saying a factory made chair building… what? It’s not simpler. It’s faster and cheaper and more consistent in quality. But way more complex.
- yakattak 8mo ago
  Anecdotally I have not seen consistency in quality at all.
  - sunir 8mo ago
    My chairs resemble each other. Have you tried ikea? If you are talking about code which isn’t what I said, then we aren’t there yet.
    - groundzeros2015 8mo ago
      It’s a bad analogy because the benefits of industrial machines were predictable processes done efficiently.
      - sunir 8mo ago
        That came later than the beginning. Workhouses came before the loom. You can see this in the progression of quality of things like dinner plates over time. Making clay pottery can be simple. But to make “fine china” with increasingly sophisticated ornamentation and strength became more complex over time. Now you can go to ikea and buy plates that would be considered expensive luxuries hundreds of years ago.
        j3k3 8mo ago
        Yeah... nah. As others have said, your analogy does not hold up to scrutiny.
        groundzeros2015 8mo ago
        You’re not addressing any points I made.
groundzeros2015 8mo ago
I’m an AI skeptic and in no sense is it taking my peers job. But it does save me time. I can do research much better than Google, explore a code base, spit out helper functions, and review for obvious mistakes.
- coffeefirst 8mo ago
  Yep. And the more time I spend with the agents the more I’m convinced that your way is the endgame.
- gitaarik 8mo ago
  So what do you mean with being a sceptic? I thought you meant you weren't convinced of it's usefulness, and therefore don't use it. But you do seem to use it, so what is it you're sceptible about?
  - groundzeros2015 8mo ago
    I’m skeptical that it’s very smart, that it can solve hard problems, and that it’s accelerating. I’m skeptical vibe coding is really viable or saves you time.
    - gitaarik 8mo ago
      Ok, so what are you actually using it for?
      - gitaarik 8mo ago
        Oh sorry, I see in your original post you use it for research, codebase exploration, and small coding tasks. I think you hit the nail on the head with that AI is ultimately not smart, it'll be dependent on humans for a long time, and we have to review their work, so they won't easily replace us. In that sense I'm also sceptical; the idea that AI can soon replace us. But I'm not sceptical about the power of AI as a tool for humans. I'm actually quite convinced by that by now. Hence my confusion of your remark. But I think we understand the misunderstanding now.
shablulman 8mo ago
[dead]
a_void_sky 8mo ago
"Coding was never the hard part. Typing syntax into a machine has always been the least interesting part of building a system." and I think these people are benefitting from it the most, people with expertise, who know their way around and knew what and how to build but did not want to do the grunt work
- embedding-shape 8mo ago
  Slight adjustment, but I'd see "maintaining code" is the same as before, matters more the people and their experience and knowledge how to manage that. But agree that the literal typing was never the difficult part, knowing what code should and shouldn't be written was a hard part, and still remains a hard part. Right now, "what code shouldn't be written" seems to have become an even more important part, as it's so easy to spit out huge amounts of code, but that's the lazy and easy way, not the one that let you slowly add in features across a decade, rather than getting stuck with a ball of spaghetti after a weekend of "agent go brrr".
  - a_void_sky 8mo ago
    this is where years of experience working with freshers and junior devs helps, AI is smart enough to exactly do if you clearly tell it what to do and how unless you understand every inch of system and foresee what issues can be created by what kind of change, things will break when using AI
- j3k3 8mo ago
  I think that captures a lot of the LLM debate. There are people who just want an object produced that allows for some outcome to be achieved closer to the present. And there are other people who want to ensure that object that is produced, will be maintainable, not break other parts of the system etc. Neither party is wrong in what they want. I think there should naturally be a split of roles - the former can prototype stuff so other individuals in the organisation can critique whether it is a thing of value / worth investing in for production.
  - 8mo ago
staticassertion 8mo ago
> Code Was Never the Hard Part I can't believe this has to be said, but yeah. Code took time, but it was never the hard part. I also think that it is radically understated how much developers contribute to UX and product decisions. We are constantly having to ask "Would users really do that?" because it directly impacts how we design. Product people obviously do this more, but engineers do it as a natural part of their process as well. I can't believe how many people do not seem to know this. Further, in my experience, even the latest models are terrible "experts". Expertise is niche, and niche simply is not represented in a model that has to pack massive amounts of data into a tiny, lossy format. I routinely find that models fail when given novel constraints, for example, and the constraints aren't even that novel - I was writing some lower level code where I needed to ensure things like "a lock is not taken" and "an allocation doesn't occur" because of reentrancy safety, and it ended up being the case that I was better off writing it myself because the model kept drifting over time. I had to move that code to a separate file and basically tell the model "Don't fucking touch that file" because it would often put something in there that wasn't safe. This is with aggressively tuning skills and using modern "make the AI behave" techniques. The model was Opus 4.5, I believe. This isn't the only situation. I recently had a model evaluate the security of a system that I knew to be unsafe. To its credit, Opus 4.6 did much better than previous models I had tried, but it still utterly failed to identify the severity of the issues involved or the proper solutions and as soon as I barely pushed back on it ("I've heard that systems like this can be safe", essentially) it folded completely and told me to ship the completely unsafe version. None of this should be surprising! AI is trained on massive amounts of data, it has to lossily encode all of this into a tiny space. Much of the expertise I've acquired is niche, borne of experience, undocumented, etc. It is unsurprising that a "repeat what I've seen before" machine can not state things it has not seen. It would be surprising if that were not the case. I suppose engineers maybe have not managed to convey this historically? Again, I'm baffled that people don't see to know how much time engineers spend on problems where the code is irrelevant. AI is an incredible accelerator for a number of things but it is hardly "doing my job". AI has mostly helped me ship trivial features that I'd normally have to backburner for the more important work. It has helped me in some security work by helping to write small html/js payloads to demonstrate attacks, but in every single case where I was performing attacks I was the one coming up with the attack path - the AI was useless there. edit: Actually, it wasn't useless, it just found bugs that I didn't really care about because they were sort of trivial. Finding XSS is awesome, I'm glad it would find really simple stuff like that, but I was going for "this feature is flawed" or "this boundary is flawed" and the model utterly failed there.
agentultra 8mo ago
100%. There are cases where a unit test or a hundred aren’t sufficient to demonstrate a piece of code is correct. Most software developers don’t seem to know what is sufficient. Those heavily using vibe coding even get the machine to write their tests. Then you get to systems design. What global safety and temporal invariants are necessary to ensure the design is correct? Most developers can’t do more than draw boxes and arrows and cite maxims and “best practices” in their reasoning. Plus you have the Sussman effect: software is often more like a natural science than engineering. There are so many dependencies and layers involved that you spend more time making observations about behaviour than designing for correct behaviours. There could be useful cases for using GenAI as a tool in some process for creating software systems… but I don’t think we should be taking off our thinking caps and letting these tools drive the entire process. They can’t tell you what to specify or what correct means.
- carlosjobim 8mo ago
  I don't have any idea of what a unit test is, but with AI I can make programs that help me immensely in my real world job. Snobby programmers would never even return an email offering money for their services.
  - staticassertion 8mo ago
    It's unclear what point you're even trying to make, other than that AI has been helpful to you. But surely you understand that if you don't know what a unit test is you're probably not in a position to comment on the value of unit testing. > Snobby programmers would never even return an email offering money for their services. Why the would they? I don't respond to the vast majority of emails, and I'm already employed.
    - carlosjobim 8mo ago
      Helpful to me and millions of others. Soon to be billions even. You are employed because somewhere in the pipeline there are paying customers. They don't care about unit tests, they care about having their problems solved. Beware of AI.
xg15 8mo ago
> Every few years a new tool appears and someone declares that the difficult parts of software engineering have finally been solved, or eliminated. To some it looks convincing. Productivity spikes. Demos look impressive. The industry congratulates itself on a breakthrough. Staff reductions kick in in the hopes that the market will respond positively. As a software engineer, I'd love if the industry had an actual breakthrough, if we found a way to make the hard parts easier and prevent software projects from devolving into balls of chaos and complexity. But not if the only reward for this would be to be laid off. So, once again, the old question: If reducing jobs is the only goal, but people are also expected to have jobs to be able to pay for food and housing, what is the end goal here? What is the vision that those companies are trying to realize?
- staticassertion 8mo ago
  > if we found a way to make the hard parts easier and prevent software projects from devolving into balls of chaos and complexity. I don't really believe this is possible. Or, it's the sort of thing that gets solved at a "product" level. Reality is complicated. People are complicated. The idea that software can exist without complexity feels sort of absurd to me. That said, to your larger point, I think the goal is basically to eliminate the middle class.
- fao_ 8mo ago
  > So, once again, the old question: If reducing jobs is the only goal, but people are also expected to have jobs to be able to pay for food and housing, what is the end goal here? What is the vision that those companies are trying to realize? Capitalism is reliant on the underclass (the homeless, the below minimum-wage) to add pressure to the broader class of workers in a way that makes them take jobs that they ordinarily wouldn't (Because they may be e.g. physically/emotionally unsafe, unethical, demeaning), for less money than they deserve and for more hours than they should. This is done in order to ensure that the price of work for companies is low, and that they can always draw upon a needy desperate workforce if required. You either comply with company requirements, or you get fired and hope you have enough runway not to starve. This was written about over a hundred years ago and it's especially true today in the modern form of it. Programmers as a field have just been materially insulated from the modern realities of "your job is timing your bathroom breaks, tracking how many hours you spend looking at the internet, your boss verbally abuses you for being slow, and you aren't making enough money to eat properly". This is also why many places do de-facto 'cleansings' of homeless people by exterminating their shelter or removing their ability to survive off donations, and why the support that is given for people without the means to survive is not only tedious but almost impossible to get. The majority of workers are supposed to look at that and go "well fuck, glad that's not me!" with a little part of their brain going "if i lost my job and things went badly, that could become me." This is also why immigration enforcement is a thing — so many modern jobs that nobody else in the western world wants to do are taken by immigrants. The employer won't look too closely at the visa, and in return the person gets work. With the benefit being towards the employer — if the person refuses to do something dangerous to themselves or others, or refuses to produce enough output to sustain the exponential growth at great personal cost, well, then the company can just cut the immigrant loose with no recourse, or outright call the authorities on them so they get deported. Significantly less risky to get people to work in intolerable conditions for illegal wages if there is no hope of them suing you for this. Back in the 1900s there were international conventions to remove passports. Now? Well, they're a convenient underclass for political manoeuvring. Why would you want people to have freedom of movement if your own citizens could just leave when things get bad, and when the benefits are a free workforce that you don't have to obey workers rights laws about?
BoredPositron 8mo ago
A lot of times bad engineering is all you need.
- deleted 8mo ago
  [deleted]
- polynomial 8mo ago
  This is the under acknowledged "secret" of this reconfiguration. It's like the Bill Joy point about mediocre technology taken to the next level.
tyleo 8mo ago
I disagree with the premise. It made all engineering easier. Bad and good. I believe vibe coding has always existed. I've known people at every company who add copious null checks rather than understanding things and fixing them properly. All we see now is copious null checks at scale. On the other hand, I've also seen excellent engineering amplified and features built by experts in days which would have taken weeks.
- bensyverson 8mo ago
  In corporate app development, I would see tests to check that the mocks return the expected values. Like, what are we even doing here?
  - anilakar 8mo ago
    Someone was asked to test untestable code so verifying mock contents was the best they could come up with.
    - mvpmvh 8mo ago
      No. Someone was asked to meet an arbitrary code coverage threshold. I'm dealing with this malicious compliance/weaponized incompetence at $current_job
      - dwoldrich 8mo ago
        How will you deal with it? I successfully convinced $big_important_group at $day_job to not implement a policy of failing their builds when code coverage dips below their target threshold > 90%. (Insane target, but that's a different conversation.) I convinced them that if they wanted to treat uncovered lines of code as tech debt, they needed to add an epic stories to their backlog to write tests. And their artificially setting some high target coverage threshold will produce garbage because developers will write do-nothing tests in order to get their work done and not trip the alarms. I argued that failing the builds on code coverage would be unfair because the tech debt created by past developers would unfairly hinder random current-day devs getting their work done. Instead, I recommended they pick their current coverage percentage (it was < 10% at the time) and set the threshold to that simply to prevent backsliding as new code was added. Then, as their backlogged, legit tests were implemented, ratchet up the coverage threshold to the new high water mark. This meant all new code would get tests written for them. And, instead of failing builds, I recommended email blasts to the whole team to indicate there was some recent backsliding in the testing regime and the codebase had grown without accompanying tests. It was not a huge shame event, but good a motivator to the team to keep up the quality. SonarQube was great for long-term tracking of coverage stats. Finally, I argued the coverage tool needed to have very liberal "ignore" rules that were agreed to by all members of the team (including managers). Anything that did not represent testable logic written by the team: generated code, configurations, tests themselves, should not count against their code coverage percentages.
zer00eyz 8mo ago
"AI" (and calling it that is a stretch) is nothing more than a nail gun. If you gave an experienced house framer a hammer, hand saw and box of nails and a random person off the street a nail gun and powered saw who is going to produce the better house? A confident AI and an unskilled human are just a Dunning-Kruger multiplier.
- j3k3 8mo ago
  Nicely put. There's this mistake Engineers make when using LLMs and loudly proclaiming its coming for their jobs / is magic... you have a lot of knowledge, experience and skill implicitly that allows for you to get the LLM to produce what you want. Without it... you produce crappy stuff that is inevitably going to get mangled and crushed. As we are seeing with Vibe code projects created by people with no exposure to proper Software Engineering.
  - zer00eyz 8mo ago
    > As we are seeing with Vibe code projects created by people with no exposure to proper Software Engineering. And I keep seeing products and projects banning AI: "My new house fell down because of the nail gun used, therefore I'm banning nail guns going forward." I understand and sympathize with maintainers and owners and the pressure they are under, but the limitation is going to look ridiculous as we see more progress with the tools. There are whole categories of problems that were creating that we have no solutions for at present: it isn't a crisis it's an opportunity.
    - j3k3 8mo ago
      I personally think its better to be cautious and wait for improvements in tooling to rise. Its not always necessary to be the one to take a risk when there's plenty of others willing to do so, for which the outcomes can then be assessed.
arty_prof 8mo ago
In terms of the Tech Debt it is obviously allow to make it a lot. But this is controllable if analysing in depth what AI is doing. I feel I become more like a Product than Software Engineer when reviewing AI code constantly satisfying my needs. And benefits provided by AI are too good. It allows to prototype near to anything in short terms which is superb. Like any tool in right hands can be a dealbreaker.
dgxyz 8mo ago
Not easier but faster. It’s really hard to catch shit now.
water_badger 8mo ago
So somewhere here there is a 2x2 or something based on these factors: 1. Programmers viewing programming through career and job security lens 2. Programmers who love the experience of writing code themselves 3. People who love making stuff 4. People who don't understand AI very well and have knee-jerk cultural / mob reactions against it because that's what's "in" right now in certain circles. It is fun to read old issues of Popular Mechanics on archive.org from 100+ years ago because you can see a lot of the same personality types playing out. At the end of the day, AI is not going anywhere, just like cars, electricity and airplanes never went anywhere. It will obviously be a huge part of how people interact with code and a number of other things going forward. 20-30 years from now the majority of the conversations happening this year will seem very quaint! (and a minority, primarily from the "people who love making stuff" quadrant, will seem ahead of their time)
sega_sai 8mo ago
When I see this: "One of the longest-standing misconceptions about software development is that writing code is the difficult part of the job. It never was." I don't think I can take this seriously. Sure, 'writing code' is not the difficult often, but when you have time constraints, 'writing code' becomes a limiting factor. And we all do not have infinite time in our hands. So AI not only enables something you just could not afford doing in the past, but it also allows to spend more time of 'engineering', or even try multiple approaches, which would have been impossible before.
- anilakar 8mo ago
  Agree. Writing code has always been the most time-consuming part that distracts me from actual design. AI just emphasizes the fact that anyone can do the keyboard mashing while reading code is the actual skill that matters. Give a woodcutter a chainsaw instead of an axe and he'll fell ten times more trees. He'll also likely cause more than ten times the collateral damage.
- staticassertion 8mo ago
  It's hard to reconcile "I don't think I can take this seriously" followed by an immediate admission that you agree but that there's some nuance. I think the author's post is far more nuanced that this one sentence that you apparently agree with fundamentally.
lowbloodsugar 8mo ago
> and ensuring that the system remains understandable as it grows in complexity. Feel like only people like this guy, with 4 decades of experience, understand the importance of this.
- polynomial 8mo ago
  Understandable as always a proxy for predictable.
jazz9k 8mo ago
Juniors that are relying too heavily on AI now will pay the price down the line, when they don't even know the fundamentals, because they just copy and pasted it from a prompt. It only means job security for people with actual experience.
hyperbovine 8mo ago
I’m seeing a real distinction emerge between “software engineering” and “research”. AI is simply amazing for exploratory research — 10x ability to try new ideas, if not more. When I find something that has promise, then I go into SWE mode. That involves understanding all the code the AI wrote, fixing all the dumb mistakes, and using my decades of experience to make it better. AI’s role in this process is a lot more limited, though it can still be useful.
- j3k3 8mo ago
  Thats because an LLM can access breadth at any given moment that you cannot. That's the advantage it has. E.g. quite often a sound (e.g. music) brings back memories of a time when it was being listened to etc. Our brains need something to 'prompt' (ironic I know) for stuff in the brain to come to the front. But the human is the final judge (or should be) if what is wrong / good quality vs high quality. A taste element is necessary here too.
rvz 8mo ago
Is that why there are so many outages across many companies adopting AI, including GitHub, Amazon, Cloudflare and Anthropic even with usage? Maybe if they "prompted the agent correctly", you get your infrastructure above at least 5 9s. If we continue through this path, not only so-called "engineers" can't read or write code at all, but their agents will introduce seemingly correct code and introduce outages like we have seen already, like this one [0]. AI has turned "senior engineers" into juniors, and juniors back into "interns" and cannot tell what is maintainable code and waste time, money and tokens reinventing a worse wheel. [0] https://sketch.dev/blog/our-first-outage-from-llm-written-code https://sketch.dev/blog/our-first-outage-from-llm-written-co...
furyofantares 8mo ago
AI Didn't Simplify Blogging: It Just Made Bad Blogging Easier I was hopeful that the title was written like LLM-output ironically, and dismayed to find the whole blog post is annoying LLM output.
- polynomial 8mo ago
  Robots making fun of us complaining about them.
_pdp_ 8mo ago
Put a bad driver in an F1 car and you won't make them a racer. You will just help them crash faster. Put a great driver in that same car, and they become unstoppable. Technology was never equaliser. It just divides more and yes ultimately some developers will get paid a lot more because their skills will be in more demand while other developers will be forced to seek other opportunities.
__MatrixMan__ 8mo ago
Naw, I just yesterday caught something in test that would've made it to prod without AI. It happens all the time. You can't satisfy every single paranoia, eventually you have to deem a risk acceptable and ship it. Which experiments you do run depends on what can be done in what limited time you have. Now that I can bootstrap a for-this-feature test harness in a day instead of a week, I'm catching much subtler bugs. It's still on you to be a good engineer, and if you're careful, AI really helps with that.
- j3k3 8mo ago
  Change 'good' for 'disciplined'. Problem is.. discipline is hard for humans. Especially when exposed to a thing that at face-value seems like it is really good and correct.
  - __MatrixMan__ 8mo ago
    We can cheat on discipline if we design our workflows with more careful thought about incentives. I wound up in a role where I throw away 100% of the code that I write within a few months. My job is about discovering cases where people are operating under false assumptions (typically about how some code will or won't be surprising in context with some dataset), and inform them of the discrepancy. "proofs" would be too strong of a word, but I generate a lot of code that then generates evidence which I then use in an argument. I do try to be disciplined about the code I rely on, but since I have no incentive to sneak through volumes of unreliable code before moving on to the next feature, it's easy to do. When I'm not diligent, the pain comes quickly, and I once again learn to be diligent. At the end of the day I end up looking at a dashboard I had an agent throw together and I decide if the argument I intend to make based on that dashboard is convincing. Also, agent sycophancy isn't really a problem because the agents are only asked to collect and represent the data. They don't know what I'm hoping to see, so it's very uncommon that they end up generating something deceptive. Their incentives are also aligned. I think we can structure much of our work this way (I just lucked into it) where there's no conflict of interest and therefore the need to be disciplined is not in opposition to anything else.
zackmorris 8mo ago
A -> (expletive) -> B I think we're all in denial about how bad software engineering has gotten. When I look at what's required to publish a web page today vs in 1996, I'm appalled. When someone asks me how to get started, all I can do is look at them and say "I'm so sorry": https://xkcd.com/1168/ https://xkcd.com/1168/ So "coding was always the hard part". All AI does is obfuscate how the sausage gets made. I don't see it fixing the underlying fallacies that turned academic computer science into for-profit software engineering. Although I still (barely) hold onto hope that some of us may win the internet lottery someday and start fixing the fundamentals. Maybe get back to what we used to have with apps like HyperCard, FileMaker and Microsoft Access but for a modern world where we need more than rolodexes. Back to paradigms where computers work for users instead of the other way around. Until then, at least we have AI to put lipstick on a pig.
tw-20260303-001 8mo ago
Or it simply made one step over the draft stage faster. It all depends how one uses it.
jwilliams 8mo ago
There are some interesting points here, but I think this essay is a little too choppy - e.g. the Aircraft Mechanic comparison is a long bow to draw. The Visual Basic comparison is more salient. I've seen multiple rounds of "the end of programmers", including RAD tools, offshoring, various bubble-bursts, and now AI. Just because we've heard it before though, doesn't mean it's not true now. AI really is quite a transformative technology. But I do agree these tools have resulted in us having more software, and thus more software problems to manage. The Alignment/Drift points are also interesting, but I think that this appeals to SWE's belief that that taste/discernment is stopping this happening in pre-AI times. I buy into the meta-point which is that the engineering role has shifted. Opening the floodgates on code will just reveal bottlenecks elsewhere (especially as AI's ability in coding is three steps ahead and accelerating). Rebuilding that delivery pipeline is the engineering challenge.
yubainu 8mo ago
[flagged]
- heliumtera 8mo ago
  Exactly, a large portion of software development was rejecting code from a intellectually functional human being. AGI is not sufficient to achieve minimum quality code because intelligence was never sufficient
rednafi 8mo ago
AI just lowered the cost of replication. Now you can replicate good or bad stuff but that doesn't automatically make AI the enabler of either.
jinko-niwashi 8mo ago
Your "don't fucking touch that file" experience is the exact pattern I kept hitting. After 400+ sessions of full-time pair programming with Claude, I stopped trying to fix it with prompt instructions and started treating it as a permissions problem. The model drifts because nothing structurally prevents it from drifting. Telling it "don't touch X" is negotiating behavior with a probabilistic system — it works until it doesn't. What actually worked: separating the workflow into phases where certain actions literally aren't available. Design phase? Read and propose only. Implementation phase? Edit, but only files in scope. Your security example is even more telling — the model folding under minimal pushback isn't a knowledge gap, it's a sycophancy gradient. No amount of system prompting fixes that. You need the workflow to not ask the model for a judgment call it can't be trusted to hold.
queenkjuul 8mo ago
Finally, an AI article i think i fully agree with (or at least mostly). In my hobby work, AI is indispensable. It's really good at showing me how to solve problems that have been solved, but haven't been applied to my specific scenario. I just ported a WiFi driver for a little RISC-V dev board i bought back in 2023, entirely using Gemini. Obviously there's lots of training data on compiling such drivers for new systems, and i could fill in the gaps (exact memory addresses, newer kennel function signatures, etc) but it really did write the code, something my JS-dev brain would've taken too long to figure out to be useful. At the same time, at work, it ignores basic project conventions, hallucinates APIs, writes nonsense documentation; it's very useful, but it my no means "does my job" There's an obvious disconnect: execs think it can do the anything, engineers think it can do a lot, but not what the execs think
michaelmoreira 8mo ago
[dead]
deleted 8mo ago
[deleted]
robenglander 8mo ago
I've published an article on Conversational Software Engineering, a direct followup to this article. https://robenglander.com/writing/cse-compiling-intent/ https://robenglander.com/writing/cse-compiling-intent/
mpajares 7mo ago
[dead]

128 points by birdculture 8mo ago

woeirua 8mo ago

How many model releases are we away from people like this throwing in the towel? 2? 3?

sshine 8mo ago

It also made good engineering easier. AI is an amplifier of existing behavior.

tinmandespot 8mo ago
“ AI is an amplifier of existing behavior” Apropos. I’m stealing that line.
qsera 8mo ago
Internet enabled instant to access to all human knowledge as well as instant chit-chat across the globe. Guess what humanity choose to drown itself in? So combine both facts here in context, with human nature, and you ll see where this will go.
genghisjahn 8mo ago
I love that I don’t have to look thru SO looking for a problem that’s kind of like the one I’m having. I have a problem solved based on my exact code taking my entire code base into account. And if I want a biting sarcastic review of my many faults as a software developer, I can ask for that too.
- sshine 8mo ago
  I have, in the last month, resorted to searching StackOverflow for something that works when Claude perpetually got it wrong three times in a row. It felt nostalgic that the answer was there in plain sight, and it just kept trying other things. So searching StackOverflow isn't quite dead yet.
  - genghisjahn 8mo ago
    Of course I still have times when Claude fumbles the fix. But the number of times it gets it exactly right far outnumber the times it can't get right. Compare that to the number of SO issues I've had to go through to get near a solution is night and day. I'm in no way saying you should work the way I do or that Claude would solve all your problems if you only just believe. I am saying it's been super helpful at squashing bugs for me in my circumstances with my code bases.
staticassertion 8mo ago
I think it's easier for good engineers to be good, perhaps. For example, I think property testing is "good" engineering. But I suspect that if you took a survey of developers the vast majority would not actually know what property testing is. So is AI really of any use then for those devs?
keeda 8mo ago
Yep, and recent reports from the likes of DORA and DX validate this with data: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report https://cloud.google.com/blog/products/ai-machine-learning/a...
maplethorpe 8mo ago
I think it depends on your process. Problems that require creative solutions are often solved through the act of doing. For me, it's the act of writing code itself that ignites the pathways and neural connections that I've built up in my brain over the years. Using AI circumvents that process, and those brain circuits go unused.

sunir 8mo ago

Simplify? It’s like saying a factory made chair building… what? It’s not simpler. It’s faster and cheaper and more consistent in quality. But way more complex.

yakattak 8mo ago
Anecdotally I have not seen consistency in quality at all.
- sunir 8mo ago
  My chairs resemble each other. Have you tried ikea? If you are talking about code which isn’t what I said, then we aren’t there yet.
  - groundzeros2015 8mo ago
    It’s a bad analogy because the benefits of industrial machines were predictable processes done efficiently.
    - sunir 8mo ago
      That came later than the beginning. Workhouses came before the loom. You can see this in the progression of quality of things like dinner plates over time. Making clay pottery can be simple. But to make “fine china” with increasingly sophisticated ornamentation and strength became more complex over time. Now you can go to ikea and buy plates that would be considered expensive luxuries hundreds of years ago.
      - j3k3 8mo ago
        Yeah... nah. As others have said, your analogy does not hold up to scrutiny.
      - groundzeros2015 8mo ago
        You’re not addressing any points I made.

groundzeros2015 8mo ago

I’m an AI skeptic and in no sense is it taking my peers job. But it does save me time. I can do research much better than Google, explore a code base, spit out helper functions, and review for obvious mistakes.

coffeefirst 8mo ago
Yep. And the more time I spend with the agents the more I’m convinced that your way is the endgame.
gitaarik 8mo ago
So what do you mean with being a sceptic? I thought you meant you weren't convinced of it's usefulness, and therefore don't use it. But you do seem to use it, so what is it you're sceptible about?
- groundzeros2015 8mo ago
  I’m skeptical that it’s very smart, that it can solve hard problems, and that it’s accelerating. I’m skeptical vibe coding is really viable or saves you time.
  - gitaarik 8mo ago
    Ok, so what are you actually using it for?
    - gitaarik 8mo ago
      Oh sorry, I see in your original post you use it for research, codebase exploration, and small coding tasks. I think you hit the nail on the head with that AI is ultimately not smart, it'll be dependent on humans for a long time, and we have to review their work, so they won't easily replace us. In that sense I'm also sceptical; the idea that AI can soon replace us. But I'm not sceptical about the power of AI as a tool for humans. I'm actually quite convinced by that by now. Hence my confusion of your remark. But I think we understand the misunderstanding now.

shablulman 8mo ago

[dead]

a_void_sky 8mo ago

"Coding was never the hard part. Typing syntax into a machine has always been the least interesting part of building a system." and I think these people are benefitting from it the most, people with expertise, who know their way around and knew what and how to build but did not want to do the grunt work

embedding-shape 8mo ago
Slight adjustment, but I'd see "maintaining code" is the same as before, matters more the people and their experience and knowledge how to manage that. But agree that the literal typing was never the difficult part, knowing what code should and shouldn't be written was a hard part, and still remains a hard part. Right now, "what code shouldn't be written" seems to have become an even more important part, as it's so easy to spit out huge amounts of code, but that's the lazy and easy way, not the one that let you slowly add in features across a decade, rather than getting stuck with a ball of spaghetti after a weekend of "agent go brrr".
- a_void_sky 8mo ago
  this is where years of experience working with freshers and junior devs helps, AI is smart enough to exactly do if you clearly tell it what to do and how unless you understand every inch of system and foresee what issues can be created by what kind of change, things will break when using AI
j3k3 8mo ago
I think that captures a lot of the LLM debate. There are people who just want an object produced that allows for some outcome to be achieved closer to the present. And there are other people who want to ensure that object that is produced, will be maintainable, not break other parts of the system etc. Neither party is wrong in what they want. I think there should naturally be a split of roles - the former can prototype stuff so other individuals in the organisation can critique whether it is a thing of value / worth investing in for production.
- 8mo ago

staticassertion 8mo ago

> Code Was Never the Hard Part I can't believe this has to be said, but yeah. Code took time, but it was never the hard part. I also think that it is radically understated how much developers contribute to UX and product decisions. We are constantly having to ask "Would users really do that?" because it directly impacts how we design. Product people obviously do this more, but engineers do it as a natural part of their process as well. I can't believe how many people do not seem to know this. Further, in my experience, even the latest models are terrible "experts". Expertise is niche, and niche simply is not represented in a model that has to pack massive amounts of data into a tiny, lossy format. I routinely find that models fail when given novel constraints, for example, and the constraints aren't even that novel - I was writing some lower level code where I needed to ensure things like "a lock is not taken" and "an allocation doesn't occur" because of reentrancy safety, and it ended up being the case that I was better off writing it myself because the model kept drifting over time. I had to move that code to a separate file and basically tell the model "Don't fucking touch that file" because it would often put something in there that wasn't safe. This is with aggressively tuning skills and using modern "make the AI behave" techniques. The model was Opus 4.5, I believe. This isn't the only situation. I recently had a model evaluate the security of a system that I knew to be unsafe. To its credit, Opus 4.6 did much better than previous models I had tried, but it still utterly failed to identify the severity of the issues involved or the proper solutions and as soon as I barely pushed back on it ("I've heard that systems like this can be safe", essentially) it folded completely and told me to ship the completely unsafe version. None of this should be surprising! AI is trained on massive amounts of data, it has to lossily encode all of this into a tiny space. Much of the expertise I've acquired is niche, borne of experience, undocumented, etc. It is unsurprising that a "repeat what I've seen before" machine can not state things it has not seen. It would be surprising if that were not the case. I suppose engineers maybe have not managed to convey this historically? Again, I'm baffled that people don't see to know how much time engineers spend on problems where the code is irrelevant. AI is an incredible accelerator for a number of things but it is hardly "doing my job". AI has mostly helped me ship trivial features that I'd normally have to backburner for the more important work. It has helped me in some security work by helping to write small html/js payloads to demonstrate attacks, but in every single case where I was performing attacks I was the one coming up with the attack path - the AI was useless there. edit: Actually, it wasn't useless, it just found bugs that I didn't really care about because they were sort of trivial. Finding XSS is awesome, I'm glad it would find really simple stuff like that, but I was going for "this feature is flawed" or "this boundary is flawed" and the model utterly failed there.

agentultra 8mo ago

100%. There are cases where a unit test or a hundred aren’t sufficient to demonstrate a piece of code is correct. Most software developers don’t seem to know what is sufficient. Those heavily using vibe coding even get the machine to write their tests. Then you get to systems design. What global safety and temporal invariants are necessary to ensure the design is correct? Most developers can’t do more than draw boxes and arrows and cite maxims and “best practices” in their reasoning. Plus you have the Sussman effect: software is often more like a natural science than engineering. There are so many dependencies and layers involved that you spend more time making observations about behaviour than designing for correct behaviours. There could be useful cases for using GenAI as a tool in some process for creating software systems… but I don’t think we should be taking off our thinking caps and letting these tools drive the entire process. They can’t tell you what to specify or what correct means.

carlosjobim 8mo ago
I don't have any idea of what a unit test is, but with AI I can make programs that help me immensely in my real world job. Snobby programmers would never even return an email offering money for their services.
- staticassertion 8mo ago
  It's unclear what point you're even trying to make, other than that AI has been helpful to you. But surely you understand that if you don't know what a unit test is you're probably not in a position to comment on the value of unit testing. > Snobby programmers would never even return an email offering money for their services. Why the would they? I don't respond to the vast majority of emails, and I'm already employed.
  - carlosjobim 8mo ago
    Helpful to me and millions of others. Soon to be billions even. You are employed because somewhere in the pipeline there are paying customers. They don't care about unit tests, they care about having their problems solved. Beware of AI.

xg15 8mo ago

> Every few years a new tool appears and someone declares that the difficult parts of software engineering have finally been solved, or eliminated. To some it looks convincing. Productivity spikes. Demos look impressive. The industry congratulates itself on a breakthrough. Staff reductions kick in in the hopes that the market will respond positively. As a software engineer, I'd love if the industry had an actual breakthrough, if we found a way to make the hard parts easier and prevent software projects from devolving into balls of chaos and complexity. But not if the only reward for this would be to be laid off. So, once again, the old question: If reducing jobs is the only goal, but people are also expected to have jobs to be able to pay for food and housing, what is the end goal here? What is the vision that those companies are trying to realize?

staticassertion 8mo ago
> if we found a way to make the hard parts easier and prevent software projects from devolving into balls of chaos and complexity. I don't really believe this is possible. Or, it's the sort of thing that gets solved at a "product" level. Reality is complicated. People are complicated. The idea that software can exist without complexity feels sort of absurd to me. That said, to your larger point, I think the goal is basically to eliminate the middle class.
fao_ 8mo ago
> So, once again, the old question: If reducing jobs is the only goal, but people are also expected to have jobs to be able to pay for food and housing, what is the end goal here? What is the vision that those companies are trying to realize? Capitalism is reliant on the underclass (the homeless, the below minimum-wage) to add pressure to the broader class of workers in a way that makes them take jobs that they ordinarily wouldn't (Because they may be e.g. physically/emotionally unsafe, unethical, demeaning), for less money than they deserve and for more hours than they should. This is done in order to ensure that the price of work for companies is low, and that they can always draw upon a needy desperate workforce if required. You either comply with company requirements, or you get fired and hope you have enough runway not to starve. This was written about over a hundred years ago and it's especially true today in the modern form of it. Programmers as a field have just been materially insulated from the modern realities of "your job is timing your bathroom breaks, tracking how many hours you spend looking at the internet, your boss verbally abuses you for being slow, and you aren't making enough money to eat properly". This is also why many places do de-facto 'cleansings' of homeless people by exterminating their shelter or removing their ability to survive off donations, and why the support that is given for people without the means to survive is not only tedious but almost impossible to get. The majority of workers are supposed to look at that and go "well fuck, glad that's not me!" with a little part of their brain going "if i lost my job and things went badly, that could become me." This is also why immigration enforcement is a thing — so many modern jobs that nobody else in the western world wants to do are taken by immigrants. The employer won't look too closely at the visa, and in return the person gets work. With the benefit being towards the employer — if the person refuses to do something dangerous to themselves or others, or refuses to produce enough output to sustain the exponential growth at great personal cost, well, then the company can just cut the immigrant loose with no recourse, or outright call the authorities on them so they get deported. Significantly less risky to get people to work in intolerable conditions for illegal wages if there is no hope of them suing you for this. Back in the 1900s there were international conventions to remove passports. Now? Well, they're a convenient underclass for political manoeuvring. Why would you want people to have freedom of movement if your own citizens could just leave when things get bad, and when the benefits are a free workforce that you don't have to obey workers rights laws about?

BoredPositron 8mo ago

A lot of times bad engineering is all you need.

deleted 8mo ago
[deleted]
polynomial 8mo ago
This is the under acknowledged "secret" of this reconfiguration. It's like the Bill Joy point about mediocre technology taken to the next level.

tyleo 8mo ago

I disagree with the premise. It made all engineering easier. Bad and good. I believe vibe coding has always existed. I've known people at every company who add copious null checks rather than understanding things and fixing them properly. All we see now is copious null checks at scale. On the other hand, I've also seen excellent engineering amplified and features built by experts in days which would have taken weeks.

bensyverson 8mo ago
In corporate app development, I would see tests to check that the mocks return the expected values. Like, what are we even doing here?
- anilakar 8mo ago
  Someone was asked to test untestable code so verifying mock contents was the best they could come up with.
  - mvpmvh 8mo ago
    No. Someone was asked to meet an arbitrary code coverage threshold. I'm dealing with this malicious compliance/weaponized incompetence at $current_job
    - dwoldrich 8mo ago
      How will you deal with it? I successfully convinced $big_important_group at $day_job to not implement a policy of failing their builds when code coverage dips below their target threshold > 90%. (Insane target, but that's a different conversation.) I convinced them that if they wanted to treat uncovered lines of code as tech debt, they needed to add an epic stories to their backlog to write tests. And their artificially setting some high target coverage threshold will produce garbage because developers will write do-nothing tests in order to get their work done and not trip the alarms. I argued that failing the builds on code coverage would be unfair because the tech debt created by past developers would unfairly hinder random current-day devs getting their work done. Instead, I recommended they pick their current coverage percentage (it was < 10% at the time) and set the threshold to that simply to prevent backsliding as new code was added. Then, as their backlogged, legit tests were implemented, ratchet up the coverage threshold to the new high water mark. This meant all new code would get tests written for them. And, instead of failing builds, I recommended email blasts to the whole team to indicate there was some recent backsliding in the testing regime and the codebase had grown without accompanying tests. It was not a huge shame event, but good a motivator to the team to keep up the quality. SonarQube was great for long-term tracking of coverage stats. Finally, I argued the coverage tool needed to have very liberal "ignore" rules that were agreed to by all members of the team (including managers). Anything that did not represent testable logic written by the team: generated code, configurations, tests themselves, should not count against their code coverage percentages.

zer00eyz 8mo ago

"AI" (and calling it that is a stretch) is nothing more than a nail gun. If you gave an experienced house framer a hammer, hand saw and box of nails and a random person off the street a nail gun and powered saw who is going to produce the better house? A confident AI and an unskilled human are just a Dunning-Kruger multiplier.

j3k3 8mo ago
Nicely put. There's this mistake Engineers make when using LLMs and loudly proclaiming its coming for their jobs / is magic... you have a lot of knowledge, experience and skill implicitly that allows for you to get the LLM to produce what you want. Without it... you produce crappy stuff that is inevitably going to get mangled and crushed. As we are seeing with Vibe code projects created by people with no exposure to proper Software Engineering.
- zer00eyz 8mo ago
  > As we are seeing with Vibe code projects created by people with no exposure to proper Software Engineering. And I keep seeing products and projects banning AI: "My new house fell down because of the nail gun used, therefore I'm banning nail guns going forward." I understand and sympathize with maintainers and owners and the pressure they are under, but the limitation is going to look ridiculous as we see more progress with the tools. There are whole categories of problems that were creating that we have no solutions for at present: it isn't a crisis it's an opportunity.
  - j3k3 8mo ago
    I personally think its better to be cautious and wait for improvements in tooling to rise. Its not always necessary to be the one to take a risk when there's plenty of others willing to do so, for which the outcomes can then be assessed.

arty_prof 8mo ago

In terms of the Tech Debt it is obviously allow to make it a lot. But this is controllable if analysing in depth what AI is doing. I feel I become more like a Product than Software Engineer when reviewing AI code constantly satisfying my needs. And benefits provided by AI are too good. It allows to prototype near to anything in short terms which is superb. Like any tool in right hands can be a dealbreaker.

dgxyz 8mo ago

Not easier but faster. It’s really hard to catch shit now.

water_badger 8mo ago

So somewhere here there is a 2x2 or something based on these factors: 1. Programmers viewing programming through career and job security lens 2. Programmers who love the experience of writing code themselves 3. People who love making stuff 4. People who don't understand AI very well and have knee-jerk cultural / mob reactions against it because that's what's "in" right now in certain circles. It is fun to read old issues of Popular Mechanics on archive.org from 100+ years ago because you can see a lot of the same personality types playing out. At the end of the day, AI is not going anywhere, just like cars, electricity and airplanes never went anywhere. It will obviously be a huge part of how people interact with code and a number of other things going forward. 20-30 years from now the majority of the conversations happening this year will seem very quaint! (and a minority, primarily from the "people who love making stuff" quadrant, will seem ahead of their time)

sega_sai 8mo ago

When I see this: "One of the longest-standing misconceptions about software development is that writing code is the difficult part of the job. It never was." I don't think I can take this seriously. Sure, 'writing code' is not the difficult often, but when you have time constraints, 'writing code' becomes a limiting factor. And we all do not have infinite time in our hands. So AI not only enables something you just could not afford doing in the past, but it also allows to spend more time of 'engineering', or even try multiple approaches, which would have been impossible before.

anilakar 8mo ago
Agree. Writing code has always been the most time-consuming part that distracts me from actual design. AI just emphasizes the fact that anyone can do the keyboard mashing while reading code is the actual skill that matters. Give a woodcutter a chainsaw instead of an axe and he'll fell ten times more trees. He'll also likely cause more than ten times the collateral damage.
staticassertion 8mo ago
It's hard to reconcile "I don't think I can take this seriously" followed by an immediate admission that you agree but that there's some nuance. I think the author's post is far more nuanced that this one sentence that you apparently agree with fundamentally.

lowbloodsugar 8mo ago

> and ensuring that the system remains understandable as it grows in complexity. Feel like only people like this guy, with 4 decades of experience, understand the importance of this.

polynomial 8mo ago
Understandable as always a proxy for predictable.

jazz9k 8mo ago

Juniors that are relying too heavily on AI now will pay the price down the line, when they don't even know the fundamentals, because they just copy and pasted it from a prompt. It only means job security for people with actual experience.

hyperbovine 8mo ago

I’m seeing a real distinction emerge between “software engineering” and “research”. AI is simply amazing for exploratory research — 10x ability to try new ideas, if not more. When I find something that has promise, then I go into SWE mode. That involves understanding all the code the AI wrote, fixing all the dumb mistakes, and using my decades of experience to make it better. AI’s role in this process is a lot more limited, though it can still be useful.

j3k3 8mo ago
Thats because an LLM can access breadth at any given moment that you cannot. That's the advantage it has. E.g. quite often a sound (e.g. music) brings back memories of a time when it was being listened to etc. Our brains need something to 'prompt' (ironic I know) for stuff in the brain to come to the front. But the human is the final judge (or should be) if what is wrong / good quality vs high quality. A taste element is necessary here too.

rvz 8mo ago

Is that why there are so many outages across many companies adopting AI, including GitHub, Amazon, Cloudflare and Anthropic even with usage? Maybe if they "prompted the agent correctly", you get your infrastructure above at least 5 9s. If we continue through this path, not only so-called "engineers" can't read or write code at all, but their agents will introduce seemingly correct code and introduce outages like we have seen already, like this one [0]. AI has turned "senior engineers" into juniors, and juniors back into "interns" and cannot tell what is maintainable code and waste time, money and tokens reinventing a worse wheel. [0] https://sketch.dev/blog/our-first-outage-from-llm-written-code https://sketch.dev/blog/our-first-outage-from-llm-written-co...

furyofantares 8mo ago

AI Didn't Simplify Blogging: It Just Made Bad Blogging Easier I was hopeful that the title was written like LLM-output ironically, and dismayed to find the whole blog post is annoying LLM output.

polynomial 8mo ago
Robots making fun of us complaining about them.

_pdp_ 8mo ago

Put a bad driver in an F1 car and you won't make them a racer. You will just help them crash faster. Put a great driver in that same car, and they become unstoppable. Technology was never equaliser. It just divides more and yes ultimately some developers will get paid a lot more because their skills will be in more demand while other developers will be forced to seek other opportunities.

__MatrixMan__ 8mo ago

Naw, I just yesterday caught something in test that would've made it to prod without AI. It happens all the time. You can't satisfy every single paranoia, eventually you have to deem a risk acceptable and ship it. Which experiments you do run depends on what can be done in what limited time you have. Now that I can bootstrap a for-this-feature test harness in a day instead of a week, I'm catching much subtler bugs. It's still on you to be a good engineer, and if you're careful, AI really helps with that.

j3k3 8mo ago
Change 'good' for 'disciplined'. Problem is.. discipline is hard for humans. Especially when exposed to a thing that at face-value seems like it is really good and correct.
- __MatrixMan__ 8mo ago
  We can cheat on discipline if we design our workflows with more careful thought about incentives. I wound up in a role where I throw away 100% of the code that I write within a few months. My job is about discovering cases where people are operating under false assumptions (typically about how some code will or won't be surprising in context with some dataset), and inform them of the discrepancy. "proofs" would be too strong of a word, but I generate a lot of code that then generates evidence which I then use in an argument. I do try to be disciplined about the code I rely on, but since I have no incentive to sneak through volumes of unreliable code before moving on to the next feature, it's easy to do. When I'm not diligent, the pain comes quickly, and I once again learn to be diligent. At the end of the day I end up looking at a dashboard I had an agent throw together and I decide if the argument I intend to make based on that dashboard is convincing. Also, agent sycophancy isn't really a problem because the agents are only asked to collect and represent the data. They don't know what I'm hoping to see, so it's very uncommon that they end up generating something deceptive. Their incentives are also aligned. I think we can structure much of our work this way (I just lucked into it) where there's no conflict of interest and therefore the need to be disciplined is not in opposition to anything else.

zackmorris 8mo ago

A -> (expletive) -> B I think we're all in denial about how bad software engineering has gotten. When I look at what's required to publish a web page today vs in 1996, I'm appalled. When someone asks me how to get started, all I can do is look at them and say "I'm so sorry": https://xkcd.com/1168/ https://xkcd.com/1168/ So "coding was always the hard part". All AI does is obfuscate how the sausage gets made. I don't see it fixing the underlying fallacies that turned academic computer science into for-profit software engineering. Although I still (barely) hold onto hope that some of us may win the internet lottery someday and start fixing the fundamentals. Maybe get back to what we used to have with apps like HyperCard, FileMaker and Microsoft Access but for a modern world where we need more than rolodexes. Back to paradigms where computers work for users instead of the other way around. Until then, at least we have AI to put lipstick on a pig.

tw-20260303-001 8mo ago

Or it simply made one step over the draft stage faster. It all depends how one uses it.

jwilliams 8mo ago

There are some interesting points here, but I think this essay is a little too choppy - e.g. the Aircraft Mechanic comparison is a long bow to draw. The Visual Basic comparison is more salient. I've seen multiple rounds of "the end of programmers", including RAD tools, offshoring, various bubble-bursts, and now AI. Just because we've heard it before though, doesn't mean it's not true now. AI really is quite a transformative technology. But I do agree these tools have resulted in us having more software, and thus more software problems to manage. The Alignment/Drift points are also interesting, but I think that this appeals to SWE's belief that that taste/discernment is stopping this happening in pre-AI times. I buy into the meta-point which is that the engineering role has shifted. Opening the floodgates on code will just reveal bottlenecks elsewhere (especially as AI's ability in coding is three steps ahead and accelerating). Rebuilding that delivery pipeline is the engineering challenge.

yubainu 8mo ago

[flagged]

heliumtera 8mo ago
Exactly, a large portion of software development was rejecting code from a intellectually functional human being. AGI is not sufficient to achieve minimum quality code because intelligence was never sufficient

rednafi 8mo ago

AI just lowered the cost of replication. Now you can replicate good or bad stuff but that doesn't automatically make AI the enabler of either.

jinko-niwashi 8mo ago

Your "don't fucking touch that file" experience is the exact pattern I kept hitting. After 400+ sessions of full-time pair programming with Claude, I stopped trying to fix it with prompt instructions and started treating it as a permissions problem. The model drifts because nothing structurally prevents it from drifting. Telling it "don't touch X" is negotiating behavior with a probabilistic system — it works until it doesn't. What actually worked: separating the workflow into phases where certain actions literally aren't available. Design phase? Read and propose only. Implementation phase? Edit, but only files in scope. Your security example is even more telling — the model folding under minimal pushback isn't a knowledge gap, it's a sycophancy gradient. No amount of system prompting fixes that. You need the workflow to not ask the model for a judgment call it can't be trusted to hold.

queenkjuul 8mo ago

Finally, an AI article i think i fully agree with (or at least mostly). In my hobby work, AI is indispensable. It's really good at showing me how to solve problems that have been solved, but haven't been applied to my specific scenario. I just ported a WiFi driver for a little RISC-V dev board i bought back in 2023, entirely using Gemini. Obviously there's lots of training data on compiling such drivers for new systems, and i could fill in the gaps (exact memory addresses, newer kennel function signatures, etc) but it really did write the code, something my JS-dev brain would've taken too long to figure out to be useful. At the same time, at work, it ignores basic project conventions, hallucinates APIs, writes nonsense documentation; it's very useful, but it my no means "does my job" There's an obvious disconnect: execs think it can do the anything, engineers think it can do a lot, but not what the execs think

michaelmoreira 8mo ago

[dead]

deleted 8mo ago

[deleted]

robenglander 8mo ago

I've published an article on Conversational Software Engineering, a direct followup to this article. https://robenglander.com/writing/cse-compiling-intent/ https://robenglander.com/writing/cse-compiling-intent/

mpajares 7mo ago

[dead]