In some ways they are giving you a spec and UI mocks to implement.

This is one of the things I keep thinking about. At the very least, these tools make prototyping and idea vetting remarkably cheaper.

Then we go back to the old “the prototype works; I’m the boss and I’m telling you to deploy it to production”

There's like three groups of developers you need:

The prototypers, who move fast and break things, who throw together shiny first versions that look great and work some of the time;

The architects, who take the prototypes and take the time to build it correctly;

And the gardeners, who maintain the built system for the next 10-30 years, fixing bugs, making incremental improvements to speed or resource usage, and updating dependencies so that it continues to function on modern machines.

The crazy thing is that there are a ton of developers with different tastes who would love to fill each of the roles, but not many companies that are able to manage all three types without pushing everyone into one bucket.

Ha, I'm a gardener then, on my 15th year of maintenance. So halfway there according to you. Slowly, very slowly, fixing the thousands of bugs the rockstar left behind 15 years ago.

It's easy to look at a newly made garden, its flowers all freshly planted and its paths all neatly laid out, and think it finished, but once you see one that's been carefully maintained for decades and how its plants have matured and grown together and how the steps have been worn by human feet, it's clear the project is merely off to a good start.

This comment made me imagine what would the guy maintaining my first deployed project at my first company thinks about me. Never had this thought ever cross my mind.

This is such a great mental model.

Prototyping is widely underappreciated. People think it's waste to throw away stuff but it's more costly to build upon shoddy foundations

The problem is those shoddy foundations can support a lot of weight before they finally fail. A prototype you write in a day - not a big deal to throw away. However if you have been working for a while that is a lot of effort/money.

Worse, often you need to spend years before you realize how an initial design decision was a mistake - not only are you proposing to throw away millions of dollars worth of work - you also don't know that your proposed better design is really better.

The day you implement the first edge case to your prototype you basically commit to using it forever or spending a lot of money to replace it.

Well, there's nothing as permanent as a temporary solution...

"So we all agree this is not ideal, but let's use it for now and focus on ..."

Heard it so many times.

But... "time to market!", "we won't have cash by the time this gets implemented properly" etc etc are the usual suspects here.

Sounds like valid issues to me. Pristine software isn’t the objective of most businesses. Leaving as a problem for another day, if we’re lucky that day will come, for many businesses, products, and startups it doesn’t and the shoddy prototype usually isn’t to blame.

I feel like SWE’s that make this gripe really need to step back and understand their role and the process for value creation. Because it’s certainly a process, the quality of code/architecture matters little if the low bar of functionality is met. Functionality can be sold to customers or used to test the market. It’s basically the whole MVP thing and the MVP should be a bit jank. If it wasn’t, you spent too much time/effort on it.

All said, there’s definitely some approaches to make it less jank from day one. Unfortunately, jankiness is a subjective metric.

It’s not about pristine software. Customers expect something that works. But changes will then be requested and the expectation is that the software will continue working. It’s hard to do that with janky code.

If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.

> If you have a good architecture and keep good code hygiene

That's a big "if" however - customers have a tendency to come up with requirements that aren't covered (or only covered in awkward ways) by the architecture you envisioned initially, while many of the well-architected parts will remain unused.

Then redesign the architecture. No need to go for a full rewrite as it can be done progressively. One thing I’ve seen is that people can be afraid to delete code, even if it’s not used anywhere.

I agree, but I think you've not understood what the reply above is saying.

You will never get the chance of "customers requesting changes" if you never ship.

The company with the janky code that shipped will. And they will iterate and get better - as described by your process.

> You will never get the chance of "customers requesting changes" if you never ship.

Why does good code imply never shipping?

Managers and Developers have different thresholds for “good enough to release”. The former are not the one on call for bugs or the one that get blamed for outage, but they are the ones that get praised when projects are completed quickly. Anything that’s past demo level is good for them.

I'm not saying they're mutually exclusive. I'm just saying that we can't expect them to come as a packaged deal.

For example: Company A - janky code, ships quick Company B - great code, ships quick Company C - great code, ships slow Company D - janky code. Ships slow

The average survival rate will be in the following order: B > A > C > D

My point is company A will capture the market and iterate quicker than company C.

Company B is what you're probably thinking of , and what many people think they are building.

Company D is what most people are actually building.

Company C will win out in the long run over company B if they have capital and network.

I like this. It has a lot to do with the company building journey too. Some companies that I feel are probably the B types had a super clear product vision that quickly resonated with users. So the original architecture that fit their vision was probably easy to scale for the features that came as a natural progression of the product. Meanwhile, a company that builds a product and tries to pivot or found the original vision only partially what customers wanted, well these situations put you in the position where it’s probably easier to just force what you have to work for the basis of your iteration. Starting from zero is usually not as easy as it sounds. It’s more like you make a Hail Mary football pass, usually ugly and risky but can get quick results.

100% - one of the biggest advantages of software is its mutability, so why not use it to prototype properly?

I don't think I've ever not learned a better way to write something after writing it. Sometimes it's small and insignificant, sometimes it "forces" me to start over. The funniest is when more than half the code deals with something that won't happen. The banana that is not a fruit clause.

You can prototype UX with a tools like balsamiq or taking photos of paper sketches with paper-to-app application. No need for code to share an idea. Especially from business to engineering or vice-versa.

Product Managers coding is like Developers writing marketing pitches.

Why not? I've seen both sides working out remarkably well. It is much more of a mindset thing than anything else.

One of the major concerns with prototyping, at least in my experience and based on the general vibe I've felt from others over the years, is that clients will generally do some variation of "You have a working prototype? So how many days until it is prod ready? No more than a few weeks, right?" and that will be their expectation. AI makes prototyping easier, but makes this specific drawback much worse. Expectations are going to be misaligned, leading to many disappointments, and likely some number of developers taking undue negative outcomes. I'm not even sure if it will normalize to reasonable expectations, given that this tension never seemed resolved even before AI was in the mix.

This is a very interesting thought. We complain about having to fix some MBAs vibecpded slop, but it actually might be faster, easier, and alot less painful than getting them to try to explain their vision to us and implement what they have in mind.

Like they actually iterate on the UX alot when they are vibecoding things up, answer alot of questions that can onky be answered when you see an initial version of experience and realize something is off. Id rather they waste the clankers time with that than mine

You are right, but at the same time, if no UX designer is involved in the loop, what happens when they've prompted a prototype that looks good - and therefore eludes them to think it's designed good as well? How do we convince them that we need to involve a UX designer to fix the application flow?

Have my angry upvote. :-)

One of my faults is "When somebody tries to explain something I hear 'A' and everyone else in the room hears 'B'". And vice-versa. But if someone can iterate a very VERY rough cut of what they want and hand it off to a design / development team ... well ... damn. That might make everyone's life a lot easier.

That's odd: all the other AI proponents on HN recently defended their decision to produce AI written code by saying the coding was never the hard part, it was the translation of business goals to a spec.

You're saying even that bit doesn't require them.

Not in some ways. The value of working code that meets the requirements and generates revenue is very high, it's a gift.

> with the hope of it giving you the right answer with the right prompt.

Consider that our ability to evaluate quality of the output is falling further behind our ability to produce it. The “right answer” is not the most likely outcome.

Notably the feed metrics and traces into the agent. I never thought of doing that.

Fantastic job!

Can you share what type of project that was? On the spectrum from a database engine to cat picture sharing web site (very high demand for correctness vs very lax).

This was primarily an Electron app with some small hosted backend services

I find that preserving logs that contain errors will confuse future sessions even if the errors were corrected at the time. Do you have that problem?

Essentially preserving logs extends the context window with all related problems.

I haven’t actually noticed that, but I’m not sure why. Maybe because I specifically describe it to the agent as a work log rather than documentation? I’m not sure

What is your impression of the course?

company must have a history of profitability before being included in the S&P 500

If investor pool becomes too loose the company becomes de facto public, subject to all SEC-enforced regulations.

The judgment is subjective though, so pushing the boundaries could be a calculated risk.

Take a look at hellointerview.com their model is very stubborn, similar to some interviewers who refuse to acknowledge even valid solutions that differ from the canon.

No affiliation.

Interesting thing about psychponancy is it’s asymmetric. If an LLM is used to train an LLM it may not have the same level of aggressiveness that humans do when punishing back on trainee. Human pushback has specific patterns which we might be able to compensate due to asymmetry.