
"A portfolio is what people see. The experience behind it is what they don't."
There is a particular kind of website you have probably seen recently.
A dark background. Purple or blue gradients. Glass-like cards. Rounded corners. A huge heading in the middle of the screen. A few glowing buttons. Maybe an animation when you move your cursor.
You have seen it before. Probably more than once.
And if you have spent any time looking at websites made with AI, you might already have a name for it.
AI slop.
Fair enough. Some websites really do look like someone typed one sentence into a prompt box, accepted the first result, and published it without looking twice.
But there is something interesting about how quickly we have started using that phrase.
We see a familiar gradient and decide we know the entire story behind the website. We see a layout that resembles ten other websites and assume the person who made it put no thought into it.
Sometimes that assumption is right.
Sometimes, we have absolutely no idea.
And yes, my portfolio has purple. Quite a lot of it, actually.
I like purple. I liked it before AI website builders became a regular part of everyone's workflow. My profile picture was purple. My favicon was purple. When I started putting together my portfolio, carrying that colour into the website felt natural.
I wasn't trying to follow a trend. I just liked the colour.
Apparently, that is now a suspicious design decision.
So, this is about my portfolio, AI-generated design, a little bit of colour history, some programming arguments, and something I think we should discuss more often: what happens when we make people feel embarrassed for trying to build something?
1. AI didn't invent purple
Before getting into the website itself, I want to take a small detour.
I have a habit of finding one interesting question and disappearing into a completely unrelated rabbit hole. This particular one started with a YouTube video asking why purple is so uncommon in national flags.
It sounds like a very specific question to spend time thinking about. But the answer leads to a surprisingly interesting history.
Purple was once an extraordinarily expensive colour to produce.
One famous example is Tyrian purple, a dye made from secretions of certain species of sea snails. The process was complicated and labour-intensive. According to the University of Chicago Library, producing just one gram of the dye could require up to 12,000 molluscs.
Twelve thousand.
Imagine explaining to someone that you need thousands of sea snails to make a little bit of purple dye.
The colour became associated with royalty, wealth and authority partly because it was so difficult to obtain. In the Roman world, purple clothing could carry a significance that went far beyond fashion.
Then came a young chemistry student named William Henry Perkin.
In 1856, Perkin was trying to synthesise quinine, a compound used to treat malaria. His experiment did not produce the result he wanted. Instead, it led to the discovery of a purple synthetic dye that became known as mauveine.
He was just eighteen years old.
That accidental discovery helped establish the synthetic dye industry and made purple much more accessible. A colour that had once required an extraordinary amount of effort to produce could now be manufactured using chemistry.
I find that fascinating. An unsuccessful experiment became an important discovery.
There is also a small science distinction worth knowing: violet and purple are not quite the same thing in physics.
The visible spectrum is the part of electromagnetic radiation our eyes can detect. NASA describes the approximate visible range as 380 to 700 nanometres. Violet sits near the short-wavelength end, while red sits near the long-wavelength end.
But purple, in the everyday sense, does not have one single wavelength.
Our eyes have three broad classes of cone cells that respond to different ranges of light. The brain processes their combined signals to produce the colours we perceive. Purple can be perceived when light stimulates combinations of the long- and short-wavelength responses without the same pattern of stimulation that would correspond to a single spectral colour.
In simple terms, you can point to violet on a rainbow, but you cannot point to one particular wavelength and say, "That is purple."
Purple is a little more interesting than it looks.
Anyway.
There is another interesting purple-related detail. The flag of Dominica features its national bird, the Sisserou parrot, in the central emblem. The bird has purplish-violet feathers, which means purple appears in the flag through a very specific piece of national identity rather than simply being chosen as a decorative colour.
So, yes, I have spent a surprising amount of time thinking about purple.
And no, AI did not invent it.
A person using purple in a website does not automatically mean they copied an AI template.
2. The website is what people see. The experience is what they don't.
Now, about my portfolio.
My journey into programming started during the 2021 lockdown.
I wasn't thinking about portfolios, personal branding or becoming a professional developer. I was simply curious about whether I could make something work.
I started experimenting with Telegram bots. One thing led to another, and suddenly I was exploring Python, APIs, databases and asynchronous programming.
I learned by building things.
I worked with Pyrogram, Flask and FastAPI. I explored MongoDB, Redis and PostgreSQL. I learned about APIs, deployment, debugging and the many ways software can behave differently from what you expected.
One of my projects, SerenaRobot, eventually reached more than 10,000 groups.
But the interesting part was never just the number.
It was the experience of building something that other people actually used.
When you build something for yourself, a mistake might be an inconvenience. When other people depend on it, you start thinking differently.
An API might fail. A database might not behave the way you expected. An asynchronous task might introduce a bug that is difficult to reproduce. A feature that works on your computer might behave differently after deployment.
You begin to realise that writing code is only one part of building software.
You also have to understand what the software is doing, how its different parts communicate, what happens when something goes wrong, and how to make changes without breaking something else.
That experience is difficult to communicate through a screenshot.
Eventually, I wanted a place where I could present my projects and share what I was learning. That became my portfolio.
The website itself turned into another project.
I worked on a custom build script that turns Markdown content into pages. I built an interactive terminal using JavaScript. I worked on the styling, structure, search and the little interactions that make the site feel like mine.
I wanted something that could grow as I built more things.
There is a lot happening behind the visible page that someone might never notice by simply opening the website.
And that is fine. A website is supposed to be experienced by its visitors, not inspected like a school practical record.
But it made me think about something:
"A portfolio is what people see. The experience behind it is what they don't."
Someone might spend weeks learning how APIs work, understanding databases, debugging a backend or figuring out why an application behaves differently after deployment.
None of that necessarily appears in the hero section of their website.
A screenshot cannot tell you how much someone knows.
And a gradient cannot tell you how much someone has learned.
3. Why do so many AI websites look alike?
There is a genuine conversation to be had about AI-generated design.
Generative AI models learn patterns from enormous amounts of existing material. When asked to create a modern website without much direction, they can fall back on familiar visual patterns.
Dark backgrounds. Gradients. Glassmorphism. Rounded cards. Large headings. Predictable sections. A few animated elements.
These patterns are not inherently bad. They are popular partly because they can look attractive and are relatively easy to combine into a coherent interface.
The problem appears when everyone keeps reaching for the same defaults.
Give different people a vague prompt like:
"Create a modern, premium developer portfolio with a beautiful UI."You might get different results, but you may also notice a familiar visual language appearing again and again.
This is not because AI models have a favourite colour or secretly coordinate their designs. It is because familiar patterns are easy to reproduce, and vague instructions leave a lot of room for those patterns to take over.
There is actually research looking into this.
In March 2026, Microsoft Research published a paper titled Interrogating Design Homogenization in Web Vibe Coding. The researchers examined how AI-assisted website creation might reduce visual diversity, particularly when people rely on frictionless generation and accept familiar defaults.
One of the ideas discussed is what they call productive friction.
The basic idea is interesting: not every part of the creative process should be reduced to one-click generation. Some amount of questioning, experimenting, making decisions and challenging the first output can help people create more distinctive work.
I like that idea.
The goal shouldn't be to make AI generate a website as quickly as possible and then call the result finished.
Maybe the more interesting process is to generate something, question it, change it, reject parts of it, try alternatives and understand why certain decisions work better than others.
AI can give you a starting point.
It doesn't have to give you the final answer.
And perhaps this is where the conversation about AI design should focus: not simply on whether AI was involved, but on whether the creator made meaningful decisions after the first output appeared.
4. Before you call someone's website AI slop
I want to make a distinction here, because this is where the conversation can become unnecessarily harsh.
Imagine someone who has never built a website before.
They have an idea. They are curious. They open an AI website builder, spend an evening describing what they want, adjust the result, change the text, try different layouts, and finally publish their first website.
Maybe it has a purple gradient.
Maybe it has rounded cards and a familiar hero section.
Maybe it looks a lot like several other websites you have already seen.
Now imagine the first response they receive is:
"AI slop."
This is a hypothetical example. It is not a story about my first website, nor am I secretly describing a particular person. I am asking you to consider what that response means to someone who has just tried building something for the first time.
You can dislike the design.
You can point out that it looks generic.
You can say the layout needs work, the typography could be better, the spacing is inconsistent or the website needs a clearer visual identity.
Those are fair criticisms.
But what exactly have you achieved by dismissing the entire thing with two words?
You don't know how much effort went into it. You don't know whether they spent hours refining the prompt, studying references, learning how the tool works, changing the output or trying to understand what they had created.
You don't know whether this is their first attempt or their fiftieth.
And even if the website was generated mostly by AI, that still doesn't tell you everything about the person who made it.
AI-generated describes how something was produced. It does not, by itself, describe the thought, effort or understanding behind it.
Likewise, a website written entirely by a human is not automatically thoughtful or well-designed.
A human can produce something careless. An AI-assisted project can involve real decisions, experimentation and learning.
The tool alone does not tell the whole story.
I am not asking people to pretend every website is brilliant. I am not saying beginners should be protected from criticism or that every attempt deserves applause.
I am asking for a little more precision.
If the design is generic, say it is generic. If the spacing is inconsistent, explain that. If the website feels unfinished, say what could improve it.
There is a difference between criticising someone's work and making someone feel foolish for having tried.
And perhaps this is a useful question to ask ourselves before making that judgement:
"If AI tools disappeared tomorrow, could you build a website yourself with the same level of attention to detail you are demanding from someone else?"
That isn't a challenge to prove who is the better developer. You don't have to be able to build something to recognise its flaws.
It is simply a reminder that making things is easier to criticise from the outside than it is to do for the first time.
Think about the first thing you ever built, wrote, designed, recorded or shared.
Would it survive the standards you apply to your work today?
Probably not.
That doesn't make the first attempt meaningless. It makes it a first attempt.
We should want people to build better things, not make them regret building anything at all.
Don't make someone regret trying. Give them a reason to make their next version better.
5. HTML, Next.js and the strange need to prove your technology choices
Recently, I had a conversation with another student about a website I had built for a student initiative.
The discussion eventually turned into the familiar question of why I had used HTML instead of something like Next.js.
I understand why people ask that question. There are plenty of frameworks worth learning, and Next.js is a useful tool for the right kind of project.
But I had chosen the technologies based on what the project needed.
HTML gives a page its structure. CSS handles its presentation. JavaScript adds behaviour. Next.js is a framework built around React that provides additional features and different ways to build applications.
These things are not competing labels in a popularity contest.
For a relatively straightforward informational website, plain HTML, CSS and JavaScript can be a perfectly reasonable choice. For a larger application with more complex requirements, a framework may make much more sense.
The right tool depends on the problem.
There is a strange idea in some developer circles that using a particular framework automatically makes a project more serious.
A project using Next.js is not automatically better than one using plain HTML. A project using plain HTML is not automatically more impressive because the developer avoided a framework.
The same applies to programming languages, databases, libraries and deployment platforms.
A technology choice should answer a requirement, not satisfy someone's desire to use the latest thing.
I also have to admit that I didn't handle that conversation particularly well. I became defensive, and some of my replies were immature.
It is easy to get attached to a technology choice when you have spent time working on something. It can start feeling as though someone is questioning your ability rather than simply questioning your decision.
But not every technical disagreement needs to become a competition.
Using a framework does not automatically make someone a better developer. Avoiding frameworks does not automatically make someone more skilled either.
Understanding why you chose a tool matters much more than using its name as a badge.
I am still learning that.
6. I use AI too. Obviously.
It would be rather strange to write an entire article about AI-assisted websites while pretending I never use AI.
I do.
I use it to explore ideas, understand unfamiliar concepts, work through bugs, generate starting points and speed up parts of my workflow.
Sometimes it gives me a useful explanation.
Sometimes it gives me code that looks convincing but doesn't actually solve the problem.
Sometimes I have to ask it to explain its own answer because I don't understand what it has produced.
That is part of working with these tools.
The important distinction, at least to me, is what happens after the output appears.
- Do you understand what you are putting into your project?
- Can you inspect it?
- Can you recognise when something is wrong?
- Can you change it when your requirements change?
- Can you take responsibility for what you publish?
AI can help write code, but it does not automatically give you the understanding required to maintain that code.
And using AI does not mean you have learned nothing.
Programming has always involved tools, abstractions, libraries and frameworks. We don't become better developers by making every task unnecessarily difficult.
But we should not confuse producing an output with understanding it.
There is a difference between asking AI to generate an API and understanding how that API handles requests, validates input, communicates with a database and responds when something goes wrong.
There is a difference between generating a website and understanding its structure, accessibility, responsiveness and behaviour.
There is a difference between getting a result and being able to maintain it.
The ability to generate something is becoming increasingly accessible.
The ability to evaluate it, make decisions about it and take responsibility for it still matters.
That is the part I want to keep improving.
7. The internet has always had templates
There is another thing worth remembering.
Websites looking alike is not an entirely new problem.
Before AI website builders, people used templates, themes, component libraries, WordPress themes, Bootstrap, UI kits and design systems.
A lot of websites already shared visual patterns because people reused things that worked.
And there is nothing inherently wrong with that.
Imagine having to build every button, navigation bar, form, layout and interaction from scratch every time you wanted to make a website.
That would be a rather inefficient way to work.
Reusing components is one of the reasons modern software development is possible at scale. Frameworks and libraries exist partly because developers shouldn't have to reinvent everything.
The problem is not reuse.
The problem is when reuse becomes the only creative decision.
A template can be a starting point. A component library can save time. An AI-generated layout can help someone get past the blank page.
But eventually, someone has to decide whether the result actually fits the project.
Does the navigation make sense? Is the content readable? Does the page work on a phone? Is the design appropriate for the people using it? Does the website communicate what it is supposed to communicate?
A beautiful hero section cannot compensate for a confusing website.
A clever animation cannot fix poor navigation.
And a website doesn't become good simply because it has a modern-looking interface.
Sometimes the best design decision is removing something.
Sometimes it is choosing a boring, familiar solution because it makes the experience easier.
Sometimes it is keeping a colour because you genuinely like it.
Not every decision needs to be a statement.
8. Maybe we should be more careful with the word "slop"
Words change the way we look at things.
- "AI-generated" tells us something about the production process.
- "AI-assisted" tells us that AI was involved.
- "Generic" describes a lack of distinction.
- "Unfinished" describes the state of the work.
- "Slop" is a judgement about quality.
These terms are not interchangeable.
Calling something AI-generated is a factual description if it was generated using AI. Calling it generic is a criticism of its design. Calling it slop is a much stronger dismissal.
And sometimes, that dismissal might be justified.
There is AI-generated content that is repetitive, misleading, careless or produced in enormous quantities without much thought. It is reasonable to criticise that.
But when the word becomes a shortcut for dismissing anything that looks familiar, we stop having a useful conversation.
A beginner's first website and a company publishing thousands of low-effort pages are not necessarily the same situation.
A student experimenting with an AI builder and a business flooding the internet with automatically generated content are not automatically doing the same thing.
The technology might overlap. The intent, effort, context and consequences can be very different.
We should be able to recognise those differences.
And if someone shares their first project, perhaps we can start by asking what they were trying to build instead of immediately deciding what label to give it.
Not every project needs praise.
But most people can benefit from useful feedback.
9. The part I don't want to lose
I started programming during lockdown without much of a local circle of people who were interested in the same things.
I was experimenting with Python, Telegram bots, APIs and all sorts of things that were difficult to explain to people around me.
There were plenty of things I didn't understand. I made mistakes. I learned by trying things and looking for answers.
Over time, I found people online who were interested in similar things. I learned from their projects, their explanations and sometimes simply from seeing what they were building.
That experience is one reason I value people who share what they make.
You never really know who might be seeing your work for the first time.
Someone might discover programming because they saw a small project someone shared online. Someone might decide to try building a website because they saw another beginner do it. Someone might realise that an idea they had been sitting on for months is actually possible to experiment with.
That is one of the genuinely exciting things about making tools more accessible.
More people can participate.
More people can experiment.
More people can share ideas that might otherwise have remained ideas.
Of course, not every experiment will turn into something useful. Not every website will be well-designed. Not every project will be maintained.
That is how learning works.
If we want people to get better, we need to leave some room for them to be beginners.
I also think this applies to people who have been building things for years. Experience should make us better at giving feedback, not simply better at finding reasons to dismiss someone else's work.
There is a difference between saying, "This could be improved, and here is how," and saying, "This is worthless because I recognise the style."
One helps someone move forward.
The other mostly ends the conversation.
10. So, is my portfolio AI slop?
Maybe someone will look at my portfolio and think it is too purple.
Maybe someone will dislike the gradients, the layout or some of the design choices.
Maybe there are things I will change six months from now.
That is fine.
I don't consider my portfolio a finished statement about my abilities. It is a place where I can present what I have built, share what I am learning and give people somewhere to explore my work.
I have spent time building software beyond the visible interface. I have experimented with backend systems, APIs, databases, bots and automation. I have also used AI, learned from it, disagreed with it and corrected its output.
All of those things can be true at the same time.
I don't need to pretend I never use AI to prove that I understand programming.
And I don't need to remove purple to prove that I have my own taste.
The bigger question is not whether a website contains a gradient or whether AI helped create it.
It is whether the result serves its purpose, whether the creator has made thoughtful decisions, and whether there is room to improve it.
We can criticise repetitive design without mocking beginners.
We can appreciate human effort without pretending every result is excellent.
We can use AI without surrendering our judgement.
And we can encourage people to build things while still being honest about what needs work.
Maybe that is a better way to approach this whole conversation.
The internet does not need every website to look the same. But it also does not need people to be afraid of publishing their first attempt.
I still have a lot to learn. My portfolio will probably change. My opinions about design will probably change too.
For now, I like what I have built, I like the colour I chose, and I am happy that I made something I can keep improving.
Someone might call it AI slop.
I still like purple anyway.