Nobody knows how to build with AI yet

Because I can never focus on just one thing, I have a philosophy degree. I’ve worked with product teams and spent lots of time with stakeholders. I’ve written tons of docs because I was the only one on the team who enjoyed it.

I’ve always bemoaned my distractibility as an impediment to deep expertise, but at least it taught me to write well, for all kinds of audiences.

Boy do I feel lucky now.

The challenge is that clearly stating things is and always has been the hard part. It’s awesome that we have tools which can translate clear natural language instructions into code but even if we get AGI you’ll still have to do that. Maybe you can save some time in the process by not having to fight with code as much but you’re still going to have to create really clear specs which, again, is the hard part.

I think about this a lot. Early on, as a self taught engineer, I spent a lot of time simply learning the vernacular of the software engineering world so that I could explain what it was that I wanted to do.

Repl.it is so hit or miss for me, and that's that is so frustrating. Like, it can knock out something in minutes that would have taken me an afternoon. That's amazing.

Then other times, I go to create something that is suggested _by them below the prompt box_ and it can't do it properly.

I've found LLMs to be a key tool in helping me articulate something clearly. I write down a few half-vague notes, maybe some hard rules, and my overall intent and ask it to articulate a spec, and then ask to for suggestions, feedback, questions to clarify from a variety of perspectives. This gives me enough material to clarify my actual requirements and then ask for that be broken down into a task list. All along the way I'm both refining my mental model and written material to more clearly communicate my intent to both machines and humans.

Increasingly I've also just ben YOLOing single shot throw-away systems to explore the design space - it is easier to refine the ideas with partially working systems than just abstract prose.

> What junior devs will do, I'm not so sure. They somehow have to jump to the top of the mountain, but the stairs are gone.

Exactly my thinking, nearly 50, more than 30 years of experience in early every kind of programming, like you do, I can easily architect/control/adjust the agent to help me produce great code with a very robust architecture. By I do that out of my experience, both in modelling (science) and programming, I wonder how the junior devs will be able to build experience if everything comes cooked by the agent. Time will tell us.

I also am enjoying LLMs, but I get no joy out of just prompting them again and again. I get so incredibly bored, with a little side of anxiety that I don’t really know how my program works.

I’ll probably get over it, but I’ve been realizing how much fun I get out building something as opposed to just having be built. I used to think all I cared about was results, and now I know that’s not true, so that’s fun!

Of course for the monotonous stuff that I’ve done before or don’t care a lick about, hell yeah I let em run wild. Boilerplate, crud, shell scripts, CSS. Had claude make me a terminal based version of snake. So sick

> Now that I have that, I can implement a strategy against it. This is super tedious. I know how it works, but when I implement it, it takes me a lot of time that isn't really fulfilling. Stuff like making a typo, or forgetting to add the dependency. Not big brain stuff, but it takes time.

Are people implementing stuff from start to finish in one go? For me, it's always been iterative. Start from scaffolding, get one thing right,then the next. It's like drawing. You start with a few shapes, then connect them. After you sketch on top, then do a line art, and then you finish with values (this step is also iterative refinements). With each step, you become more certain of what you want to do, while also investing the minimum possible effort.

So for me coding is more about refactoring. I always type the minimal amount of code to get something to work. And it usually means shortcuts which I annotate with a TODO comment. Then I iterate over, making it more flexible, adds more flexibility, makes the code more clean.

> What junior devs will do, I'm not so sure

I see it as a worrying extension of a pre-LLM problem: No employer wants to train, they just want to hire employees after someone else trains them.

> I would normally just relax and do something else. Instead, I'm relaxing and coding.

So more work gets to penetrate a part of your life that it formerly wouldn't. What's the value of “productivity gains”, when they don't improve your quality of life?

> So for me, career-wise, it has come at the exact right time. A few years after I reached a level where the little things were getting tedious, a time when all the architectural elements had come together and been investigated manually.

Wish I had your confidence in this. I can easily see how this nullifies my hard earned experience and basically puts me in the same sport as a more mid level or even junior engineer.

Right, I’ve been using it recently for writing a message queue -> database bridge with checkpointing and all kinds of stuff (I work for a timeseries database company).

I saw this as a chance to embrace AI, after a while of exploring I found Claude Code, and ended up with a pretty solid workflow.

But I say this as someone who has worked with distributed systems / data engineering for almost 2 decades, and spend most of my time reviewing PRs and writing specs anyway.

The trick is to embrace AI on all levels: learn how to use prompts. learn how to use system prompts. learn how to use AI to optimize these prompts. learn how to first write a spec, and use a second AI (“adversarial critic”) to poke holes in that plan. find incompletenesses. delegate the implementation to a cheaper model. learn how to teach AI how to debug problems properly, rather than trying to one-shot fixes in the hope it fixes things. etc

It’s an entirely different way of working.

I think juniors can learn this as well, but need to work within very well-defined frameworks and probably needs to be part of college curriculum as well.

This is exactly what makes me excited as well. It really does replace the tedious parts of coding I’ve done thousands of times at this point.

Have you had the realization that you could never go back to dealing with all the minutia again?

LLMs have changed me. I want to go outside while they are working and I am jealous of all the young engineers that won’t lose the years I did sitting in front of a screen for 12 hours a day while sometimes making no progress on connecting two black boxes.

What junior devs will do, I'm not so sure. They somehow have to jump to the top of the mountain, but the stairs are gone.

"That's OK, I found a jetpack."

Chess is probably a good analogue to how the juniors will learn. You will have to learn for the sake of it even though the space is solved.

Hot take: Junior devs are going to be the ones who "know how to build with AI" better than current seniors.

They are entering the job market with sensibilities for a higher-level of abstraction. They will be the first generation of devs that went through high-school + college building with AI.

It is known team size and speed are not linear.

Many times adding a new junior to a team makes it slower.

How does using llms as junior makes you more productive?

At one hand you get insane productivity boost, something that could take maybe days, weeks or months to do now you can do in significantly shorter amount of time, but how much are you learning if you are at a junior level and not consciously being careful about how you use it, feels like it can be dangerous without a critical mindset, where you eventually rely too much on it that you can't survive without it. Or maybe this is ok? Perhaps the way of programming in the future should be like this, since we have this technology now, why not use it?

Like there's a mindset where you just want to get the job done, ok cool just let the llm do it for me (and it's not perfect atm), and ill stitch everything together fix small stuff that it gets wrong etc, saves alot of time and sure I might learn something in the process as well. And then the other way of working is the traditional way, you google, look up on stackoverflow, read documentations, you sit down try to find out what you need and understand the problem, code a solution iteratively and eventually you get it right and you get a learning experience out of it. Downside is this can take 100 years, at the very least much longer than using an llm in general. And you could argue that if you prompt the llm in a certain way, it would be equivalent to doing all of this but in a faster way, without taking away from you learning.

For seniors it might be another story, it's like they have the critical thinking, experience and creativity already, through years of training, so they don't loose as much compared to a junior. It will be closer for them to treat this as a smarter tool than google.

Personally, I look at it like you now have a smarter tool, a very different one as well, if you use it wisely you can definitely do better than traditional googling and stackoverflow. It will depend on what you are after, and you should be able to adapt to that need. If you just want the job done, then who cares, let the llm do it, if you want to learn you can prompt it in certain way to achieve that, so it shouldn't be a problem. But this sort of way of working requires a conscious effort on how you are using it and an awareness of what downsides there could be if you choose to work with the llm in a certain way to be able to change the way you interact with the llm. In reality I think most people don't go through the hoops of "limiting" the llm so that you can get a better learning experience. But also, what is a better learning experience? Perhaps you could argue that being able to see the solution, or a draft of it, can be a way of speeding up learning experience, because you have a quicker starting point to build upon a solution. I dunno. My only gripe with using LLM, is that deep thinking and creativity can take a dip, you know back in the day when you stumbled upon a really difficult problem, and you had to sit down with it for hours, days, weeks, months until you could solve that. I feel like there are some steps there that are important to internalize, that LLM nowdays makes you skip. What also would be so interesting to me is to compare a senior that got their training prior to LLM, and then compare them to a senior now that gets their training in the new era of programming with AI, and see what kinds of differences one might find I would guess that the senior prior to LLM era, would be way better at coding by hand in general, but critical thinking and creativity, given that they both are good seniors, maybe shouldn't be too different honestly but it just depends on how that other senior, who are used to working with LLMs, interacts with them.

Also I don't like how LLM sometimes can influence your approach to solving something, like perhaps you would have thought about a better way or different way of solving a problem if you didn't first ask the LLM. I think this could be true to a higher degree for juniors than seniors due to gap in experience when you are senior, you sort of have seen alot of things already, so you are aware of alot of ways to solve something, whereas for a junior that "capability" is more limited than a senior.

So you are relaxing and the AI is coding? Neat! Way to replace yourself, hope you won't cry after your job once it is gone.

Yeah; there's still a massive chasm between "I spent hours precisely defining my requirements for this greenfield application with no users and the AI one-shot it" and "million line twenty team enterprise SaaS hellscale with ninety-seven stakeholders per line of code".

The fact that AI can actually handle the former case is, to be clear, awesome; but not surprising. Low-code tools have been doing it for years. Retool, even back in 2018, was way more productive than any LLMs I've seen today, at the things Retool could do. But its relative skill at these things, to me, does not conclusively determine that it is on the path toward being able to autonomously handle the latter.

The english language is simply a less formal programming language. Its informality means it requires less skill to master, but also means it may require more volume to achieve desired outcomes. At some level of granularity, it is necessarily the case that programming in english begins to look like programming in javascript; just with capital letters, exclamation points, and threats to fire the AI instead of asserts and conditionals. Are we really saving time, and thus generating higher levels of productivity? Or, is its true benefit that it enables foray into languages and domains you might be unfamiliar with; unlocking software development for a wider range of people who couldn't muster it before? Its probably a bit of both.

Dario Amodei says we'll have the first billion dollar solo-company by 2026 [1]. I lean toward this not happening. I would put money on even $100M not happening, barring some level of hyperinflation which changes our established understanding of what a dollar even is. But, here's what I will say: hitting levels of revenue like this, with a human count so low that the input of the AI has to overwhelm the input from the humans, is the only way to prove to me that, actually, these things might be more than freakin awesome tools. Blog posts from people making greenfield apps named after a furrsona DJ isn't moving the needle for me on this issue.

[1] https://www.inc.com/ben-sherry/anthropic-ceo-dario-amodei-pr...

> Search has just become Chat

I think chat-like LLM interfacing is not the most efficient way. There has to be a smarter way.

Unlike peak google, this reduces signal to noise and obfuscates the source data its pulling against.

A lot of modern entry-level jobs were filled by people who knew how to use google and follow instructions.

I imagine the next generation will have a similar relationship with AI. What might seem "common sense" with the younger, more tech-saavy crowd, will be difficult for older generations whose default behavior isn't to open up chatgpt or gemini and find the solution quickly.

Google doesn’t have to change search. It already returns AI generated crap before anything useful.

As search gives the answer rather than the path to it, the job of finding things out properly and writing it down for others is lost. If we let that be lost, then we will all be lost.

If we cannot find a way to redirect income from AI back to the creators of the information they rehash (such as good and honest journalism), a critical load-bearing pillar of democratic society will collapse.

The news industry has been in grave danger for years, and we've seen the consequences it brings (distrust, division, misinformation, foreign manipulation). AI may drive the last stake in its back.

It's not about some jobs being replaced; that is not even remotely the issue. The path we are on currently is a dark one, and dismissing it as "just some jobs being lost" is a naive dismissal of the danger we're in.

I agree that people are using it for things they would've googled, but I doubt that it's a good replacement.

To me it mostly comes with a feeling of uncertainty. As if someone tells you something he got told on a party. I need to Google it, to find a trustful source for verification, else it's just a hint.

So I use it if I want a quick hint. Not if I really want to have information worth remembering. So it's certainly not a replacement for me. It actually makes things worse for me because of all that AI slop atm.

It's clearly useful for many things other than search.

This comment makes no sense here. Did you read the article? The author built an entire SaaS app in a few days with an agent. That isn't "just search"

The MBA hears ya. The MBA don't care.

I tend to generally think the same as you, as I work in the same field. A long time ago I thought to myself, if AI adoption increases exponentially, there is a chance that the amount of security vulnerabilities introduced by it also increases at the same rate.

However, what we are maybe not considering enough is that general AI adoption could and almost certainly will affect the standards for cybersecurity as well. If everyone uses AI and everyone gets used to its quirks and mistakes and is also forgiving about someone else using it since they themselves use it too, the standards for robust and secure systems could decrease to adjust to that. Now, your services as a cybersecurity consultant are no longer in need as much, as whatever company would need them can easily point to all the other companies also caring less and not doing anything about the security issues introduced by the AI that everyone uses. The legal/regulation body would also have to adjust to this, as it is not possible to enforce certain standards if no one can adhere to them.

Potentially. But also remember what they say about self-driving cars, that it'd make fewer and fewer mistakes than a real driver.

Knowing is at least half the battle. Doesn't matter what kind of tools you intend to use if you don't even know where the job site is located.

I've been around the block a few times on ideas like a B2B/SaaS requirements gathering product that other B2B/SaaS vendors could use to collect detailed, structured requirements from their customers. Something like an open-world Turbo Tax style workflow experience where the user is eventually cornered into providing all of the needed information before the implementation effort begins.

> The most wonderful thing I see about AI is that it should help people focus on these things.

Unfortunately I’ve been around this industry long enough to know that this is not in fact what is going to happen. We will be driven by greedy people with small minds to produce faster rather build correct systems, and the people who will pay will be users and consumers.

> And if you think these aspects .. , you've probably never done serious work in those spaces.

To be fair, a lot of commercial software clearly hasn't, either.

what makes you think that the writer omitted these? Any good developer would include these parts of the requirements. That's why we make the money we do. We know what is involved. That is orthogonal to the use of LLMs for coding.

I'm skeptical too, but at least accessibility and usability do show up in those four documents they link to.

I didn't see internationalization and localization, but I don't see anything fundamental about those that would be different.

Security, on the other hand, does feel like a different beast.

Exactly.

>My four-document system? Spaghetti that happened to land in a pattern I could recognize. Tomorrow it might slide off the wall. That's fine. I'll throw more spaghetti.

Amazing that in July 2025 people still think you can scale development this way.

Isn’t that like „the dog speaks English, but makes occasional grammar mistakes“?

Give it two years.

> I think a lot of people (who love crafting) will be leaving the industry in the next 5 years, for better or worse.

I think you're spot on. It was once necessary to acquire knowledge in order to acquire productivity. This made knowledge valuable and worth attaining. Now, with LLMs, we we can skip the middle man and go straight to the acquisition of productivity. I'd call it the democratisation of knowledge, but it's something more than that — knowledge just isn't needed anymore.

It works for people who don't really look at the code, or try to understand what the LLM spat out. It's right there in this article: if it compiles and runs, just commit and push.

They usually don't write this kind of blog post anymore after they tried to vibe-code an extension or modification onto their vibe-coded application.

There was a good one on HN a while ago, though, of someone who decided to actually take a look at their vibe-coded codebase, finding an unbelievable mess of inconsistencies and redundancies.

People who just want to put something together and hate programming can be fine with this. Anyone who wants to build something clean that actually lasts, won't.

There’s about half a trillion reasons that it’s unfathomable to some.

> The only thing that should matter in software development is: does it work to spec?

Unless you've never written code outside of a classroom you should know how unbelievably wrong this is.

This is all very emotive and I'm sure is a dream many of us would love to live.

But does Claude's code work? Does it work to the level where you'd depend on it yourself; where you'd bill customers for it; where you'd put your reputation behind it?

I say no. And it's because I use Claude. Two events changed how I use Claude: now it's an advisor, and I mostly type the code myself. Because I don't trust it.

First, I caught it copying one of my TypeScript interfaces and modifying it. So now we have User which looks like my actual user, that I defined, and UserAgain which does not, and which Claude is now using and proudly proclaiming that my type checks all pass. Well of course they do!

Second, I was told that the best way to catch this sort of thing is to get it to write tests. So it wrote some tests, and they failed, and it kept going, and it eventually wrote an un-failable test. The test mocked itself.

So, sure, enjoy time with your kids. Please don't ask me to use your app for anything important.

So like, why would I pay someone to work like this? Or why would I pay for software at all when I could just do this myself?

careful, Claude might soon start complaining you're not pulling your weight and refuse to work

Let’s see this app.

Not sure if a developer would ever say that to their manager. Agreed on the need to 100% fully understand what's going on. Otherwise the "AI can get it done in a day" is extremely high risk to the business. Junior may not be able to recognize a half-baked solution that doesn't follow existing patterns, poor security, poor performance, etc.

Until an LLM or some new form of AI can manage an entire architecture itself, I say we need a middle ground. Something will always go wrong, and understanding of the system is necessary to troubleshoot.

I feel like I’m in your camp, to my own surprise.

I’ll try my hand at some guidelines: the prime directive would be “use the right ai tool for the right task”. Followed by “use a statically typed language”. Followed by “express yourself precisely in English. You need to be able to write like a good technical lead and a good product manager.”

With those out of the way:

Completions work when you’re doing lots of rote moderately difficult work within established patterns. Otherwise, turn them off, they’ll get in the way. When they do work, their entire point is to extend your stamina.

Coding agents work when at-worst a moderately novel vertical needs implementation. New architecture and patterns need to be described exhaustively with accurate technical language. Split up the agents work into the same sort of chunks that you would do between coffee breaks. Understand that while the agent will make you 5x faster, you’ll still need to put in real work. Get it right the first time. Misuse the agent and straightening out the mistakes will cost more time than if you hadn’t used the agent at all.

If novelty or complexity is high, use an advanced reasoning model as interactive documentation, a sparring partner, and then write the code by hand. Then ask the reasoning model to critique your code viciously. Have the reasoning model configured for this role beforehand.

These things together have added up to the biggest force multiplier I’ve encountered in my career.

I’m very much open to other heuristics.

Just record yourself doing it and post online. If the projects are indeed complex and you’ve found a way to be 20x more productive people will learn from it.

The problem is not having any evidence or basis on which to compare claims. Alchemists claimed for centuries to synthesize gold, if they only had video we could’ve ruled that out fast.

It's just hard to believe something is real when it's not reproducible.

your problem domain is greenfield freelancing if i am reading you correctly?

The tarpit of AI discussion is that everybody assumes that their local perspective is globally applicable. It is not.

> For me it’s just a huge force multiplier, maybe 10-20x of my ability to deliver with my own knowledge and skills on a web dev basis.

I can tell you that this claim is where a lot of engineers are getting hung up. People keep saying that they are 10, 20 and sometimes even 100x more productive but it's this hyperbole that is harming that building style more than anything.

If you anyone could get 10 to 20 years worth of work done in 1 year, it would be so obvious that you wouldn't even have to tell anyone. Everyone would just see how much work you got done and be like "How did you do 2 decades worth of work this year?!"

I've noticed a great deal programmers, very good programmers at that, that completely underestimate how fast things are moving. They're natural skeptics, and checked out ChatGPT when it was released. Then they maybe checked out some other models a year after. But eventually wrote it off as hype, and continue to do things their way. You know, artisanal code and all that.

I think that if you willfully ignore the development, you might be left in the dust. As you say, it is a force multiplier. Even average programmers can become extremely productive, if they know how to use the AI.

What sort of code are you writing? I find a lot of my stuff requires careful design, refactoring an existing system to work in a new way.

If the code I was writing was, say, small websites all the time for different clients, I can see it being a big improvement. But iterating on a complex existing platform, I’m not so sure that AI will keep the system designed in a maintainable and good way.

But if your experience is with the same sort of code as me, then I may have to re evaluate my judgments.

Probably down to a combination of LLMs on average having a harder time with tasks that humans typically find difficult, and the task of prompting being easier the more you know about the problem.

Yes, it's not faster to develop with AI if you watch it work. It's faster to develop with AI if you parallelize. Typing was never the bottleneck, but is is a now-parallelizeable part of the pipeline.

Stefan Munz called this “YOLO vs tight-leash” at a very entertaining agentic coding meetup in Hamburg recently.

https://bsky.app/profile/stefanmunz.bsky.social

https://www.meetup.com/de-DE/de-DE/agentic-coding-meetup-ham...

This was the study with a population size of 16?

That’s reminiscent of how when people are “in the flow”, they feel productive but also tend to not notice how quickly time passes.

It depends on how the AI is used; there's a huge difference in productivity between a structured workflow with repeated automated feedback to the AI, and just ad-hoc prompting. For instance, Gemini 2.5 coding up a spec-compliant HTTP2.0 server in two weeks: https://outervationai.substack.com/p/building-a-100-llm-writ... . 15k lines of code and 30k lines of tests; no human coder could produce something like that so fast.

Reminds me of that quaalude scene from the movie The Wolf of Wall Street.

Software jazz is when you and your teammate are working hard on a project and you both land big PRs at the same time without a merge conflict, then integrate before the build system even has time to realize what happened.

  You prompt. You go live your life. You come back to ten thousand lines of code. You spend 5 minutes reading. One sentence of feedback. Another ten thousand lines appear while you're making lunch.

> First of all, the article is really wordy to say very few things.

A clickbaity title in opposition with the content isn't helpful either. I would've recommended their "The Great Experiment Nobody's Running the Same Way" heading as a better choice, even thought it might not perform as well from a content marketing POV.

>Which is cool, but is it something that would have taken a competent dev months to build? Probably not.

Right...but it exists today. The days of wondering "should I spend time building this" are gone.

I have this small project that lets you use Claude code (because their terminal UI is really smart) with any OpenRouter model:

https://github.com/terhechte/CCORP

Works fine on macOS / Linux, untested on Windows. Still working on improving it.

Yep! I work on multiple client projects. And while one agent is running in one project, I’m reviewing and writing down the task for another. Generally I just do this 2-3 hours per day; trying to block this time. And then go outside and enjoy free time.

Man you struck a nerve with this one. All these devs want to believe they are still going to get paid $200k a year working 30mins a day. The reality is we will be spending the same 8 hours a day, be paid less, but now we need to work on 16 projects at the same time.

> That means, sooner or later there will be a great rebalancing where people will be required to do significantly more work; probably the work of other developers who will be fired.

Correct - covered here in my talk - https://ghuntley.com/six-month-recap/

AI isn't going to take anyone's jobs. Your co-worker who knows how to use multiple agents at a time and automates their job function will.

If human productivity and unemployment increases at the same time the obvious solution for regulators will be to decrease the work week from 5 to 4 days or even further

> sooner or later there will be a great rebalancing where people will be required to do significantly more work; probably the work of other developers who will be fired.

this already started in 2022-23 with all the layoffs and "downsizing"

Twas always such. Until we build a system where necessities are cheap (housing scarcity is a self-imposed own goal for one) we will be in constant competition with our peers so the value we produce can be extracted by casual owners.

I am hopeful that AI leads to a future with mandatory 10 hour work weeks.

Playing with your kids, aka increasing their IQ and investing in the future.

"deserve" has nothing to do with it.

Just enjoy the hike and bike ride and keep the coding at home (:

I am working on something for that at https://automa.app. Let me know if you are interested in trying it out.

I think you can already kind of do that with something like vibetunnel :)

https://vibetunnel.sh

Screen+SSH. 90s technology. An LLM probably could have told you this.

I don't think it's either "vibe coding or nothing" choice you have to make with AI. I am part of a team working on a complex Kotlin backend. I have been experimenting with Claude recently and I have been amazed how well it can pick up the existing patterns used in the project and create new code if given reasonable instructions. And it writes great tests too (something that would take me a lot of time and kill my motivation). It has been a great productivity boost for me. Of course we review the code in PRs, we test it but in the end it does the job in less time and saves me from doing tedious work.

I've been working on AI dev tools for a bit over a year and I don't love using AI this way either. I mostly use it for boilerplate, ideas, or to ask questions about error messages. But I've had a very open mind about it ever since I saw it oneshotting what I saw as typical Google Cloud Functions tasks (glue together some APIs, light http stuff) a year ago.

I think in the last month we've entered an inflection point with terminal "agents" and new generations of LLMs trained on their previously spotty ability to actually do the thing. It's not "there" yet and results depend on so many factors like the size of your codebase, how well-represented that kinda stuff is in its training data, etc but you really can feed these things junior-sized tickets and send them off expecting a PR to hit your tray pretty quickly.

Do I want the parts of my codebase with the tricky, important secret sauce to be written that way? Of course not, but I wouldn't give them to most other engineers either. A 5-20 person army of ~interns-newgrads is something I can leverage for a lot of the other work I do. And of course I still have to review the generated code, because it's ultimately my responsibility, but I prefer that over having to think about http response codes for my CRUD APIs. It gives me more time to focus on L7 load balancing and cluster discovery and orchestration engines.

> Just keep it away from me

I'm reminded of teaching bootcamp software engineering, when every day #1 we go through simple git workflows and it seems very intimidating to students and they don't understand the value. Which fair enough because git has a steep learning curve and you need to use it practically to start picking it up.

I think this might be analogous to the shift going on with ai-generated and agent-generated coding, where you're introducing an unfamiliar tool with a steep learning curve, and many people haven't seen the why? for its value.

Anyways, I'm 150 commits into a vibe coding project that still standing strong, if you're curious as to how this can work, you can see all the prompts and the solutions in this handy markdown I've created: https://github.com/sutt/agro/blob/master/docs/dev-summary-v1...

It does sound horrible. No more getting in the flow, no more thinking about anything, no more understanding anything. Just touch it with a ten-foot pole every few hours, then get distracted again.

I guess if all you do is write React To-Do apps all day, it might even work for a bit.

But you also can't not swim with the tide. If you drove a horse-buggy 100 years ago, it was probably worth your while to keep your eye on whether motor-cars went anywhere.

I was super skeptical about a year ago. Copilot was making nice predictions, that was it. This agent stuff is truly impressive.

This has to be someone working solely on personal projects right? Because I don't know anyone who actually works like this and frequently the code that AI will spit out is actually quite bad.

The market for utility software like this predates the internet, we used to pass them around on floppies. It was never subject to particularly high QA or scrutiny. It just has to be "adequate."

But it's never displaced the market for highly-produced, highly-planned, "central" software pieces that the utilities glue together and help you work with, etc.

The growth of that software-as-big-business has only enlarged the need for utilities, really, to integrate everything, but it's a tough space to work in - "it's hard to compete with free." One classic move is selling support, etc.

Might be tough to do non-LLM-driven software development there - the selling support for your LLM-created-products model is still viable, but if there's an increase in velocity in useful utility creation or maintenance, possibly the dev headcount needs are lower.

But does anyone know how to use LLMs to make those giant ones yet? Or to make those central core underlying libraries you mention? Doesn't seem like it. Time will tell if there's a meaningful path that is truly different from "an even higher level programming language." Even on the edges - "we outgrew the library and we have to fork it because of [features/perf/bugs]" is a pretty common pattern when working on those larger projects already, and the more specific the exact changes you need are, the less the LLM might be able to do it for you (e.g. the "it kept assuming this function existed because it exists in a lot of similar things" problem).

What I hope is that we can find good ways to leverage these for quality control and testing and validation. (Though this is the opposite of the sort of greenfield dev demos that get the most press right now.)

Testing/validation is hard and expensive enough that basically nobody does a thorough job of it right now, especially in the consumer space. It would be wonderful if we could find ways to release higher quality software without teams of thousands doing manual validation.

I promise everyone one thing - there ain’t no such thing as a free lunch.

A lot of what is “working” in the article is closer to “jugaad”/prototyping.

Something the author acknowledges in their opening- it’s a way to prototype and get something off the ground.

Technically debt will matter for those products that get off the ground.

Scary part is: what if it’s inevitable? We don’t get to choose our environment, and toss one is forming around us.

A friend’s dad only knows assembly. He’s the ceo of his company and they do hardware, and he’s close to retirement now, but he finds this newfangled C and C++ stuff a little too abstract. He sadly needs to trust “these people” but really he prefers being on the metal.

> and maybe most importantly I don't want to work with somebody who works like this.

Which, of course, is your perogative, but in what other ways do we, as fellow programmers, judge software libraries and dependencies so harshly? As a Vim user, do I care that Django was written with a lot of emacs? Or that Linus used emacs to write git? Or maybe being judgemental about programming languages; ugh, that's "just" a scripting language, it's not "real" programming unless you use a magnet up against a hard drive to program in ones and zeros. As a user, do I care that Calibre is written in Python, and not something "better"? Or that curl is written in good ole C. Or how about being opinionated as to whether or not the programmer used GDB or printf debugging to make the library?

>I don't want to work with somebody who works like this.

You will most likely get your wish but not in the way you want. In a few years when this is fully matured there will be little reason to hire devs with their inflated salaries (especially in the US) when all you need is someone with some technical know-how and a keen eye on how to work with AI agents. There will be plenty of those people all over the globe who will demand much less than you will.

Hate to break it to you but this is the future of writing software and will be a reckoning for the entire software industry and the inflated salaries it contains. It won't happen overnight but it'll happen sooner than many devs are willing to admit.

Genuinely this is what it sounds like to accept obsolescence and I just can’t understand it.

What are you attached to and identify with that you’re rejecting new ways to work?

Change is the only constant and tools now look like superhuman tools created for babies compared to the sota at bell or NASA in the 1960s when they were literally trying to create superhuman computing.

We have more access to powerful compute and it’s never been easier to build your own everything.

What’s the big complaint?

I know, it's scary. But I guess it's the direction we are aiming for.

Imagine a future where creating software is about the designing the UX, overseeing the architecture and quality assurance. Implementation is farmed out.

> in a different reality.

It is. And one reality is getting bigger each day and the other is shrinking.

>I don't work like this, I don't want to work like this and maybe most importantly I don't want to work with somebody who works like this.

It suggests you've had very positive life experiences, that you trust human developers so much more than computers.

Check out image boards like 4chan or more localized boards like Kohlchan for Germany. No votes, no accounts

I guess one man's exceptional is another man's borderline unreadable (:

My feelings exactly. For a while I thought I was missing out and then I started learning how(and why) it works and I thought it was interesting but greatly over-hyped, exactly like bitcoin was.

I tried to follow the hype and generate an application but it took a lot of time and it did generate something but not something that works with many subtle bugs. Now it may be that I needed to prompt it better, but that response also feels similar to how Scrum is always "done wrong" when it doesn't work. The result started getting better when I got more and more detailed with my prompts and then I realized that I am about to start writing code as a prompt and I may as well write the code myself.

So I still think it's an interesting tool, and it will automate away certain industries but no where near what the advertising is implying.

Dismissing any new technology because of Bitcoin makes exactly as much sense as dismissing any new medical advancements because of Theranos. Ok, some people said Bitcoin would change the world, and they were wrong. Some people also said the PC, Internet, and smartphones would change the world, and they were right.

And of course you'll have people replying to this trying to make the case for why AI coding is already a thing, when in reality those posts are once again going to be carbon copies of similar comments from the Bitcoin days

What is the actual argument here? Anyone claiming that AI has been useful for them is a lying shill?

The difference is that Bitcoin was an overhyped solution looking for a problem.

Whereas AI is as big as life, eukaryotes, multi-cellularity, human intelligence, agriculture and the industrial revolution. It will certainly change everything (and make humans go extinct unless we are very careful).

peeThe difference is Bitcoin is a networked system. Bitcoin is useless if I use it and you/my landlord/stores/the taxman doesn't. If my pizza store doesn't take Bitcoin, I can't use my Bitcoin. Meanwhile, LLM assisted programming has value to its adherents without needing you/my landlord/stores/the taxman to even have heard of it. My time machine is just as good as yours, so I have no idea if OpenAI, specifically is going to be around in 10 years, but I can tell you that I'll still have deepseek-r1.ggml

> Why be in computing at all if you don’t like new technology?

Because computers can be used to run programs.

You feel sorry for them. I feel sorry for the future.