I can only read code at a basic level, so I am in the same position as the author of this article.I built a diagnostic app using AI. With my initial prompt, I was able to get it to generate diagnostic results.However, when I ask AI to make changes, something else sometimes breaks. Every time this happens, I have to ask AI to check the code again.

You should architect the base app yourself and create a structure with a good separation of concerns then let AI build on top it.

The anecdote the author gave is already kind of outdated, since Claude will write tests and debug itself as it progresses. It doesn't take much insight to realize that the maintainers are going to be AI.

Houses are still standing built with hand saws and elementary-school level tools; we don't tear them down, just cut new pieces with power tools and bolt on new additions built with new pieces made from advanced tools.

Isn't AI just another purity test? nasty VSCode users instead of pure elite Vim users?

While the maintainers surely will be AI, the last bastion is the architects. Claude can write the scaffolding, but does Claude know how the parts go together? Even the concept of fuzz-testing existing means that even humans can't envision all the failure paths, so it would be unfair to hold the metric against AI. What we are going to see more of is the architectural failures: massive data breaches because the architecture aroung the breach will be reveaed to be laughably simple, from prompts that just didn't know what to ask.

I wonder how big you could say my friend Larry's "context" memory is. He's the long-time architect of a big, complex, international micro-services based system.

I'm guessing that when he goes to debug a complex problem that spans across multiple systems for his app, he brain is paging through the equivalent of a well-written 3GiB markdown design document file.

And my opinion is, yes, pretty soon SOTAs will be able to be that guy, if we are willing to hand that much control to an AI. But I sure hope we don't--it seems like way too much power for an AI. However: Larry sitting next to Fable working together? A team like that could change the world. I hope he's digging in to Claude or something, I'll have to give him a call.

Agreed. Also, Claude could relatively easily add the features he lists as lacking (dark mode, translation, etc.). Responsive design is on by default now in most models. Stuff like logins/auth would be more complicated, but Claude could certainly do it -- it would make for heavier hosting dependency, though.

As long as claude don't use breakpoints skillfully enough to analyse weird behaviors, you will have to do some research yourself, sometimes. Especially in huge OOP codebase. Because print-based debugging can only get you so far until the context explode (and even then, honestly it's almost always faster to investigate yourself if your code if of high quality, which, i will admit, is becoming an issue lately)

I think the last bastion will be people prepared to take responsibility for a system and keep it running. And cast a critical eye to streamline and simplify. I use LLMs and they have a tendency to double down on complexity, rather than zoom out and ask “Why”.

Wherever there is a chain of command, the buck will always stop with a human. “Claude did it and I’m waiting for it to fix it, but it’s not getting anywhere” - this will not fly when there’s a severity 1 outage on something critical.

You're talking about AI on a blog about vibes? How about you post something more relevant for a start?

How is vibing the maintenance supposed to bring about anything different from the original vibed prompts?

> "...or the parts that have never once executed in production because they’re there for a worst case someone sat down and imagined."

Good stuff.

> "It’s the record of what the code was supposed to do ... written down somewhere a human or an agent can read them back. Ours are markdown files in git..."

I keep getting surprised how many quite technical people I know are doing real work with AI but have never touched markdown.

If you are one of those people, allow me to offer a suggestion:

Stop. No more sending questions to ChatGPT or Claude until you do the following:

- Install Typora on your Windows or Mac machine.

- Write a .md (markdown text) file a full page long using Typora (or another editor that understands markdown, but Typora will do just fine). Make use of Heading 1, Heading 2, and underline formatting, at least.

- Make the one page file be a complex request to an AI. Something like "research x, compare it to y, make a guess what will happen in the future, here are some of my opinions and guesses, make your replies short, provide references".

Hand that .md file to your favorite AI. (Bonus points for using drag and drop or pointing the AI at the dir the file is in.) Look at your results. Make a change to your .md file. Hand it to the AI again, see the different results.

In my opinion, if you work on a keyboard and you've been making use of AI for the last 8 months, you should have done the above 4 months ago. Until you do, you will have a hard time understanding how drastically AI has changed almost all developer's lives, and how it is changing more and more fields that are not software development.

Or at least have your LLM generate a context .MD file for you.

No.

You need to be able to read and write for yourself at some level.

Markdown is like, the closest thing you can get to WYSIWYG without exiting the realm of machine-readable plaintext.

> I keep getting surprised how many quite technical people I know ... > > - Install Typora on your Windows or Mac machine.

I keep getting surprised how many people don't realize Linux is a thing.

I can't get them to try an app that is barely more complicated than Notepad, and you think I can get them to switch to Ubuntu?

Note that I said "quite technical people", not "fully technical people" or developers.

Every time I see a comment like this I feel like you are only 50% into the transition that is occurring.

The crafting of the requirements is better suited to an interactive process. You will have superior results and a quicker turn around by having the AI research the change implications, what current implementations actually do and where (so you can look at the parts you want to), etc.

When working in a BIG codebase, having it detail up a flow of how all the parts fit together is great and helps get you setup to work. Then work through your planned constraints with the AI and make sure the perception matches your intent (with prevents a lot of issues that a fire and forget document creates).

Then when you are satisfied that it sees the problem as you do, have the model capture it and then let it rip.

Oh I agree totally. I find it to be one of the coolest parts of the whole thing: Getting the AI to help put together the docs that will be handed to the AI. But the "quite technical people" that I referenced are not "full technical people"; I would lose them if I tried to explain the above to them.

I also really like telling the AI, "while we are hacking our way through the jungle trying to figure out how this thing should be built, at the same time, I want you to keep a design document up to date so that, if I asked you to rebuild the whole system again but without all the false starts etc we went through while we were figuring it out together, you could do so."

I probably won't use any of the "zombie clone" versions of my app that get built from the AI-generated design doc, but the fact that the zombie app (and design doc) look good at a casual glance, and the design doc is not 200 pages of AI bloatware verbiage, seems like good evidence that if a human expert needed to step in and save the system from some big surprise, that design spec would be found to be exactly what that human needed to help find the problem.

How is this new? The code is the spec has been a thing for a very long time.

Honestly using markdown is really inefficient. Code is much more expressive and terse. Why do you need all these markdown files when you have code already? I could see markdown if you can’t read code, but otherwise…

Don’t get me wrong docs are useful when code isn’t sufficient (for more esoteric things), but in many cases code is much better.

Well, you've changed the subject but fine, let's go there.

That's one of the things that has drastically changed, in my opinion. One way to look at it could be: in the past it was okay to have a minimal design spec doc, if your programmer wrote excellent code and comments, and the system wasn't too big.

But now, you can't complete if you try to do it that way while not using AI. You need to take all that effort that used to go into good code and good comments, and put it into a good spec doc, and hand that file to the AI.

So that once the AI has built your system, you can say either "hey AI, a bug just showed up in the widget area, go look at your strange spaghetti code of yours and the design doc and fix it", or, "hey AI, the whole sub-system seems to have gone critical mess, take the code, spec doc, lessons learned, and the following few high-level design decision changes, and re-write the whole thing!"

Apologies for bluntness, but there just isn't going to be much need in this world for people that are excellent at hand-building intricate watches, in a world where $20 quartz-movement watches have appeared.

> You need to take all that effort that used to go into good code and good comments, and put it into a good spec doc, and hand that file to the AI

This is inefficient. If quality matters at all, you’re going to miss things in your English design doc and/or use 100 words where 1 line of code will do.

If quality (as in product, not code) doesn’t matter then sure, do whatever. LLM will fill in the gaps.

> world where $20 quartz-movement watches have appeared

Much like in real life, if you’re paying for a cheap knock off you get what you pay for. Also much like real life, plenty of people will pay for $20 knock offs and be content.

I keep meeting ex software developers that changed careers to watchmaking by the way. Clockmakers that survived the quartzopocalypse have more work than they can handle, 6 month to 1 year turn around times.

Check out Hodinkee and Monochrome Watches to see all the hand built watches announced everyday. $100,000 and up. People appreciate craft, beauty, tradition, and are willing to pay.

He's saying that as a language of prompting, English won't scale properly, and that a well scaffolded codebase is also part of the prompt.

I think it makes sense. You're in a company full of many teams and people are building things, some manual, some autogenerated, some hybrid. When you notice that people are rebuilding many of the same things, of course you're not going to keep using LLMs to regenerate the basics of the universe. So you pick the very best and use that as the starting point, not tabula rasa markdown file.

>hey AI, a bug just showed up in the widget area, go look at your strange spaghetti code of yours and the design doc and fix it",

Your AI fix it, and you take it your users. Users come back with a new bug. You ask your AI about it. AI says, "Sure, I didn't handle it because you didn't say so!"

i have absurdly lightweight amounts of markdown within my projects that are meant to stay for the long term, a minimal agents.md, which whatever harness im using that day consumes, which maybe has some lines that point at another md file or two or whatever if i deem it vital for rules of a specific section

The real use for markdown for me and why i have a TON of markdown usage, is for planning tasks. these aren't "permanent" or anything but end up in a very much archived section of the repo once concluded but will have commit ids and such attached so intent can be retrieved at a later date if needed, as well as session ids for whatever model/harness i was using for that particular task.

It also serves another purpose of allowing me to nicely chunk up work as i see fit, so if i start a task in CC, and would prefer a section be done with some other model i can easily do so, or if i feel the work is suited to parallel sessions i can spin those up as well, with whatever models/harnesses i want.

Yeah, this is where I’ve landed after trying to painfully construct a markdown plan and hope it’d be implemented to spec the first time through. I’d review, find mistakes, get annoyed and then realize it was simpler to just build iteratively. And just have it give me code when possible, since that cut through the middleman, so to speak.

I’ll get a rough markdown plan to start but don’t treat it as much more than a launch point.

> I’ll get a rough markdown plan to start but don’t treat it as much more than a launch point.

If i am more entrenched in the codebase, i find that to be the case as well. the full on markdown plan structure is more for just trying to keep the more vibey projects in check.

  > "The code is the spec has been a thing for a very long time"

The code is the "what" and the "how", but not the "why".

To manage change, you need the "why" – Chesterton's fence being the classic example.

> Install Typora on your Windows or Mac machine. - Write a .md (markdown text) file a full page long using Typora (or another editor that understands markdown, but Typora will do just fine). Make use of Heading 1, Heading 2, and underline formatting, at least.

Who's still typing?

were in the slopocalypse

Decent points, but at this point if the restaurant owner could articulate their needs at a non technical level, I bet Claude or Codex could do a good job. Which is harder than it sounds but not exactly rocket science:

* Make an app for scheduling shifts for my staff. * Needs to handle multiple users with intelligent reconciling of edits * Needs to adapt to both English and Spanish speakers. * Needs authentication * Need 99.9% reliability

This gets most of the way there. Presumably the restaurant owner will need to iterate, but isn't that always the case? Iterating now doesn't require hiring external help.

> * Needs to handle multiple users with intelligent reconciling of edits

> * Needs to adapt to both English and Spanish speakers.

> * Needs authentication

> * Need 99.9% reliability

This is exactly what the post is about. The restraunt owner doesn't have experience in software development, they don't know to ask for any of those things, they got the frontend which to them seems complete, and they don't know where to go from there.

The “need reliability” prompt is a bit weird. Reminds me of the prompt I once saw “don’t hallucinate”. These are both emergent properties that yes of course the agent would like to fulfill anyway, rather than the opposite, but there is no direct strategy.

  > "Make an app for scheduling shifts for my staff"

Can you articulate the rules for the shifts? All the rules?

- Shifts should be at least 4 hours

- Shifts shouldn't be more than 8 hours

- Except on festival days, where shifts can be 12 hours

- Someone who is scheduled for an evening shift shouldn't be scheduled for the morning shift the next day

- Some staff members don't work on religious holidays

- Some staff members can't work mornings / evenings / weekends

- Some days pay extra, so schedules should be reserved for preferred/long-term/permanent staff members

- Some shifts may end early if there isn't enough demand

Around 2014 I was in school and working at a bar where schedules were done by hand each week. I figured I could easily build a little web app to handle this.

The rules were impossible to encode because they didn't really exist. Building the schedule by hand allowed the manager to draw on their knowledge of everything from employee work ethic and personality to expected rushes (e.g. hockey nights) and reservations.

Are you arguing that it’s not possible to articulate all the rules? It seems as though you’ve done a good job highlighting a good number of constraints and edge cases.

Further iteration and feedback when implicit/undocumented rules are violated will get you closer. It’s not like there’s an infinite source of rules, and many of these are just general knowledge that does exist online. You can eventually get there.

If we look at traditional project roles, it's the responsibility of the Programmer to articulate the Business Logic in a way that can be interpreted by a computer (i.e. write the rules in code, using their chosen programming language).

It's the responsibility of a Business Analyst to study a work process, and articulate the rules which govern the process.

With vibe-coding, the agent is usually playing the role of a Programmer. Are they also playing the role of a Business Analyst?

If we look at iterative development, that's usually the responsibility of a Product Owner.

With agentic development, we expect AI to perform the role of developer. In this example, is the bar manager able to perform the role of BA or PO? Is the agent able to accommodate and fill in the blanks that a BA or PO would normally fill?

There may also be human edge-cases, such as "Don't schedule Dave and Brian together, they don't get on".

Agentic AI doesn't have the nuance for all these factors. Many situations (such as a bar manager or restaurant manager with a small venue) may be better off with simply having a human plan the schedule on paper.

Where's error handling? At that point that guy's probably stuck making tiny improvements everytime he gets a bug (which is probably often) or needs to migrate his DB. He'll be forced to pay $100 for a higher usage claude/chatgpt subscription when this could've all been done with some SaaS probably.

Restaurant software isn't exactly hard to find.

This sounded like AI slop and Pangram agrees. If it actually is AI slop, cue the irony.

[delayed]

Vibes are vibes lol

This aint completely true anymore but i do agree to the fact that , ai cant reliably build the entire app in one shot or within couple of days, and also you can expect the same bug from a dev himself, even big teams do make mistakes and leave out edge cases.

I get the point but it seems overstated: when the app breaks, they'll ask AI to maintain it (with varying results) and in the first place they can ask AI to do checks to catch some things in advance that they might need

what's also ironic to me is a lack of templates for pro or am alike to follow along with (whether using AI or not), like the list of possible problems that could pop up... a lot of those could probably be handled in a template or like checklist (with AI assistance)

"At that point he has two options. Find someone to fix it and prepare to hand them all his money, because the first week of that engagement is pure archaeology. Or flee the country."

Err no they would go back to claude and ask it to fix it. And it would.

I dunno what it is with these hate pieces. Its like they've never even used the thing they despise. This guy just seems deeply uninformed.

As a developer with 20 years of experience, this post sounds very defensive - if you have a brain, you can vibe solve all these issues you mentioned. Even pre AI you had exactly the same problems if you were using cheap / bad developers, this is not any different.

Your friend already got an application working for his restaurant and he can fix the issues that come his way.

I see my friends do it all the time: non technical but high iq enough they can chat with claude code or grok bot and solve the issues until their product works.

One of my non technical friends started offering web dev services. He makes static websites with claude, charges 1k and everyone is happy. Last week he charged 150 to setup DNS to another vibe coder who made a website but couldn't set up the DNS records. If only they knew they can ask claude to use the browser and operate godaddy interface.

Developers won't disappear - there is the last 10% where you need an expert - but they will greatly diminish in numbers.

I expect businesses to make their own POS software and get off fee based services. They can focus on the cheapest payment processor with an api. Then make all the software they want on top of it.

Software engineers need to start businesses and use their skill to make it run better than other businesses. The vapid business people will eventually take the hit because most of those people rely on moats that are going away.

I agree with the main point, is easy for a non technology person to build an app, code is basically free, but one that survives with less needs of maintance requires a plan, building with excellence, of course the AI can do an app that does X, but you as the person chatting with it also need to think of any risks/security concerns, as mentioned on top comment like a checklist, I found some on X.