From writing code to designing systems
The biggest misunderstanding about AI in software development is that it's just a “smarter autocomplete”. What we've discovered is fundamentally different: AI is a full-fledged thinking partner that helps you make better architectural decisions.
Take our recent project for an intelligent document processing system. In the past, we would spend weeks writing out specifications, designing the architecture, and only then starting to build. Now we start with a simple question to our AI partner: “We want to process and classify documents automatically. What is the minimum code to prove that this is possible?”
Within 30 minutes, we had a working prototype. Not perfect, but functional enough to learn what we really needed.
Progressive specificity
Our biggest pitfall was: wanting to specify too much in advance. We initially thought we should give AI a complete specification — a 50-page document with all requirements. The result was disastrous: the generated code was technically correct but practically unusable.
What does work is what we call “Progressive Specificity”. We're starting broad and getting more specific:
Week 1: “Build a system that can extract data from websites”
Week 2: “The system must also be able to handle JavaScript-rendered pages”
Week 3: “Add intelligent rate-limiting that learns from response patterns”
Week 4: “Deploy a cache layer that recognizes semantically similar queries”
Each iteration builds on real problems we encounter, not theoretical edge cases. The system evolves organically towards what is needed.
Structured prompt patterns
One of our most important breakthroughs was developing reusable “prompt patterns” — structured ways to give AI commands. This isn't rocket science, but the difference between hobby crafting and building professional systems.
A simple example: instead of “create a function that processes HTML”, we now use:
Deploy an HTML processing feature with:
— Input: raw HTML as string
— Output: clean text or None in case of failure
— Error handling: log alerts but never crash
— Performance: must be able to handle 1000 pages per minute
— Tests: [concrete examples of input and expected output]
The difference? The AI can't get “creative” in ways that break your system. Each constraint is testable and verifiable.
The hallucination problem: trust but verify
AI models sometimes invent things. They generate code that looks perfect but is subtly wrong. A classic example: we asked for code for asynchronous web requests, and the AI generated code that looked asynchronous but actually executed everything sequentially.
Our solution is threefold:
- Competitive Validation: We're letting AI solve the same problem in two different ways. If the solutions are fundamentally different, we know that something is wrong.
- Reality Checkpoints: Throughout the code, we place simple checks. For example, assert len (urls) < 10000, “Unrealistic amount of URLs”. If the AI is completely lost, these checks catch that.
- Semantic Barriers: We use type hints not only for documentation, but as semantic boundaries. A validatedURL type can't just be any string — the AI must respect validation.
From prototype to production: The evolutionary architecture approach
The biggest difference between a demo and a production system? Evolution versus planning.
We started with a web scraper that could only extract headlines. Simple, but it worked. That's when we added support for various websites. Then Javascript rendering. Then intelligent content detection. Each step was a working system, each step taught us something new.
After two months of “evolution”, our system had capabilities that we could never have planned:
- It automatically recognizes whether a website is a news, e-commerce, or documentation site
- It is adapting its extraction strategy based on previous successes with similar sites
- It learns from mistakes and literally gets better with each use
We could never have specified this in a traditional development process. The system developed these capabilities through thousands of real-world interactions.
Practice: Concrete results
What does this mean for our customers in concrete terms?
Development speed: We now deliver a system that would traditionally take 6 months in 6 weeks. Not because we work harder, but because we build smarter.
Quality: Counterintuitive maybe, but our AI-first systems have fewer bugs. Why? Because we work with working software from day one and continuously test against real data.
Adaptability: Changes that used to take weeks are now implemented in hours. The AI understands the context and can make surgically precise adjustments.
Scalability: Because we work with production data from the start, we discover scalability issues right away, not just at the go-live.
The new role of developers: From coders to conductors
The most radical lesson? The best “AI developers” aren't necessarily the best programmers. They are the people who can most clearly describe what they want to build.
We have team members who cannot write a sorting algorithm but who build complete systems. How? They have a crystal clear idea of what the system should do, and they can articulate that to AI.
This is not a degradation of the profession — it is evolution. Just as we went from assembly to high-level languages, we're now moving from syntax to intent. The computer finally understands what we mean, not just what we type.
What this means for your organization
The implications for enterprise IT are huge:
- Time to market: Competitive advantage no longer comes from who has the most developers, but from who can iterate and learn the fastest.
- Innovation capacity: Ideas that used to be too expensive to try can now be tested over the weekend.
- Technical debt: Instead of dragging legacy systems around for years, we can rebuild them in weeks — better, faster, more maintainable.
- Talent: The bottleneck is no longer technical knowledge but domain knowledge. Your best business analysts can now build what they come up with right away.
The future is now
We are at the beginning of a fundamental shift in how software is created. The question is not whether you will use AI, but when.Our experience shows: organizations that are now starting AI-first development will have an unbeatable advantage in a year. Not because the technology is better then (although that is), but because they have learned to operate in this new reality.
The question is not whether AI will replace developers. The question is whether developers who don't use AI still remain relevant.
Do you want to know how to start AI-first development yourself?
Our tips:
- Start small: Choose one internal problem that has been annoying for years but was never given priority. Build a solution for that with AI in a week.
- Experiment without shame: Initial versions will be messy. That's ok. Perfection is the enemy of progress.
- Measure everything: How long did it take? How many iterations were required? What did or didn't work? This data is worth its weight in gold for optimization.
- Invest in prompt engineering training: This is the new core competency. Whoever is best at communicating with AI wins.
Inside us white paper you'll read about the framework we used to make Blis Digital AI-first and what we're currently using to make our customers AI-first.
