17 ms·

GitHub CEO: manual coding remains key despite AI boom

usmanmehmood55 1y ago
> The continued shortage of software engineers, coupled with research showing that AI tools are particularly beneficial for junior developers... I stopped reading after this.
exabrial 1y ago
Amazingly, so does air and water. What AI salesman could have predicted this?
CoffeeOnWrite 1y ago
“Manual” has a negative connotation. If I understand the article correctly, they mean “human coding remains key”. It’s not clear to me the GitHub CEO actually used the word “manual”, that would surprise me. Is there another source on this that’s either more neutral or better at choosing accurate words? The last thing we need is to put down human coding as “manual”; human coders have a large toolbox of non-AI tools to automate their coding. (Wow I sound triggered! sigh)
- upghost 1y ago
  It's almost as bad as "manual" thinking!
- vram22 1y ago
  >Manual” has a negative connotation. If I understand the article correctly, they mean “human coding remains key”. A man is a human.
  - layer8 1y ago
    Humanual coding? ;) “Manual” comes from Latin manus, meaning “hand”: https://en.wiktionary.org/wiki/manus https://en.wiktionary.org/wiki/manus. It literally means “by hand”.
    - vram22 1y ago
      Nice one :) I too can sling a bit of Latin. ;) Here is one phrase, in which one word, malus, is like an off-by-one error from your manus word, so to speak :) : nemo malus nisi probetur https://www.google.com/search?q=nemo+malus+nisi+probetur https://www.google.com/search?q=nemo+malus+nisi+probetur From the AI overview (need to at least try that out a few times after all the talk about Google enshittification like by Cory Doctorow in this year's PyCon US keynote: >Nemo malus nisi probetur" is a Latin legal maxim that translates to "No one is evil unless proven." It signifies that a person is presumed innocent until proven guilty in a court of law. This principle is fundamental to legal systems that value fairness and due process, ensuring that accusations are substantiated before a person is considered culpable. Here's a breakdown of the phrase: Nemo: No one malus: Evil, bad, wicked nisi: Unless probetur: Is proven, is shown, is demonstrated The maxim essentially means that one should not be treated as inherently bad or guilty without sufficient evidence. This principle is closely related to the concept of "presumption of innocence" and is crucial for upholding justice and protecting individual rights.
- deleted 1y ago
  [deleted]
- anamexis 1y ago
  What is the distinction between manual coding and human coding?
  - jdiff 1y ago
    Often when you're calling something "manual" you're taking something off the automated happy path to tediously and slowly wind the thing through its complex process by hand. The difference between manual coding and human coding is tedium and laboriousness. It's not laborious to program, but the phrase "manual coding" evokes that image.
    - skydhash 1y ago
      Maybe that’s what they’ve been doing? No one using Vim, Emacs, or Unix as an IDE would say they do manual coding with the amount of automation that usually goes there.
      - aeonik 1y ago
        Indeed, if your not using butterflies to program, it's not manual, and your not a real programmer https://xkcd.com/378/ https://xkcd.com/378/
- GuinansEyebrows 1y ago
  > Wow I sound triggered! sigh this is okay! it's a sign of your humanity :)
- deleted 1y ago
  [deleted]
- layer8 1y ago
  How about “organic coding”? ;)
- dalyons 1y ago
  Acoustic coding
- ivanjermakov 1y ago
  Analog coding
- mrheosuper 1y ago
  "Authentic" maybe ?
- bluefirebrand 1y ago
  > “Manual” has a negative connotation Wait does it? This is a new idea to me, in what way could "manual" have a negative connotation? Are people really that against doing things manually nowadays?
FirmwareBurner 1y ago
I wonder how much coding he does and how does he know which code is human written and which by machine.
treefarmer 1y ago
I get a 403 forbidden error when trying to view the page. Anyone else get that?
strict9 1y ago
It's interesting to see a CEO express thoughts on AI and coding go in a slightly different direction. Usually the CEO or investor says 30% (or some other made up number) of all code is written by AI and the number will only increase, implying that developers will soon be obsolete. It's implied that 30% of all code submitted and shipped to production is from AI agents with zero human interaction. But of course this is not the case, it's the same developers as before using tools to more rapidly write code. And writing code is only one part of a developer's job in building software.
- heisenbit 1y ago
  Well, I suspect GitHub's income is a function of the number of developers using it so it is not surprising that he takes this position.
- madeofpalk 1y ago
  He’s probably more right than not. But he also has a vested interest in this (just like the other CEOs who say the opposite), being in the business of human-mediated code.
  - yodon 1y ago
    Presumably you're aware that the full name of Microsoft's Copilot AI code authoring tool is "GitHub Copilot", that GitHub developed it, and that he runs GitHub.
    - Imustaskforhelp 1y ago
      Yea, which is why I was surprised too when he said this.
    - madeofpalk 1y ago
      Copilot. Not Pilot.
- nextlevelwizard 1y ago
  I love that the 30% quote is so miss used. You probably should watch that clip again and actually listen what he said.
deleted 1y ago
[deleted]
jstummbillig 1y ago
Going by the content of the linked post, this is very much a misleading headline. There is nothing in the quotes that I would read as an endorsement of "manual coding", at least not in the sense that we have used the term "coding" for the past decades.
jasonthorsness 1y ago
"He warned that depending solely on automated agents could lead to inefficiencies. For instance, spending too much time explaining simple changes in natural language instead of editing the code directly." Lots of changes where describing them in English takes longer than just performing the change. I think the most effective workflow with AI agents will be a sort of active back-and-forth.
- sodality2 1y ago
  Yeah, I can’t count the number of times I’ve thought about a change, explained it in natural language, pressed enter, then realized I’ve already arrived at the exact change I need to apply just by thinking it through. Oftentimes I even beat the agent at editing it, if it’s a context-heavy change.
  - dgfitz 1y ago
    Rubber duck. I’ve kept one on my desk for over a decade. It was also like a dollar, which is more than I’ve spent on LLMs. :) https://en.m.wikipedia.org/wiki/Rubber_duck_debugging https://en.m.wikipedia.org/wiki/Rubber_duck_debugging
- neom 1y ago
  How active are you ok with/want? I've just joined an agent tooling startup (yesh...I wrote that huh...) - and it's something we talk a lot about internally, we're thinking it's fine to do back and forth, tell it frankly it's not doing it right, etc, but some stuff might be annoying? Do you have a sense of how this might work to your mind? Thanks! :)
sysmax 1y ago
AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing. Here's a fresh example that I stumbled upon just a few hours ago. I needed to refactor some code that first computes the size of a popup, and then separately, the top left corner. For brevity, one part used an "if", while the other one had a "switch": if (orientation == Dock.Left || orientation == Dock.Right) size = /* horizontal placement */ else size = /* vertical placement */ var point = orientation switch { Dock.Left => ... Dock.Right => ... Dock.Top => ... Dock.Bottom => ... }; I wanted the LLM to refactor it to store the position rather than applying it immediately. Turns out, it just could not handle different things (if vs. switch) doing a similar thing. I tried several variations of prompts, but it very strongly leaning to either have two ifs, or two switches, despite rather explicit instructions not to do so. It sort of makes sense: once the model has "completed" an if, and then encounters the need for a similar thing, it will pick an "if" again, because, well, it is completing the previous tokens. Harmless here, but in many slightly less trivial examples, it would just steamroll over nuance and produce code that appears good, but fails in weird ways. That said, splitting tasks into smaller parts devoid of such ambiguities works really well. Way easier to say "store size in m_StateStorage and apply on render" than manually editing 5 different points in the code. Especially with stuff like Cerebras, that can chew through complex code at several kilobytes per second, expanding simple thoughts faster than you could physically type them.
- gametorch 1y ago
  [flagged]
  - npinsker 1y ago
    Sweeping generalizations about how LLMs will always (someday) be able to do arbitrary X, Y, and Z don't really capture me either
    - gametorch 1y ago
      [flagged]
deleted 1y ago
[deleted]
- pxeger1 1y ago
  Thomas Dohmke is CEO of GitHub .
TacticalCoder 1y ago
What's amazing with "vibe coding" is the number of non tecchie who now decide they want to code. They understand that a new tool is on the block and they realize how it could help their business but they also realize that to really harness this superpower you need to code. So out of nowhere both my brother and my wife, without concerting themselves (they don't live on the same continent), are now taking coding lessons. Not AI related: just learning to code in Python. And suddenly I'm winning lots of cookie points: my wife realizes that coding is not something that's that simple and that it's really the coders who have it easy with AI. As for the AI boom: it's another tool. I use it daily (and pay for it). But it's still just a tool. Wake me up when 95% of Linux's kernel code is written by an AI.
dboreham 1y ago
That's him out the Illuminati then.
hnthrow90348765 1y ago
My guess is they will settle for 2x the productivity as a before-AI developer as their skill floor, but then not take a look at how long meetings and other processes take. Why not look at Bob who takes like 2 weeks to write tickets on what they actually want in a feature? Or Alice who's really slow getting Figma designs done and validated? How nice would having a "someone's bothered a developer" metric be and having the business seek to get that to zero and talk very loudly about it as they have about developers?
- hobs 1y ago
  Because everyone who bothers the developers is actually in charge, and they would never want to reduce their utilization, all of this removal of need to focus on the code makes them excited that you can be in even more meetings.
mycocola 1y ago
I think most programmers would agree that thinking represents the majority of our time. Writing code is no different than writing down your thoughts, and that process in itself can be immensely productive -- it can spark new ideas, grant epiphanies, or take you in an entirely new direction altogether. Writing is thinking. I think an over-reliance, or perhaps any reliance, on AI tools will turn good programmers into slop factories, as they consistently skip over a vital part of creating high-quality software. You could argue that the prompt == code, but then you are adding an intermediary step between you and the code, and something will always be lost in translation. I'd say just write the code.
- sothatsit 1y ago
  I think this misses the point. You're right that programmers still need to think. But you're wrong thinking that AI does not help with that. With AI, instead of starting with zero and building up, you can start with a result and iterate on it straight away. This process really shines when you have a good idea of what you want to do, and how you want it implemented. In these cases, it is really easy to review the code, because you knew what you wanted it to look like. And so, it lets me implement some basic features in 15 minutes instead of an hour. This is awesome. For more complex ideas, AI can also be a great idea sparring partner. Claude Code can take a paragraph or two from me, and then generate a 200-800 line planning document fleshing out all the details. That document: 1) helps me to quickly spot roadblocks using my own knowledge, and 2) helps me iterate quickly in the design space. This lets me spend more time thinking about the design of the system. And Claude 4 Opus is near-perfect at taking one of these big planning specifications and implementing it, because the feature is so well specified. So, the reality is that AI opens up new possible workflows. They aren't always appropriate. Sometimes the process of writing the code yourself and iterating on it is important to helping you build your mental model of a piece of functionality. But a lot of the time, there's no mystery in what I want to write. And in these cases, AI is brilliant at speeding up design and implementation.
  - mycocola 1y ago
    Based on your workflow, I think there is considerable risk of you being wooed by AI into believing what you are doing is worthwhile. The plan AI offers is coherent, specific, it sounds good. It's validation. Sugar.
agentultra 1y ago
… because programming languages are the right level of precision for specifying a program you want. Natural language isn’t it. Of course you need to review and edit what it generates. Of course it’s often easier to make the change yourself instead of describing how to make the change. I wonder if the independent studies that show Copilot increasing the rate of errors in software have anything to do with this less bold attitude. Most people selling AI are predicting the obsolescence of human authors.
- soulofmischief 1y ago
  Transformers can be used to automate testing, create deeper and broader specification, accelerate greenfield projects, rapidly and precisely expand a developer's knowledge as needed, navigate unfamiliar APIs without relying on reference, build out initial features, do code review and so much more. Even if code is the right medium for specifying a program, transformers act as an automated interface between that medium and natural language. Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual. > Most people selling AI are predicting the obsolescence of human authors. It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace. This replacement might not happen tomorrow, or next year, or even in the next decade, but it's clear that we are able to build capable models. What remains to be done is R&D around things like hallucinations, accuracy, affordability, etc. as well as tooling and infrastructure built around this new paradigm. But the cat's out of the bag, and we are not returning to a paradigm that doesn't involve intelligent automation in our daily work; programming is literally about automating things and transformers are a massive forward step. That doesn't really mean anything, though; You can still be as involved in your programming work as you'd like. Whether you can find paid, professional work depends on your domain, skill level and compensation preferences. But you can always program for fun or personal projects, and decide how much or how little automation you use. But I will recommend that you take these tools seriously, and that you aren't too dismissive, or you could find yourself left behind in a rapidly evolving landscape, similarly to the advent of personal computing and the internet.
lunarboy 1y ago
It was only 2 years ago we were still taking about GPTs making up completely nonsense, and now hallucinations are almost gone from the discussions. I assume it will get even better, but I also think there is an inherent plateau. Just like how machines solved mass manufacturing work, but we still have factory workers and overseers. Also, "manually" hand crafted pieces like fashion and watches continue to be the most expensive luxury goods. So I don't believe good design architects and consulting will ever be fully replaced.
- jashmatthews 1y ago
  Hallucinations are now plausibly wrong which is in some ways harder to deal with. GPT4.1 still generates Rust with imaginary crates and says “your tests passed, we can now move on” to a completely failed test run.
- mrheosuper 1y ago
  "hallucinations are almost gone from the discussions" because everyone now accepts that LLM hallucinate all the times, no point in mentioning it anymore.
deleted 1y ago
[deleted]
OJFord 1y ago
This seems to be an AI summary of a (not linked) podcast.
randomNumber7 1y ago
Code monkeys that doesn't understand the limits of LLMs and can't solve problems where the LLM fails are not needed in the world of tomorrow. Why wouldn't your boss ask ChatGPT directly?
guluarte 1y ago
AI is good for boilerplate, suggestions, nothing more.
- johnisgood 1y ago
  For you, perhaps.
  - beej71 1y ago
    For me, too. On the poorly-documented stuff that I get into, where I really need help, it flails. I wanted some jq script and it made an incomprehensible thing that usually worked. And every fix it made broke something else. It just kept digging a deeper hole. After a while of that, I bit the bullet and learned jq script. I wrote a solution that was more capable, easier to read, and, importantly, always worked. The thing is, jq is completely documented. Everything I needed was online. But there just aren't many examples to for LLMs, so they choke. Start asking it questions about complexity classes and you can get it to contradict itself in no time. Most of the code in the world right now is very formulaic, and it's great at that. Sorry, WordPress devs. It's a powerful tool, but it's not that powerful.
    - johnisgood 1y ago
      Have you tried feeding it the documentation of jq? And which LLM(s) have you tried? I had great success with niche programming languages by feeding it the documentation and a couple of projects.
layer8 1y ago
One of the most useful properties of computers is that they enable reliable, eminently reproducible automation. Formal languages (like programming languages) not only allow to unambiguously specify the desired automation to the upmost level of precision, they also allow humans to reason about the automation with precision and confidence. Natural language is a poor substitute for that. The ground truth of programs will always be the code, and if humans want to precisely control what a program does, they’ll be best served by understanding, manipulating, and reasoning about the code.
swyx 1y ago
> In an appearance on “The MAD Podcast with Matt Turck,” Dohmke said that > Source: The Times of India what in the recycled content is this trash?
lawgimenez 1y ago
Not gonna lie, first time I've heard of manual coding.
another_twist 1y ago
I think these are coordinated posts by Microsoft execs. First their director of product, now this. Its like they're trying to calm the auto coding hype until they catchup and thus keep OpenAI from running away.
- svachalek 1y ago
  Microsoft is the largest shareholder in OpenAI.
taysix 1y ago
I had a fun result the other day from Claude. I opened a script in Zed and asked it to "fix the error on line 71". Claude happily went and fixed the error on line 91.... 1. There was no error on line 91, it did some inconsequential formatting on that line 2. More importantly, it just ignored the very specific line I told it to go to. It's like I was playing telephone with the LLM which felt so strange with text-based communication. This was me trying to get better at using the LLM while coding and seeing if I could "one-shot" some very simple things. Of course me doing this _very_ tiny fix myself would have been faster. Just felt weird and reinforces this idea that the LLM isn't actually thinking at all.
- baby 1y ago
  ITT: people trying to use AI to code for the first time
- klysm 1y ago
  LLMs probably have bad awareness of line numbers
  - mcintyre1994 1y ago
    I suspect if OP highlighted line 71 and added it to chat and said fix the error, they’d get a much better response. I assume Cursor could create a tool to help it interpret line numbers, but that’s not how they expect you to use it really.
    - recursive 1y ago
      How is this better from just using a formal language again?
      - svachalek 1y ago
        Who said it's better? It's a design choice. Someone can easily write an agent that takes instructions in any language you like.
klysm 1y ago
CEOs are possibly the last person you should listen to on any given subject.
- beej71 1y ago
  I'm just vibe-CEOing my new company. It's amazing how productive it is!
  - konfusinomicon 1y ago
    just wait til it starts virtue signalling and posting contrived anecdotes about b2b sales and the benefits of RTO on LinkedIn. the vibe-HR department is gonna have to rein things in fast!
- dgfitz 1y ago
  So do we ignore the Github CEO or all the other ones?
GiorgioG 1y ago
No fucking shit Sherlock.
bmitc 1y ago
It would be nice if he would back that up by increasing focus on quality of life issues on GitHub. GitHub's feature set seems to get very little attention unless it overlaps with Copilot.
exiguus 1y ago
Personally, I define the job of a software engineer as transform requirements into software. Software is not only code. Requirements are not only natural language. At the moment I can't manage to be faster with the AI than manually. Unless its a simple task or software. In my experience AI's are atm junior or mid-level developers. And in the last two years, they didn't get significant better.
- nicbou 1y ago
  Most of the time, the requirements are not spelled out. Nobody even knows what the business logic is supposed to be. A lot of it has to be decided by the software engineer based on available information. It sometimes involve walking around the office asking people things. It also requires a fair bit of wisdom to know where the software is expected to grow, and how to architect for that eventuality. I can't picture an LLM doing a fraction of that work.
  - exiguus 1y ago
    I think that's my problem with AI. Let's say I have all the requirements, down to the smallest detail. Then I make my decisions at a micro level. Formulate an architecture. Take all the non-functionals into account. I would write a book as a prompt that is not able to express my thoughts as accurately as if I were writing code right away. Apart from the fact that the prompt is generally a superfluous intermediate step in which I struggle to create an exact programming language with an imprecise natural language with a result that is not reproduce-able.
    - ra0x3 1y ago
      This is a really good point. At a certain point, huge prompts (which you can readily find available on Github, used by large LLM-based corps) are just....files of code? Why wouldn't I just write the code myself at that point? Almost makes me think this "AI coding takeover" is strictly pushed by non-technical people.
    - mediaman 1y ago
      AI is less useful when I'm picking through specific, careful business logic. But we still have lots of boilerplate code that's required, and it's really good at that. If I need a reasonably good-looking front-end UI, Claude will put that together quickly for me. Or if I need it to use a common algorithm against some data, it's good at applying that. What I like about AI is that it lets me slide along the automation-specificity spectrum as I go through my work. Sometimes it feels like I've opened up a big stretch of open highway (some standard issue UI work with structures already well-defined) and I can "goose" it. Sometimes there's some tricky logic, and I just know the AI won't do well; it takes just as long to explain the logic as to write it in code. So I hit the brakes, slow down, navigate those tricky parts. Previously, in the prior attempt to remove the need for engineers, no-code solutions instead trapped people. They pretended like everything is open highway. It's not, which is why they fail. But here we can apply our own judgment and skill in deciding when a lot of "common-pattern" code is required versus the times where specificity and business context is required. That's also why these LLMs get over-hyped: people over-hype them for the same reason they over-hyped no-code; they don't understand the job to be done, and because of that, they actually don't understand why this is much better than the fanciful capabilities they pretend it has ("it's like an employee and automates everything!"). The tools are much more powerful when an engineer is in the driver's seat, exercising technical judgment on where and how much to use it for every given problem to be solved.
mewc 1y ago
More complaining & pessimism means better signal for teams building the AI coding tools! Keep it up! The ceiling for AI is not even close to being met. We have to be practical with whats reasonable, but getting 90% complete in a few prompts is magic.
boshalfoshal 1y ago
Imo this is a misunderstanding of what AI companies want AI tools to be and where the industry is heading in the near future. The endgame for many companies is SWE automation, not augmentation. To expand - 1. Models "reason" and can increasingly generate code given natural language. Its not just fancy autocomplete, its like having an intern - mid level engineer at your beck and call to implement some feature. Natural language is generally sufficient enough when I interact with other engineers, why is it not sufficient for an AI, which (in the limit), approaches an actual human engineer? 2. Business wise, companies will not settle for augmentation. Software companies pay tons of money in headcount, its probably most mid-sized companies top or second line item. The endgame for leadership at these companies is to do more with less. This necessitates automation (in addition to augmenting the remaining roles). People need to stop thinking of LLMs as "autocomplete on steroids" and actually start thinking of them as a "24/7 junior SWE who doesn't need to eat or sleep and can do small tasks at 90% accuracy with some reasonable spec." Yeah you'll need to edit their code once in a while but they also get better and cost less than an actual person.
- __loam 1y ago
  Folks who believe this are going to lose a lot of money fixing broken software and shipping products that piss off their users.
  - HexDecOctBin 1y ago
    Good for outsourcing companies. India used Y2K to build its IT sector and lift up its economy, hopefully Africa can do the same fixing AI slop.
  - Terr_ 1y ago
    Thought not as much as they ought to, if all their competitors jump off the same cliff to fit in. :/
- throw234234234 1y ago
  That is the ideal for the management types and the AI labs themselves yes. Copilots are just a way to test the market, and gain data and adoption early. I don't think it is much of a secret anymore. We even see benchmarks created (e.g. OpenAI recently did one) that are solely about taking paid work away from programmers and how many "paid tasks" it can actually do. They have a benchmark - that's their target. As a standard pleb though I can understand why this world; where the people with connections, social standing and capital have an advantage isn't appealing to many on this forum. If anyone can do something - other advantages that aren't as easy to acquire matter more relatively.
bad_haircut72 1y ago
I think so many devs fail to realise that to your product manager / team lead, the interface between you and the LLM is basically the same. They write a ticket/prompt and they get back a bunch of code that undoubtedly has bugs and misinterpretations in it, will probably go through a few rounds of revisions of back and forth until its good enough to ship (ie they tested it black-box style and it worked once) then they can move on to the next thing until whatever this ticket was about rears its ugly head again at some point in the future. If you arent used to writing user stories / planning, youre really gonna be obsolete soon.
voidhorse 1y ago
Hopefully a CEO finally tempering some expectations and the recent Apple paper bring some sanity back into the discourse around these tools.[^1] Are they cool and useful? Yes. Do they reason? No. (Before you complain, please first define reason). Are they end all be all of all problem solving and the dawn of AGI? Also no. Once we actually bring some rationality back into the radius of discourse maybe we'll actually begin to start figuring out how these things actually fit into an engineering workflow and stop throwing around ridiculous terms like vibe coding. If you are an engineer, you are signing up to build rigorously verified and validated system, preferably with some amount of certainty about their behavior under boundary conditions. All the current hype-addled discussion around LLM seems to have had everything but correctness as it's focus. [^1]: It shouldn't take a CEO but many people, even technologists, who should be more rational about whose opinions they deem worthy of consideration, m seem to overvalue the opinions of the csuite for some bizarre, inexplicable reason.
- crackalamoo 1y ago
  The recent Apple paper seemed pretty flawed. Anthropic/Open Philanthropy did a rebuttal paper, The Illusion of the Illusion of Thinking. > Do they reason? No. (Before you complain, please first define reason). Defining reasoning is the problem. No, they don't reason in the same way as humans. But they seem to be able to go through reasoning steps in some important way. It's like asking if submarines swim.
  - voidhorse 1y ago
    I completely agree. The difference is, the utility of the submarine and its sales strategy did not depend on convincing human beings that it does swim like them. The opposite is true of LLMs. Much of the sales pitch of these companies is that these things are capable of some form of reasoning that is in 1:1 correspondence with human reason. Not true. That's what makes this whole segment of the industry snake oil. It's not complete bunk because they do have some utility, but these companies know what they are doing when they use the term reason in all their marketing and papers. They are, in fact, trying to sell you the submarine because it can "swim".
h4kunamata 1y ago
Too late, I am seeing developer after developer doing copy/paste from AI tools and when asked, they have no idea how the code works coz "it just works" Google itself said 30% of their code is AI generated, and yet they had a recent outage worldwide, coincidence?? You tell me.
- octo888 1y ago
  "How do you know it works?" "It's got tests" "Who wrote the tests?" "It did. So?" They're "tactical tornados"[0] with a jetpack [0] A term from the book A Philosophy of Software Design - people who constantly chuck out "working" code with no design. Tactical programming vs Strategic programming
bamboozled 1y ago
We've generated a lot of code with claude code recently...then we've had to go back and rationalize it... :) fun times...you absolutely must have a well defined architecture established before using these tools.
rufius 1y ago
Water’s wet, fire’s hot. News at 5.
lvl155 1y ago
AI is still not there yet. For example, I constantly have to deal with mis-referenced documents and specifications. I think part of the problem is that it was trained on outdated materials and is unable to actively update on the fly. I can get around this problem but… The problem with today’s LLM and GI solutions is that they try to solve all n steps when solving the first i steps would be infinitely more useful for human consumption. I’ve yet to see a fully modular solution (though MCPs partly solves it), where I can just say, “Hey, using my specific coding style based on my github, solve problem x, based on resources a, b, and c and only a, b, and c.” I would also like to see a more verbose/interactive coding AI, where it will ask incremental questions as it traverses a problem tree.
hintymad 1y ago
Copying from another post. I’m very puzzled on why people don’t talk more about essential complexity of specifying systems any more: In No Silver Bullet, Fred Brooks argues that the hard part of software engineering lies in essential complexity - understanding, specifying, and modeling the problem space - while accidental complexity like tool limitations is secondary. His point was that no tool or methodology would "magically" eliminate the difficulty of software development because the core challenge is conceptual, not syntactic. Fast forward to today: there's a lot of talk about AI agents replacing engineers by writing entire codebases from natural language prompts. But that seems to assume the specification problem is somehow solved or simplified. In reality, turning vague ideas into detailed, robust systems still feels like the core job of engineers. If someone provides detailed specs and iteratively works with an AI to build software, aren’t they just using AI to eliminate accidental complexity—like how we moved from assembly to high-level languages? That doesn’t replace engineers; it boosts our productivity. If anything, it should increase opportunities by lowering the cost of iteration and scaling our impact. So how do we reconcile this? If an agent writes a product from a prompt, that only works because someone else has already fully specified the system—implicitly or explicitly. And if we’re just using AI to replicate existing products, then we’re not solving technical problems anymore; we’re just competing on distribution or cost. That’s not an engineering disruption—it’s a business one. What am I missing here?
- andyferris 1y ago
  I'm not sure what the answer is - but I will say that LLMs do help me wrangle with essential complexity / real-world issues too. Most problems businesses face have been seen by other businesses; perhaps some knowledge is in the training set or perhaps some problems are so easy to reason through that a LLM can do the "reasoning" more-or-less from first principles and your problem description. I am speculating that AI will help with both sides of the No Silver Bullet dichotomy?
  - daxfohl 1y ago
    Yeah, I give it about two years until we get to "Hey AI, what should we do today?" "Hi, I've noticed an increase in users struggling with transactions across individual accounts that they own. It appears some aspect of multitenancy would be warmly received by a significant fraction of our userbase. I have compiled a report on the different approaches taken by medium and large tech companies in this regard, and created a summary of user feedback that I've found on each. Based on this, and with the nuance of our industry, current userbase, the future markets we want to explore, and the ability to fit it most naturally into our existing infrastructure, I have boiled it down to one of these three options. Here are detailed design docs for each, that includes all downstream services affected, all data schema changes, lists out any concerns about backwards compatibility, user interface nuances, and has all the new operational and adoption metrics that we will want to monitor. Please read these through and let me know which one to start, and if you have any questions or suggestions I'll be more than happy to take them. For the first option, I've already prepared a list of PRs that I'm ready to commit and deploy in the designated order, and have tested e2e in a test cluster of all affected services, and it is up and running in a test cluster currently if you would like to explore it. It will take me a couple hours to do the same with the other two options if you'd like. If I get the green light today, I can sequence the deployments so that they don't conflict with other projects and have it in production by the end of the week, along with communication and optional training to the users I feel would find the feature most useful. Of course any of this can be changed, postponed, or dropped if you have concerns, would like to take a different approach, or think the feature should not be pursued."
Zaylan 1y ago
AI tools are great for speeding up small tasks, but when it comes to debugging, refactoring, or designing anything more complex, manual coding is still essential. Especially when things break, if you do not understand the underlying logic, you cannot really fix it properly. AI is becoming a helpful assistant, but it is still far from replacing real engineering skill.
deadbabe 1y ago
The other day we had a fairly complex conditional, modified incorrectly by AI, and it cost the company a lot of money and harmed reputation with partners. AI just cannot reason about logical things reliably. And no one noticed because the AI had made several other sweeping changes, and the noise drowned it out.
- deleted 1y ago
  [deleted]
sneak 1y ago
> GitHub CEO Thomas Dohmke Did I miss Nat Friedman stepping down? Does the new guy think having ICE as a customer is ok, too?
astariul 1y ago
> The continued shortage of software engineers, coupled with research showing that AI tools are particularly beneficial for junior developers Am I living in a different timeline than these guys ? In my timeline, the tech job market is terrible, and AI is the worst for junior developers, because they aren't learning what they should by doing.
- ThunderSizzle 1y ago
  There's a shortage of software engineers, but not a shortage of people who have those job titles. Aka, 80% of the work being done by 20% of the people. The problem is you still have to hire the other 80% of the developers to also get those 20%
alganet 1y ago
> Dohmke described an effective workflow where AI tools generate code and submit pull requests. This is kind of vague. What kinds of contributions he's talking about? Adding features, refactoring, removing dead code, optimizing, adding new tests? The article mentions boilerplate. Is that all current coding AIs can do? > For instance, spending too much time explaining simple changes in natural language instead of editing the code directly. Why not write the code directly then? Even less friction. Again, _it all depends on the kinds of contributions AI can make_. The fact that they're being vague about it tells me something. If you had a bot that can fix tests (or even get you 90% of the way), you'd be boasting that everywhere. It would be an extraordinary evidence and you'd be very proud of it. If someone made a PR to my repo adding a bunch of automated boilerplate, I'd be pissed, not encouraged to make it work.
notyouraibot 1y ago
I recently started consulting for a company that's building an AI first tool. The entire application is powered through several AI agents, I had a look at their code and had to throw up, each agent is a single Python file of over 4000 lines, you can just look at the first 100 lines and tell its all LLM generated code, the hilarious part is if I paste the code into ChatGPT to help me break it down, it hits the context window in like 1 response! I think this is one of the main problems with AI code, 5 years ago every time I took on a project, I knew the code I was reading and diving into was written by a human, well thought and structured. These days almost all the code I see is glue code, AI has done severe damage by enabling engineers who do not understand basic structures and fundamentals write 'code that just works'. At the same time, I don't blame just the AI, cause several times I have written code myself which is gluecode, but then asked AI to refactor it in a way I want and it is usually really good at it.
WolfOliver 1y ago
I think in 5 years from now we will see a major software dev shortage. Mainly because of all the reports that big tech companies are replacing devs with AI which scares new students to sign up for a CS degree. The truth is that those devs who has been replaced should not have been hired in the first place as the companies were already overstuffed.
thtuothy57747 1y ago
Yawn... Epistemic standards have fallen to rock bottom levels across STEM due to metric matching, more so in the cookie-cutter jira world of soulless software factories. That these "geniuses" think they can replace humans, not only for knowledge work, but also for labour is laughable for any one who has worked with LLMs.
guicen 1y ago
I believe it's important to learn the basics of manual programming and also figure out how to work with AI tools in a smart way. It's not just about letting AI do the coding for us. We still need to think clearly and improve our own Solving the problem skills. AI can help turn ideas into reality, but we need to grow too if we want to really make use of it.
Daisywh 1y ago
I'm not really afraid that AI will replace programmers. What I worry about is that it might make programmers stop thinking. I've seen beginners who quickly get used to asking AI for answers and no longer try to understand how things actually work. It may feel fast at first, but over time they lose the ability to solve problems on their own.
careful_ai 1y ago
Great post—Dohmke’s call to preserve hands‑on coding while leveraging AI resonates strongly. It’s not about replacing devs but enabling them to build faster while staying in control. In practice, pure LLM suggestions often feel detached from your actual codebase—missing intent, architectural constraints, or team conventions. What helped us was adopting a repo‑aware evaluation approach with tooling that: - Scans entire repos, generates architecture diagrams, dependency maps, and feature breakdowns. - Surfaces AI suggestions grounded in context—so prompts don’t float in isolation. - Supports human-in-the-loop validation, making it easy to vet AI‑generated PRs before merging. - Tracks drift, technical debt, and cost per eval, so AI usage isn’t a black box. The result isn’t autopilot coding—it’s contextual assistance that amplifies developer decisions. That aligns exactly with Dohmke: use AI to accelerate, but keep the engineer firmly in the driver’s seat. Curious if others have tried similar repo‑aware AI workflows that don’t sacrifice control for speed?
stego-tech 1y ago
I cannot help but read this in the subtext of, “We need more training data from humans; please don’t stop uploading your code to us.” Look, manual coding (and art, and media, and IT, and others) will always be needed. GenAI was never going to replace these jobs wholesale, or even permanently displace workers. The fact this is trending in an APAC-focused site suggests the real message is, “we don’t want our outsource farms thinking this [GenAI] will replace you.” Prediction of tokens was never going to lead to AGI. All it’s going to accomplish is instilling a deep, traumatic hostility in the populace towards further automation right when we need it the most.
user4673568345 1y ago
WELL YOU DONT SAY

> The continued shortage of software engineers, coupled with research showing that AI tools are particularly beneficial for junior developers... I stopped reading after this.

exabrial 1y ago

Amazingly, so does air and water. What AI salesman could have predicted this?

CoffeeOnWrite 1y ago

“Manual” has a negative connotation. If I understand the article correctly, they mean “human coding remains key”. It’s not clear to me the GitHub CEO actually used the word “manual”, that would surprise me. Is there another source on this that’s either more neutral or better at choosing accurate words? The last thing we need is to put down human coding as “manual”; human coders have a large toolbox of non-AI tools to automate their coding. (Wow I sound triggered! sigh)

upghost 1y ago
It's almost as bad as "manual" thinking!
vram22 1y ago
>Manual” has a negative connotation. If I understand the article correctly, they mean “human coding remains key”. A man is a human.
- layer8 1y ago
  Humanual coding? ;) “Manual” comes from Latin manus, meaning “hand”: https://en.wiktionary.org/wiki/manus https://en.wiktionary.org/wiki/manus. It literally means “by hand”.
  - vram22 1y ago
    Nice one :) I too can sling a bit of Latin. ;) Here is one phrase, in which one word, malus, is like an off-by-one error from your manus word, so to speak :) : nemo malus nisi probetur https://www.google.com/search?q=nemo+malus+nisi+probetur https://www.google.com/search?q=nemo+malus+nisi+probetur From the AI overview (need to at least try that out a few times after all the talk about Google enshittification like by Cory Doctorow in this year's PyCon US keynote: >Nemo malus nisi probetur" is a Latin legal maxim that translates to "No one is evil unless proven." It signifies that a person is presumed innocent until proven guilty in a court of law. This principle is fundamental to legal systems that value fairness and due process, ensuring that accusations are substantiated before a person is considered culpable. Here's a breakdown of the phrase: Nemo: No one malus: Evil, bad, wicked nisi: Unless probetur: Is proven, is shown, is demonstrated The maxim essentially means that one should not be treated as inherently bad or guilty without sufficient evidence. This principle is closely related to the concept of "presumption of innocence" and is crucial for upholding justice and protecting individual rights.
deleted 1y ago
[deleted]
anamexis 1y ago
What is the distinction between manual coding and human coding?
- jdiff 1y ago
  Often when you're calling something "manual" you're taking something off the automated happy path to tediously and slowly wind the thing through its complex process by hand. The difference between manual coding and human coding is tedium and laboriousness. It's not laborious to program, but the phrase "manual coding" evokes that image.
  - skydhash 1y ago
    Maybe that’s what they’ve been doing? No one using Vim, Emacs, or Unix as an IDE would say they do manual coding with the amount of automation that usually goes there.
    - aeonik 1y ago
      Indeed, if your not using butterflies to program, it's not manual, and your not a real programmer https://xkcd.com/378/ https://xkcd.com/378/
GuinansEyebrows 1y ago
> Wow I sound triggered! sigh this is okay! it's a sign of your humanity :)
deleted 1y ago
[deleted]
layer8 1y ago
How about “organic coding”? ;)
dalyons 1y ago
Acoustic coding
ivanjermakov 1y ago
Analog coding
mrheosuper 1y ago
"Authentic" maybe ?
bluefirebrand 1y ago
> “Manual” has a negative connotation Wait does it? This is a new idea to me, in what way could "manual" have a negative connotation? Are people really that against doing things manually nowadays?

FirmwareBurner 1y ago

I wonder how much coding he does and how does he know which code is human written and which by machine.

treefarmer 1y ago

I get a 403 forbidden error when trying to view the page. Anyone else get that?

strict9 1y ago

It's interesting to see a CEO express thoughts on AI and coding go in a slightly different direction. Usually the CEO or investor says 30% (or some other made up number) of all code is written by AI and the number will only increase, implying that developers will soon be obsolete. It's implied that 30% of all code submitted and shipped to production is from AI agents with zero human interaction. But of course this is not the case, it's the same developers as before using tools to more rapidly write code. And writing code is only one part of a developer's job in building software.

heisenbit 1y ago
Well, I suspect GitHub's income is a function of the number of developers using it so it is not surprising that he takes this position.
madeofpalk 1y ago
He’s probably more right than not. But he also has a vested interest in this (just like the other CEOs who say the opposite), being in the business of human-mediated code.
- yodon 1y ago
  Presumably you're aware that the full name of Microsoft's Copilot AI code authoring tool is "GitHub Copilot", that GitHub developed it, and that he runs GitHub.
  - Imustaskforhelp 1y ago
    Yea, which is why I was surprised too when he said this.
  - madeofpalk 1y ago
    Copilot. Not Pilot.
nextlevelwizard 1y ago
I love that the 30% quote is so miss used. You probably should watch that clip again and actually listen what he said.

deleted 1y ago

[deleted]

jstummbillig 1y ago

Going by the content of the linked post, this is very much a misleading headline. There is nothing in the quotes that I would read as an endorsement of "manual coding", at least not in the sense that we have used the term "coding" for the past decades.

jasonthorsness 1y ago

"He warned that depending solely on automated agents could lead to inefficiencies. For instance, spending too much time explaining simple changes in natural language instead of editing the code directly." Lots of changes where describing them in English takes longer than just performing the change. I think the most effective workflow with AI agents will be a sort of active back-and-forth.

sodality2 1y ago
Yeah, I can’t count the number of times I’ve thought about a change, explained it in natural language, pressed enter, then realized I’ve already arrived at the exact change I need to apply just by thinking it through. Oftentimes I even beat the agent at editing it, if it’s a context-heavy change.
- dgfitz 1y ago
  Rubber duck. I’ve kept one on my desk for over a decade. It was also like a dollar, which is more than I’ve spent on LLMs. :) https://en.m.wikipedia.org/wiki/Rubber_duck_debugging https://en.m.wikipedia.org/wiki/Rubber_duck_debugging
neom 1y ago
How active are you ok with/want? I've just joined an agent tooling startup (yesh...I wrote that huh...) - and it's something we talk a lot about internally, we're thinking it's fine to do back and forth, tell it frankly it's not doing it right, etc, but some stuff might be annoying? Do you have a sense of how this might work to your mind? Thanks! :)

sysmax 1y ago

AI can very efficiently apply common patterns to vast amounts of code, but it has no inherent "idea" of what it's doing. Here's a fresh example that I stumbled upon just a few hours ago. I needed to refactor some code that first computes the size of a popup, and then separately, the top left corner. For brevity, one part used an "if", while the other one had a "switch": if (orientation == Dock.Left || orientation == Dock.Right) size = /* horizontal placement */ else size = /* vertical placement */ var point = orientation switch { Dock.Left => ... Dock.Right => ... Dock.Top => ... Dock.Bottom => ... }; I wanted the LLM to refactor it to store the position rather than applying it immediately. Turns out, it just could not handle different things (if vs. switch) doing a similar thing. I tried several variations of prompts, but it very strongly leaning to either have two ifs, or two switches, despite rather explicit instructions not to do so. It sort of makes sense: once the model has "completed" an if, and then encounters the need for a similar thing, it will pick an "if" again, because, well, it is completing the previous tokens. Harmless here, but in many slightly less trivial examples, it would just steamroll over nuance and produce code that appears good, but fails in weird ways. That said, splitting tasks into smaller parts devoid of such ambiguities works really well. Way easier to say "store size in m_StateStorage and apply on render" than manually editing 5 different points in the code. Especially with stuff like Cerebras, that can chew through complex code at several kilobytes per second, expanding simple thoughts faster than you could physically type them.

gametorch 1y ago
[flagged]
- npinsker 1y ago
  Sweeping generalizations about how LLMs will always (someday) be able to do arbitrary X, Y, and Z don't really capture me either
  - gametorch 1y ago
    [flagged]

deleted 1y ago

[deleted]

pxeger1 1y ago
Thomas Dohmke is CEO of GitHub .

TacticalCoder 1y ago

What's amazing with "vibe coding" is the number of non tecchie who now decide they want to code. They understand that a new tool is on the block and they realize how it could help their business but they also realize that to really harness this superpower you need to code. So out of nowhere both my brother and my wife, without concerting themselves (they don't live on the same continent), are now taking coding lessons. Not AI related: just learning to code in Python. And suddenly I'm winning lots of cookie points: my wife realizes that coding is not something that's that simple and that it's really the coders who have it easy with AI. As for the AI boom: it's another tool. I use it daily (and pay for it). But it's still just a tool. Wake me up when 95% of Linux's kernel code is written by an AI.

dboreham 1y ago

That's him out the Illuminati then.

hnthrow90348765 1y ago

My guess is they will settle for 2x the productivity as a before-AI developer as their skill floor, but then not take a look at how long meetings and other processes take. Why not look at Bob who takes like 2 weeks to write tickets on what they actually want in a feature? Or Alice who's really slow getting Figma designs done and validated? How nice would having a "someone's bothered a developer" metric be and having the business seek to get that to zero and talk very loudly about it as they have about developers?

hobs 1y ago
Because everyone who bothers the developers is actually in charge, and they would never want to reduce their utilization, all of this removal of need to focus on the code makes them excited that you can be in even more meetings.

mycocola 1y ago

I think most programmers would agree that thinking represents the majority of our time. Writing code is no different than writing down your thoughts, and that process in itself can be immensely productive -- it can spark new ideas, grant epiphanies, or take you in an entirely new direction altogether. Writing is thinking. I think an over-reliance, or perhaps any reliance, on AI tools will turn good programmers into slop factories, as they consistently skip over a vital part of creating high-quality software. You could argue that the prompt == code, but then you are adding an intermediary step between you and the code, and something will always be lost in translation. I'd say just write the code.

sothatsit 1y ago
I think this misses the point. You're right that programmers still need to think. But you're wrong thinking that AI does not help with that. With AI, instead of starting with zero and building up, you can start with a result and iterate on it straight away. This process really shines when you have a good idea of what you want to do, and how you want it implemented. In these cases, it is really easy to review the code, because you knew what you wanted it to look like. And so, it lets me implement some basic features in 15 minutes instead of an hour. This is awesome. For more complex ideas, AI can also be a great idea sparring partner. Claude Code can take a paragraph or two from me, and then generate a 200-800 line planning document fleshing out all the details. That document: 1) helps me to quickly spot roadblocks using my own knowledge, and 2) helps me iterate quickly in the design space. This lets me spend more time thinking about the design of the system. And Claude 4 Opus is near-perfect at taking one of these big planning specifications and implementing it, because the feature is so well specified. So, the reality is that AI opens up new possible workflows. They aren't always appropriate. Sometimes the process of writing the code yourself and iterating on it is important to helping you build your mental model of a piece of functionality. But a lot of the time, there's no mystery in what I want to write. And in these cases, AI is brilliant at speeding up design and implementation.
- mycocola 1y ago
  Based on your workflow, I think there is considerable risk of you being wooed by AI into believing what you are doing is worthwhile. The plan AI offers is coherent, specific, it sounds good. It's validation. Sugar.

agentultra 1y ago

… because programming languages are the right level of precision for specifying a program you want. Natural language isn’t it. Of course you need to review and edit what it generates. Of course it’s often easier to make the change yourself instead of describing how to make the change. I wonder if the independent studies that show Copilot increasing the rate of errors in software have anything to do with this less bold attitude. Most people selling AI are predicting the obsolescence of human authors.

soulofmischief 1y ago
Transformers can be used to automate testing, create deeper and broader specification, accelerate greenfield projects, rapidly and precisely expand a developer's knowledge as needed, navigate unfamiliar APIs without relying on reference, build out initial features, do code review and so much more. Even if code is the right medium for specifying a program, transformers act as an automated interface between that medium and natural language. Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual. > Most people selling AI are predicting the obsolescence of human authors. It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace. This replacement might not happen tomorrow, or next year, or even in the next decade, but it's clear that we are able to build capable models. What remains to be done is R&D around things like hallucinations, accuracy, affordability, etc. as well as tooling and infrastructure built around this new paradigm. But the cat's out of the bag, and we are not returning to a paradigm that doesn't involve intelligent automation in our daily work; programming is literally about automating things and transformers are a massive forward step. That doesn't really mean anything, though; You can still be as involved in your programming work as you'd like. Whether you can find paid, professional work depends on your domain, skill level and compensation preferences. But you can always program for fun or personal projects, and decide how much or how little automation you use. But I will recommend that you take these tools seriously, and that you aren't too dismissive, or you could find yourself left behind in a rapidly evolving landscape, similarly to the advent of personal computing and the internet.

lunarboy 1y ago

It was only 2 years ago we were still taking about GPTs making up completely nonsense, and now hallucinations are almost gone from the discussions. I assume it will get even better, but I also think there is an inherent plateau. Just like how machines solved mass manufacturing work, but we still have factory workers and overseers. Also, "manually" hand crafted pieces like fashion and watches continue to be the most expensive luxury goods. So I don't believe good design architects and consulting will ever be fully replaced.

jashmatthews 1y ago
Hallucinations are now plausibly wrong which is in some ways harder to deal with. GPT4.1 still generates Rust with imaginary crates and says “your tests passed, we can now move on” to a completely failed test run.
mrheosuper 1y ago
"hallucinations are almost gone from the discussions" because everyone now accepts that LLM hallucinate all the times, no point in mentioning it anymore.

deleted 1y ago

[deleted]

OJFord 1y ago

This seems to be an AI summary of a (not linked) podcast.

randomNumber7 1y ago

Code monkeys that doesn't understand the limits of LLMs and can't solve problems where the LLM fails are not needed in the world of tomorrow. Why wouldn't your boss ask ChatGPT directly?

guluarte 1y ago

AI is good for boilerplate, suggestions, nothing more.

johnisgood 1y ago
For you, perhaps.
- beej71 1y ago
  For me, too. On the poorly-documented stuff that I get into, where I really need help, it flails. I wanted some jq script and it made an incomprehensible thing that usually worked. And every fix it made broke something else. It just kept digging a deeper hole. After a while of that, I bit the bullet and learned jq script. I wrote a solution that was more capable, easier to read, and, importantly, always worked. The thing is, jq is completely documented. Everything I needed was online. But there just aren't many examples to for LLMs, so they choke. Start asking it questions about complexity classes and you can get it to contradict itself in no time. Most of the code in the world right now is very formulaic, and it's great at that. Sorry, WordPress devs. It's a powerful tool, but it's not that powerful.
  - johnisgood 1y ago
    Have you tried feeding it the documentation of jq? And which LLM(s) have you tried? I had great success with niche programming languages by feeding it the documentation and a couple of projects.

layer8 1y ago

One of the most useful properties of computers is that they enable reliable, eminently reproducible automation. Formal languages (like programming languages) not only allow to unambiguously specify the desired automation to the upmost level of precision, they also allow humans to reason about the automation with precision and confidence. Natural language is a poor substitute for that. The ground truth of programs will always be the code, and if humans want to precisely control what a program does, they’ll be best served by understanding, manipulating, and reasoning about the code.

swyx 1y ago

> In an appearance on “The MAD Podcast with Matt Turck,” Dohmke said that > Source: The Times of India what in the recycled content is this trash?

lawgimenez 1y ago

Not gonna lie, first time I've heard of manual coding.

another_twist 1y ago

I think these are coordinated posts by Microsoft execs. First their director of product, now this. Its like they're trying to calm the auto coding hype until they catchup and thus keep OpenAI from running away.

svachalek 1y ago
Microsoft is the largest shareholder in OpenAI.

taysix 1y ago

I had a fun result the other day from Claude. I opened a script in Zed and asked it to "fix the error on line 71". Claude happily went and fixed the error on line 91.... 1. There was no error on line 91, it did some inconsequential formatting on that line 2. More importantly, it just ignored the very specific line I told it to go to. It's like I was playing telephone with the LLM which felt so strange with text-based communication. This was me trying to get better at using the LLM while coding and seeing if I could "one-shot" some very simple things. Of course me doing this _very_ tiny fix myself would have been faster. Just felt weird and reinforces this idea that the LLM isn't actually thinking at all.

baby 1y ago
ITT: people trying to use AI to code for the first time
klysm 1y ago
LLMs probably have bad awareness of line numbers
- mcintyre1994 1y ago
  I suspect if OP highlighted line 71 and added it to chat and said fix the error, they’d get a much better response. I assume Cursor could create a tool to help it interpret line numbers, but that’s not how they expect you to use it really.
  - recursive 1y ago
    How is this better from just using a formal language again?
    - svachalek 1y ago
      Who said it's better? It's a design choice. Someone can easily write an agent that takes instructions in any language you like.

klysm 1y ago

CEOs are possibly the last person you should listen to on any given subject.

beej71 1y ago
I'm just vibe-CEOing my new company. It's amazing how productive it is!
- konfusinomicon 1y ago
  just wait til it starts virtue signalling and posting contrived anecdotes about b2b sales and the benefits of RTO on LinkedIn. the vibe-HR department is gonna have to rein things in fast!
dgfitz 1y ago
So do we ignore the Github CEO or all the other ones?

GiorgioG 1y ago

No fucking shit Sherlock.

bmitc 1y ago

It would be nice if he would back that up by increasing focus on quality of life issues on GitHub. GitHub's feature set seems to get very little attention unless it overlaps with Copilot.

exiguus 1y ago

Personally, I define the job of a software engineer as transform requirements into software. Software is not only code. Requirements are not only natural language. At the moment I can't manage to be faster with the AI than manually. Unless its a simple task or software. In my experience AI's are atm junior or mid-level developers. And in the last two years, they didn't get significant better.

nicbou 1y ago
Most of the time, the requirements are not spelled out. Nobody even knows what the business logic is supposed to be. A lot of it has to be decided by the software engineer based on available information. It sometimes involve walking around the office asking people things. It also requires a fair bit of wisdom to know where the software is expected to grow, and how to architect for that eventuality. I can't picture an LLM doing a fraction of that work.
- exiguus 1y ago
  I think that's my problem with AI. Let's say I have all the requirements, down to the smallest detail. Then I make my decisions at a micro level. Formulate an architecture. Take all the non-functionals into account. I would write a book as a prompt that is not able to express my thoughts as accurately as if I were writing code right away. Apart from the fact that the prompt is generally a superfluous intermediate step in which I struggle to create an exact programming language with an imprecise natural language with a result that is not reproduce-able.
  - ra0x3 1y ago
    This is a really good point. At a certain point, huge prompts (which you can readily find available on Github, used by large LLM-based corps) are just....files of code? Why wouldn't I just write the code myself at that point? Almost makes me think this "AI coding takeover" is strictly pushed by non-technical people.
  - mediaman 1y ago
    AI is less useful when I'm picking through specific, careful business logic. But we still have lots of boilerplate code that's required, and it's really good at that. If I need a reasonably good-looking front-end UI, Claude will put that together quickly for me. Or if I need it to use a common algorithm against some data, it's good at applying that. What I like about AI is that it lets me slide along the automation-specificity spectrum as I go through my work. Sometimes it feels like I've opened up a big stretch of open highway (some standard issue UI work with structures already well-defined) and I can "goose" it. Sometimes there's some tricky logic, and I just know the AI won't do well; it takes just as long to explain the logic as to write it in code. So I hit the brakes, slow down, navigate those tricky parts. Previously, in the prior attempt to remove the need for engineers, no-code solutions instead trapped people. They pretended like everything is open highway. It's not, which is why they fail. But here we can apply our own judgment and skill in deciding when a lot of "common-pattern" code is required versus the times where specificity and business context is required. That's also why these LLMs get over-hyped: people over-hype them for the same reason they over-hyped no-code; they don't understand the job to be done, and because of that, they actually don't understand why this is much better than the fanciful capabilities they pretend it has ("it's like an employee and automates everything!"). The tools are much more powerful when an engineer is in the driver's seat, exercising technical judgment on where and how much to use it for every given problem to be solved.

mewc 1y ago

More complaining & pessimism means better signal for teams building the AI coding tools! Keep it up! The ceiling for AI is not even close to being met. We have to be practical with whats reasonable, but getting 90% complete in a few prompts is magic.

boshalfoshal 1y ago

Imo this is a misunderstanding of what AI companies want AI tools to be and where the industry is heading in the near future. The endgame for many companies is SWE automation, not augmentation. To expand - 1. Models "reason" and can increasingly generate code given natural language. Its not just fancy autocomplete, its like having an intern - mid level engineer at your beck and call to implement some feature. Natural language is generally sufficient enough when I interact with other engineers, why is it not sufficient for an AI, which (in the limit), approaches an actual human engineer? 2. Business wise, companies will not settle for augmentation. Software companies pay tons of money in headcount, its probably most mid-sized companies top or second line item. The endgame for leadership at these companies is to do more with less. This necessitates automation (in addition to augmenting the remaining roles). People need to stop thinking of LLMs as "autocomplete on steroids" and actually start thinking of them as a "24/7 junior SWE who doesn't need to eat or sleep and can do small tasks at 90% accuracy with some reasonable spec." Yeah you'll need to edit their code once in a while but they also get better and cost less than an actual person.

__loam 1y ago
Folks who believe this are going to lose a lot of money fixing broken software and shipping products that piss off their users.
- HexDecOctBin 1y ago
  Good for outsourcing companies. India used Y2K to build its IT sector and lift up its economy, hopefully Africa can do the same fixing AI slop.
- Terr_ 1y ago
  Thought not as much as they ought to, if all their competitors jump off the same cliff to fit in. :/
throw234234234 1y ago
That is the ideal for the management types and the AI labs themselves yes. Copilots are just a way to test the market, and gain data and adoption early. I don't think it is much of a secret anymore. We even see benchmarks created (e.g. OpenAI recently did one) that are solely about taking paid work away from programmers and how many "paid tasks" it can actually do. They have a benchmark - that's their target. As a standard pleb though I can understand why this world; where the people with connections, social standing and capital have an advantage isn't appealing to many on this forum. If anyone can do something - other advantages that aren't as easy to acquire matter more relatively.

bad_haircut72 1y ago

I think so many devs fail to realise that to your product manager / team lead, the interface between you and the LLM is basically the same. They write a ticket/prompt and they get back a bunch of code that undoubtedly has bugs and misinterpretations in it, will probably go through a few rounds of revisions of back and forth until its good enough to ship (ie they tested it black-box style and it worked once) then they can move on to the next thing until whatever this ticket was about rears its ugly head again at some point in the future. If you arent used to writing user stories / planning, youre really gonna be obsolete soon.

voidhorse 1y ago

Hopefully a CEO finally tempering some expectations and the recent Apple paper bring some sanity back into the discourse around these tools.[^1] Are they cool and useful? Yes. Do they reason? No. (Before you complain, please first define reason). Are they end all be all of all problem solving and the dawn of AGI? Also no. Once we actually bring some rationality back into the radius of discourse maybe we'll actually begin to start figuring out how these things actually fit into an engineering workflow and stop throwing around ridiculous terms like vibe coding. If you are an engineer, you are signing up to build rigorously verified and validated system, preferably with some amount of certainty about their behavior under boundary conditions. All the current hype-addled discussion around LLM seems to have had everything but correctness as it's focus. [^1]: It shouldn't take a CEO but many people, even technologists, who should be more rational about whose opinions they deem worthy of consideration, m seem to overvalue the opinions of the csuite for some bizarre, inexplicable reason.

crackalamoo 1y ago
The recent Apple paper seemed pretty flawed. Anthropic/Open Philanthropy did a rebuttal paper, The Illusion of the Illusion of Thinking. > Do they reason? No. (Before you complain, please first define reason). Defining reasoning is the problem. No, they don't reason in the same way as humans. But they seem to be able to go through reasoning steps in some important way. It's like asking if submarines swim.
- voidhorse 1y ago
  I completely agree. The difference is, the utility of the submarine and its sales strategy did not depend on convincing human beings that it does swim like them. The opposite is true of LLMs. Much of the sales pitch of these companies is that these things are capable of some form of reasoning that is in 1:1 correspondence with human reason. Not true. That's what makes this whole segment of the industry snake oil. It's not complete bunk because they do have some utility, but these companies know what they are doing when they use the term reason in all their marketing and papers. They are, in fact, trying to sell you the submarine because it can "swim".

h4kunamata 1y ago

Too late, I am seeing developer after developer doing copy/paste from AI tools and when asked, they have no idea how the code works coz "it just works" Google itself said 30% of their code is AI generated, and yet they had a recent outage worldwide, coincidence?? You tell me.

octo888 1y ago
"How do you know it works?" "It's got tests" "Who wrote the tests?" "It did. So?" They're "tactical tornados"[0] with a jetpack [0] A term from the book A Philosophy of Software Design - people who constantly chuck out "working" code with no design. Tactical programming vs Strategic programming

bamboozled 1y ago

We've generated a lot of code with claude code recently...then we've had to go back and rationalize it... :) fun times...you absolutely must have a well defined architecture established before using these tools.

rufius 1y ago

Water’s wet, fire’s hot. News at 5.

lvl155 1y ago

AI is still not there yet. For example, I constantly have to deal with mis-referenced documents and specifications. I think part of the problem is that it was trained on outdated materials and is unable to actively update on the fly. I can get around this problem but… The problem with today’s LLM and GI solutions is that they try to solve all n steps when solving the first i steps would be infinitely more useful for human consumption. I’ve yet to see a fully modular solution (though MCPs partly solves it), where I can just say, “Hey, using my specific coding style based on my github, solve problem x, based on resources a, b, and c and only a, b, and c.” I would also like to see a more verbose/interactive coding AI, where it will ask incremental questions as it traverses a problem tree.

hintymad 1y ago

Copying from another post. I’m very puzzled on why people don’t talk more about essential complexity of specifying systems any more: In No Silver Bullet, Fred Brooks argues that the hard part of software engineering lies in essential complexity - understanding, specifying, and modeling the problem space - while accidental complexity like tool limitations is secondary. His point was that no tool or methodology would "magically" eliminate the difficulty of software development because the core challenge is conceptual, not syntactic. Fast forward to today: there's a lot of talk about AI agents replacing engineers by writing entire codebases from natural language prompts. But that seems to assume the specification problem is somehow solved or simplified. In reality, turning vague ideas into detailed, robust systems still feels like the core job of engineers. If someone provides detailed specs and iteratively works with an AI to build software, aren’t they just using AI to eliminate accidental complexity—like how we moved from assembly to high-level languages? That doesn’t replace engineers; it boosts our productivity. If anything, it should increase opportunities by lowering the cost of iteration and scaling our impact. So how do we reconcile this? If an agent writes a product from a prompt, that only works because someone else has already fully specified the system—implicitly or explicitly. And if we’re just using AI to replicate existing products, then we’re not solving technical problems anymore; we’re just competing on distribution or cost. That’s not an engineering disruption—it’s a business one. What am I missing here?

andyferris 1y ago
I'm not sure what the answer is - but I will say that LLMs do help me wrangle with essential complexity / real-world issues too. Most problems businesses face have been seen by other businesses; perhaps some knowledge is in the training set or perhaps some problems are so easy to reason through that a LLM can do the "reasoning" more-or-less from first principles and your problem description. I am speculating that AI will help with both sides of the No Silver Bullet dichotomy?
- daxfohl 1y ago
  Yeah, I give it about two years until we get to "Hey AI, what should we do today?" "Hi, I've noticed an increase in users struggling with transactions across individual accounts that they own. It appears some aspect of multitenancy would be warmly received by a significant fraction of our userbase. I have compiled a report on the different approaches taken by medium and large tech companies in this regard, and created a summary of user feedback that I've found on each. Based on this, and with the nuance of our industry, current userbase, the future markets we want to explore, and the ability to fit it most naturally into our existing infrastructure, I have boiled it down to one of these three options. Here are detailed design docs for each, that includes all downstream services affected, all data schema changes, lists out any concerns about backwards compatibility, user interface nuances, and has all the new operational and adoption metrics that we will want to monitor. Please read these through and let me know which one to start, and if you have any questions or suggestions I'll be more than happy to take them. For the first option, I've already prepared a list of PRs that I'm ready to commit and deploy in the designated order, and have tested e2e in a test cluster of all affected services, and it is up and running in a test cluster currently if you would like to explore it. It will take me a couple hours to do the same with the other two options if you'd like. If I get the green light today, I can sequence the deployments so that they don't conflict with other projects and have it in production by the end of the week, along with communication and optional training to the users I feel would find the feature most useful. Of course any of this can be changed, postponed, or dropped if you have concerns, would like to take a different approach, or think the feature should not be pursued."

Zaylan 1y ago

AI tools are great for speeding up small tasks, but when it comes to debugging, refactoring, or designing anything more complex, manual coding is still essential. Especially when things break, if you do not understand the underlying logic, you cannot really fix it properly. AI is becoming a helpful assistant, but it is still far from replacing real engineering skill.

deadbabe 1y ago

The other day we had a fairly complex conditional, modified incorrectly by AI, and it cost the company a lot of money and harmed reputation with partners. AI just cannot reason about logical things reliably. And no one noticed because the AI had made several other sweeping changes, and the noise drowned it out.

deleted 1y ago
[deleted]

sneak 1y ago

> GitHub CEO Thomas Dohmke Did I miss Nat Friedman stepping down? Does the new guy think having ICE as a customer is ok, too?

astariul 1y ago

> The continued shortage of software engineers, coupled with research showing that AI tools are particularly beneficial for junior developers Am I living in a different timeline than these guys ? In my timeline, the tech job market is terrible, and AI is the worst for junior developers, because they aren't learning what they should by doing.

ThunderSizzle 1y ago
There's a shortage of software engineers, but not a shortage of people who have those job titles. Aka, 80% of the work being done by 20% of the people. The problem is you still have to hire the other 80% of the developers to also get those 20%

alganet 1y ago

> Dohmke described an effective workflow where AI tools generate code and submit pull requests. This is kind of vague. What kinds of contributions he's talking about? Adding features, refactoring, removing dead code, optimizing, adding new tests? The article mentions boilerplate. Is that all current coding AIs can do? > For instance, spending too much time explaining simple changes in natural language instead of editing the code directly. Why not write the code directly then? Even less friction. Again, _it all depends on the kinds of contributions AI can make_. The fact that they're being vague about it tells me something. If you had a bot that can fix tests (or even get you 90% of the way), you'd be boasting that everywhere. It would be an extraordinary evidence and you'd be very proud of it. If someone made a PR to my repo adding a bunch of automated boilerplate, I'd be pissed, not encouraged to make it work.

notyouraibot 1y ago

I recently started consulting for a company that's building an AI first tool. The entire application is powered through several AI agents, I had a look at their code and had to throw up, each agent is a single Python file of over 4000 lines, you can just look at the first 100 lines and tell its all LLM generated code, the hilarious part is if I paste the code into ChatGPT to help me break it down, it hits the context window in like 1 response! I think this is one of the main problems with AI code, 5 years ago every time I took on a project, I knew the code I was reading and diving into was written by a human, well thought and structured. These days almost all the code I see is glue code, AI has done severe damage by enabling engineers who do not understand basic structures and fundamentals write 'code that just works'. At the same time, I don't blame just the AI, cause several times I have written code myself which is gluecode, but then asked AI to refactor it in a way I want and it is usually really good at it.

WolfOliver 1y ago

I think in 5 years from now we will see a major software dev shortage. Mainly because of all the reports that big tech companies are replacing devs with AI which scares new students to sign up for a CS degree. The truth is that those devs who has been replaced should not have been hired in the first place as the companies were already overstuffed.

thtuothy57747 1y ago

Yawn... Epistemic standards have fallen to rock bottom levels across STEM due to metric matching, more so in the cookie-cutter jira world of soulless software factories. That these "geniuses" think they can replace humans, not only for knowledge work, but also for labour is laughable for any one who has worked with LLMs.

guicen 1y ago

I believe it's important to learn the basics of manual programming and also figure out how to work with AI tools in a smart way. It's not just about letting AI do the coding for us. We still need to think clearly and improve our own Solving the problem skills. AI can help turn ideas into reality, but we need to grow too if we want to really make use of it.

Daisywh 1y ago

I'm not really afraid that AI will replace programmers. What I worry about is that it might make programmers stop thinking. I've seen beginners who quickly get used to asking AI for answers and no longer try to understand how things actually work. It may feel fast at first, but over time they lose the ability to solve problems on their own.

careful_ai 1y ago

Great post—Dohmke’s call to preserve hands‑on coding while leveraging AI resonates strongly. It’s not about replacing devs but enabling them to build faster while staying in control. In practice, pure LLM suggestions often feel detached from your actual codebase—missing intent, architectural constraints, or team conventions. What helped us was adopting a repo‑aware evaluation approach with tooling that: - Scans entire repos, generates architecture diagrams, dependency maps, and feature breakdowns. - Surfaces AI suggestions grounded in context—so prompts don’t float in isolation. - Supports human-in-the-loop validation, making it easy to vet AI‑generated PRs before merging. - Tracks drift, technical debt, and cost per eval, so AI usage isn’t a black box. The result isn’t autopilot coding—it’s contextual assistance that amplifies developer decisions. That aligns exactly with Dohmke: use AI to accelerate, but keep the engineer firmly in the driver’s seat. Curious if others have tried similar repo‑aware AI workflows that don’t sacrifice control for speed?

stego-tech 1y ago

I cannot help but read this in the subtext of, “We need more training data from humans; please don’t stop uploading your code to us.” Look, manual coding (and art, and media, and IT, and others) will always be needed. GenAI was never going to replace these jobs wholesale, or even permanently displace workers. The fact this is trending in an APAC-focused site suggests the real message is, “we don’t want our outsource farms thinking this [GenAI] will replace you.” Prediction of tokens was never going to lead to AGI. All it’s going to accomplish is instilling a deep, traumatic hostility in the populace towards further automation right when we need it the most.

user4673568345 1y ago

WELL YOU DONT SAY