DEV Community: Júlio César Ködel

AI Didn't Kill Software Engineering. It Made It More Valuable Than Ever.

Júlio César Ködel — Tue, 21 Jul 2026 21:50:29 +0000

We've Been Asking the Wrong Question

For years the industry asked:

"Will AI replace software developers?"

Now we know that isn't the right question.

The better question is:

What becomes valuable when writing code is no longer expensive?

That single shift changes software engineering.

For decades every major methodology---from Waterfall to Agile, DDD and
Clean Architecture---evolved in a world where writing software was
expensive. Documentation aged quickly because updating it was costly.
Specifications were abandoned because implementation consumed weeks.

Generative AI changed that assumption.

Writing code is now almost free.

Value moved elsewhere.

Code Is Cheap. Judgment Isn't.

Modern LLMs generate hundreds of lines of code in seconds.

They do not decide:

what should be built;
which business rules matter;
which edge cases deserve attention;
what architectural trade-offs should survive for years.

Those remain engineering decisions.

The Bottleneck Has Moved

Typing is no longer the bottleneck.

Thinking is.

Specifications.

Architecture.

Acceptance criteria.

Code review.

Engineering has become less about producing code and more about
producing clarity.

Why Vibe Coding Doesn't Scale

Chats are a poor long-term source of truth.

Every prompt expands the context window.

Every correction burns more tokens.

Eventually the model reasons about the conversation rather than the
software.

That is the hidden cost of vibe coding.

Specifications Become the Project Memory

That realization led me to write Spec Driven Development.

Instead of relying on conversations, every feature starts with a
specification, evolves into a plan, becomes executable tasks and only
then turns into code.

The outcome is straightforward:

fewer ambiguities;
fewer tokens;
less rework;
more predictable software.

https://books.kodel.com.br/en/books/sdd/

But Specifications Need Architecture

Great specifications cannot rescue a chaotic codebase.

Architecture exists to answer one question:

Where does this belong?

That question inspired FOCUS Architecture.

Rather than multiplying layers, it organizes software around four
responsibilities:

View
Orchestrator
Use Cases
Repository

Its purpose isn't novelty.

Its purpose is lowering the cost of change.

In the AI era that also means smaller context windows, fewer tokens and
fewer unintended modifications.

https://books.kodel.com.br/en/books/focus/

Standing on Giants

Neither book claims to reinvent software engineering.

Both synthesize decades of work from Martin Fowler, Kent Beck, Eric
Evans, Bertrand Meyer, Robert C. Martin, Andrew Hunt, David Thomas and
many others, reinterpreting timeless ideas for AI-assisted development.

Two Books. One Goal.

Spec Driven Development structures engineering thinking.

FOCUS Architecture structures engineering systems.

One answers what should be built.

The other answers where it belongs.

Together they help human engineers and AI agents build software that
remains understandable years after it ships.

Final Thoughts

AI made code inexpensive.

Engineering became even more valuable.

The future won't belong to teams with the best AI.

It will belong to teams with the best engineering discipline.

A IA não matou a Engenharia de Software. Ela a tornou mais importante do que nunca.

Júlio César Ködel — Tue, 21 Jul 2026 21:50:03 +0000

Durante anos fizemos a pergunta errada

"Será que a IA vai substituir os desenvolvedores?"

Hoje sabemos que essa não era a pergunta correta.

A pergunta correta é:

O que passa a ter valor quando escrever código deixa de ser caro?

Isso muda completamente a engenharia de software.

Por décadas, metodologias como Waterfall, Scrum, XP, DDD e Clean
Architecture nasceram em um mundo onde escrever código era caro.
Documentação envelhecia rapidamente porque reescrevê-la custava caro.
Especificações eram abandonadas porque implementar consumia semanas.

Então surgiu a IA.

Pela primeira vez na história, produzir código ficou quase gratuito.

O valor migrou.

Código ficou barato. Julgamento não.

Hoje qualquer LLM produz centenas de linhas de código em segundos.

Mas ela não decide:

qual problema resolver;
quais regras de negócio existem;
quais exceções importam;
quais compromissos arquiteturais devem permanecer pelos próximos cinco anos.

Essas continuam sendo responsabilidades humanas.

O gargalo mudou

Antes, escrevíamos código.

Agora escrevemos decisões.

Especificações.

Arquiteturas.

Critérios de aceitação.

Revisões.

A vantagem competitiva deixou de ser velocidade de digitação.

Passou a ser clareza de pensamento.

Por que o vibe coding não escala

Conversas são uma péssima fonte de verdade.

Cada prompt aumenta o contexto.

Cada correção adiciona mais tokens.

Cada interação obriga a IA a reconstruir sua intenção.

Em algum momento ela deixa de raciocinar sobre o sistema e passa a
raciocinar sobre a conversa.

Esse é o verdadeiro custo escondido do vibe coding.

Especificações passam a ser o centro do projeto

Foi essa percepção que originou o Spec Driven Development.

A ideia é simples:

A conversa deixa de ser a memória do projeto.

A especificação passa a ser.

Cada funcionalidade nasce de uma spec, evolui para um plano,
transforma-se em tarefas e somente depois é implementada.

O resultado é previsibilidade.

Menos retrabalho.

Menos tokens.

Menos ambiguidades.

https://books.kodel.com.br/pt-br/livros/sdd/

Mas especificação não resolve arquitetura

Mesmo boas especificações falham quando o projeto é caótico.

Arquitetura existe para responder apenas uma pergunta:

Onde isso pertence?

Essa pergunta originou o segundo livro: FOCUS Architecture.

Em vez de dezenas de camadas, a proposta reduz responsabilidades para
quatro peças bem definidas:

View
Orchestrator
Use Cases
Repository

O objetivo nunca foi criar uma arquitetura nova.

Foi reduzir custo de mudança.

Na era da IA isso significa também reduzir contexto, consumo de tokens e
risco de alterações inesperadas.

https://books.kodel.com.br/pt-br/livros/focus/

Sobre os ombros de gigantes

Esses livros não reinventam a engenharia.

Eles sintetizam décadas de ideias de Martin Fowler, Kent Beck, Eric
Evans, Bertrand Meyer, Robert C. Martin, Andrew Hunt, David Thomas e
muitos outros, reinterpretadas para uma realidade em que agentes de IA
escrevem boa parte do código.

Dois livros. Um objetivo.

Spec Driven Development organiza o pensamento.

FOCUS Architecture organiza o código.

Um responde o que construir.

O outro responde onde construir.

Juntos ajudam equipes humanas e agentes de IA a produzir software
previsível, legível e sustentável.

Considerações finais

A IA tornou código barato.

Mas tornou engenharia ainda mais valiosa.

O futuro não pertence às equipes que possuem a melhor IA.

Pertence às equipes que pensam melhor.

streamline 1.0.0

Júlio César Ködel — Fri, 17 Jan 2025 21:03:29 +0000

https://pub.dev/packages/streamline

Streamline

CQRS/Mediator Pattern for Flutter - The Simple Way! 🚀

Streamline is a lightweight library that brings enterprise-grade application architecture to Flutter, making it super easy to understand and implement - even if you're new to professional software development!

What's This All About? 🤔

Think of Streamline as a smart messenger for your app. Instead of components talking directly to each other (which can get messy), they send messages through a central hub. It's like having a super-organized assistant managing all communication in your app!

Core Concepts Made Simple 📚

Commands & Queries

Commands: Actions that change things (like "CreateUser" or "UpdateProfile")
Queries: Questions that just get information (like "GetUserProfile" or "GetTodoList")

Events

Think of these as announcements about things that happened
Example: "UserSignedIn", "ProfileUpdated", "TodoCreated"
Great for updating different parts of your app when something important happens

Aggregators

Special queries that collect information from multiple sources
Perfect for features like calendars where you need to gather events from different parts of your app. "GetAllCalendarEvents" might collect meetings, tasks, and reminders to show them all on one calendar UI.

Flutter Widgets That Make Life Easier 🎯

QueryBuilder

// Simple usage
QueryBuilder<UserProfile>(
  query: GetUserProfileQuery(),
  builder: (context, profile) => Text(profile.name),
)

// With event observers to auto-refresh
QueryBuilder<UserProfile>(
  query: GetUserProfileQuery(),
  builder: (context, profile) => Text(profile.name),
  eventObservers: [
    // Refresh when user updates their profile
    Mediator.events.getStream<UserProfileUpdated>(),
    // Also refresh when user changes their settings
    Mediator.events.getStream<UserSettingsChanged>(),
  ],
  // Optional loading widget
  waiterBuilder: (context) => CircularProgressIndicator(),
  // Optional error handler
  errorBuilder: (context, error, stackTrace) => Text('Oops! $error'),
)

Why Should You Use Streamline? ✨

Keep Things Organized: Each piece of your app has a clear job

Easy to Test: Commands and queries are isolated and simple to test

Flexible: Need to add new features? Just add new commands/queries!

Flutter-Friendly: Built specifically for Flutter developers

Beginner-Friendly: No PhD in software architecture required!

Getting Started 🚀

Add to your pubspec.yaml:

dependencies:
  streamline: ^1.0.0

Import and start using:

import 'package:streamline/streamline.dart';

Examples 📱

Check the examples folder for a ToDo list app using this architecture!

Dependencies 📦

dart_mappable Dart Mappable is a very good library that implements value equality, copyWith, pretty toString and JSON serialization for your models and messages.

⚠️⚠️⚠️ IMPORTANT: ⚠️⚠️⚠️: All your commands, queries, events and aggregators must use dart_mappable (we are requesting an specific interface (IAction<TResult>, with toJson and toMap methods) for you to remember this). This is important to avoid unnecessary rebuilds both in events and queries.

rxdart RxDart is a reactive programming library for Dart and Flutter. We use the Behavior Subject stream implementation to keep track of the last emitted event, so you don't need to store the last state.

Need Help? 🆘

Issue Tracker

Contributing 🤝

We love contributions! Whether it's:

Reporting bugs
Improving documentation
Adding new features
Fixing bugs

Feel free to open an issue or submit a pull request!

License

This package is licensed under the GNU AGPL v3 license.

Important licensing notes:

👉 You can freely use this package in your applications (commercial or non-commercial) without having to license your entire application under AGPL 👈
The AGPL license only applies if you modify THIS package's source code
If you modify this package's source code and distribute it (either directly or as part of a network service), you must make your modifications available under AGPL v3