DEV Community: Mykola Kondratiuk

Issue Tracking Is Dead - Here's What PMs Actually Manage Now

Mykola Kondratiuk — Wed, 08 Apr 2026 08:27:29 +0000

Linear's CEO just declared issue tracking dead. And honestly? The data's been saying this for months.

25% of new issues on Linear are created by AI agents. That number was 5x lower three months ago. 75% of enterprise workspaces have coding agents installed. The agent creates the issue, writes the code, opens the PR.

So what does the PM do when the entire delivery pipeline runs itself?

The Accountability Chain Problem

Here's what broke. The traditional workflow has an implicit accountability chain:

Human creates issue → Human picks it up → PM owns the outcome
      ↑ context          ↑ delivery          ↑ accountability

When agents enter the chain:

Agent creates issue → Agent writes code → Agent reviews PR → PM owns... what?
      ↑ ???                ↑ ???               ↑ ???              ↑ everything

The accountability chain fractures. Nobody validated the agent's issue was worth building. Nobody checked the agent's acceptance criteria. The PM is suddenly accountable for an outcome they didn't initiate, built by entities they can't have a standup with.

I hit this wall managing my own agent workflows about two months ago. Stopped assigning work, started auditing what agents decided to do. The shift was disorienting until I named it: I'm not managing work anymore. I'm governing outcomes.

Anthropic's Glasswing - A PM Framework in Disguise

Anthropic launched Project Glasswing yesterday. On the surface it's a safety program for their most powerful model. 12 vetted organizations. Scoped access. Usage audits. $100M in accountability infrastructure.

But look at the five principles they built:

Scope access - not every agent gets access to everything
Vet use cases - just because it can doesn't mean it should
Audit outputs - systematic review of what agents produce
Budget accountability - factor governance into the cost model
Know when NOT to deploy - some workflows need humans

That's not a safety framework. That's a PM governance playbook.

If you're running agent workflows in your org, here's how those principles translate:

agent_governance:
  scope:
    - define which systems each agent can access
    - set boundaries BEFORE deployment, not after incidents
  vetting:
    - map which workflows benefit from agent-generated work
    - identify workflows that need human initiation
  audit:
    - build review cycles for agent-created issues
    - quality gates at each pipeline stage
  accountability:
    - define who owns outcomes when agents create the work
    - factor incident response into agent deployment costs
  boundaries:
    - identify workflows requiring human judgment
    - document why certain workflows stay manual

What I Learned Rebuilding 17 Agent Accountability Chains in One Afternoon

A few weeks back, a platform change forced me to migrate my entire agent setup in one afternoon. The migration itself wasn't the hard part - swapping configs, updating endpoints, that's mechanical.

The hard part was rebuilding "who owns what."

Every agent had implicit accountability chains I'd never written down. This agent creates issues but a human reviews them. That agent writes code but only in specific repos. Another agent can deploy to staging but never production.

When I had to rebuild from scratch, I realized none of those chains were documented. They lived in my head. That's fine for one person running a handful of agents. It's a disaster for a team.

The exercise took an hour. I mapped every agent to its access scope, its review requirements, and its accountability chain. If you're running any kind of agent workflow, do this before your platform forces you to:

## Agent: Issue Creator
- Access: Linear workspace, read-only on codebase
- Can create: Bug reports, feature suggestions
- Review required: Human validates before issue enters sprint
- Accountable: PM (me) for issue quality

## Agent: Code Writer  
- Access: Specific repos only, staging environment
- Can create: PRs, branch commits
- Review required: Human code review before merge
- Accountable: Tech lead for code quality, PM for scope

Simple? Yeah. But I guarantee most teams running agents haven't done it.

The 10x Employee Governance Gap

The "10x employee" narrative is everywhere right now. One person plus AI replaces five. Solo founder to $80M exit. The numbers are impressive.

Nobody's asking the governance question though.

The 10x employee makes judgment calls at 5x the rate. Runs agent stacks that drift incrementally. Produces outputs nobody else can review because nobody else has context on what the agents actually did.

I've seen agent drift firsthand. It's not dramatic. It's a half-percent quality shift per week. The agent interprets a requirement slightly off. Over a month, those tiny drifts compound into something you wouldn't have shipped manually.

What Dies, What Survives

Dead:

Status updates (agent knows its status)
Task assignment (agent picks up work)
Progress tracking (pipeline is observable)
Manual triage (agent prioritizes on data)

Survives and gets harder:

Outcome definition
Quality gates
Accountability chains
Agent governance
Stakeholder alignment

What to Do Monday Morning

If you're a PM reading this and thinking "ok but what do I actually change" - here's the practical version:

Audit your current agent usage. Which agents create work items? Which write code? Which have production access?
Map accountability chains. For each agent, who owns the outcome of what it produces?
Build review cycles. Not for everything - for the high-risk outputs. Agent-created issues that go to sprint. Agent-written code that touches production.
Document boundaries. Which workflows stay manual? Why? Write it down before someone automates them without asking.
Set quality gates. What's the bar for agent outputs? How do you measure drift over time?

Linear's CEO just told you tracking is dead. The PM who builds agent governance this week is the PM who stays relevant next year.

What's your agent governance setup look like? Curious how other teams are handling this.

Anthropic's 3-Agent Harness Is Just a Sprint - And That's the Point

Mykola Kondratiuk — Sun, 05 Apr 2026 08:53:28 +0000

I've been mapping PM workflows to agent architectures for months. Then Anthropic went and published the diagram.

Their multi-agent harness for autonomous software engineering has three roles:

Planner → takes short prompt, outputs full spec
Generator → takes spec, builds output  
Evaluator → runs tests, scores against contracts

That's scope, execute, review. That's a sprint. They just compiled project management into agent infrastructure.

The Mapping

I sat down and compared the harness to what I do every sprint:

Harness Role	PM Equivalent	What It Does
Planner	Scoping / Requirements	Expands vague input into actionable spec
Generator	Sprint Execution	Builds the thing
Evaluator	Acceptance Criteria / QA	Tests output against contracts
Iteration Loop	Sprint Retro	Feeds results back, adjusts approach

The loop runs 5-15 iterations over 2-6 hours. Each cycle, the Evaluator scores the output and feeds results back to the Planner. The Planner adjusts the spec. The Generator tries again.

Replace "iteration" with "sprint" and "contract" with "acceptance criteria" and you have every PM's weekly cycle.

The Cost/Quality Tradeoff Is a PM Problem

Here's where it gets interesting:

Solo agent run: 20 minutes, $9
Full 3-agent harness: 6 hours, $200

40x cost difference. The question: when is it worth it?

I've been running agent pipelines where I make this call daily. Quick config change? Solo run. Feature touching three services? Full pipeline. The judgment is identical to sprint planning - which items get the full team, which get a quick fix.

# pseudo-decision tree for harness allocation
if task.complexity < THRESHOLD:
    run_solo(agent, budget=9, time="20min")
else:
    run_harness(
        planner=spec_agent,
        generator=build_agent, 
        evaluator=test_agent,
        max_iterations=15,
        budget=200,
        time_limit="6hrs"
    )

That decision tree is resource allocation. PMs do it every sprint. The currency changed from developer-hours to compute-dollars, but the judgment is the same.

What I Learned Migrating My Own Pipeline

After Anthropic changed their architecture, I had to migrate my agent pipeline to match. The Planner/Generator/Evaluator pattern actually made things clearer.

Before, I had agents with fuzzy boundaries - some planned and executed, some executed and reviewed. The separation of concerns forced better thinking about where each decision lives.

The biggest lesson: the Evaluator is not optional. I had a pipeline running without proper evaluation criteria and the output quality was inconsistent - some runs were excellent, some were garbage. Adding structured evaluation with clear contracts was the single biggest improvement. Same as adding acceptance criteria to user stories.

The FreeBSD Warning

An AI agent hacked FreeBSD in 4 hours. Autonomously. Nobody told it to.

That's a harness with no scope constraints on the Planner and no Evaluator checking outputs. The Generator just ran until it accomplished... something.

In PM terms: shipping without QA. Except in the agent world, "bugs" means "autonomous systems exceeding their mandate at machine speed."

The Evaluator role is the governance layer. If you're building agent systems without one, you're shipping without QA. It works fine until it doesn't, and when it doesn't, it fails spectacularly.

What "Harness Design" Actually Means for Builders

Mollick's 3-layer model puts the harness at the top - above the model, above the app. The harness determines what agents can actually do.

For builders and PMs working with agent systems:

Define your evaluation contracts first. Before you build, decide what "done" looks like. Specific enough that an automated system can check it.
Separate planning from execution. The Planner and Generator should have different scopes. Don't let one agent do both.
Budget your iterations. 15 iterations is Anthropic's upper bound. What's yours? Set it explicitly.
Make cost/quality tradeoffs visible. Track which tasks get the full harness vs solo runs. Build your own decision criteria.

GPT-5.4 just hit 75% on desktop task benchmarks - above human level for routine knowledge work. The question isn't "should I automate?" anymore. It's "what harness do I build?"

If you've been running sprints, you already know how. The vocabulary just changed.

What harness patterns are you seeing in your agent architectures? I'm curious how others are handling the Planner/Evaluator split.

The Layoff-Proof PM: Why Influence Without Authority Is Your Career Insurance in 2026

Mykola Kondratiuk — Wed, 01 Apr 2026 08:46:41 +0000

45,000+ tech jobs cut in Q1 2026. Andreessen on 20VC calling AI layoffs a "silver bullet excuse" for overstaffing. Cognizant's updated report: 93% of jobs are now AI-affected.

Whether you believe the macro narrative or not, the PM reading this has one real question: can your job be replaced by a good prompt?

I've been thinking about this a lot lately. Not in a "time to panic" way - more like a "let's be honest about what actually survives" way.

The skill you've had all along

Here's what I keep coming back to: project managers have never had formal authority over the people they coordinate. No direct reports. No budget control in most cases. Just influence - through clarity, alignment, trust, and knowing when to push and when to step back.

Jessica Fain called this "the one skill AI can't replace" on Lenny's Podcast this week. She wasn't talking about PMs specifically, but she might as well have been. Influence without authority is what we do.

The thing is, that skill is getting more valuable, not less. Because now you're not just influencing engineers and executives. You're also setting context for AI agents - writing the specs they execute on, evaluating whether their output is good enough to ship, making judgment calls when they hit an edge case.

The PM who can do both - align humans and orchestrate AI agents - is genuinely hard to replace.

The PMs who are at risk

Let me be direct: if your job is mostly project administration - updating Jira, running standups, compiling status reports, chasing approvals - AI already handles that. Not theoretically. Actually, today.

Stripe's engineering team ships 1,300 PRs per week triggered by Slack emojis. The value in that org isn't in the people moving tickets around. It's in the people who designed the trigger, evaluate the output, and handle the edge cases when something breaks.

Marty Cagan has been saying for years that PMs who are "project administrators" are in a fragile position. AI just made that fragile position visible faster.

What the layoff-proof PM career actually looks like

I've been rebuilding my own practice around four things:

1. Context design. Writing specs that AI agents can actually execute on. This sounds simple until you watch an agent fail because your requirements were ambiguous. The PM who writes clear, unambiguous context is worth a lot more than the one who writes beautiful documents nobody reads.

2. Evaluation practice. Knowing when AI output is good enough to ship and when it's dangerously wrong. This is the highest-leverage skill right now. Most teams don't have anyone systematically doing this.

3. Agent governance. Autonomy levels, escalation frameworks, monitoring. When does an agent need a human in the loop? What's the blast radius if it makes the wrong call? These are PM questions dressed in AI clothes.

4. Visible ROI. Don't just use AI tools. Show what changed because you orchestrate them well. "I shipped the same roadmap in half the time" is a career argument. "I use AI for PRDs" is not.

The supervisor class is forming

Fortune ran a piece this week about a new professional class forming: people whose value is orchestrating autonomous agents. This isn't 2030 science fiction - it's happening in the better engineering orgs right now.

PMs are naturally positioned for this. We already think in terms of delegation, evaluation, and escalation. We already manage across functions without direct authority. The skills transfer directly - they just need to be applied to a new kind of team member.

The title "AI-Native PM" doesn't exist yet as an industry label. But the role does. And the people building it now have a compounding advantage - Anthropic's Economic Index confirmed that 6+ months of AI orchestration experience creates a measurable productivity gap versus people just starting out.

One uncomfortable truth

If you're waiting for a clean path - a certification, a course, a new job title - you're going to wait through the part where the advantage compounds for the people who started experimenting already.

The PMs getting laid off aren't the ones running agent teams. They're the ones doing status-report theater that an AI generates in 30 seconds.

The ones staying are the ones whose value was always in the judgment, not the document.

That's been the PM superpower all along. The AI era just made it more obvious.

What's your read on this? Are you seeing this split happening in your org - between PMs who are adapting and those who aren't? Curious what the actual tipping point looks like from the inside.

I Stopped Writing PRDs. I Started Writing Prompts. Here's What Broke (and What Worked)

Mykola Kondratiuk — Sun, 29 Mar 2026 10:16:55 +0000

About six months ago I had a weird realization: the prompts I was writing for AI agents looked a lot like the PRDs I used to write for engineers. Not identical - but structurally, the job was the same. You're trying to encode intent in text so someone (or something) else can act on it without you in the room.

I started treating them the same way. It broke things. Then I fixed them. This is that story.

The experiment

I manage a team and run about a dozen AI agents in parallel - content, data analysis, competitive monitoring, etc. At some point I noticed I was spending 30-40 minutes per agent writing detailed setup docs. Background context, edge cases, behavior guidelines, failure modes.

It looked exactly like a PRD.

So I tried the obvious thing: started writing my PRDs the same way I write agent prompts. Ruthlessly specific. Present tense. Active voice. Outcomes stated, not features. No "we will investigate" - actual decisions.

The engineers actually liked it. Reviews got faster. Fewer "what does this mean?" Slack messages. One dev said it was the clearest spec he'd gotten in years.

But then I made the reverse mistake.

What broke when I went the other way

I started writing agent prompts like PRDs. Background sections. Stakeholder notes. "As a system that helps users..." framing.

The agents got worse.

Not dramatically worse - subtly worse. More hedging. More "I should clarify that..." type responses. The agents started behaving like junior PMs trying to look thorough rather than senior engineers shipping things.

Took me a few weeks to figure out what happened. PRDs are written about a system. Prompts are instructions to a system. Same words, completely different relationship.

A PRD says "the system should handle edge case X by doing Y." A prompt that works says "when X happens, do Y. if you're unsure, ask."

The framing changes how the model interprets authority. "Should" in a PRD is a requirement. "Should" in a prompt is a hedge.

The framework that clicked

I ended up with something I call spec layering. Three levels:

Level 1: Identity and authority
Who is this agent? What decisions can it make without asking? What's explicitly off-limits?

This is the hardest one to write. Most people skip it or make it vague. "Be helpful and accurate" isn't identity - it's noise. "Make engagement decisions autonomously. Escalate anything that touches pricing or partnerships" - that's authority.

Level 2: Operating procedures
The actual behavior spec. Step by step. Concrete. Written like you're explaining to a very competent new hire who doesn't yet know your specific context.

I borrowed from how we write runbooks for on-call engineers. If production breaks at 3am, the runbook can't assume the on-call has full context. It has to be self-contained.

Agent prompts are runbooks.

Level 3: Failure modes and recovery
What does the agent do when something unexpected happens? Default behavior in ambiguous situations?

This is where most agent prompts fall apart. You spec the happy path and leave edge cases to "use judgment." That's not a spec - that's hope.

Where this maps back to PM work

The thing I keep coming back to: writing a good prompt is the same skill as writing a good acceptance criterion.

Both are trying to pre-answer the question "is this done?" Both require you to be specific enough that two different people (or models) would give the same answer. Both fail the same way - too abstract, too much left to interpretation.

The difference is that with engineers you can have a conversation when the spec is unclear. With an agent you find out at runtime, usually at the worst possible moment.

So the bar is higher. You have to write the prompt as if you won't be available to answer questions. Because you won't.

What I actually changed

Practically, I now write agent prompts the way I write incident response playbooks:

Use numbered steps, not prose
State the success condition explicitly before the steps
Include a "when this breaks" section
Avoid passive voice and hedging language entirely
Never use "should" - use "do" or "don't"

For product specs I pulled the other direction - more concrete outcomes, less explanation of reasoning, explicit escalation criteria.

Both got better.

The uncomfortable implication

If writing a good prompt requires the same clarity as writing a good spec, then most product specs are not actually that good. The ambiguity we tolerate in PRDs gets papered over by smart engineers asking smart questions.

Remove the smart human intermediary and the ambiguity becomes a bug.

I think that's what a lot of the vibe coding discourse is actually about, underneath the hype. Not whether AI can write code - it clearly can. Whether the person directing it can write specs. Historically that's been optional. Increasingly it's not.

If you've tried treating prompts like specs (or vice versa) I'm curious what you found. The failure modes in particular - would love to compare notes.

I Run 10+ AI Agents Daily - Here's What Nobody Tells You About Orchestration

Mykola Kondratiuk — Sat, 28 Mar 2026 09:32:09 +0000

Somewhere around agent number seven I realized I had a management problem.

Not a technical one. The agents worked fine individually. Each one did its job - one handled social media, another monitored codebases, a third drafted content, and so on. The problem was that nobody was watching the watchers.

The meta-orchestration problem

When you run one AI agent, you manage it directly. Check its output, fix its prompts, adjust its schedule. Simple.

When you run ten, you need something to manage the managers. And that something turns out to be... mostly project management. The same boring PM skills I've been using for fifteen years.

Here's what I mean. Agent A posts a comment. Agent B is supposed to track whether anyone replies. Agent C is supposed to draft a follow-up based on the reply context. Sounds great in theory. In practice, Agent B checks notifications at 10:15 but Agent A posted at 10:14 and the reply came at 10:13. Agent C never fires because Agent B never saw the reply.

The coordination layer is harder than any individual agent.

What actually breaks

It's never the AI model. Claude is smart enough. GPT is smart enough. The failure mode is always one of three things:

State drift. Agent thinks it already did something because a tracking file got corrupted, or because a heartbeat interrupted mid-write. Now it skips the task forever. You don't notice for three days.

Context loss. Agent A has context that Agent B needs but there's no clean way to pass it. You end up with twelve JSON files that are basically a bad database, and every agent reads slightly stale data.

Timing collisions. Two agents try to update the same file within seconds of each other. One wins, one loses. The loser's work just... disappears. No error. No log. Just gone.

The PM framework I accidentally built

After enough of these failures I started treating my agent fleet like a team. Sounds obvious in retrospect but it took me a while.

Daily standups (automated). Each agent writes a heartbeat log at the end of every run. Not just "done" but what it did, what it skipped, what failed. I grep these every morning.

Sprint planning (for real). Each agent has a schedule.json that gets generated the night before. Tasks are assigned with capacity limits, jitter for timing randomization, and anti-collision spacing. Same concept as sprint planning - finite capacity, prioritized backlog, explicit assignments.

Retrospectives (weekly insights). Each agent updates an INSIGHTS.md with what worked and what didn't. I review these on Sundays. The patterns are surprisingly consistent - certain topics perform well, certain times of day are better, certain approaches keep failing.

Deduplication as a first-class concern. Every agent maintains tracking files. Before doing anything, it checks "did I already do this?" This is the single most important thing. Without it, agents spam the same action repeatedly and you get flagged or banned.

The uncomfortable realization

The agents don't need better AI. They need better project management.

Most of my debugging sessions aren't about prompt engineering or model selection. They're about figuring out why a tracking file has a stale entry, or why a schedule generator assigned 12 tasks when the daily limit is 8, or why two agents both tried to follow the same person.

It's ops work. It's coordination work. It's the same stuff PMs do when managing a team of junior developers - write clear briefs, set explicit boundaries, track who did what, and build in verification at every step.

What I'd tell someone starting this

Don't start with the orchestration framework. Start with one agent. Make it work reliably for a week. Then add a second one and immediately discover all the ways they step on each other. Fix those. Then maybe add a third.

The architecture emerges from the problems you actually hit, not from the framework you designed upfront. Every time I tried to plan the coordination layer in advance I got it wrong. Every time I just let it break and then fixed the specific failure, I ended up with something that actually worked.

Also - and this is the part that took me the longest to accept - sometimes the right answer is to just run fewer agents. Not every task needs automation. The ones that do need it tend to make that pretty obvious.

If you're running multiple AI agents and dealing with similar coordination headaches, I'd genuinely like to hear what patterns you've found. The space is moving fast and I keep learning new approaches from other builders.

I Scanned 100 AI Codebases - Here's What I Found

Mykola Kondratiuk — Thu, 19 Mar 2026 08:41:48 +0000

I've been building VibeCheck for the past few months - it's a security scanner specifically for AI-generated code. And after scanning over a hundred real codebases that people built with Cursor, Copilot, Claude, and various other AI tools, I have thoughts.

Not the "AI is dangerous" hot take. Something more specific than that.

The pattern that kept showing up

Almost every codebase had the same category of issue. Not SQL injection or XSS or anything that would show up in a classic OWASP checklist. The dominant problem was what I started calling trust misconfigurations - places where the code just... assumed everything was fine.

Open CORS policies. Service accounts with admin permissions because that was the fastest path to getting it working. API keys hardcoded in config files that weren't in .gitignore. Input that got passed straight into shell commands with no sanitization.

None of it was malicious. The AI wasn't trying to introduce vulnerabilities. It was just optimizing for "make it work" and had zero weight on "make it survivable in production."

The thing that surprised me most

I expected the biggest problems in the actual logic - like the AI misunderstanding authentication flows or getting crypto wrong. That exists too, but it's not the main thing.

The main thing is environmental. All these tiny decisions about permissions and access and trust that a senior dev would make automatically, almost subconsciously, because they've been burned before - the AI just doesn't make those decisions. It picks the path of least resistance every time.

One project had a DB connection string with full admin creds, no connection pooling limits, and a query that accepted raw user input. Technically functional. Completely fine for local dev. The kind of thing that gets quietly exploited six months after launch.

What actually helps

Scanning after the fact (what we do with VibeCheck) catches the obvious stuff. But the real fix is earlier in the loop.

The projects that had the least issues were the ones where the developer was actually paying attention during generation - not just accepting output wholesale but reading it, asking "wait, why does this need admin access?" That friction. Even a little bit of it makes a big difference.

Some people are building this into their prompts - explicitly telling the AI to follow least-privilege principles, to validate all inputs, to not hardcode credentials. Works okay. Feels like workarounds.

The better solution is probably tooling that runs in the background during vibe coding sessions and flags stuff in real time. Not a code review gate. Just... something watching.

The uncomfortable part

A lot of these codebases were shipped. Some had real users. A few were running in production environments with actual credentials and real data.

The developers weren't careless people. Most of them were genuinely excited about what they'd built - and most of what they built was genuinely cool. The security stuff just wasn't on their radar because it never came up during development. Nothing broke. Tests passed. It worked on their machine.

I keep thinking about that gap. Between "works fine in dev" and "safe to run with real users." AI coding tools are really good at closing the first gap - getting something functional fast. Nobody's really solved the second one yet.

That's the problem I'm trying to figure out. Not sure I have it yet. But the 100 codebases were pretty clarifying.

If you're using AI to build things and want to know what the scanner finds in your repo, VibeCheck is live. Free tier, no credit card. Takes about 2 minutes.

I Vibe Coded 4 Apps and Ignored Security Until It Bit Me

Mykola Kondratiuk — Wed, 18 Feb 2026 09:36:41 +0000

There's a specific moment when vibe coding goes from fun to terrifying. For me it was a Saturday afternoon, three espressos deep, shipping my fourth side project in three months. I'd been on a roll - prompting Claude, watching code appear, deploying to Vercel, feeling like a wizard.

Then I ran a basic security scan on one of my apps and the report was... not great.

The setup

Quick context: I'm a director at a gaming company by day, indie builder by night. I'd been cranking out AI-powered apps on weekends - a mood tracker, a feedback tool, a recipe thing, a growth analytics dashboard. All built mostly through prompting, minimal manual coding. Ship fast, learn fast.

The problem is "learn fast" didn't include "learn about the security holes your AI just introduced."

What I actually found

I won't pretend I did some sophisticated penetration test. I literally just ran npm audit and checked my environment variable handling. Here's what showed up across my projects:

Hardcoded API keys in client-side code. I asked the AI to add an API call and it put the key right in the React component. Not in an env file, not server-side - just sitting there in the bundle. I caught two of these. Who knows if I missed more.

No input validation anywhere. Every form in every app just trusted whatever the user typed. The AI generated clean-looking form handlers that did zero sanitization. SQL injection? XSS? Wide open. The code looked professional but it was essentially a welcome mat for anyone who wanted to mess with my database.

Dependencies with known vulnerabilities. When you prompt "add authentication" the AI picks packages. It doesn't always pick the latest or most secure ones. I had three packages with high-severity CVEs that were fixed in newer versions.

Overly permissive CORS. Every backend had Access-Control-Allow-Origin: * because that's what makes things work fast during development and the AI never suggested tightening it for production.

Why this keeps happening

I think about this a lot now. The AI isn't trying to write insecure code. It's optimizing for "working code that does what you asked." Security is almost never what you asked for.

When you prompt "build me a login page" you get a login page. You don't get rate limiting on login attempts. You don't get account lockout after failed tries. You don't get CSRF protection. You get the thing you asked for and nothing else.

And honestly? When you're vibe coding and in flow, you don't want to stop and ask "now add rate limiting, now add CSRF tokens, now add input validation to every field." That kills the vibe. That's the whole tension.

What I changed

I'm not going to pretend I figured out some perfect system. But here's what I do now:

Security prompt at the end. After the app works, I do one dedicated pass: "Review this entire codebase for security vulnerabilities. Check for hardcoded secrets, missing input validation, CORS configuration, dependency vulnerabilities, and authentication weaknesses." It's not perfect but it catches the obvious stuff.

Automated scanning in CI. I added npm audit and a basic SAST tool to my deploy pipeline. Takes five minutes to set up. Catches things I'd never think to check manually.

Env file template. I keep a .env.example in every project and I tell the AI upfront "all API keys go in environment variables, never hardcode them." Setting context early helps.

Dependency review. Before I accept whatever packages the AI suggests, I check when they were last updated and if there are known issues. This takes like 2 minutes and has saved me multiple times.

The bigger picture

I think vibe coding is genuinely amazing for shipping fast and I'm not going to stop doing it. But there's this gap between "it works" and "it's production-ready" that AI doesn't bridge on its own. The AI writes code that works. Making it secure is still on you.

The irony is that the same AI that introduced these vulnerabilities can also help fix them - you just have to ask. It's weirdly good at security reviews when you explicitly prompt for them. The problem is remembering to ask in the first place when you're riding that shipping high.

If you're vibe coding side projects and deploying them publicly, just do the security pass. Twenty minutes of review can save you from being the person who leaked their OpenAI key to GitHub or got their user database dumped because of a missing parameterized query.

Not that I'd know anything about that first one. Definitely not from personal experience. Nope.

I Built 4 Apps in 3 Months Using AI — Here’s What Actually Happened

Mykola Kondratiuk — Thu, 05 Feb 2026 13:55:19 +0000

The honest breakdown of shipping SomeYum, TellMeMo, VibeCheck, and GrowthForge as a weekend vibe coder.

Originally published on Medium

I have a full-time job. Director of Tech Program at a gaming company, 13+ years in. Meetings, roadmaps, cross-team coordination - the usual corporate chaos. I'm not a developer by trade anymore.

But on weekends, I vibe code.

Between November 2025 and February 2026, I shipped 4 apps to production. Real apps with real users. Not tutorials, not toy projects - products with landing pages, app store listings, and people actually using them.

Here's how that happened, and what I learned.

The Setup

I'd been watching the AI coding space for a while. Claude Code, Cursor, Copilot - tools that let you describe what you want and get working code back. The "vibe coding" wave, as Andrej Karpathy called it.

My background is technical - I started in support, moved through IT roles, eventually became a PM and then director. I can read code, understand architecture, and debug when things break. But I hadn't shipped personal projects in years because the time investment never made sense. Evenings and weekends aren't enough to build something meaningful.

Or at least, they weren't.

The 4 Apps

ðŸ• SomeYum - Recipe Swiper

The problem: "What should we cook tonight?" - the question that kills 30 minutes every evening.

The solution: Tinder for recipes. Swipe right on recipes you like, left on ones you don't. AI learns your taste. Now with meal planning and grocery lists.

Tech: Flutter, 10K+ recipes, AI-powered recommendations.

What surprised me: This was the most fun to build. The swipe mechanic is satisfying in a way I didn't expect. 52K+ daily swipers now, which still feels surreal.

ðŸŽ¯ TellMeMo - Meeting Intelligence

The problem: I sit in meetings all day. Someone asks a question, and instead of answering from our own docs, we say "let me get back to you" and create a follow-up. Multiply that by 8 meetings a day.

The solution: AI that sits in your meeting, listens, and automatically answers questions from your uploaded documents in real-time. Also tracks action items with owners and deadlines.

Tech: 100% open source. Self-hostable.

What surprised me: This one came directly from my day job pain. The "let me get back to you" problem is universal - every PM I talked to immediately got it.

ðŸ”’ VibeCheck - Security Scanner

The problem: We're all vibe coding now. But AI-generated code has patterns - it takes shortcuts, skips input validation, uses string concatenation for SQL queries. The code works, it just isn't safe.

The solution: Paste your GitHub repo or app URL, get a security scan focused on the specific vulnerabilities AI tends to introduce. Get fix prompts you can paste right back into Claude Code.

Tech: Static analysis + AI pattern matching for common AI code smells.

What surprised me: This one resonated with developers more than anything else I've built. Security is the elephant in the vibe coding room that nobody wants to talk about.

ðŸ“ˆ GrowthForge - Personal Development

The problem: I tried every habit tracker and goal-setting app. They're all either too simple (just checkboxes) or too complex (enterprise OKR tools). Nothing connected goals â†’ habits â†’ reflection â†’ progress in one flow.

The solution: A personal development system combining OKRs, habit tracking, journaling, AI coaching, and progress analytics. Gamified with XP and achievements because apparently I need that dopamine hit.

Tech: iOS native, AI-powered coaching.

What surprised me: Building a habit tracker while simultaneously trying to build the habit of shipping products is peak irony. But it works.

How AI Made This Possible

Let me be real: I could not have built these without AI coding tools. Not in 3 months. Not as a weekend project. Probably not at all, given my current skill set and available time.

Here's what my typical weekend coding session looks like:

Saturday morning, 7 AM. Coffee. Open Claude Code. Describe what I want to build in plain language.
Iterate. "Make the swipe animation smoother." "Add error handling for the API calls." "The grocery list should group items by store section."
Review. Read the generated code. I can't write Flutter from scratch anymore, but I can read it and spot issues.
Test. Run it, break it, describe the bug, get a fix.
Ship. By Sunday evening, there's a working feature.

The key insight: AI didn't replace my skills - it amplified them. I still need to know what to build, how to architect it, and what "good" looks like. The AI handles the syntax and implementation details I'd otherwise spend weeks relearning.

But here's the part nobody talks about enough: AI-generated code has blind spots. It writes code that works but isn't always secure. It takes convenient shortcuts. It doesn't think about edge cases the way a senior engineer would. That's literally why I built VibeCheck - I needed it for my own projects first.

What Worked

1. Scratching my own itches. Every app solves a problem I personally have. SomeYum = dinner decisions. TellMeMo = meeting overload. VibeCheck = security concerns. GrowthForge = personal growth tracking. When you're your own user, product decisions are easy.

2. Shipping ugly, then iterating. First versions were rough. SomeYum v1 was basically a recipe list with a swipe gesture bolted on. But it was live, people used it, and feedback shaped v2.

3. Not quitting my day job. This sounds counterintuitive for an indie hacker story, but my full-time role gives me perspective. I see how teams actually work, what tools they need, where the gaps are. TellMeMo exists because I sit in too many meetings. VibeCheck exists because I see AI code going to production without review.

4. Weekend-only discipline. I don't touch these projects on weekdays. No late-night coding sessions. No "just one more feature." Constraints breed creativity, and a 2-day window forces ruthless prioritization.

What Didn't Work

1. Assuming AI code is production-ready. It's not. I learned this the hard way when I ran a security scan on my own SomeYum code and found issues I'd never have caught manually. AI writes confident code - but confidence isn't correctness.

2. Trying to be on every platform simultaneously. Marketing 4 products across Twitter, Reddit, LinkedIn, Product Hunt, Hacker News, Indie Hackers, Dev.to, and Medium is... a lot. I'm still figuring out the right balance. You can't do everything, even with AI help.

3. Perfectionism on non-core features. I spent an entire weekend on GrowthForge's achievement animations. Cool? Yes. Did it move the needle? No. Should've shipped the AI coaching feature instead.

4. Underestimating the "last 20%." Getting from working prototype to polished product takes as long as building the prototype itself. App Store screenshots, landing pages, onboarding flows, privacy policies - the boring stuff is half the work.

The Numbers (Honest)

I'm not going to pretend these are rocketship metrics. This is building in public, so here's the reality:

SomeYum: 52K+ daily swipers, growing organically
TellMeMo: Open source, early users, solving a real pain point
VibeCheck: Strong developer interest, resonates with the security conversation
GrowthForge: On the App Store, growing slowly

None of these are making me rich. That's not the point (yet). The point is: a non-developer with a full-time job can ship real products in their spare time, and AI is what makes that possible.

What I'd Tell You

If you're thinking about vibe coding your own thing, here's my take:

Start with a problem you have. Not a cool technology. Not a market gap you read about. A problem that annoys you personally.
Ship the ugliest viable version first. Nobody cares about your code quality on day one. They care if it solves the problem.
Scan your AI code for security issues. Seriously. The convenience of AI coding creates a false sense of safety. The code works, but "works" and "secure" are different things.
Set time boundaries. Weekend-only saved my sanity and my relationships. Don't burn out on side projects.
Build in public. Tell people what you're doing. The feedback loop is invaluable and the accountability keeps you shipping.

Three months. Four apps. One full-time job. Zero burnout.

AI didn't make me a developer. It made me a builder again.

I'm Mykola - Director of Tech Program by day, weekend vibe coder by night. You can find me on Twitter/X where I share the building journey, or check out the products: SomeYum, TellMeMo, VibeCheck, and GrowthForge.