RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
70% Positive
Analyzed from 8281 words in the discussion.
Trending Topics
#design#code#more#don#claude#figma#where#working#already#right

Discussion (268 Comments)Read Original on HackerNews
In the future they will come with their 'ready' solution, already 'working' and be even less receptive to look at design and architecture holistically. Just make it like that. And why do you need to spend X man hours? The thing is basically already done!
The downside is that the business people don't understand why you can't just put their app in production as is. And then there's a lot of pressure to make it happen quickly "because we can use AI to move fast". This is going to come down to healthy organization dynamics, and hopefully represents a learning opportunity for leadership.
The upside is that the idea has already been proven out much more thoroughly than a sketch on a napkin. Claude has already prompted them about edge cases and design decisions. It's very likely that at some point they had to explicitly tell Claude "don't worry about that and just make an assumption", or "I actually don't like that interaction after trying it a few times, can you do a differently". They had to write out much of their idea in clear and direct language in order to prompt the AI. They've probably been playing with their own toy because it's fun to play with toys you summoned from thin air, so they've had a chance to discover the experience and refine their own preferences.
It's probably a net negative right now because the "ship it what's the problem team" pressure is intense and stupid and demoralizing and miserable to work under. But I think it will stabilize and it might be a net positive in future projects.
I’d flip that around and say that engineers don’t understand that sometimes you _can_ just put their app into production. It might take some cleanup, and some clever ways of deploying it in isolation, but some of these “vibe coded prototypes” — many made by technical business people (they do exist) – are much closer to production-ready than you might initially assume.
I’d encourage you to challenge your assumptions before dismissing the possibility. I’ve personally seen this workflow produce real production code, used by customers, in an extremely rapid feedback loop. Now is the time to adapt, not push back. Keep an open mind or you’ll be left behind.
An open mind to what? To yolo deployment of dodgy code straight into production? Moving fast and breaking things?
> I’ve personally seen this workflow produce real production code, used by customers, in an extremely rapid feedback loop.
Yes. I've seen it as well. I've also seen what happens. It goes wrong.
Should the engineers building your cars, your house, all other infrastructure also "keep an open mind" to slopping up their work?
Your next words will be "I'm not working on something safety critical".
You are. Even the most basic CRUD app handling personal data of any kind of safety critical these days. Data leaks alone KILL.
But yes, I do agree that some engineers and some engineering teams are slow and cautious where it's not needed, to the point of obstructing rapid prototyping and iteration. And yes I agree that AI will be good to help push them to overcome it.
That isn't to say that there aren't cases where "just do the happy path" is actually sufficient, and the right thing to do. However, and bit overly simplified, but the non-happy-path is almost always the important parts of a system. It's the monitoring. Disaster recovery. Error handling and correction. Well thought out data models that prepare for future features, etc.
Security, legal considerations, internal controls and tracking for monitoring.
See, corporate means usually financial services. Money laundering is a thing here and there are deliberately checks and controls implemented as well as boundaries which don't allow for "deploy to PROD instantly" processes since they pose a red flag.
For example, PEN testing is mandatory as well as token handling to connect to the right backend.
Legal, as a hint, has a show stopping word in here. Every text, that surfaces, needs to be approved first, and also documented. "How inflexibel and anti-business" you might think, but here is the kicker: the wrong words as well as wording gets you into trouble faster than you can imagine.
Here is one example out of many dangerous mistakes, that cost you dearly besides a noticeable shitstorm:
We (one of the largest banks operating globally) were 2017 (!) already closely monitored which means, every change would not be undetected. And we are not talking about days later, but instantly, seconds later.
We have to follow certain obligations in certain countries to conform to legislation. So we are also obliged to incorporate changes, but these had to follow strictly the letters of the law. So if you deploy this change 5 minutes too early or too late for a specific day, you could be hit by a lawsuit. Ridiculous you might say and I somehow have to agree but my opinion does not play a relevant role here or better: won't change because I follow law while keeping my opinion.
And this is also something that disallows for the "vibe code to PROD" myth: Usually many teams and departments are involved.
I am glad I worked in corporate, because my understanding went from the cocky and totally arrogant "One team from us would beat you all easily. You are totally outdated." line to the "Well, now I understand that it is a difference to be under scrutiny globally and have to define responsibility as well as accountability depending on the context. And god forgive me, that I had no insights into a huge regulated machine, that has serious redundancy, however it works and rebels do more harm than good."
That’s not the gating factor. Who picks up the liability accountability and picks up the pager duty at o’dark thirty when it breaks in production, that’s the big gate. That long tail of accountability for operational risk weeds out a ton of Eager Ethan’s who want to see something go live yesterday. Because the success of launching has many fathers while the failures in the operational long tail is an orphan.
Get them to sign up for the long tail troubleshooting operations of the product. They are after all, now the SME on the product having built 90% of it. The full promise of AI in such a world is deploying and operating an AI-forward application is an artificial distinction, and full conviction means fully committing to the operational model.
The other day my friend discovered lovable and vibe coded an entire app and he started feeling like I was scamming him. Why would I take weeks or months in building our app if he could do it on hours?
He might be stubborn but ended up blindly believing me, but I couldn't find a good way of explaining that a prototype wasn't a final product. It has lots of errors, doesn't consider edge cases and it's impossible to fix if something breaks. Of course what I said didn't mean much because he didn't understand what I was talking about.
How do you communicate this problem? That there's much more than what you see in a frontend? Seems really hard to explain to non technical people.
it’s the only way they learn
Non technical folks vibe coding aren't explicitly telling Claude anything other than "Accept"
What is it like working for organizations with healthy dynamics and leadership that is capable of learning?
I don't think I've ever encountered it in my professional career.
I'm seeing so many of these come in with "this is 95% done, just need a couple of minor tweaks for production release"
"Minor tweaks" being fix the layout so it's not messed up if the browser isn't exactly 1920px wide, sometimes these filters and sorting don't seem to work right and the app doesn't seem to refresh new values properly after an action.
No matter the issue it's pre-estimated by the business as "should be a quick fix, for an experienced dev" because they (allegedly) did 95% of the work already.
This has already been common in the audio engineering world for some time, as home demos of music approach professional quality. As you forsee here, people get used to what they have and become even less inclined to accept changes in a new professional mix.
This was only possible due to the “productivity boost” of digital editing pipelines, which allowed directors to edit immediately after filming.
https://youtu.be/7vfqkvwW2fs from 5:50 on but the whole video is a masterpiece.
We have that too and more often than not, it’s not what a customer wants. Yes there are some very talented customer facing people (PMs, CSMs, TAMs etc.) that also have a natural knack for translating customer problems into product features with great usability. However, for the rest, skipping the part of defining the problem and letting other functions to come up with a solution, usually leads to catastrophic messes that waste a lot of engineering and other resources. When someone shows up with a solution, you risk wasting months of resources in making production ready software, only to find, customers hate it and the solution either doesn’t fix the problem or introduces new ones.
Of course you need the person making that vibe product to understand it's just a mockup of their idea and that it'll change. But I would argue this has always been a necessary quality for a product person.
when they already come up with a working model it doesnt really leave any room for abstract thought because now you are in concerte world . They see you as a machine that turns mocks into impls ( maybe you youself see yourself like that).
its ok if you see yourself as a code monkey monkey doing menial job of implementing someones mockup. But that job wont be here long and you will be on the streets holding "can turn working mocks to production code for food" signs.
honestly your attitude scares me more than some business guy building crap in lovable.
Sometimes words are better, sometimes a visual demo is better.
Is your solution to the problem you presented that you should artificially restrict what a person can express just to keep your own personal moat?
I prefer the alternative, let a person express themselves and grow thanks to AI, while keeping the necessary culture and boundaries to where it's also accepted for _me_ to cross boundaries and express my ideas to them in the same way. Or suggest other ways to express those ideas.
We then become a marketplace of ideas in a much deeper sense than before, where product managers would already expect you to implement what they want, but without them being able to convey it properly.
If I didn't have original ideas and didn't think I could compete in that marketplace of ideas, I would be scared like you convey in your message. But I'm confident that my value is not about translating things into code, it's because I have original thoughts I can convey to other people (and to AIs). (and about understanding architecture and systems to a degree that keeps me valuable even if all the code itself is written by AI without my direct involvement)
Might I suggest taking a step back and asking yourself why you were so triggered by the prior post. You made a bunch of mental leaps that are not supported by the prior post. Won't waste my time going through all of them, but the suggestion that they couldn't understand before has no basis in reality, they merely said it's easier to understand with increased fidelity of mocks.
The words can't hurt you. Deep breaths. :)
If your goal was discourse, might I suggest leaving the insults out of the message, it rarely is effectual.
If your goal was simply to insult, might I suggest leaving HNs, your anger and insults do the community a disservice.
the ai making assumptions can’t get it right
Then your job as SE just becomes reviewing and untangling vibe-coded stuff
> In July 2025, the Securities and Exchange Board of India (SEBI) alleged that Jane Street used multiple entities for market manipulation and barred it from accessing the market.
I think the designer here takes a wrong approach and sort of falls into engineer envy where he wants to make prototypes as deep and realistic as possible. And that is not really the most important part of the design job.
The most important thing is that the right thing gets build (why do we need a JSQL input box? what do we actually want? what are other ways to do this?). And this is often better done with pen and paper sketches, meetings, observation, discussions ... rather than too quickly narrowing on a particular design and spinning into discussions on whether buttons should be on the left or on the right, LLM intricacies etc.
As a non-designer I want to see a thought through 1-2 ideas, not 10 ideas you coded with llm and now the burden of thinking which one is better and why is for some reason is on me.
Not really. Maybe its effective from designer side but from other side that has to review all those ideas it is exhausting and counterproductive. Especially when it is in code.
You really don't need a real prototype for most things. Simple visual is more than enough to present an idea and explain etc. In fact, it is often much better as you can see all flows in canvas at once.
With interactive prototype to see all flows of a feature you have to go through each one, which again is very uneffective.
Give it some time. We’ll figure out what LLMs are good and bad at. I think vibe engineering will eventually go up on the wall next to static vs dynamic typing and vi vs eMacs.
At least, that assumes AI models won’t keep improving by leaps and bounds. We’re in a transition period. It’s gonna be chaos.
But a lot of times they don't. Devs building websites for small businesses used to be a thing, and it was almost universally a crap product. Practically every restaurant in my small town has been able to take control of their own website with AI, and it's a better experience for everyone.
Rapid digitisation meant a lot of low-value work wound up being done by high-value people. The economy is pivoting away from that configuration. The high-value folks getting displaced are pissed, partly rightly, partly out of spite. The folks who had to pay those bills are ecstatic, mostly overexuberantly, but in part correctly.
Besides I remember what kind of code we had when we first started coding with AI and now with all these coding agents etc. it has become quite impressive.
However, at the end it is still a tool and needs to be used accordingly.
What do you mean by "vibe engineering"?
It really depends on what you mean by this on how people can agree or disagree with you.
My guess is that in any sense that you mean it, you're almost certainly wrong. AI coding and engineering will continue to improve until any developer who refuses to use it will be unemployable at corporate gigs, and outcompeted even in freelance stuff.
[0] https://news.ycombinator.com/item?id=48420827
In the name of "loyalty" or "faith" cults require members to burn their bridges, actively cutting off their own potential to escape to any other social support network. That may mean creating enemies out of former associates, humiliating rituals or blackmail material, or simply ruining their reputations through obvious lies.
I myself, I pump my investments at least twice a day. Once in the morning, right after I work out. And then once right after lunch.
I want to, that's not why I do it. I do it cause I fuckin' need to.
I'm not saying AI isn't a good tool. However the less you understand what you're using and what you're doing the further you stand to geopardize the business you're working for.
How much does that matter?
Surely, we would expect Jane Street to invest in one of the major AI companies, right?
Do you not pay for Claude?
I think they mean that specifically in working with 3rd party per-project / freelance designers you usually get a "first draft + one adjustment" price, then every modification costs more. Similar for small design shops. Prices aren't necessarily per hour, as you'd get from developers.
It's not the first time, either. They didn't like the non-stop questions about how things should look and really wanted it to be a one-and-done type of handoff. Even at marketing and advertising agencies, I was fighting with them to give me samples of how things not in their design spec should look. I'm not saying I was right, but that's just a huge Achilles heal for me.
So when someone says
> free, unlimited iteration, unbothered
That's immediately what comes to mind. Not necessarily money, but time and patience. Bolt (which is the tool I use for protyping) never gets mad me. It might not produce the best designs, but they are miles ahead of what I'm capable of. When I'm done, I'll have a real designer make it look better, but until then I don't have to worry about pissing someone off.
Keen to hear if anyone has had unconventional creative adventures with it.
I find it funny about meeting requirements when you give them, and making safe choices when you don't give direction. So if you're going to rate the output aesthetics and UX/content, but you don't prompt especially much around the aesthetics, you're only getting the safe assumed defaults. It's good at making bootstrap/tailwind clone designs unless you work that angle. For simple web pages, I've started making this the only focus for initial iteration.
If I have an aesthetic in mind I'll use some screenshots of those sites in the prompt and phrase their inclusion as: "Look at these slightly non-standard designs that work really well for me." So far I've only seen Claude look for through-lines and high-level takeaways--"user likes <design feature> based on the screenshots, so I'll include that"--and screenshots aren't currently a granularity level where it can lift specific details or produce something derivative.
Other than that I try to encourage specific consideration of: type scale, borders and rounding, padding/whitespace, elevation as shadow vs blur, colors. I don't think one needs to pull every customization lever on every project.
There’s still value in it for me, I get decent enough output to convey my intent and I sometimes manually tweak the HTML.
Defining fonts is a good way to at least not get the same typography as everyone else.
By the way, you can always tune your prompts to not be generic, if you ask for generic UIs without detailed styling prompts you will get generic designs.
By the way figma has a decent mcp that you can connect your LLMs to and extract the design tokens from.
Just like SaaS boilerplate from the decade prior, there is LLM boilerplate (since it’s trained on the internet).
So if you put in enough elbow-grease anything is (still) possible!
I don’t know what prompted to get it away from the base model and any of like the non-standard web design like styles are a little bit too harsh for me if that makes sense. Like for example I like brutalist design, but it just feels heavy sometimes on the apps that I’m making.
I’ve tried to get the AI to describe a style based on the product name or you know it seem that I wanna have for example travel. But then it creates us like steal, amorphic design where everything looks like a boarding pass airplane ticket.
However, designing in code is technology-first. One could argue that the purpose of design - to shape the artifacts for human purpose - is better done NOT starting with the strict rules of code. Pen and paper is still hard to beat, not for anything that looks nice, but for helping your mind forward.
Designers aren't learning to code.
My wife works as a product manager in a FAANG and her team has leaned extremely heavily in using AI to vibe-code some pieces of software that they would have done on Word, Excel or similar otherwise.
They're not learning to code, they don't even look at the code a single second.
It helps to understand the constraints of a medium, but you really don't need to know every level down to the electrons moving through the silicon.
maybe that doesn't matter though, I suspect many developers will no longer look at all the code they produce either
Of course hammering away prompts aren’t learning at all.
I some times notice this. the LLM cant see past the interation so I have to think outside the box and say, what if we look at it from this perspective, and suddenly a new way of designing it comes into existance. Somes times I have to create a flow chart to get the LLM to see past its own progression steps.
That’s solves an issue I have with all POC - a really good approach
Figma is still my preferred canvas. Figjam is still great for rough wireframes, flows, and agreeing on data models with my eng counterparts.
But Claude accelerates the divergent early stage 'exploration' work. Unfortunately we don't take the time to properly validate the concepts with customers. Again in the name of 'moving fast'. They will learn eventually I guess.
I'm getting off-topic. Claude is super helpful. As time passes I'm doing more and more work with it. But sometimes taking my design system and pushing pixels is genuinely faster when there is an obvious solution, opposed to ensuring Claude has all the right context to solve a relatively simple problem.
All depends on what I'm working on really.
Written specifications are being reduced in favor of these working prototypes, and now there’s this extra cognitive burden of reading the code and trying to determine what were the intended changes, and what’s the slop that needs to be tossed aside.
We also have to figure out, should we take over this generated PR and make any needed changes? Or do we start over from scratch? There’s often a sense of friction either way.
There have been times where a bunch of unintended changes were generated and I took time to port them over on my reimplementation, and then later on it’s “oops! Sorry! We didn’t mean to change that.”
I get it’s empowering but it does take away from some of the joy I used to find in my work and replaced it with some headaches.
The reason, I believe, is we’ve lost something along the way. Thinking. A non-trivial amount of which is now outsourced to a language model. It paints over the cracks in the prompt, hallucinates how things should work when unspecified, what would normally make someone stop and say “this isn’t quite working”, “how should I communicate this idea” or “what happens when…” has gone. Now, these details are left for after it’s been built proper.
Sure, we can improve the process and reflect more on how to utilise this new technique … but is it better than how things used to be? Yeah nah
Do you look at generated assembly that comes out of your compiler? You don't. So why are you looking at this code?
We have pushed up the abstraction layer.
Because I am getting the call to fix it when it breaks. I don't have to fix assembly by hand because compilers are deterministic and I have maybe encountered a single real compiler bug in my whole career. Compilers have earned my trust. LLMs are eroding that trust more and more every day I work with them. I encounter LLM-created problems in basically every single diff they surface for me, just over the months the diffs are getting bigger and harder to review and uncover the problems.
LLMs are not an abstraction(not even a bad one) because by design what they are doing is disambiguation. Compilers are not doing that, what you put IN the compiler has to be unambiguous in the first place.
Disambiguation is not a functionality of an abstraction layer. A good abstraction layer is the one I don't have to understand and can trust, if I have to understand its inner workings to use it it ceases to be an abstraction. Except with LLMs you can't even do that, they are a black box you can have no hope of understanding.
And it is not to say LLMs and agentic coding tools are not useful, they are absolutely very useful. They are just not an abstraction layer.
That's not what "abstraction" means. You wouldn't hire a designer and then call their work an "abstraction", would you?
It's something, but "abstraction" it aint.
do I care for every snippet? every call's signature? no I do not.
do I understand what it does 100%? yes, because I directed it to be built like that.
I don't get people like you. "care about their craft" - what craft? my job is to make ideas into reality, how I get there is irrelevant. this is what I get paid for and this is what gets me satisfaction.
I've always disliked spending weeks arguing with people about every little detail and having an ideaological war. From the end output most of the decisions that people who "care about their craft" care about are utterly irrelevant.
no thanks. BE boys do FE now
[1] https://x.com/ClaudeDevs/status/2054610152817619388
[2] https://lanes.sh/blog/claude-billing-split
For me building a quick (not production quality) frontend demo in code was already often faster than getting the right interaction working in Figma. And it allowed to make it fully interactive so you can catch much more edge cases on the UX side.
Now with Claude Code it's even faster to build the throw away prototype. But not a huge difference since discussing with the users and thinking about how it should work is 80% of the time. Claude maybe halves the other 20% compared to quickly doing it yourself. Faster to first version, slower to iterate if it didn't fully get it.
I think the ability to get to a working prototype faster is very empowering, even if some will be tempted to ship these incomplete ideas. Design and UX needs benefits greatly from being able to play with it, and experience the actual flows beyond just a storyboard and wireframes.
It's much harder to RL out design taste because it's not self-grounding, and human labelers have no real skin in the game, so this (having a human with a vested outcome in the process directing a model's work) is the best way to get LLMs better at design/"taste"/aesthetic judgment themselves. We were working on the same thing 7 months ago and then I realized that winning over designers to do this would be a huge uphill battle setting up an inevitable fall from grace later on.
What makes me most suspicious of Claude Design is that when you disconnect and reconnect later, it loses context and nags you that the product doesn't work like that. Bullshit. It's at best an anti-abuse/implementation detail (to keep you from launching 10 at once and coming back to them later) or product shortcoming that just so happens to be optimized for keeping you from continuing your design in better tools than theirs for the inevitable followups.
It's great for one shots and it makes sense when you're trying to build a vertical product development stack like Anthropic but I'm disappointed it feels more like a tool optimized for keeping you in their product than for what you're working on. If a company other than Anthropic had shipped this - it's not that hard to build a visual self-eval loop, just use Chrome Devtools Protocol to run headless chrome and take screenshots -> feed into a judge LLM for feedback -> continue - I don't think it would really have seen much adoption.
That said, AI trained on Actor-Critic with a tight human feedback loop definitely seems like the right approach to solving the problem, just not something I want to spend my time training for someone else unless I can do so with higher "entropy" ie high parallelism/optionality
Also, you're mentioning a lot of unrelated tech. DPO, PPO, actor-critic, visual self-eval loops, Anthropic's "vertical product development stack" may be interesting, but they are mostly orthogonal. The article's point is simply that a designer can now turn design proposals into working prototypes faster than with Figma.
Also, you mention what seems to be a random product bug about disconnect and reconnect that doesn't have anything to do with this workflow. It seems to me that you're post-rationalising some insights that are not really there.
Good to think things through and in public, not discouraging it. I hope this reads as constructive.
from 6 sessions and 5 projects only one template that I choose anything else is really really bad
Yeah you don't say. High of $124, currently $22. But hey: that's ~~gambling~~ stock trading for you.
https://au.finance.yahoo.com/quote/FIG/
That's pretty mean. I disagree with a lot of people on their investment choices and evangelism. That doesn't mean I want them to suffer for it.
It's a shame because if they'd taken an iterative approach of automating various parts of a normal Figma workflow to speed things up for users, that would have helped them discover where the value was; lots of little ideas, failing fast, testing and updating.
Maybe they just got too big and lost their mojo.
It's a nice article and good point but I feel "design" in the title is misleading - the example given has an extremely reduced visual or spatial scope (something models are still not good at). The post is more about rapid prototyping.
In a way it's not much different from copy-pasting components from templates or whatever, just with more customisability. And for stuff that isn't HTML-based like React it does worse. It's also not great at building component libraries, I still write those myself with little LLM involvement, but that makes sense because the architecture is actually relevant with that, unlike generating CSS and xml-derived components, which is mostly just declarative templating anyways.
I've had decent success writing the core logic myself and then delegating the UI to AI. I think if I didn't write the core logic it would not work very well, but since it's designed well by myself the AI has a much smaller scope to work in which constrains it enough where vibe coding works. Pretty cool.
When they paywall hard, I’ll use a local model on my laptop processor instead,
or phone,
and wait a few hours as needed.
This is a very disappointing post from Jane Street.
Klankers will fix everything. Right?
The one non-circular-financing entity that is heavily spending on AI, is interested in you knowing how wisely they think they are spending their money.
Jane Street isn't one to telegraph their moves (seems like they prefer to Telegram them privately https://protos.com/what-weve-learned-from-terraform-labs-unr... , so not only Jump Crypto felt fine letting everyone believe the ponzi, per these allegations it seems Jane Street did too). If Jane Street is spending the most, and their staff is supposedly high value pay/profit but low headcount, for all the end user knows, their "AI agent" is half chat bot / half software engineer with 20 years experience who checks each result before sending it. Literally the Mechanical Turk scam of hundreds of years ago, where a midget hides in the stand and moves the chess pieces--with shades of Amazon Fresh self checkout. Maybe the higher ups at Jane Street know this, maybe not. But unless they have a closed system that Anthropic can't get into, I would be suspicious. And, of course, they aren't /that/ free from the circular financing because they are a major investor of Anthropic. To me the fact that the blog post doesn't start with a disclosure doesn't seem like a misstep/accident. And if they find out they are being Mechanical-Turked, I think it far more likely they'll find some way of shorting before telling anyone, or they won't tell anyone.
Using AI for things you aren't good at, or not experienced with, is literally the worst way to use AI. You WANT to struggle when learning a new language, and use reliable documentation to solve your problems, not circumvent them entirely by using AI.
This is extreme incompetence, I'm shocked that Jane Street would advertise it.
What happens after the submission? Who reviews the feature? How long? Are there any limits to the size of the diff? Do reviewers push back? How often are features submitted?
where i'd normally spend hours combing through dribbble looking for inspiration for layouts for specific components (most of the time finding nothing), now I use chatgpt to come up with a number of different designs, then port them over to figma.
most designs produced by cgpt arent production-ready, especially for mobile. figma allows me to set proper constraints (screen size, for example), that give it a more grounded "shape"
for that reason, the actual final design is still by hand for now. however, the translation from design to implementation is greatly sped up by codex, which basically does it pixel-perfect.
all the same, still lots of tweaks needed before the final implementation is ready. design to code still has a bunch of issues that often need figuring out/standardising - font sizes, weights, etc.
this is on mobile btw, where space is very limited. havent worked on a website in a while, but i'd imagine the extra space would allow for far more liberty. i do not miss having to craft ten different designs just to ensure responsiveness. massive pita.
I've worked with graphic designers, whether its 1 person on a team, or a group, or a division, and had the back and forth for years. I've also contracted with many graphic designers to polish my own applications as well as promotional materials. I've contracted with agencies, I know what a style guide looks like, a press kit, a design library shared between applications and departments needs to have.
Now it's not a full time job. Its 3 tabs for different user flows in the application.
And on the flip side, designers can also deploy software now that's good enough - (I feel like I can deploy more efficient software than an AI will initially suggest, and do things that stay on free tiers for far longer than anyone just going along with AI's suggestions.)
https://www.bloomberg.com/news/articles/2026-06-04/jane-stre...
In other words, it is an AI booster. Abusing the goodwill of programmers for their OCaml involvement even though most of it was convoluted bloat and inferior to INRIA code is devious.
It happens all the time now and people need to inoculate themselves against it:
A single famous open source person or an open source involved company invested in AI suddenly posts "organic" testimonies in favor of AI. It means nothing. The person is not the same person, the company is not the same company (or is now overtly evil).