Software Engineering Beyond Code: The Art of System Design

My two cents on vibe coding 🤖 Recently, I started a personal project and used this as an opportunity to practice my vibe coding skills. Since this was my first real hands-on experience, I wanted to share a few perceptions. First of all, it's hard to ignore how impressive it is to generate working code in minutes. But of course… it’s not perfect (they learned from us, after all 😅). Some recurring challenges I noticed: - Technical debt still exists and needs to be managed - Security issues, like plain-text credentials in the code - Performance gaps, both on frontend (unnecessary API calls) and backend (inefficient queries) - And the most common one: duplicated code — especially when prompts lack context In my view, the biggest gains come when building new or independent features with clear requirements, or even just generating boilerplate. That’s where things really shine. On the other hand, small to medium changes can require very detailed prompts and multiple iterations, and in those cases, the productivity gain feels much closer to traditional development. One thing is already clear to me: we'll soon see non-developers building small applications for personal use. But at the same time, this experience reinforced how much developer expertise still matters, especially when it comes to architecture, scalability, and quality in more complex systems. It was about two months ago, and since then, AI agents keep evolving really fast. I can't wait to try it again and see how much they improved. #AI #SoftwareDevelopment #DevExperience #Productivity #CodeQuality #VibeCoding

Vibe coding made the easy part of software development even easier. The problem is that the easy part was only ever 10% of the work. AI tools, more often than not, still require you to know how to build. Otherwise the common pattern of slop codebases repeats itself: prototype looks and feels great. Then it gets deployed and falls apart. Often in many very interesting ways. The short version: → A junior with AI tools is still a junior. A senior is still a senior. The gap just changed shape. → The prototype is 10% of the work. Vibe coding just made that faster. The other 90% still didn't get easier. → AI agents read existing code and replicate its quality level — slop in, slop out → Fixing a vibe-coded codebase often takes longer than rewriting it from scratch → "Anyone can build anything" is a pleasant dream until a paying customer depends on what you built The longer version covers the "slop inheritance" problem, why you often can't just prompt your way out of a bad codebase, and the three real options you have when you need to ship that as something that actually works. Head over yonder for the full piece: https://lnkd.in/dSHqQe9n #vibecoding #agenticdevelopment #webdev

Last year, I tried vibe coding an app to manage the parent schedule at my son's co-op pre-school. I'm talking about actually completely riffing an app together without a project plan. Pure "vibes". It never got released. The idea wasn't bad. But the reason it didn't work was because the logic updates got stuck. The scheduling had some level of complexity. Every parent had their own availability restrictions, we needed to track repeat sign ups, and two families had twins which added another layer entirely. Some complexity, but for sure no where near impossible. But there were enough moving parts that when I kept feeding new details into the AI after the initial build, it couldn't reconcile them. It felt like the logic was already baked. My follow up prompts weren't changing it the way I expected. That's what I'm calling a logic lockout. Could I have fixed it by going into the code directly and using AI to revise the specific logic? For sure. But that wasn't the point. I was truly trying to vibe this thing together. Here's what I learned: "Vibe coding" works. To get something started, it's genuinely fast and impressive. Getting to a prototype? Extremely quick. Front-end work, proof of concepts, UI mockups. AI-assisted development platforms crush this. I've made AI-assisted software development the standard at my company for some time now. This isn't an experiment anymore, it's just how software should be built. Choosing not to use it is like a contractor showing up to a job site and leaving the power tools in the truck. But when creating solutions with real complexity, the prompting plan matters as much as the product plan. Dumping everything in at once causes details to get lost or misinterpreted. Break the build into stages. Define the logic before you start prompting. Feed it one layer at a time and validate before you move on. The AI can handle complexity, but it needs you to introduce it in the right order. And when you pair that structured prompting with real software architecture and planning up front, you're not just building something that works. You're building something that can scale.

The internet is arguing about whether vibe coding is "real programming." I run a vibe coding team that ships production systems. The debate is asking the wrong question entirely. The question is not "is vibe coding real programming?" The question is "what does a team look like when AI writes 80% of the code?" Here is what I have observed: The skill that matters most is not prompt engineering. It is architectural judgment. When AI generates 500 lines of code in 30 seconds, the bottleneck shifts from writing to evaluating. Can you read AI-generated code and spot the subtle bug that will only appear at scale? Can you design the system architecture that makes AI-generated components fit together correctly? The teams that fail at vibe coding treat it like faster typing. The teams that succeed treat it like having a junior developer with infinite energy and zero judgment. You still need the senior engineer who knows what to build and can review what was built. The economic shift is real: A 3-person vibe coding team can output what used to require 8-10 developers. But those 3 people need to be significantly more experienced, not less. You are trading headcount for seniority. The part nobody talks about: Debugging AI-generated code is harder than debugging code you wrote yourself. You do not have the mental model of why it was written that way. When it breaks at 3 AM, you are reverse-engineering someone else's logic — except that "someone" is a model that cannot explain its reasoning. I am bullish on vibe coding for production systems. But the teams that will win are the ones building review processes and architectural guardrails. Not the ones celebrating how fast they can generate code. Most discourse frames this as "AI replacing developers." I think it is closer to "AI redefining what seniority means." Where am I wrong?

Vibe coding will get you to a demo. It won't get you to a product. I see this constantly with post-seed teams. They used AI tools to build fast, got to something fundable, and now a real engineer has joined and can't make sense of what's there. Features conflict. Nothing is documented. Adding anything new breaks something old. This isn't a failure of the tools. It's a failure of the model running past its useful life. Vibe coding has a ceiling. It shows up in specific ways: a new developer needs a two-hour walkthrough just to understand the codebase. Adding a new feature breaks an existing one. There's no record of what the product is supposed to do, so every decision gets made twice. Investors start asking about architecture and nobody has a clean answer. The team isn't bad. The product isn't broken. But the structure that lets it scale doesn't exist yet — and that gap is widening every sprint. At this point, the question isn't whether to add structure. It's how quickly you can do it before the cost compounds. This is exactly the stage where fractional product leadership makes the most sense. Not a full-time hire. Not a consultant who advises from the outside. Someone who embeds, audits what's there, and builds the foundation that lets the team move forward with clarity. If your team is at this stage, DM me. Happy to talk through what the first 30 days would look like.

💡 Insights on programming We are living through a silent shift. Programming used to be highly technical and restricted. Today, with the rise of AI, development is becoming more accessible — and more present in our daily lives. But this post is not about AI. It’s about something that still makes a real difference: 👉 Code quality. Throughout my journey as a Software Engineer, one thing has always been present in every project: There is the new. And there is the legacy. And that will never change. Technology evolves faster than we can rewrite systems. There are solutions that have been built and improved over many years — and in many cases, rewriting them from scratch is simply not an option. So here’s the question: 👉 Where is the balance? Is there such a thing as “future-proof” code? In my view, yes. And it has one thing in common: Simplicity. Good code is not the most complex. Nor the most “clever”. It’s the one that solves the problem clearly. The simpler it is: • easier to maintain • easier to evolve • easier to understand (even for AI) But here’s the catch: Simple is not easy. It requires technical depth. It requires understanding the product. It requires clarity about the problem. And this is exactly where many issues begin. Under pressure or without proper context, we build without understanding the full picture. And that leads to complex code… and inevitable bugs. Understanding the product is also part of a developer’s job. When that happens, everything changes. The code becomes clearer. More efficient. More sustainable. At the end of the day, writing simple code is not about reducing lines. It’s about maturity. And those are the kinds of systems that truly stand the test of time.

Coding is all about solving problems, building systems, and turning ideas into functional products. Every application, platform, or digital experience starts with structured thinking translated into code.  It is the process of breaking down complex problems into smaller, logical steps and creating solutions that machines can execute efficiently. From mobile apps to enterprise systems, coding sits at the core of everything digital. As technology evolves, coding is becoming less about memorizing syntax and more about understanding logic, architecture, and how different systems connect. It is also about knowing how to use modern tools, including AI, to build faster and smarter. Today, great developers are not just coders. They are problem solvers, system thinkers, and innovators who understand both technology and the user behind it. Whether you are a developer or a business leader, understanding coding at a fundamental level is becoming increasingly important in a digital-first world. #Coding #SoftwareDevelopment #TechEducation #Programming #Developers #LearnToCode #DigitalSkills #TechIndustry #Innovation #FutureOfWork

Most developers don’t realize this… You’re not paid to write code. You’re paid to reduce problems. Think about it: A feature isn’t valuable because it’s coded. It’s valuable because it solves something real. Early in my career, I focused on: • writing more code • using better syntax • learning new frameworks Now I focus on: → understanding the actual problem → asking “why does this matter?” → removing unnecessary complexity → delivering the simplest working solution Because sometimes the best solution is: • fewer lines of code • fewer moving parts • fewer things that can break Great developers don’t add more. They remove what’s not needed. That’s where real impact comes from. Before you start coding next time, ask: “Is this solving the right problem?” What’s one problem you solved recently that made a real impact? #softwareengineering #developers #problemsolving #buildinpublic #careergrowth

First there was pair programming. Then there was AI pair programming. Now there's something else entirely: vibe coding. It's loose. It's fast. It's messy. Here's what vibe coding actually looks like, why developers love it, and where it breaks. https://lnkd.in/e_6mi2fd

Two months ago I set myself a challenge: ship a real code to our production codebase. As a product designer with zero formal coding background, that felt pretty daunting. This week, I did it. ✅ Here's what the journey actually looked like: It started with a simple idea — designers at Jane App making small, low-risk code changes directly, rather than filing tickets and waiting. Copy fixes, label corrections, accessibility tweaks. Things we spec out anyway. Why couldn't we just... do them? I used Cursor to tackle inconsistent sentence case and field labels on our US billing page. The AI handled the actual code changes through natural language prompts. What I had to learn was everything around it — the Git workflow, resolving merge conflicts, linting, CI/CD, PR etiquette. That part humbled me. A lot. I paired with engineers on my team who were incredibly generous with their time. We debugged flaky tests, fixed ESLint errors, worked through merge conflicts from overlapping branches, and talked through when to amend commits vs. add new ones. Things that are second nature to developers but genuinely opaque if you've never been in a codebase before. The PR took longer than it probably should have. But I learned more about how software actually ships than I have in years of working alongside engineers. A few things I'd tell designer-curious-about-code: → AI tools make the code part surprisingly approachable. The workflow and culture around code is the real learning curve. → Find an engineer willing to pair with you. It unlocks everything. → Start with something low-risk and self-contained. Copy changes, label fixes, sentence case. You don't need to build a feature. → It changes how you design. Knowing what's hard to change (and what isn't) makes you a better collaborator. The goal isn't for designers to replace engineers. It's to close the gap - and in doing so, ship more delight, faster, together. Shoutout: Joseph Green for all the help along the way! 🚀 🌘