8 ms·

The Codex app illustrates the shift left of IDEs and coding GUIs

81 points by straydusk 8mo ago

GalaxyNova 8mo ago
> I don’t read code anymore Never thought this would be something people actually take seriously. It really makes me wonder if in 2 - 3 years there will be so much technical debt that we'll have to throw away entire pieces of software.
- binsquare 8mo ago
  Reading and understanding code is more important than writing imo
  - eikenberry 8mo ago
    It’s pretty well established that you cannot understand code without having thought things through while writing it. You need to know why things are written the way the are to understand what is written.
    - tomjakubowski 8mo ago
      Yeah, just reading code does little to help me understand how a program works. I have to break it apart and change it and run it. Write some test inputs, run the code under a debugger, and observe the change in behavior when changing inputs.
    - fragmede 8mo ago
      If that were true, then only the person who wrote the code could ever understand it enough to fix bugs, which is decidedly not true.
      - jason_oster 8mo ago
        I’ll grant you that there are many trivial software defects that can be identified by simply reading the code and making minor changes. But for architectural issues, you need to be able to articulate how you would have written the code in the first place, once you understand the existing behavior and its problems. That is my interpretation of GP’s comment.
- Computer0 8mo ago
  I have wondered the same but for the projects I am completely "hands off" on, the model improvements have overcome this issue time and time again.
- RA_Fisher 8mo ago
  Claude, Codex and Gemini can read code much faster than we can. I still read snippets, but mostly I have them read the code.
  - GalaxyNova 8mo ago
    Unfortunately they're still too superficial. 9 times out of 10 they don't have enough context to properly implement something and end up just tacking it on in some random place with no regard for the bigger architecture. Even if you do tell it something in an AGENT.md file or something, it often just doesn't follow it.
    - RA_Fisher 8mo ago
      I use them to probabilistically program. They’re better than me and I’ve been at it for 16 years now. So I wouldn’t say they’re superficial at all. What have you tried to use them for?
- sixdimensional 8mo ago
  Half serious - but is that really so different than many apps written by humans? I've worked on "legacy systems" written 30 to 45 years ago (or more) and still running today (things like green-screen apps written in Pick/Basic, Cobol, etc.). Some of them were written once and subsystems replaced, but some of it is original code. In systems written in the last.. say, 10 to 20 years, I've seen them undergo drastic rates of change, sometimes full rewrites every few years. This seemed to go hand-in-hand with the rise of agile development (not condemning nor approving of it) - where rapid rates of change were expected.. and often the tech the system was written in was changing rapidly also. In hardware engineering, I personally also saw a huge move to more frequent design and implementation refreshes to prevent obsolescence issues (some might say this is "planned obsolescence" but it also is done for valid reasons as well). I think not reading the code anymore TODAY may be a bit premature, but I don't think it's impossible to consider that someday in the nearer than further future, we might be at a point where generative systems have more predictability and maybe even get certified for safety/etc. of the generated code.. leading to truly not reading the code. I'm not sure it's a good future, or that it's tomorrow, but it might not be beyond the next 20 year timeframe either, it might be sooner.
  - sixdimensional 8mo ago
    I would enjoy discussion with whoever voted this down - why did you? What is your opinion and did you vote this down because you think it's silly, dangerous or you don't agree?
- ekidd 8mo ago
  I have a wide range of Claude Code based setups, including one with an integrated issue tracker and parallel swarms. And for anything really serious? Opus 4.5 struggles to maintain a large-scale, clean architecture. And the resulting software is often really buggy. Conclusion: if you want quality in anything big in February 2026, you still need to read the code.
  - manmal 8mo ago
    Opus is too superficial for coding (great at bash though, on the flipside), I‘d recommend giving Codex a try.
- cdfuller 8mo ago
  As LLMs advance so rapidly I think that all the AI slop code written today will be easily digestible by the LLMs a few generations down the line. I think there will be a lot of improvements in making user intent clearer. Combined with a bad codebase and larger context windows, refactoring wont be a challenge.
- farnsworth 8mo ago
  Yes, and you can rebuild them for free
- Hamuko 8mo ago
  I've seen software written and architected by Claude and I'd say that they're already ready to be thrown out. Security sucks, performance will probably suck, maintainability definitely sucks, and UX really fucking sucks.
- joriJordan 8mo ago
  Remember though this forum is full of people who consider code objects when it's just state in a machine. We have been throwing away entire pieces of software forever. Where's Novell? Who runs 90s Linux kernels in prod? Code isn't a bridge or car. Preservation isn't meaningful. If we aren't shutting the DCs off we're still burning the resources regardless if we save old code or not. Most coders are so many layers of abstraction above the hardware at this point anyway they may as well consider themselves syntax artists as much as programmers, and think of Github as DeviantArt for syntax fetishists. Am working on a model of /home to experiment with booting Linux to models. I can see a future where Python in my screen "runs" without an interpreter because the model is capable of correctly generating the appropriate output without one. Code is ethno objects, only exists socially. It's not essential to computer operations. At the hardware level it's arithmetical operations against memory states. Am working on my own "geometric primitives" models that know how to draw GUIs and 3D world primitives, text; think like "boot to blender". Rather store data in strings, will just scaffold out vectors to a running "desktop metaphor". It's just electromagnetic geometry, delta sync between memory and display: https://iopscience.iop.org/article/10.1088/1742-6596/2987/1/012001 https://iopscience.iop.org/article/10.1088/1742-6596/2987/1/...
  - geraneum 8mo ago
    Wie bitte?
- rustyhancock 8mo ago
  I'm 2-3 years from now if coding AI continues to improve at this pace I reckon people will rewrite entire projects. I can't imagine not reading the code I'm responsible for any more than I could imagine not looking out the windscreen in a self driving Tesla. But if so many people are already there, and mostly highly skilled programmers imagine in 2 years time with people who've never programmed!
  - weakfish 8mo ago
    Well, Tesla has been nearly at FSD for how long? The analogy you make sorta makes it sound less likely
  - nullsanity 8mo ago
    If I keep getting married at the same pace I have, then in a few years I'll have like 50 husbands.
  - GalaxyNova 8mo ago
    Seems dangerous to wager your entire application on such an uncertainty
    - geraneum 8mo ago
      Some people are not aware that they are one race condition away from a class action lawsuit.
- Aeolun 8mo ago
  > 2 - 3 years there will be so much technical debt that we'll have to throw away entire pieces of software. That happens just as often without AI. Maybe the people that like it all thave experience with trashing multiple sets of products over the course of their life?
- sho_hn 8mo ago
  > Never thought this would be something people actually take seriously. You have to remember that the number of software developers saw a massive swell in the last 20 years, and many of these folks are Bootcamp-educated web/app dev types, not John Carmack. They typically started too late and for the wrong reasons to become very skilled in the craft by middle age, under pre-AI circumstances and statistically (of course there are many wonderful exceptions; one of my best developers is someone who worked in a retail store for 15 years before pivoting). AI tools are now available to everyone, not just the developers who were already proficient at writing code. When you take in the excitement you always have to consider what it does for the average developer and also those below average: A chance to redefine yourself, be among the first doing a new thing, skip over many years of skill-building and, as many of them would put it, focus on results. It's totally obvious why many leap at this, and it's even probably what they should do, individually. But it's a selfish concern, not a care for the practice as-is. It also results in a lot of performative blog posting. But if it was you, you might well do the same to get ahead in life. There's only to so many opportunities to get in on something on the ground floor. I feel a lot of senior developers don't keep the demographics of our community of practice into account when they try to understand the reception of AI tools.
  - arjie 8mo ago
    Well, there are programmers like Karpathy in his original coinage of vibe coding > There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works. Notice "don't read the diffs anymore". In fact, this is practically the anniversary of that tweet: https://x.com/karpathy/status/2019137879310836075?s=20 https://x.com/karpathy/status/2019137879310836075?s=20
- straydusk 8mo ago
  I actually think this is fair to wonder about. My overall stance on this is that it's better to lean into the models & the tools around them improving. Even in the last 3-4 months, the tools have come an incredible distance. I bet some AI-generated code will need to be thrown away. But that's true of all code. The real questions to me are - are the velocity gains be worth it? Will the models be so much better in a year that they can fix those problems themselves, or re-write it? I feel like time will validate that.
- subsection1h 8mo ago
  > Never thought this would be something people actually take seriously The author of the article has a bachelor's degree in economics[1], worked as a product manager (not a dev) and only started using GitHub[2] in 2025 when they were laid off[3]. [1] https://www.linkedin.com/in/benshoemaker000/ https://www.linkedin.com/in/benshoemaker000/ [2] https://github.com/benjaminshoemaker https://github.com/benjaminshoemaker [3] https://www.benshoemaker.us/about https://www.benshoemaker.us/about
  - zipy124 8mo ago
    Whilst I won't comment on this specific person, one of the best programmers I've met has a law degree, so I wouldn't use their degree against them. People can have many interests and skills.
  - straydusk 8mo ago
    I've written code since 2012, I just didn't put it online. It was a lot harder, so all my code was written internally, at work. But sure, go with the ad hominem.
- strken 8mo ago
  I'm torn between running away to be an electrician or just waiting three years until everyone realises they need engineers who can still read. Sometimes it feels like pre-AI education is going to be like low-background steel for skilled employees.
- well_ackshually 8mo ago
  Also take something into account: absolutely _none_ of the vibe coding influencer bros make anything more complicated than a single-feature, already implemented 50 times webapp. They've never built anything complicated either, or maintained something for more than a few years with all the warts that it entails. Literally, from his bio on his website: > For 12 years, I led data and analytics at Indeed - creating company-wide success metrics used in board meetings, scaling SMB products 6x, managing organizations of 70+ people. He's a manager that made graphs on Power BI. They're not here because they want to build things, they're here to shit a product out and make money. By the time Claude has stopped being able to pipe together ffmpeg commands or glue together 3 JS libraries, they've gone on to another project and whoever bought it is a sucker. It's not that much different from the companies of the 2000s promising a 5th generation language with a UI builder that would fix everything. And then, as a very last warning: the author of this piece sells AI consulting services. It's in his interest to make you believe everything he has to say about AI, because by God is there going to be suckers buying his time at indecently high prices to get shit advice. This sucker is most likely your boss, by the way.
  - fragmede 8mo ago
    No true programmer would vibecode an app, eh?
    - well_ackshually 8mo ago
      Oh no, they would. I would. I'd have the decency to know and tell people that it's a steaming pile of shit and that I have no idea how it works though, and would not have the shamelessness to sell a course on how to put out LLM vomit in public though. Engineering implies respect for your profession. Act like it.
    - sebastos 8mo ago
      But invoking No True Scotsman would imply that the focus is on gatekeeping the profession of programming. I don’t think the above poster is really concerned with the prestige aspect of whether vibe bros should be considered true programmers. They’re more saying that if you’re a regular programmer worried about becoming obsolete, you shouldn’t be fooled by the bluster. Vibe bros’ output is not serious enough to endanger your job, so don’t fret.
- j_bizzle 8mo ago
  The coincidental timing between the rapid increase in the number of emergency fixes coming out on major software platforms and the proud announcement of the amount of code that's being produced by AI at the same companies is remarkable. I think 2-3 years is generous. Don't get me wrong, I've definitely found huge productivity increases in using various LLM workflows in both development as well as operational things. But removing a human from the loop entirely at this point feels reckless bordering on negligent.
- bloomca 8mo ago
  If the models don't get to the point where they can correct fixes on their own, then yeah, everything will be falling apart. There is just no other way around increasing entropy. The only way to harness it is to somehow package code producing LLMs into an abstraction and then somehow validate the output. Until we achieve that, imo doesn't matter how closely people watch out the output, things will be getting worse.
  - esperent 8mo ago
    > If the models don't get to the point where they can correct fixes on their own Depending on what you're working on, they are already at that point. I'm not into any kind of AI maximalist "I don't read code" BS (I read a lot of code), but I've been building a fairly expensive web app to manage my business using Astro + React and I have yet to find any bug or usability issue that Claude Code can't fix much faster than I would have (+). I've been able to build out, in a month, a fully TDD app that would have conservatively taken me a year by myself. (+) Except for making the UI beautiful. It's crap at that. The key that made it click is exactly what the person describes here: using specs that describe the key architecture and use cases of each section. So I have docs/specs with files like layout.md (overall site shell info), ui-components.md, auth.md, database.md, data.md, and lots more for each section of functionality in the app. If I'm doing work that touches ui, I reference layout and ui-components so that the agent doesn't invent a custom button component. If I'm doing database work, reference database.md so that it knows we're using drizzle + libsql, etc. This extends up to higher level components where the spec also briefly explains the actual goal. Then each feature building session follows a pattern: brainstorm and create design doc + initial spec (updates or new files) -> write a technical plan clearly following TDD, designed for batches of parallel subagents to work on -> have Claude implement the technical plan -> manual testing (often, I'll identify problems and request changes here) -> automated testing (much stricter linting, knip etc. than I would use for myself) -> finally, update the spec docs again based on the actual work that was done. My role is less about writing code and more about providing strict guardrails. The spec docs are an important part of that.
- abrookewood 8mo ago
  The proponents of Spec Driven Development argue that throwing everything out completely and rebuilding from scratch is "totally fine". Personally, I'm not comfortable with the level of churn.
gtm1260 8mo ago
I don't like the craft of the app. There are a few moments that really left me feeling it wasn't 100 percent thought through like cursor is at this point.
letstango 8mo ago
> The people really leading AI coding right now (and I’d put myself near the front, though not all the way there) So humble. Who is he again?
- tty456 8mo ago
  "Ex-Indeed" https://www.linkedin.com/in/benshoemaker000/ https://www.linkedin.com/in/benshoemaker000/
  - rileymichael 8mo ago
    > I don’t read code anymore > Senior Technical Product Manager yeah i'd wager they didn't read (let alone write) much code to begin with..
    - sho_hn 8mo ago
      At least going by their own CV, they've mostly written what sounds like small scripting-type programs described in grandiose terms like "data warehouse". This blog post is influencer content.
      - straydusk 8mo ago
        Pretty unpopular influencer if that were the case
- straydusk 8mo ago
  When I talk with people in the space, go to meetups, present my work & toolset, I am usually one of the more advanced, but usually not THE most, people in the conversation / group. I'm not saying I'm some sort of genius, I'm just saying I'm relatively near the leading edge of how to use these tools. I feel like it's true.
Groxx 8mo ago
>I think the industry is moving left. Toward specs. The code is becoming an implementation detail. What matters is the system that produces it - the requirements, the constraints, the architecture. Get those right, and the code follows. So basically a return to waterfall design. Rather than YOLO planning (agile), we go back to YOLO implementation (farming it out to dozens of replaceable peons, but this time they're even worse).
torben-friis 8mo ago
>The people really leading AI coding right now (and I’d put myself near the front, though not all the way there) don’t read code. They manage the things that produce code. I can’t imagine any other example where people voluntarily move for a black box approach. Imagine taking a picture on autoshot mode and refusing to look at it. If the client doesn’t like it because it’s too bright, tweak the settings and shoot again, but never look at the output. What is the logic here? Because if you can read code, I can’t imagine poking the result with black box testing being faster. Are these people just handing off the review process to others? Are they unable to read code and hiding it? Why would you handicap yourself this way?
- manmal 8mo ago
  > I can’t imagine any other example where people voluntarily move for a black box approach. Anyone overseeing work from multiple people has to? At some point you have to let go and trust people‘s judgement, or, well, let them go. Reading and understanding the whole output of 9 concurrently running agents is impossible. People who do that (I‘m not one of them btw) must rely on higher level reports. Maybe drilling into this or that piece of code occasionally.
  - re-thc 8mo ago
    > Anyone overseeing work from multiple people has to? That's not a black box though. Someone is still reading the code. > At some point you have to let go and trust people‘s judgement Where's the people in this case? > People who do that (I‘m not one of them btw) must rely on higher level reports. Does such a thing exist here? Just "done".
    - manmal 8mo ago
      > Someone is still reading the code. But you are not. That’s the point? > Where's the people in this case? Juniors build worse code than codex. Their superiors also can‘t check everything they do. They need to have some level of trust for doing dumb shit, or they can’t hire juniors. > Does such a thing exist here? Just "done". Not sure what you mean. You can definitely ask the agent what it built, why it built it, and what could be improved. You will get only part of the info vs when you read the output, but it won’t be zero info.
Ifkaluva 8mo ago
Sometimes when I vibe code, I also have a problem with the code, and find myself asking: “What went wrong with the system that produced the code?” The answer is clear: I didn’t write the code, I didn’t read it, I have no idea what it does, and that’s why it has a bug.
- Aeolun 8mo ago
  That as it may be. I spot bugs a lot faster when I didn’t write the code than when I did.
  - Ifkaluva 8mo ago
    Well, I’d wager there are quite a few more bugs, so naturally it should be easier to spot a few.
    - Bishonen88 8mo ago
      When you write code yourself, you're convinced each line is correct as you write it. That assumption is hard to shake, so you spend hours hunting for bugs that turn out to be obvious. When reading AI-generated code fresh, you lack that assumption. Bugs can jump out faster. That's at least my naive explanation to this phenomenon
franze 8mo ago
has someone figured out on how to set the codex app to yolo mode yet? the constant asking drives me crazy
- manmal 8mo ago
  There‘s a button looking like a shield, next to the voice dictation button.
- CryptoBanker 8mo ago
  It's called the "Yeet" skill in the app
frank00001 8mo ago
Clearly written by someone who has no systems of importance in production. If my code fail people loose money, planes halts, cars break down. Read. The. Code.
- kwindla 8mo ago
  Yes, but also ... the analogy to assembly is pretty good. We're moving pretty quickly towards a world where we will almost never read the code. You may read all the assembly that your compiler produces. (Which, awesome! Sounds like you have a fun job.) But I don't. I know how to read assembly and occasionally do it. But I do it rarely enough that I have to re-learn a bunch of stuff to solve the hairy bug or learn the interesting system-level thing that I'm trying to track down if I'm reading the output of the compiler. And mostly even when I have a bug down at the level where reading assembly might help, I'm using other tools at one or two removes to understand the code at that level. I think it's pretty clear that "reading the code" is going to go the way of reading compiler output. And quite quickly. Even for critical production systems. LLMs are getting better at writing code very fast, and there's no obvious reason we'll hit a ceiling on that progress any time soon. In a world where the LLMs are not just pretty good at writing some kinds of code, but very good at writing almost all kinds of code, it will be the same kind of waste of time to read source code as it is, today, to read assembly code.
  - sho_hn 8mo ago
    I think it's the performative aspects that are grating, though. You're right that even many systems programmers only look at the generated assembly occasionally, but at least most of them have the good sense to respect the deeper knowledge of mechanism that is to be found there, and many strive to know more eventually. Totally orthogonal to whether writing assembly at scale is sensible practice or not. But with the AI tools we're not yet at the wave of "sometimes it's good to read the code" virtue signaling blog posts that will make front page next year or so, and still at the "I'm the new hot shit because I don't read code" moment, which is all a bit hard to take.
  - gombosg 8mo ago
    I think this analogy to assembly is flawed. Compilers predictably transform one kind of programming language code to CPU (or VM) instructions. Transpilers predictably transform one kind of programming language to another. We introduced various instruction architectures, compiler flags, reproducible builds, checksums exactly to make sure that whatever build artifact that's produced is super predictable and dependable. That reproducibility is how we can trust our software and that's why we don't need to care about assembly (or JVM etc.) specifics 99% of the time. (Heck, I'm not familiar with most of it.) Same goes for libraries and frameworks. We can trust their abstractions because someone put years or decades into developing, testing and maintaining them and the community has audited them if they are open-source. It takes a whole lot of hand-waving to traverse from this point to LLMs - which are stochastic by nature - transforming natural language instructions (even if you call it "specs", it's fundamentally still a text prompt!) to dependable code "that you don't need to read" i.e. a black box.
yodsanklai 8mo ago
> Here’s the thing: I don’t read code anymore. I used to write code and read code. Now when something isn’t working, I don’t go look at the code. Recently I picked a smallish task from our backlog. This is some code I'm not familiar with, frontend stuff I wouldn't tackle normally. Claude wrote something. I tested, it didn't work. I explained the issue. It added a bunch of traces, asked me to collect the logs, figured out a fix, submitted the change. Got bunch of linter errors that I don't understand, and that I copied and pasted to Claude. It fixed something, but still got lint errors, which Claude dismissed as irrelevant, but I realized I wasn't happy with the new behavior. After 3 days of iteration, my change seems ok, passed the CI, the linters, and automatic review. At that stage, I have no idea if this is the right way to fix the problem, and if it breaks something, I won't be able to fix it myself as I'm clueless. Also, it could be that a human reviewer tells me it's totally wrong, or ask me questions I won't be able to answer. Not only, this process wasn't fun at all, but I also didn't learn anything, and I may introduce technical debt which AI may not be able to fix. I agree that coding agents can boost efficiency in some cases, but I don't see a shift left of IDEs at that stage.
- skybrian 8mo ago
  Why not look at the code? If you see something that looks messy, ask for it to be cleaned up. Code health is a choice. We have power tools now. All you have to do is ask.
  - ikrenji 8mo ago
    a simple this seems odd / messy / un-pythonic is often enough
- CuriouslyC 8mo ago
  My rule is 3 tries then dig deeper. Sometimes I don't even wait that long, certain classes of bugs are easy for humans to detect but hard for agents, such as CSS issues. Try asking the agent to explain/summarize the code that's causing the problem and double checking against docs for the version you're using, that solves a lot of problems.
- 8mo ago
gchamonlive 8mo ago
The skills required to perform as a software engineer in an environment where competent AI agents is a commodity has shifted. Before it was important for us to be very good as reading documentation and writing code. Now we need to be very good at writing docs, specs and interfaces, and reading code. That goes a bit against the article, but it's not reading code in the traditional sense where you are looking for common mistakes we humans tend to make. Instead you are looking for clues in the code to determine where you should improve in the docs and specs you fed into your agent, so the next time you run it chances are it'll produce better code, as the article suggests. And I think this is good. In time, we are going to be forced to think less technically and more semantically.
pjmlp 8mo ago
Yeah, the revenge of waterfall, specs documents for AI agents.
timhh 8mo ago
Not really what "shift left" means...
insin 8mo ago
turning a big dial taht says "Psychosis" on one side and "Wishful thinking" on the other and constantly looking back at the LinkedIn audience for approval like a contestant on the price is right
sho_hn 8mo ago
I still think this is mostly people who never could hack it at coding taking to the new opportunities that these tools afford them without having to seriously invest in the skill, and basking in touting their skilless-ness being accepted as the new temporary cool. Which is perhaps what they should do, of course. Any transition is a chance to get ahead and redefine yourself.
- CuriouslyC 8mo ago
  Just FYI, this is the attitude that causes pro-AI people to start shit-talking anti-AI folks as Luddites who need to learn to use the tools. Agents are a quality/velocity tradeoff (which is often good), if you can't debug stuff without them that's a problem as you'll get into holes, but that doesn't mean you have to write the code by hand.
  - sho_hn 8mo ago
    I enjoy new technology in general, so I very much keep up with the tools and also like using them for the things they do well at any given moment. I'm not among the Luddites, FWIW. I think there's a lot of legitimately great building going on right now. Note though we're talking about "not reading code" in context, not the writing of it.
  - sjsisjsh 8mo ago
    Author is a former data analytics product manager (already a bit of a tea leaf reading domain) who says he never reads code and is now marketing himself as a new class of developer. Parent post sounds like a very accurate description.
- straydusk 8mo ago
  I completely agree in a sense - the cost of producing software is plummeting, and it's leading to me being able to develop things that I would never have invested months in before.
thefz 8mo ago
I have always thought that AI code generation is an irresistible attraction for those personalities who lack the technical skills or knowledge necessary for programming, but nevertheless feel undeservedly like geniuses. This post is proof of that. Also, the generated picture in this post makes me want to kick someone in the nuts. It doesn't explain anything.
- straydusk 8mo ago
  Ouch lol. Is the image really not that clear? There are IDE-like tools that all are focusing on different parts of the Spec --> Agent --> Code continuum. I think it illustrates that all right.
jwpapi 8mo ago
I really wonder why nobody is talking about how it is more important to be able to test the code. 9/10 my ai generated code is bad before my verification layers 9/10 its good after. Claude fights through your rules. And if you code in another language you could use other agents to verify code. This is the challenge now, effectively verify the code. Whenever I end up with a bad response I ask myself what layers could i set to stop AI as early as possible. Also things like namings, comments, tree traversal, context engineering, even data-structures, multi-agenting. I know it sounds like buzzword, but these are the topics a software-engineer really should think about. Everything else is frankly cope.
- straydusk 8mo ago
  I think people attacking "don't read the code" are not considering the status quo - they're comparing to some perfect world where staff engineers are reading every line of code. That's not even close to happening. Test-driven development is something most engineers just won't put up with... AI's will do it, no problem. If I can automate ten different checks for every commit, is my code really getting looked at less?
  - sjsisjsh 8mo ago
    [dead]
  - jwpapi 8mo ago
    Yeah I’ve talked about verification layers here https://jw.hn/dark-software-fabric https://jw.hn/dark-software-fabric . I think that is the most efficient way of approaching engineering today.
sho_hn 8mo ago
This blog post is written by a product manager, not a programmer. Their CV speaks to an Economics background, a stint in market research, writing small scripting-type programs ("Cron+MySQL data warehouse") and then off to the product management races. What it's trying to express is that the (T)PM job still should still be safe because they can just team-lead a dozen agents instead of software developers. Take with a grain of salt when it comes to relevance for "coding", or the future role breakdown in tech organizations.
- straydusk 8mo ago
  That's me! I'm pretty open about that. I'm not trying to express that my particular flavor of career is safe. I think that the ability to produce software is much less about the ability to hand-write code, and that's going to continue as the models and ecosystem improve, and I'm fascinated by where that goes.
hollowturtle 8mo ago
Hell I see the big banner picture hallucinated by a prompt and all I see is an unproductive mess. Won't comment on the takes the article makes they're just miserable
Xx_crazy420_xX 8mo ago
Why create IDE without IDE features? Whats the benefit of this over using IDE with Codex plugin? I don't believe that you can review the code without code traversal by references, so looks like its directed towards toy projects/ noobs. And the agents are not yet near the autonomy that will omit the code review in complex systems.
bigwheels 8mo ago
Why do the illustrations bear such a strong resemblance to those in the Gas Town article? https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04 https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d... Is it a nano banana tendency or was it probably intentional?
- straydusk 8mo ago
  It's nano banana - I actually noticed the same thing. I didn't prompt it as such. Here's the prompt I used, actually: Create a vibrant, visually dynamic horizontal infographic showing the spectrum of AI developer tools, titled "The Shift Left" Layout: 5 distinct zones flowing RIGHT TO LEFT as a journey/progression. Use creative visual metaphors — perhaps a road, river, pipeline, or abstract flowing shapes connecting the stages. Each zone should feel like its own world but connected to the others. Zones (LEFT to RIGHT): 1. "Specs" (leftmost) - Kiro logo, VibeScaffold logo, GitHub Spec Kit logo Label: "Requirements → Design → Tasks" 2. "Multi-Agent Orchestration" - Claude Code logo, Codex CLI logo, Codex App logo, Conductor logo Label: "Parallel agents, fire & forget" 3. "Agentic IDE" - Cursor logo, Windsurf logo Label: "Autonomous multi-file edits" 4. "Code + AI" - GitHub Copilot logo Label: "Inline suggestions" 5. "Code" (rightmost) - VS Code logo Label: "Read & write files" Visual style: Fun, energetic, modern. Think illustrated tech landscape or isometric world. NOT a boring corporate chart. Use warm off-white background (#faf8f5) with amber/orange (#b45309) as the primary accent color throughout. Add visual flair — icons, small illustrations, depth, texture, but don't make it visually overloaded. Aspect ratio: 16:9 landscape
clarity_hacker 8mo ago
[dead]
ottah 8mo ago
> Where IDEs are headed and why specs matter more than code. We are very far away from this being a settled or agreed upon statement and I really struggle to understand how one vendor making a tool is indicative of an industry practice.
prewett 8mo ago
I really wish posts like this explained what sort of development they are doing. Is this for an internal CRUD server? Internal React app? Scala server with three instances? Golang server with complex AWS configuration? 10k lines? 100k lines? 1M+? Externally facing? iOS app? Algorithm-heavy photo processing desktop app? It would give me a much better idea of whether the argument is reasonable, and whether it is applicable for the kind of software I generally write.
- straydusk 8mo ago
  You're completely right and I wish I had in retrospect... I was honestly just talking mostly in broad terms, but people really (maybe rightly) focused on the "not reading code" snippet. I'm mostly developing my own apps and working with startups.
- bopbopbop7 8mo ago
  The author is a PM with a bachelors in economics who got laid off last year and began building with AI. Zero engineering experience. You can guess what kind of software he is building. When you read the 100th blog post about how AI is changing software development, just remember that these are the authors.
- TonyStr 8mo ago
  He makes <10k cloc websites trying to sell you a spec-creation wizard[0]. Considering Claude wrote the site, it could probably be written in 1/10th of the lines. I think these tools are great for allowing non-technical people like OP to create landing pages and small prototypes, but they're useless for anything serious. That said, I applaud OP for embodying the "when in a gold rush, sell shovels" mentality. [0] - https://vibescaffold.dev/ https://vibescaffold.dev/
oxag3n 8mo ago
Following this logic, why not move further left? Become a CTO, CEO or even a venture investor. "Here's $100K worth tokens, analyze market, review various proposals from Agents, invest tokens, maximize profit". You know why not? Because it will be more obvious it doesn't work as advertised.
- ipnon 8mo ago
  You have to move up or down to survive. In 10 years we'll either be managers (either of humans or agents), or we'll be electrical engineers. Programming is done! I for one am glad.
  - oxag3n 8mo ago
    There are two extremes and spectrum in between: * AI can replace knowledge workers - most of existing software engineers, managers of all levels will loose their job and have to re-qualify. * AI requires human in the loop. In the first scenario, I see no reason to waste time and should start building plan B now (remaining job markets will be saturated at that point). In the second scenario, tech-debt and zettabytes of slop will harm companies which relied on it heavily. In the age of failing giants and crumbling infrastructure, engineers and startups that can replace gigawatt burning data center with a few kilowatt rack, by manually coding a shell script that replaces Hadoop, will flourish. Most probably it will be a spectrum - some roles can be replaced, some not.
- krackers 8mo ago
  If one truly believed in LLMs being able to replace knowledge workers, then it would also hold that they could replace managers and execs. In fact, they should be able to do it even better: LLMs could convert every company into a "flat" one, bypassing the manangement hierarchy and directly consuming meeting notes from every meeting to get the real status as the source of truth, and provide suggestions as needed. If combined with web-search capability, they would also be more plugged into the market, customer sentiment, and competitors than most execs could ever be.
  - 8mo ago
dougthesnails 8mo ago
Why have a spec when I have the concrete implementation and a system ready and willing to answer any questions I have about it? I don't understand why people value an artifact that can be out of sync with reality over the actual reality. The LLM can answer questions based on the code. We might drift away from needing a code editor, but I likely won't be drifting to reading specs in a world where I can converse with the deployed implementation.
- TonyStr 8mo ago
  I think the idea is more to program the prompter than to program the LLM. He sells a wizard for generating project specs. Anyone can do this with a normal LLM conversation, but I suppose some people forget
teecha 8mo ago
I find so many of these comments and debates fascinating as a lay person. I'm more tech savy than mostI meet, built my own PCs, know my way around some more 'advanced' things like terminal a bit and have a deeper understanding of computer systems, software, etc. than most people I know. It has always been more of a hobby for me. People look at me as the 'tech' guy even though I'm actually not. Something I know very little about is coding. I know there are different languages with pros and cons to each. I know some work across operating systems while others don't but other than that I don't know too much. For the first time I just started working on my own app in Codex and it feels absolutely amazing and magical. I've not seen the code, would have basically no idea how to read it, but i'm working on a niche application for my job that it is custom tailored to my needs and if it works I'll be thrilled. Even better is that the process of building is just feels so special and awesome. This really does feel like it is on the precipice of something entirely different. I think back to computers before a GUI interface. I think back to even just computers before mobile touch interfaces. I am sure there are plenty of people who thought some of these things wouldn't work for different reasons but I think that is the wrong idea. The focus should be on who this will work for and why and there, I think, there are a ton of possibilities. For reference, I'm a middle school Assistant Principal working on an app to help me with student scheduling.
- chasd00 8mo ago
  Keep building and keep learning, I think you are the kind of user that stands to benefit the most from this technology.
- grigri907 8mo ago
  After 10+ years of stewing on an idea, I started building an app (for myself) that I've never had the courage or time to start until now. I really wanted to learn the coding, the design patterns, etc, but truthfully, it was never gonna happen without a Claude. I could never get past the unknown-unknowns (and I didn't even grasp how broad is the domain of knowledge it actually requires.) Best case I would have started small chunks and abandoned it countless times, piling on defeatism and disappointment each time. Now in under two weeks of spare time and evenings, I've got a working prototype that's starting to resemble my dream. Does my code smell? Yes. Is it brittle? Almost certainly. Is it a security risk? I hope not. (It's not.) I want to be intentional about how I use AI; I'm nervous about how it alters how we think and learn. But seeing my little toy out in the real world is flippin incredible.
andai 8mo ago
I don't get it. Can't you just open Claude Code in another terminal? I had like 5 open yesterday. I haven't used Codex though, so maybe there's something I'm missing about the parallel-ness of it here.
andai 8mo ago
Spec is too low level in my experience. The graph continues far further to the left. I tried doing clean room reimplementations from specs, and just ended up with even worse garbage. Cause it kept all the original garbage and bloated it further! Giving it a description of what you're actually trying to do works way better. Then it finds the most elegant solution to the problem, both in terms of the code and the UI design.
saadn92 8mo ago
reason why I also ended up creating something like this: https://github.com/saadnvd1/aTerm https://github.com/saadnvd1/aTerm
Sunscratch 8mo ago
>Here’s the thing: I don’t read code anymore. I used to write code and read code. Now when something isn’t working, I don’t go look at the code. I don’t question the code. I either ask one of my coding agents, or - more often - I ask myself: what happened with my system? What can I improve about the inputs that led to that code being generated? Good luck debugging any non trivial problem in such codebase
- bonesss 8mo ago
  Not to mention data retention and upgrade management. When an update script jacks up the guaranteed-to-be-robust vibed data setup in this first of a kind, one of a kind, singular installation… what then? The pros have separate dev, test, QA, and prod environments. Immutable servers, NixOs, containers, git, and rollback options in orchestration frameworks. Why? Because uh-oh, oh-shit, say-what, no-you’re-kidding, oh-fuck, and oops are omnipresent. MS Access was a great product with some scalability ceilings that took engineering to work past. MS Access solutions growing too big then imploding was a real concern that bit many departments. MS access was not dumping 15,000 LoC onto the laps of these non-developers and telling them they are hybrid spirit code warriors with next level hacking skills. Ruby on Rails, Wordpress, SharePoint… there are legitimately better options out there for tiny-assed self-serving CRUD apps and cheap developer ecosystems. They’re not quite as fun, tho, and they don’t gas people up as well.
rptrainor 8mo ago
For anyone who says you don’t need to look at code to code, I’d encourage you to look at this code: https://github.com/benjaminshoemaker/benshoemaker-us https://github.com/benjaminshoemaker/benshoemaker-us Or simply look at the Astro blog, which is still showing the default Astro favicon. I say this not to discourage anyone. Building a blog—or any app—is a huge accomplishment, and you should be proud. In particular, if you’re sharing what you’ve learned and sharing your code publicly, you’re already ahead of the majority of people on this journey. What I’d encourage you to do is keep doing what you’re doing. The best way to learn to build software is to build software. The more you do, the more you learn.

81 points by straydusk 8mo ago

> I don’t read code anymore Never thought this would be something people actually take seriously. It really makes me wonder if in 2 - 3 years there will be so much technical debt that we'll have to throw away entire pieces of software.

binsquare 8mo ago
Reading and understanding code is more important than writing imo
- eikenberry 8mo ago
  It’s pretty well established that you cannot understand code without having thought things through while writing it. You need to know why things are written the way the are to understand what is written.
  - tomjakubowski 8mo ago
    Yeah, just reading code does little to help me understand how a program works. I have to break it apart and change it and run it. Write some test inputs, run the code under a debugger, and observe the change in behavior when changing inputs.
  - fragmede 8mo ago
    If that were true, then only the person who wrote the code could ever understand it enough to fix bugs, which is decidedly not true.
    - jason_oster 8mo ago
      I’ll grant you that there are many trivial software defects that can be identified by simply reading the code and making minor changes. But for architectural issues, you need to be able to articulate how you would have written the code in the first place, once you understand the existing behavior and its problems. That is my interpretation of GP’s comment.
Computer0 8mo ago
I have wondered the same but for the projects I am completely "hands off" on, the model improvements have overcome this issue time and time again.
RA_Fisher 8mo ago
Claude, Codex and Gemini can read code much faster than we can. I still read snippets, but mostly I have them read the code.
- GalaxyNova 8mo ago
  Unfortunately they're still too superficial. 9 times out of 10 they don't have enough context to properly implement something and end up just tacking it on in some random place with no regard for the bigger architecture. Even if you do tell it something in an AGENT.md file or something, it often just doesn't follow it.
  - RA_Fisher 8mo ago
    I use them to probabilistically program. They’re better than me and I’ve been at it for 16 years now. So I wouldn’t say they’re superficial at all. What have you tried to use them for?
sixdimensional 8mo ago
Half serious - but is that really so different than many apps written by humans? I've worked on "legacy systems" written 30 to 45 years ago (or more) and still running today (things like green-screen apps written in Pick/Basic, Cobol, etc.). Some of them were written once and subsystems replaced, but some of it is original code. In systems written in the last.. say, 10 to 20 years, I've seen them undergo drastic rates of change, sometimes full rewrites every few years. This seemed to go hand-in-hand with the rise of agile development (not condemning nor approving of it) - where rapid rates of change were expected.. and often the tech the system was written in was changing rapidly also. In hardware engineering, I personally also saw a huge move to more frequent design and implementation refreshes to prevent obsolescence issues (some might say this is "planned obsolescence" but it also is done for valid reasons as well). I think not reading the code anymore TODAY may be a bit premature, but I don't think it's impossible to consider that someday in the nearer than further future, we might be at a point where generative systems have more predictability and maybe even get certified for safety/etc. of the generated code.. leading to truly not reading the code. I'm not sure it's a good future, or that it's tomorrow, but it might not be beyond the next 20 year timeframe either, it might be sooner.
- sixdimensional 8mo ago
  I would enjoy discussion with whoever voted this down - why did you? What is your opinion and did you vote this down because you think it's silly, dangerous or you don't agree?
ekidd 8mo ago
I have a wide range of Claude Code based setups, including one with an integrated issue tracker and parallel swarms. And for anything really serious? Opus 4.5 struggles to maintain a large-scale, clean architecture. And the resulting software is often really buggy. Conclusion: if you want quality in anything big in February 2026, you still need to read the code.
- manmal 8mo ago
  Opus is too superficial for coding (great at bash though, on the flipside), I‘d recommend giving Codex a try.
cdfuller 8mo ago
As LLMs advance so rapidly I think that all the AI slop code written today will be easily digestible by the LLMs a few generations down the line. I think there will be a lot of improvements in making user intent clearer. Combined with a bad codebase and larger context windows, refactoring wont be a challenge.
farnsworth 8mo ago
Yes, and you can rebuild them for free
Hamuko 8mo ago
I've seen software written and architected by Claude and I'd say that they're already ready to be thrown out. Security sucks, performance will probably suck, maintainability definitely sucks, and UX really fucking sucks.
joriJordan 8mo ago
Remember though this forum is full of people who consider code objects when it's just state in a machine. We have been throwing away entire pieces of software forever. Where's Novell? Who runs 90s Linux kernels in prod? Code isn't a bridge or car. Preservation isn't meaningful. If we aren't shutting the DCs off we're still burning the resources regardless if we save old code or not. Most coders are so many layers of abstraction above the hardware at this point anyway they may as well consider themselves syntax artists as much as programmers, and think of Github as DeviantArt for syntax fetishists. Am working on a model of /home to experiment with booting Linux to models. I can see a future where Python in my screen "runs" without an interpreter because the model is capable of correctly generating the appropriate output without one. Code is ethno objects, only exists socially. It's not essential to computer operations. At the hardware level it's arithmetical operations against memory states. Am working on my own "geometric primitives" models that know how to draw GUIs and 3D world primitives, text; think like "boot to blender". Rather store data in strings, will just scaffold out vectors to a running "desktop metaphor". It's just electromagnetic geometry, delta sync between memory and display: https://iopscience.iop.org/article/10.1088/1742-6596/2987/1/012001 https://iopscience.iop.org/article/10.1088/1742-6596/2987/1/...
- geraneum 8mo ago
  Wie bitte?
rustyhancock 8mo ago
I'm 2-3 years from now if coding AI continues to improve at this pace I reckon people will rewrite entire projects. I can't imagine not reading the code I'm responsible for any more than I could imagine not looking out the windscreen in a self driving Tesla. But if so many people are already there, and mostly highly skilled programmers imagine in 2 years time with people who've never programmed!
- weakfish 8mo ago
  Well, Tesla has been nearly at FSD for how long? The analogy you make sorta makes it sound less likely
- nullsanity 8mo ago
  If I keep getting married at the same pace I have, then in a few years I'll have like 50 husbands.
- GalaxyNova 8mo ago
  Seems dangerous to wager your entire application on such an uncertainty
  - geraneum 8mo ago
    Some people are not aware that they are one race condition away from a class action lawsuit.
Aeolun 8mo ago
> 2 - 3 years there will be so much technical debt that we'll have to throw away entire pieces of software. That happens just as often without AI. Maybe the people that like it all thave experience with trashing multiple sets of products over the course of their life?
sho_hn 8mo ago
> Never thought this would be something people actually take seriously. You have to remember that the number of software developers saw a massive swell in the last 20 years, and many of these folks are Bootcamp-educated web/app dev types, not John Carmack. They typically started too late and for the wrong reasons to become very skilled in the craft by middle age, under pre-AI circumstances and statistically (of course there are many wonderful exceptions; one of my best developers is someone who worked in a retail store for 15 years before pivoting). AI tools are now available to everyone, not just the developers who were already proficient at writing code. When you take in the excitement you always have to consider what it does for the average developer and also those below average: A chance to redefine yourself, be among the first doing a new thing, skip over many years of skill-building and, as many of them would put it, focus on results. It's totally obvious why many leap at this, and it's even probably what they should do, individually. But it's a selfish concern, not a care for the practice as-is. It also results in a lot of performative blog posting. But if it was you, you might well do the same to get ahead in life. There's only to so many opportunities to get in on something on the ground floor. I feel a lot of senior developers don't keep the demographics of our community of practice into account when they try to understand the reception of AI tools.
- arjie 8mo ago
  Well, there are programmers like Karpathy in his original coinage of vibe coding > There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works. Notice "don't read the diffs anymore". In fact, this is practically the anniversary of that tweet: https://x.com/karpathy/status/2019137879310836075?s=20 https://x.com/karpathy/status/2019137879310836075?s=20
straydusk 8mo ago
I actually think this is fair to wonder about. My overall stance on this is that it's better to lean into the models & the tools around them improving. Even in the last 3-4 months, the tools have come an incredible distance. I bet some AI-generated code will need to be thrown away. But that's true of all code. The real questions to me are - are the velocity gains be worth it? Will the models be so much better in a year that they can fix those problems themselves, or re-write it? I feel like time will validate that.
subsection1h 8mo ago
> Never thought this would be something people actually take seriously The author of the article has a bachelor's degree in economics[1], worked as a product manager (not a dev) and only started using GitHub[2] in 2025 when they were laid off[3]. [1] https://www.linkedin.com/in/benshoemaker000/ https://www.linkedin.com/in/benshoemaker000/ [2] https://github.com/benjaminshoemaker https://github.com/benjaminshoemaker [3] https://www.benshoemaker.us/about https://www.benshoemaker.us/about
- zipy124 8mo ago
  Whilst I won't comment on this specific person, one of the best programmers I've met has a law degree, so I wouldn't use their degree against them. People can have many interests and skills.
- straydusk 8mo ago
  I've written code since 2012, I just didn't put it online. It was a lot harder, so all my code was written internally, at work. But sure, go with the ad hominem.
strken 8mo ago
I'm torn between running away to be an electrician or just waiting three years until everyone realises they need engineers who can still read. Sometimes it feels like pre-AI education is going to be like low-background steel for skilled employees.
well_ackshually 8mo ago
Also take something into account: absolutely _none_ of the vibe coding influencer bros make anything more complicated than a single-feature, already implemented 50 times webapp. They've never built anything complicated either, or maintained something for more than a few years with all the warts that it entails. Literally, from his bio on his website: > For 12 years, I led data and analytics at Indeed - creating company-wide success metrics used in board meetings, scaling SMB products 6x, managing organizations of 70+ people. He's a manager that made graphs on Power BI. They're not here because they want to build things, they're here to shit a product out and make money. By the time Claude has stopped being able to pipe together ffmpeg commands or glue together 3 JS libraries, they've gone on to another project and whoever bought it is a sucker. It's not that much different from the companies of the 2000s promising a 5th generation language with a UI builder that would fix everything. And then, as a very last warning: the author of this piece sells AI consulting services. It's in his interest to make you believe everything he has to say about AI, because by God is there going to be suckers buying his time at indecently high prices to get shit advice. This sucker is most likely your boss, by the way.
- fragmede 8mo ago
  No true programmer would vibecode an app, eh?
  - well_ackshually 8mo ago
    Oh no, they would. I would. I'd have the decency to know and tell people that it's a steaming pile of shit and that I have no idea how it works though, and would not have the shamelessness to sell a course on how to put out LLM vomit in public though. Engineering implies respect for your profession. Act like it.
  - sebastos 8mo ago
    But invoking No True Scotsman would imply that the focus is on gatekeeping the profession of programming. I don’t think the above poster is really concerned with the prestige aspect of whether vibe bros should be considered true programmers. They’re more saying that if you’re a regular programmer worried about becoming obsolete, you shouldn’t be fooled by the bluster. Vibe bros’ output is not serious enough to endanger your job, so don’t fret.
j_bizzle 8mo ago
The coincidental timing between the rapid increase in the number of emergency fixes coming out on major software platforms and the proud announcement of the amount of code that's being produced by AI at the same companies is remarkable. I think 2-3 years is generous. Don't get me wrong, I've definitely found huge productivity increases in using various LLM workflows in both development as well as operational things. But removing a human from the loop entirely at this point feels reckless bordering on negligent.
bloomca 8mo ago
If the models don't get to the point where they can correct fixes on their own, then yeah, everything will be falling apart. There is just no other way around increasing entropy. The only way to harness it is to somehow package code producing LLMs into an abstraction and then somehow validate the output. Until we achieve that, imo doesn't matter how closely people watch out the output, things will be getting worse.
- esperent 8mo ago
  > If the models don't get to the point where they can correct fixes on their own Depending on what you're working on, they are already at that point. I'm not into any kind of AI maximalist "I don't read code" BS (I read a lot of code), but I've been building a fairly expensive web app to manage my business using Astro + React and I have yet to find any bug or usability issue that Claude Code can't fix much faster than I would have (+). I've been able to build out, in a month, a fully TDD app that would have conservatively taken me a year by myself. (+) Except for making the UI beautiful. It's crap at that. The key that made it click is exactly what the person describes here: using specs that describe the key architecture and use cases of each section. So I have docs/specs with files like layout.md (overall site shell info), ui-components.md, auth.md, database.md, data.md, and lots more for each section of functionality in the app. If I'm doing work that touches ui, I reference layout and ui-components so that the agent doesn't invent a custom button component. If I'm doing database work, reference database.md so that it knows we're using drizzle + libsql, etc. This extends up to higher level components where the spec also briefly explains the actual goal. Then each feature building session follows a pattern: brainstorm and create design doc + initial spec (updates or new files) -> write a technical plan clearly following TDD, designed for batches of parallel subagents to work on -> have Claude implement the technical plan -> manual testing (often, I'll identify problems and request changes here) -> automated testing (much stricter linting, knip etc. than I would use for myself) -> finally, update the spec docs again based on the actual work that was done. My role is less about writing code and more about providing strict guardrails. The spec docs are an important part of that.
abrookewood 8mo ago
The proponents of Spec Driven Development argue that throwing everything out completely and rebuilding from scratch is "totally fine". Personally, I'm not comfortable with the level of churn.

gtm1260 8mo ago

I don't like the craft of the app. There are a few moments that really left me feeling it wasn't 100 percent thought through like cursor is at this point.

letstango 8mo ago

> The people really leading AI coding right now (and I’d put myself near the front, though not all the way there) So humble. Who is he again?

tty456 8mo ago
"Ex-Indeed" https://www.linkedin.com/in/benshoemaker000/ https://www.linkedin.com/in/benshoemaker000/
- rileymichael 8mo ago
  > I don’t read code anymore > Senior Technical Product Manager yeah i'd wager they didn't read (let alone write) much code to begin with..
  - sho_hn 8mo ago
    At least going by their own CV, they've mostly written what sounds like small scripting-type programs described in grandiose terms like "data warehouse". This blog post is influencer content.
    - straydusk 8mo ago
      Pretty unpopular influencer if that were the case
straydusk 8mo ago
When I talk with people in the space, go to meetups, present my work & toolset, I am usually one of the more advanced, but usually not THE most, people in the conversation / group. I'm not saying I'm some sort of genius, I'm just saying I'm relatively near the leading edge of how to use these tools. I feel like it's true.

Groxx 8mo ago

>I think the industry is moving left. Toward specs. The code is becoming an implementation detail. What matters is the system that produces it - the requirements, the constraints, the architecture. Get those right, and the code follows. So basically a return to waterfall design. Rather than YOLO planning (agile), we go back to YOLO implementation (farming it out to dozens of replaceable peons, but this time they're even worse).

torben-friis 8mo ago

>The people really leading AI coding right now (and I’d put myself near the front, though not all the way there) don’t read code. They manage the things that produce code. I can’t imagine any other example where people voluntarily move for a black box approach. Imagine taking a picture on autoshot mode and refusing to look at it. If the client doesn’t like it because it’s too bright, tweak the settings and shoot again, but never look at the output. What is the logic here? Because if you can read code, I can’t imagine poking the result with black box testing being faster. Are these people just handing off the review process to others? Are they unable to read code and hiding it? Why would you handicap yourself this way?

manmal 8mo ago
> I can’t imagine any other example where people voluntarily move for a black box approach. Anyone overseeing work from multiple people has to? At some point you have to let go and trust people‘s judgement, or, well, let them go. Reading and understanding the whole output of 9 concurrently running agents is impossible. People who do that (I‘m not one of them btw) must rely on higher level reports. Maybe drilling into this or that piece of code occasionally.
- re-thc 8mo ago
  > Anyone overseeing work from multiple people has to? That's not a black box though. Someone is still reading the code. > At some point you have to let go and trust people‘s judgement Where's the people in this case? > People who do that (I‘m not one of them btw) must rely on higher level reports. Does such a thing exist here? Just "done".
  - manmal 8mo ago
    > Someone is still reading the code. But you are not. That’s the point? > Where's the people in this case? Juniors build worse code than codex. Their superiors also can‘t check everything they do. They need to have some level of trust for doing dumb shit, or they can’t hire juniors. > Does such a thing exist here? Just "done". Not sure what you mean. You can definitely ask the agent what it built, why it built it, and what could be improved. You will get only part of the info vs when you read the output, but it won’t be zero info.

Ifkaluva 8mo ago

Sometimes when I vibe code, I also have a problem with the code, and find myself asking: “What went wrong with the system that produced the code?” The answer is clear: I didn’t write the code, I didn’t read it, I have no idea what it does, and that’s why it has a bug.

Aeolun 8mo ago
That as it may be. I spot bugs a lot faster when I didn’t write the code than when I did.
- Ifkaluva 8mo ago
  Well, I’d wager there are quite a few more bugs, so naturally it should be easier to spot a few.
  - Bishonen88 8mo ago
    When you write code yourself, you're convinced each line is correct as you write it. That assumption is hard to shake, so you spend hours hunting for bugs that turn out to be obvious. When reading AI-generated code fresh, you lack that assumption. Bugs can jump out faster. That's at least my naive explanation to this phenomenon

franze 8mo ago

has someone figured out on how to set the codex app to yolo mode yet? the constant asking drives me crazy

manmal 8mo ago
There‘s a button looking like a shield, next to the voice dictation button.
CryptoBanker 8mo ago
It's called the "Yeet" skill in the app

frank00001 8mo ago

Clearly written by someone who has no systems of importance in production. If my code fail people loose money, planes halts, cars break down. Read. The. Code.

kwindla 8mo ago
Yes, but also ... the analogy to assembly is pretty good. We're moving pretty quickly towards a world where we will almost never read the code. You may read all the assembly that your compiler produces. (Which, awesome! Sounds like you have a fun job.) But I don't. I know how to read assembly and occasionally do it. But I do it rarely enough that I have to re-learn a bunch of stuff to solve the hairy bug or learn the interesting system-level thing that I'm trying to track down if I'm reading the output of the compiler. And mostly even when I have a bug down at the level where reading assembly might help, I'm using other tools at one or two removes to understand the code at that level. I think it's pretty clear that "reading the code" is going to go the way of reading compiler output. And quite quickly. Even for critical production systems. LLMs are getting better at writing code very fast, and there's no obvious reason we'll hit a ceiling on that progress any time soon. In a world where the LLMs are not just pretty good at writing some kinds of code, but very good at writing almost all kinds of code, it will be the same kind of waste of time to read source code as it is, today, to read assembly code.
- sho_hn 8mo ago
  I think it's the performative aspects that are grating, though. You're right that even many systems programmers only look at the generated assembly occasionally, but at least most of them have the good sense to respect the deeper knowledge of mechanism that is to be found there, and many strive to know more eventually. Totally orthogonal to whether writing assembly at scale is sensible practice or not. But with the AI tools we're not yet at the wave of "sometimes it's good to read the code" virtue signaling blog posts that will make front page next year or so, and still at the "I'm the new hot shit because I don't read code" moment, which is all a bit hard to take.
- gombosg 8mo ago
  I think this analogy to assembly is flawed. Compilers predictably transform one kind of programming language code to CPU (or VM) instructions. Transpilers predictably transform one kind of programming language to another. We introduced various instruction architectures, compiler flags, reproducible builds, checksums exactly to make sure that whatever build artifact that's produced is super predictable and dependable. That reproducibility is how we can trust our software and that's why we don't need to care about assembly (or JVM etc.) specifics 99% of the time. (Heck, I'm not familiar with most of it.) Same goes for libraries and frameworks. We can trust their abstractions because someone put years or decades into developing, testing and maintaining them and the community has audited them if they are open-source. It takes a whole lot of hand-waving to traverse from this point to LLMs - which are stochastic by nature - transforming natural language instructions (even if you call it "specs", it's fundamentally still a text prompt!) to dependable code "that you don't need to read" i.e. a black box.

yodsanklai 8mo ago

> Here’s the thing: I don’t read code anymore. I used to write code and read code. Now when something isn’t working, I don’t go look at the code. Recently I picked a smallish task from our backlog. This is some code I'm not familiar with, frontend stuff I wouldn't tackle normally. Claude wrote something. I tested, it didn't work. I explained the issue. It added a bunch of traces, asked me to collect the logs, figured out a fix, submitted the change. Got bunch of linter errors that I don't understand, and that I copied and pasted to Claude. It fixed something, but still got lint errors, which Claude dismissed as irrelevant, but I realized I wasn't happy with the new behavior. After 3 days of iteration, my change seems ok, passed the CI, the linters, and automatic review. At that stage, I have no idea if this is the right way to fix the problem, and if it breaks something, I won't be able to fix it myself as I'm clueless. Also, it could be that a human reviewer tells me it's totally wrong, or ask me questions I won't be able to answer. Not only, this process wasn't fun at all, but I also didn't learn anything, and I may introduce technical debt which AI may not be able to fix. I agree that coding agents can boost efficiency in some cases, but I don't see a shift left of IDEs at that stage.

skybrian 8mo ago
Why not look at the code? If you see something that looks messy, ask for it to be cleaned up. Code health is a choice. We have power tools now. All you have to do is ask.
- ikrenji 8mo ago
  a simple this seems odd / messy / un-pythonic is often enough
CuriouslyC 8mo ago
My rule is 3 tries then dig deeper. Sometimes I don't even wait that long, certain classes of bugs are easy for humans to detect but hard for agents, such as CSS issues. Try asking the agent to explain/summarize the code that's causing the problem and double checking against docs for the version you're using, that solves a lot of problems.
8mo ago

gchamonlive 8mo ago

The skills required to perform as a software engineer in an environment where competent AI agents is a commodity has shifted. Before it was important for us to be very good as reading documentation and writing code. Now we need to be very good at writing docs, specs and interfaces, and reading code. That goes a bit against the article, but it's not reading code in the traditional sense where you are looking for common mistakes we humans tend to make. Instead you are looking for clues in the code to determine where you should improve in the docs and specs you fed into your agent, so the next time you run it chances are it'll produce better code, as the article suggests. And I think this is good. In time, we are going to be forced to think less technically and more semantically.

pjmlp 8mo ago

Yeah, the revenge of waterfall, specs documents for AI agents.

timhh 8mo ago

Not really what "shift left" means...

insin 8mo ago

turning a big dial taht says "Psychosis" on one side and "Wishful thinking" on the other and constantly looking back at the LinkedIn audience for approval like a contestant on the price is right

sho_hn 8mo ago

I still think this is mostly people who never could hack it at coding taking to the new opportunities that these tools afford them without having to seriously invest in the skill, and basking in touting their skilless-ness being accepted as the new temporary cool. Which is perhaps what they should do, of course. Any transition is a chance to get ahead and redefine yourself.

CuriouslyC 8mo ago
Just FYI, this is the attitude that causes pro-AI people to start shit-talking anti-AI folks as Luddites who need to learn to use the tools. Agents are a quality/velocity tradeoff (which is often good), if you can't debug stuff without them that's a problem as you'll get into holes, but that doesn't mean you have to write the code by hand.
- sho_hn 8mo ago
  I enjoy new technology in general, so I very much keep up with the tools and also like using them for the things they do well at any given moment. I'm not among the Luddites, FWIW. I think there's a lot of legitimately great building going on right now. Note though we're talking about "not reading code" in context, not the writing of it.
- sjsisjsh 8mo ago
  Author is a former data analytics product manager (already a bit of a tea leaf reading domain) who says he never reads code and is now marketing himself as a new class of developer. Parent post sounds like a very accurate description.
straydusk 8mo ago
I completely agree in a sense - the cost of producing software is plummeting, and it's leading to me being able to develop things that I would never have invested months in before.

thefz 8mo ago

I have always thought that AI code generation is an irresistible attraction for those personalities who lack the technical skills or knowledge necessary for programming, but nevertheless feel undeservedly like geniuses. This post is proof of that. Also, the generated picture in this post makes me want to kick someone in the nuts. It doesn't explain anything.

straydusk 8mo ago
Ouch lol. Is the image really not that clear? There are IDE-like tools that all are focusing on different parts of the Spec --> Agent --> Code continuum. I think it illustrates that all right.

jwpapi 8mo ago

I really wonder why nobody is talking about how it is more important to be able to test the code. 9/10 my ai generated code is bad before my verification layers 9/10 its good after. Claude fights through your rules. And if you code in another language you could use other agents to verify code. This is the challenge now, effectively verify the code. Whenever I end up with a bad response I ask myself what layers could i set to stop AI as early as possible. Also things like namings, comments, tree traversal, context engineering, even data-structures, multi-agenting. I know it sounds like buzzword, but these are the topics a software-engineer really should think about. Everything else is frankly cope.

straydusk 8mo ago
I think people attacking "don't read the code" are not considering the status quo - they're comparing to some perfect world where staff engineers are reading every line of code. That's not even close to happening. Test-driven development is something most engineers just won't put up with... AI's will do it, no problem. If I can automate ten different checks for every commit, is my code really getting looked at less?
- sjsisjsh 8mo ago
  [dead]
- jwpapi 8mo ago
  Yeah I’ve talked about verification layers here https://jw.hn/dark-software-fabric https://jw.hn/dark-software-fabric . I think that is the most efficient way of approaching engineering today.

sho_hn 8mo ago

This blog post is written by a product manager, not a programmer. Their CV speaks to an Economics background, a stint in market research, writing small scripting-type programs ("Cron+MySQL data warehouse") and then off to the product management races. What it's trying to express is that the (T)PM job still should still be safe because they can just team-lead a dozen agents instead of software developers. Take with a grain of salt when it comes to relevance for "coding", or the future role breakdown in tech organizations.

straydusk 8mo ago
That's me! I'm pretty open about that. I'm not trying to express that my particular flavor of career is safe. I think that the ability to produce software is much less about the ability to hand-write code, and that's going to continue as the models and ecosystem improve, and I'm fascinated by where that goes.

hollowturtle 8mo ago

Hell I see the big banner picture hallucinated by a prompt and all I see is an unproductive mess. Won't comment on the takes the article makes they're just miserable

Xx_crazy420_xX 8mo ago

Why create IDE without IDE features? Whats the benefit of this over using IDE with Codex plugin? I don't believe that you can review the code without code traversal by references, so looks like its directed towards toy projects/ noobs. And the agents are not yet near the autonomy that will omit the code review in complex systems.

bigwheels 8mo ago

Why do the illustrations bear such a strong resemblance to those in the Gas Town article? https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04 https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d... Is it a nano banana tendency or was it probably intentional?

straydusk 8mo ago
It's nano banana - I actually noticed the same thing. I didn't prompt it as such. Here's the prompt I used, actually: Create a vibrant, visually dynamic horizontal infographic showing the spectrum of AI developer tools, titled "The Shift Left" Layout: 5 distinct zones flowing RIGHT TO LEFT as a journey/progression. Use creative visual metaphors — perhaps a road, river, pipeline, or abstract flowing shapes connecting the stages. Each zone should feel like its own world but connected to the others. Zones (LEFT to RIGHT): 1. "Specs" (leftmost) - Kiro logo, VibeScaffold logo, GitHub Spec Kit logo Label: "Requirements → Design → Tasks" 2. "Multi-Agent Orchestration" - Claude Code logo, Codex CLI logo, Codex App logo, Conductor logo Label: "Parallel agents, fire & forget" 3. "Agentic IDE" - Cursor logo, Windsurf logo Label: "Autonomous multi-file edits" 4. "Code + AI" - GitHub Copilot logo Label: "Inline suggestions" 5. "Code" (rightmost) - VS Code logo Label: "Read & write files" Visual style: Fun, energetic, modern. Think illustrated tech landscape or isometric world. NOT a boring corporate chart. Use warm off-white background (#faf8f5) with amber/orange (#b45309) as the primary accent color throughout. Add visual flair — icons, small illustrations, depth, texture, but don't make it visually overloaded. Aspect ratio: 16:9 landscape

clarity_hacker 8mo ago

[dead]

ottah 8mo ago

> Where IDEs are headed and why specs matter more than code. We are very far away from this being a settled or agreed upon statement and I really struggle to understand how one vendor making a tool is indicative of an industry practice.

prewett 8mo ago

I really wish posts like this explained what sort of development they are doing. Is this for an internal CRUD server? Internal React app? Scala server with three instances? Golang server with complex AWS configuration? 10k lines? 100k lines? 1M+? Externally facing? iOS app? Algorithm-heavy photo processing desktop app? It would give me a much better idea of whether the argument is reasonable, and whether it is applicable for the kind of software I generally write.

straydusk 8mo ago
You're completely right and I wish I had in retrospect... I was honestly just talking mostly in broad terms, but people really (maybe rightly) focused on the "not reading code" snippet. I'm mostly developing my own apps and working with startups.
bopbopbop7 8mo ago
The author is a PM with a bachelors in economics who got laid off last year and began building with AI. Zero engineering experience. You can guess what kind of software he is building. When you read the 100th blog post about how AI is changing software development, just remember that these are the authors.
TonyStr 8mo ago
He makes <10k cloc websites trying to sell you a spec-creation wizard[0]. Considering Claude wrote the site, it could probably be written in 1/10th of the lines. I think these tools are great for allowing non-technical people like OP to create landing pages and small prototypes, but they're useless for anything serious. That said, I applaud OP for embodying the "when in a gold rush, sell shovels" mentality. [0] - https://vibescaffold.dev/ https://vibescaffold.dev/

oxag3n 8mo ago

Following this logic, why not move further left? Become a CTO, CEO or even a venture investor. "Here's $100K worth tokens, analyze market, review various proposals from Agents, invest tokens, maximize profit". You know why not? Because it will be more obvious it doesn't work as advertised.

ipnon 8mo ago
You have to move up or down to survive. In 10 years we'll either be managers (either of humans or agents), or we'll be electrical engineers. Programming is done! I for one am glad.
- oxag3n 8mo ago
  There are two extremes and spectrum in between: * AI can replace knowledge workers - most of existing software engineers, managers of all levels will loose their job and have to re-qualify. * AI requires human in the loop. In the first scenario, I see no reason to waste time and should start building plan B now (remaining job markets will be saturated at that point). In the second scenario, tech-debt and zettabytes of slop will harm companies which relied on it heavily. In the age of failing giants and crumbling infrastructure, engineers and startups that can replace gigawatt burning data center with a few kilowatt rack, by manually coding a shell script that replaces Hadoop, will flourish. Most probably it will be a spectrum - some roles can be replaced, some not.
krackers 8mo ago
If one truly believed in LLMs being able to replace knowledge workers, then it would also hold that they could replace managers and execs. In fact, they should be able to do it even better: LLMs could convert every company into a "flat" one, bypassing the manangement hierarchy and directly consuming meeting notes from every meeting to get the real status as the source of truth, and provide suggestions as needed. If combined with web-search capability, they would also be more plugged into the market, customer sentiment, and competitors than most execs could ever be.
- 8mo ago

dougthesnails 8mo ago

Why have a spec when I have the concrete implementation and a system ready and willing to answer any questions I have about it? I don't understand why people value an artifact that can be out of sync with reality over the actual reality. The LLM can answer questions based on the code. We might drift away from needing a code editor, but I likely won't be drifting to reading specs in a world where I can converse with the deployed implementation.

TonyStr 8mo ago
I think the idea is more to program the prompter than to program the LLM. He sells a wizard for generating project specs. Anyone can do this with a normal LLM conversation, but I suppose some people forget

teecha 8mo ago

I find so many of these comments and debates fascinating as a lay person. I'm more tech savy than mostI meet, built my own PCs, know my way around some more 'advanced' things like terminal a bit and have a deeper understanding of computer systems, software, etc. than most people I know. It has always been more of a hobby for me. People look at me as the 'tech' guy even though I'm actually not. Something I know very little about is coding. I know there are different languages with pros and cons to each. I know some work across operating systems while others don't but other than that I don't know too much. For the first time I just started working on my own app in Codex and it feels absolutely amazing and magical. I've not seen the code, would have basically no idea how to read it, but i'm working on a niche application for my job that it is custom tailored to my needs and if it works I'll be thrilled. Even better is that the process of building is just feels so special and awesome. This really does feel like it is on the precipice of something entirely different. I think back to computers before a GUI interface. I think back to even just computers before mobile touch interfaces. I am sure there are plenty of people who thought some of these things wouldn't work for different reasons but I think that is the wrong idea. The focus should be on who this will work for and why and there, I think, there are a ton of possibilities. For reference, I'm a middle school Assistant Principal working on an app to help me with student scheduling.

chasd00 8mo ago
Keep building and keep learning, I think you are the kind of user that stands to benefit the most from this technology.
grigri907 8mo ago
After 10+ years of stewing on an idea, I started building an app (for myself) that I've never had the courage or time to start until now. I really wanted to learn the coding, the design patterns, etc, but truthfully, it was never gonna happen without a Claude. I could never get past the unknown-unknowns (and I didn't even grasp how broad is the domain of knowledge it actually requires.) Best case I would have started small chunks and abandoned it countless times, piling on defeatism and disappointment each time. Now in under two weeks of spare time and evenings, I've got a working prototype that's starting to resemble my dream. Does my code smell? Yes. Is it brittle? Almost certainly. Is it a security risk? I hope not. (It's not.) I want to be intentional about how I use AI; I'm nervous about how it alters how we think and learn. But seeing my little toy out in the real world is flippin incredible.

andai 8mo ago

I don't get it. Can't you just open Claude Code in another terminal? I had like 5 open yesterday. I haven't used Codex though, so maybe there's something I'm missing about the parallel-ness of it here.

andai 8mo ago

Spec is too low level in my experience. The graph continues far further to the left. I tried doing clean room reimplementations from specs, and just ended up with even worse garbage. Cause it kept all the original garbage and bloated it further! Giving it a description of what you're actually trying to do works way better. Then it finds the most elegant solution to the problem, both in terms of the code and the UI design.

saadn92 8mo ago

reason why I also ended up creating something like this: https://github.com/saadnvd1/aTerm https://github.com/saadnvd1/aTerm

Sunscratch 8mo ago

>Here’s the thing: I don’t read code anymore. I used to write code and read code. Now when something isn’t working, I don’t go look at the code. I don’t question the code. I either ask one of my coding agents, or - more often - I ask myself: what happened with my system? What can I improve about the inputs that led to that code being generated? Good luck debugging any non trivial problem in such codebase

bonesss 8mo ago
Not to mention data retention and upgrade management. When an update script jacks up the guaranteed-to-be-robust vibed data setup in this first of a kind, one of a kind, singular installation… what then? The pros have separate dev, test, QA, and prod environments. Immutable servers, NixOs, containers, git, and rollback options in orchestration frameworks. Why? Because uh-oh, oh-shit, say-what, no-you’re-kidding, oh-fuck, and oops are omnipresent. MS Access was a great product with some scalability ceilings that took engineering to work past. MS Access solutions growing too big then imploding was a real concern that bit many departments. MS access was not dumping 15,000 LoC onto the laps of these non-developers and telling them they are hybrid spirit code warriors with next level hacking skills. Ruby on Rails, Wordpress, SharePoint… there are legitimately better options out there for tiny-assed self-serving CRUD apps and cheap developer ecosystems. They’re not quite as fun, tho, and they don’t gas people up as well.

rptrainor 8mo ago

For anyone who says you don’t need to look at code to code, I’d encourage you to look at this code: https://github.com/benjaminshoemaker/benshoemaker-us https://github.com/benjaminshoemaker/benshoemaker-us Or simply look at the Astro blog, which is still showing the default Astro favicon. I say this not to discourage anyone. Building a blog—or any app—is a huge accomplishment, and you should be proud. In particular, if you’re sharing what you’ve learned and sharing your code publicly, you’re already ahead of the majority of people on this journey. What I’d encourage you to do is keep doing what you’re doing. The best way to learn to build software is to build software. The more you do, the more you learn.