BlackProject.ai - Insights #AI Tools

I Wrote Over 1 Million Lines of Code Last Year—And I'm Not a Software Developer

Thu, 15 Jan 2026 21:06:06 +0000

Let me be clear upfront: I'm not a software developer. Never have been. My background is 28 years in enterprise software—20 years in product management and consulting. I served 1000+ companies and over 3,000+ customers at TekDog helping them optimize operations with SharePoint and Nintex. I understand business problems, workflows, what enterprises need. But writing code? That was always someone else's job. Until 2025, when I spent a year doing R&D on AI-assisted development tools so you don't have to.

How It Started

In 2024, I was working a corporate Product Owner role, dabbling with AI like everyone else—ChatGPT for emails, documentation, brainstorming. Nothing crazy. Productivity helper stuff. Then I discovered N8N and started experimenting with workflow automation using AI. Interesting. Then in December 2024, someone showed me Lovable—an AI-assisted development platform that could generate entire applications from prompts. I tried it. Impressive. Buggy, but impressive. Still felt like a toy. I put it aside and went back to my day job.

Then March 2025 happened. That's when my evenings and weekends became a one-person R&D lab.

The Moment Everything Changed

I gave Lovable another shot in March. The platform had improved dramatically in just three months. What I saw didn't feel like a toy anymore. It felt like something that could fundamentally change how software gets built. As a product leader with two decades of experience, I knew I needed to understand this technology deeply—not just play with it casually. So I started serious R&D. Nights. Weekends. Building prototypes. Internal workflow tools. Data management applications. Approval systems. Things that would help me understand the real capabilities and limitations.

I showed early prototypes to colleagues. They were skeptical.

"AI generates slop."

"It's not production-ready."
"You'll spend more time fixing bugs than if you'd just built it properly."

I heard all the objections. Meanwhile, I kept researching. More prototypes. More experiments. Each one helping me understand what had actually changed and what was still hype. Then other tools started emerging: Claude Code, Replit Agent, Bolt, Cursor, Windsurf. I tried many. I needed to understand what each was good at, where it would fail, and how to work around limitations.

Here's what I discovered: when you understand the technology—what it's good at, what it isn't, and how to work within its constraints—you can turn ideas into working applications in hours instead of months.

But more importantly, I learned that emerging technologies without standards require falling back on industry best practices and adapting them for the new paradigm.

Why Best Practices Matter More Than Ever

Here's what many people get wrong about AI-assisted development: they think AI eliminates the need for proper software development practices.

Requirements gathering? Gone.

User stories? Obsolete.

Personas? Unnecessary.

Architecture design? Let the AI figure it out.

That's completely backwards.

Emerging technologies have no standards yet. No established patterns. No proven methodologies. No guardrails. That's exactly when you need to fall back on industry best practices. User stories and personas are more important now than ever. They provide the context AI needs to generate relevant, useful code. A well-written user story tells AI exactly what behavior to implement and why. A detailed persona helps AI understand edge cases and UX considerations. Good requirements give AI the constraints and business rules it needs to generate production-ready code instead of generic CRUD.

AI-assisted development isn't about throwing away 20 years of software development best practices. It's about using those best practices to provide the structured context that makes AI incredibly effective.

Discovery still matters. Design still matters. Architecture still matters. Requirements still matter.

What changes is the implementation speed once you've done that foundational work properly.

The CivicXpress Comparison That Made Everything Click

At TekDog, my last major product was CivicXpress—a municipal permitting and inspections platform. Two development teams working around the clock. Eight months of development. Significant investment. Endless meetings about requirements, architecture, design, testing. During my R&D phase, I prototyped workflow modules similar to what we'd built in CivicXpress. Simple approval routing. Form submission. Status tracking. Basic reporting.

What took those teams 8+ months to design, implement, test, and deploy, I could prototype in a weekend.

Not production-ready. Not fully tested. But working well enough to validate concepts and gather feedback. The math was staggering. Not because AI replaced good development practices—but because it accelerated the implementation phase after proper planning and design. The requirements gathering still took time. The architecture design still required thought. The data modeling still needed careful consideration. But once those artifacts existed? The code generation happened at a pace that would have seemed impossible a year earlier. That's when I realized this wasn't just interesting technology.

This was something that would fundamentally change the economics of custom software development.

What Actually Makes This Work

Here's what my year of R&D taught me: AI-assisted development isn't about typing "build me an app" and getting production software. That doesn't work. That will never work.

The key is this: you still need to know what you want to build and how it should be built.

AI doesn't replace thinking. It doesn't replace architecture. It doesn't replace requirements gathering or design. What it replaces is the repetitive, pattern-based implementation work that developers have been doing manually for decades. CRUD operations follow patterns. API endpoints follow patterns. Form validation follows patterns. State management follows patterns. Database schemas follow patterns. UI components follow patterns. Give AI proper direction, break work into focused tasks, provide clear context—and yes, AI can do remarkable things.

But the difference between slop and production-ready software is understanding those patterns yourself.

I spent 28 years in enterprise software. I know what good architecture looks like. I know what data models need to support complex business processes. I know what security and compliance require. I know what makes software maintainable. When I work with AI tools, I'm not asking them to figure out the architecture. I'm providing architecture and asking them to implement following enterprise patterns. I'm not asking them to design the database. I'm giving detailed requirements about entities, relationships, constraints. I'm not asking them to guess at business logic. I'm describing workflows, edge cases, validation rules.

That's the difference. Understanding what you're building. Providing context. Breaking complex problems into focused tasks. Reviewing output critically. Testing thoroughly. All the same practices we've used for decades—just applied to a new set of tools.

The Tools I Evaluated

Since March 2025, I've done extensive R&D with Lovable, Encore/Leap, Bolt, Replit Agent, and Antigravity.

Each has strengths:

Lovable: Rapid prototyping and full-stack applications... I built so many applications... an ungodly amount!
Encore/Leap: Iterative development, enterprise architecture, scalability
Bolt: Quick frontend components and UI iteration.. kind of like Lovable's little brother... step brother....
Antigravity: Complex business logic and architectural, full stack applications.. The FUTURE is GOOGLE
Replit Agent: Deployment and infrastructure.. rock solid clean applications, great experience.
N8N: Agent Development and AI workflows. Pretty cool stuff for executing automations.

I don't rely on just one. I use whatever tool is best for the specific task. The tools are getting better every month. What was impossible in December 2024 was routine by March 2025. Love a tool today only to fall in love with another tomorrow... it's an addiction!

Critical insight: These tools don't replace developers. They make everyone who understands software problems exponentially more productive. A developer using these tools can do in a day what used to take a week. A product manager who understands architecture can build prototypes that used to require entire teams.

But only if they're using industry best practices to provide proper context and structure.

What I Actually Built

Over the past year of R&D: Aria (voice-first workflow automation), AriaERP experiments, internal tooling for requirements gathering, architecture design, database modeling, and countless workflow modules, prototypes, and learning projects. How many lines of code across all these research projects? According to Lovable, over one million lines. Most AI-generated. All reviewed and tested by me to understand what works and what doesn't. Is all that code in production? No—it's research. It's learning. It's prototyping.

I spent a year experimenting so I could understand this technology deeply enough to help others use it effectively.

And critically: the prototypes that did work demonstrated that AI-assisted development can produce production-grade code with proper architecture, security, and quality standards. When you know what enterprise software requires and you ensure the AI-generated code meets those standards, the results are remarkable.

When you don't, you get slop. My R&D proved which approach works.

From Corporate to Full-Time BlackProject

On January 8, 2026, my corporate role ended. I could have looked for another Product Owner position. Instead, I took everything I'd learned from a year of intensive R&D and went all-in on BlackProject. The day after I got laid off, I started building FeatureFlow—not prototypes, but the actual go-to-market product. An AI-assisted product development platform that guides teams through complete SDLC workflows. By the end of January 2026, I had something real. I had 15 years of enterprise relationships from TekDog. I had the credibility of serving 3,000+ customers. I had real prototypes, real learnings, and real conviction from spending hundreds of hours researching these tools.

Current state: We're accepting beta customer applications through February 2026. Beta program runs March-May. Market launch in June 2026.

So I went all-in. Full-time. Teaching other teams how to leverage these tools effectively while maintaining enterprise standards.

What This Means for You

If you're a CTO, VP Engineering, or Product Manager thinking "this sounds too good to be true," I understand. I was skeptical too. But I've spent a year researching these tools so you don't have to. The productivity gains are real. The cost savings are real. The speed is real.

What's not real is the hype that AI will replace developers or magically generate perfect production software with zero human involvement.

AI-assisted development is exactly what it sounds like: AI assists skilled people in building software faster. If you're skilled—if you understand architecture, data modeling, business logic, security, and quality—you can prototype and validate ideas now that would have required teams and months a year ago. If you're not skilled, AI won't magically make you skilled. It will just help you build slop faster.

The companies that figure this out now will have a massive competitive advantage.

They'll build custom software in weeks instead of months. They'll pay $50K instead of $500K. They'll iterate based on user feedback instead of being locked into year-long development cycles. They'll own their code, control their roadmap, and move at startup speed with enterprise resources. The companies that wait, that dismiss this as hype, that keep doing software development the old way? They'll be competing against teams moving 10x faster at a fraction of the cost.

That's not a winning position.

One Million Lines of R&D

I wrote over one million lines of code last year for research and development purposes. I'll write millions more this year as we build FeatureFlow and help clients leverage AI-assisted development.

And I'm still not a software developer.

I'm a product leader with 28 years of enterprise software experience who spent a year researching how to apply industry best practices to a completely new technology paradigm.

That's the future.

Not AI replacing developers or eliminating software development processes. AI empowering people who understand problems and processes to validate solutions faster. When combined with proper architecture, enterprise quality standards, and production-ready practices, the results are transformative.

The world changed in 2025. Most people just haven't realized it yet. But they will.

Think This Sounds Too Good to Be True? Let Us Prove It.

Here's my offer: Let's talk about ideas for solutions or products for your business. Give me 1 week to do discovery and research with your team, and 1 week to build. I will deliver a fully documented application with source code that your team can deploy to whatever infrastructure you prefer. Not a prototype. Not a concept. A working application with:

Complete documentation
Source code you own
Architecture your team can maintain
Deployment flexibility

This shit is real.

Want to learn how to leverage AI-assisted development for your team while maintaining enterprise standards? Want to build custom software 10x faster without sacrificing quality?

Let's talk. Because I spent a year doing the research. Now I can help you apply what I learned.

Let's Talk!

Stop Blaming AI for Your Terrible Prompts: Why Context Matters

Tue, 13 Jan 2026 23:21:45 +0000

I'm working on a tree right now.

What image just popped into your head? George Washington with an axe? A lumberjack with a chainsaw? Me sitting in a literal tree with my laptop balanced on a branch like some productivity-obsessed squirrel? The reality: I'm sitting at a wood desk in my home office. Made from a tree. Working on my laptop. Totally normal.

The problem: I gave you zero context, and your brain filled in the gaps with whatever made sense based on limited information.

That's not your fault—that's how brains work when context is missing.

Now apply this exact same principle to AI development, and suddenly you'll understand why so many people claim "AI creates slop."

The "AI Creates Slop" Crowd

I see this complaint constantly. Developers, CTOs, tech Twitter personalities—all declaring that AI-generated code is garbage. Slop. Unusable.

And you know what? Sometimes they're right. The code IS garbage.

But here's what nobody wants to admit: the problem isn't the AI. The problem is you gave it a one-sentence prompt and expected an enterprise application.

Let me ask you this: would you build a normal application with a one-sentence stakeholder meeting? "Hey, build me a CRM." Then walk away, come back six months later, and expect a production-ready system that perfectly matches unstated requirements and unexpressed business rules?

Of course not. That would be insane.

You'd have discovery meetings. Requirements sessions. Architecture reviews. Design approvals. Stakeholder feedback loops. You'd ask hundreds of questions to understand context—what data do you track, who are the users, what workflows matter, what integrations exist, what reports do you need, what's the security model? But for some reason, people think you can skip all that with AI. They type "build me a CRM" into ChatGPT, get back generic CRUD operations with a basic UI, and declare "AI creates slop."

No. You created slop. The AI just did exactly what you asked it to do with the context you provided—which was almost none.

What Good Context Actually Looks Like

When I use AI development tools, I don't throw prompts at them and hope for the best. I provide context. Lots of it.

Here's what I might include when asking AI to generate a database schema for an inventory management system:

"I need a PostgreSQL database schema for a multi-warehouse inventory management system. We track physical products (not services or digital goods). Each product has multiple SKUs for size/color variations. We have 12 warehouses across North America. We need to track inventory levels per warehouse per SKU. We have three types of inventory movements: receiving from suppliers, transfers between warehouses, and fulfillment for customer orders. Each movement needs full audit trail with timestamp, user, reason, and quantity. We need to support cycle counting where warehouse staff verify physical inventory matches system records. We need to calculate reorder points based on lead time and sales velocity. We're subject to lot tracking requirements for some product categories due to FDA regulations."

That's not a one-sentence prompt. That's context.

Now the AI knows:

Database type (PostgreSQL, not MySQL or MongoDB)
Business domain (physical inventory, not services)
Key entities (products, SKUs, warehouses, movements)
Important relationships (products have SKUs, SKUs have inventory per warehouse)
Critical workflows (receiving, transfers, fulfillment, cycle counting)
Data requirements (audit trails, lot tracking)
Compliance constraints (FDA lot tracking)

With that context, the AI generates a schema that actually makes sense. Proper normalization. Appropriate indexes. Audit columns. Lot tracking tables. Relationships modeled correctly. Without that context? You get generic products and inventory_levels tables that don't account for multi-warehouse operations, don't support lot tracking, don't have audit trails, and don't calculate reorder points. And then someone looks at it and says "AI creates slop."

No, you created slop by providing slop-level context.

Enterprise Applications Need Enterprise Context

The same people who demand detailed specifications and comprehensive requirements for traditional development will throw a vague prompt at AI and blame the tool when it doesn't read their mind.

If you're building an enterprise application, you need enterprise-level context:

Business context: Industry? Regulations? Compliance requirements? Business model? Users? Problems being solved?

Technical context: Tech stack? Databases and frameworks? Infrastructure? Performance requirements? Security model?

Integration context: Systems to integrate? APIs? Data flows? Authentication approach?

Workflow context: User workflows? Approvals required? Notifications? Reports? Data lifecycle?

Scale context: How many users? How much data? Growth trajectory? Performance expectations? Uptime requirements?

You wouldn't skip this in traditional development. Don't skip it with AI-assisted development.

"But I Shouldn't Have To Provide All That Context!"

I hear this objection sometimes. "The AI should be smart enough to figure it out!" or "If I have to provide all that detail, what's the point of using AI?"

Let me be direct: this is an entitled and frankly lazy perspective.

Yes, AI is impressive. Yes, it can do amazing things. But it's not telepathic. It can't read your mind. It can't access your internal business requirements. It can't interview your stakeholders.

The point of AI-assisted development isn't to eliminate thinking. It's to eliminate repetitive implementation work AFTER you've done the thinking.

You still need to:

Think through requirements
Understand your business domain
Make architectural decisions
Model your data properly

But once you've provided that context, the AI can generate the database schema, write the CRUD operations, scaffold the API, build the UI components, create the tests, and write the documentation in minutes instead of days or weeks.

That's the productivity gain. Not skipping the thinking. Accelerating the implementation after you've done the thinking.

If you want to skip the thinking, you're not doing software development. You're playing with toys.

And yes, toys created without proper context are slop.

How to Actually Use AI Development Tools

AI-assisted development uses the same processes and artifacts we've been using for 20+ years. We just go way faster.

We still do:

Discovery and requirements documentation
Persona definition
User story breakdown
Architecture design
Database modeling
Deployment planning

All of those artifacts provide AI tools the same context you'd provide human developers.

When I feed a prompt to Claude or Cursor, it's not "build me a CRM." It's a detailed prompt based on documented requirements, defined personas, mapped workflows, and designed data models.

AI is the worker. You still need project management. You still need someone making decisions about what gets built and why.

The AI doesn't replace thinking. It replaces typing.
It doesn't replace planning. It replaces implementation time.
It doesn't replace requirements gathering. It replaces the weeks of coding after requirements are clear.

If you hired a construction crew with power tools, you wouldn't skip the blueprints and just say "build me a house." You'd have architectural drawings. Engineering specifications. Material requirements. Building code compliance docs.

Power tools make construction faster—they don't eliminate the need for proper planning.

Same thing with AI development tools.

The FeatureFlow Solution

This is exactly why we built FeatureFlow the way we did. We don't let you just throw prompts at AI and hope.

We guide you through a structured process that builds context systematically:

Voice-driven ideation that asks clarifying questions one at a time
Discovery phase that captures business context
Validation phase that confirms market context
Product design phase that documents workflow context
Architecture phase that establishes technical context
Database phase that models data context

By the time we generate code, the AI has so much context that it produces production-ready results. Not generic CRUD. Not toy examples. Actual enterprise-grade code that reflects real business rules, real workflows, real data relationships.

We're not skipping project management because we have AI. We're doing project management faster and then using AI to accelerate implementation.

That's the difference between building real software and creating slop.

When AI Actually Does Create Suboptimal Code

To be fair, sometimes AI generates suboptimal code even with good context:

The AI doesn't know your highly specialized domain deeply enough
The AI makes assumptions that don't match your constraints (REST vs GraphQL, MongoDB vs PostgreSQL)
The AI optimizes for the wrong thing (readable vs performant, simple vs extensible)
You're using the wrong AI tool for the task

But here's the key: when these things happen, it's usually because context was still incomplete or the tool was mismatched.

When I see suboptimal output, I ask:

What context was missing?
What assumptions did it make that I should have specified?
What constraints did I fail to communicate?
What domain knowledge did it lack?

Nine times out of ten, the problem traces back to incomplete context.

The Real Problem: Laziness Masquerading as Skepticism

Here's what's really happening: a lot of developers don't want to do the hard work of providing context. They want to type "build me X" and get production-ready code. They want AI to read their mind. They want to skip requirements gathering, architecture design, and thoughtful planning. They want magic. And when they don't get magic, they blame the AI instead of admitting they cut corners.

"I tried AI and it didn't work" really means "I tried AI without providing proper context and got predictably poor results."

The developers who are successful with AI-assisted development? They're doing the hard work of providing context. They're writing detailed prompts. They're breaking down complex problems. They're reviewing and refining generated code. They're treating AI as a powerful tool that needs proper input, not as magic that requires no effort. There's no shortcut. Good software requires good requirements, good architecture, good design, and good implementation.

AI can massively accelerate implementation. It cannot replace thinking.

Stop Blaming the Tool

"I'm working on a tree" means nothing without context. It could mean anything. "Build me an application" means nothing without context. It could mean anything. Context is how we communicate. Context is how we build understanding. Context is how we deliver results.

AI doesn't eliminate the need for context—it makes it more important because the feedback loop is so much faster. Bad context with human developers? You might not find out for weeks. Bad context with AI? You know in minutes. That's actually a feature, not a bug. It forces you to be clearer, more specific, more thoughtful. So the next time you see someone complaining that "AI creates slop," ask them: what context did you provide? How specific were your requirements? How clear were your constraints? Because I guarantee you, if the output is slop, the input was slop.

Context matters. Provide it properly, and AI is incredibly powerful. Skip it, and you get exactly what you deserve—garbage in, garbage out.

Stop blaming AI for your terrible prompts. Start providing better context.

Schedule a Consultation