On August 28, JetRuby hosted JetConf 2026, our internal conference where teams share practical engineering ideas, experiments, and lessons learned from real projects.
This year, AI was everywhere – but the most interesting part was not the models themselves. The talks showed something much bigger: AI is becoming part of the infrastructure around software development.
From turning company processes into code to migrating 20-year-old Java applications, from generating mobile interfaces from Figma to building an AI-powered code reviewer and automating QA, the same idea kept coming back:
AI works best when it is given context, explicit rules, reliable data, and clear boundaries.
Here are some of the ideas that stood out at JetConf 2026.
From CompanyOS to AI-ready processes
JetRuby’s Founder & CEO — Ivan Linko — opened the conference with “CompanyOS: Company as a Codebase” – a vision for treating the company itself more like a software system.
The starting point is simple:
Infrastructure as Code → Company as Code.
Instead of keeping strategy, policies, processes, decisions, and operational knowledge scattered across documents and people’s heads, JetRuby is experimenting with putting this knowledge into structured, version-controlled repositories.
The idea is to build CompanyOS in several stages: first codify the operating model, then connect it to real company data such as meetings and metrics, and eventually increase the amount of work that can be delegated to AI.
This approach rests on an important cultural shift. If company knowledge lives in a repository, employees can inspect it, spot problems, create issues, and propose improvements—much like contributing to an open-source project.
The goal isn’t to replace people with automation. It is to make the company’s accumulated knowledge visible, structured, and usable by both people and AI.
When Marketing Starts Working Like Engineering
Our CMO presented “Agentic Marketing Development Life Cycle” — a case about what happens when a non-engineering team starts applying engineering principles to marketing.
The problem was not simply the amount of work. It was the loss of context. One idea could turn into a landing page, a sales presentation, blog posts, social media content, and emails — with each stage introducing new edits and new versions. A change made in one place then had to be manually propagated across all related assets, and something would inevitably be missed.
The team approached the problem differently: move context into the system.
ADLC introduces an engineering-style workflow built around Research → Brainstorm → Plan → Implement → Verify, with Git, branches, version history, skills, recipes, and agents becoming part of the production process.
Instead of rebuilding context for every asset, the system keeps a shared source of truth. A change made at the source can then propagate through the chain of related assets, much like a change merged into the root of a codebase.
The result is not only faster production. The workflow becomes more parallel, predictable, and consistent. Some marketing production flows that previously took roughly a quarter can now be completed in around a week.
Most importantly, the role of people changes:
People → produce becomes People → direct & decide.
People set direction, manage context, make decisions, and review quality, while agents handle more of the repetitive production work.
A particularly fitting proof that the approach works: the JetConf presentation itself was created using the same system.
The broader lesson goes beyond marketing. If engineering teams can use repositories, versioning, and automated workflows to preserve context, there is no reason other knowledge-heavy departments cannot do the same.
AI-native work is not about a specific tool. It is about building a system where context is preserved, work is structured, and AI can operate within clear boundaries.
Figma → Code: AI with contracts, not guesses
A presenter from the mobile team shared “AI in Mobile Development: Figma → Code — A Skills System.”
The project explores how to automate the path from a Figma design to production mobile code.
But instead of giving an AI agent a screenshot and asking it to “build this screen,” the team built a structured system around the model:
- 13 specialized skills
- 2 orchestrators
- a dedicated tooling layer
- explicit intermediate artifacts
- deterministic validation
- human approval at critical points
The pipeline starts with a Figma frame and its node-id. The design is then transformed into structured artifacts such as PROJECT.yaml and DesignSpec.json, which serve as contracts between stages.
One particularly useful idea is that skills do not pass hidden state directly to each other. They communicate through files.
That makes the workflow easier to debug, reproduce, audit, and resume.
The system also separates generation from evaluation. The AI generates the code, but external tools determine whether it is acceptable: linters, build checks, Git diffs, scope guards, and visual verification.
Even token selection has explicit rules.
A three-tier resolution system decides whether an existing design-system token can be reused, whether a human needs to decide, or whether to propose a new token. For colors, the system uses CIEDE2000-based distance calculations with defined thresholds.
The important principle is broader than Figma:
When AI faces ambiguous decisions, don’t hide the ambiguity. Turn it into an explicit human gate.
AI Code Reviewer: Build the layer around the model
An engineering lead presented AI Code Reviewer, a platform designed to bring AI-assisted code review into JetRuby’s engineering workflow.
The team deliberately avoided building yet another tightly coupled AI reviewer.
Instead, they built an infrastructure layer that can work with different runners and models.
The platform handles:
- project-specific and shared rules
- GitLab integration
- review comments
- model and provider selection
- API keys and quotas
- review history
- feedback
- statistics
- cost tracking
The actual runner becomes interchangeable: Claude Code, Codex, OpenAI-based execution, or another implementation can be used without redesigning the rest of the platform.
That architecture solves a problem that appears surprisingly quickly with AI tooling: vendor lock-in.
If every project depends directly on one model or one AI review product, changing providers means changing the entire process. By putting an abstraction layer around execution, the model becomes an implementation detail.
The system also makes AI review measurable.
JetRuby can track review runs, comments per pull request, token usage, cost, developer feedback, resolved threads, and the difference between useful and useless comments.
That turns AI code review from a novelty into an engineering process you can actually evaluate.
Designing AI Services: Treat them as software systems
Members of the architecture team examined AI from an architectural perspective in “Designing AI Services.” Their starting point was deliberately unglamorous: An AI service is, at its core, still an HTTP request.
A request, context, tools, history, a model response, token usage, and application-level decisions surround it.
The model itself has no persistent state. What looks like “memory” is usually the application sending relevant history or stored information back into the next request.
From there, the team highlighted several recurring engineering problems:
- conversations become too large
- token costs grow
- company data has to be retrieved and supplied
- multi-step workflows can fail
- users need memory between sessions
- model outputs are nondeterministic
- security boundaries become more complicated
The solution is not necessarily to introduce a huge “agent framework.” Instead, AI services should be designed around three clear layers:
orchestration → context assembly → model gateway
Observability belongs around the model gateway, where you can measure token usage, cost, latency, and model identity.
One of the strongest recommendations was to separate deterministic code from model-based uncertainty as much as possible.
And when reliability matters, start with a golden set of real inputs and expected outputs. Measure the actual system against it rather than relying on a model’s confidence or a few successful demos.
The same philosophy applies to autonomy.
Before letting an AI system cause real side effects, run it in shadow mode: let it make decisions, but only record what it would have done. Compare those results with human work first.
Full automation should be the endpoint of a process, not its starting point.
Legacy Migration: Teaching AI from the mistakes we already made
One of the most impressive examples of practical AI usage came from the Trustmark legacy modernization project.
The scale was daunting:
36 applications, more than 20 years of code, and almost no documentation.
The technology stack was being moved from:
WebSphere + Ant + Struts 1 + Java 8
to:
Azure + Maven + Struts 7 + Java 21
The first applications were migrated largely by hand. Initially, AI was used like an extremely capable search assistant:
“Show me an example.”
“What does this exception mean?”
“Translate this JSP.”
But the process changed as the team learned. The first application took around three weeks. The second took around two weeks. By the fifth, the migration took less than a week. The breakthrough was context.
Instead of repeatedly explaining the same problems to AI, the team started turning migration experience into explicit rules.
One example was the infamous javax → jakarta migration. A global replacement looked logical but caused runtime problems because some javax packages should not be changed.
The team documented the correct mapping.
The same thing happened with recurring bugs.
Ten known bugs became ten rules:
- UTF-8 BOMs in properties files
- ScopedModelDriven initialization
- saveMessages() behavior
- radio-button state
- modal rendering
- date handling
- getText() timing
- message types
- OGNL security
- filter ordering
The principle became:
Every bug happens once. Then it becomes knowledge. Then AI checks it forever.
This may be one of the most useful ways to think about AI-assisted legacy modernization. The model doesn’t magically understand a 20-year-old system.
The team teaches it what the team has already learned.
When AI becomes a security engineer’s assistant
The same Trustmark modernization project also had to deal with security and compliance. The applications process healthcare-related information, making requirements such as HIPAA, SOC 2 Type II, and PCI DSS critical to delivery.
The team faced around 9,000 security findings from SAST and SCA analysis. Some were relatively straightforward dependency vulnerabilities.
Others were much harder: weaknesses in shared libraries, legacy cryptography, third-party dependencies, or findings that depended on deployment context.
AI became part of the remediation loop.
It helped the team:
- parse security reports
- research CWE findings
- locate vulnerable code
- identify usages across modules
- propose fixes
- build and test changes
- compare security reports
- turn successful fixes into reusable rules
- apply those rules to other applications
But the project also exposed the limits of automation. A shared-library fix can break another application. Changing an old encryption algorithm can break an external integration. A security scanner can report something that is not exploitable in the actual deployment environment.
And sometimes the code simply cannot be changed because the vulnerable component is proprietary or abandoned.
The final goal was therefore not “make every scanner perfectly green.”
It was to meet the customer’s security requirements, deliver on time, minimize production risk, and use mitigation where a direct fix was not realistic. That is a very different definition of successful AI automation:
not maximum automation — maximum useful automation within real-world constraints.
AI AQA: From undocumented legacy apps to a test factory
Another Trustmark case focused on QA and the Struts upgrade.
The starting point was familiar:
34+ applications, unclear ownership, undocumented integrations, complicated access, unknown test data, and decades of accumulated behavior.
Before automation, the team first had to understand what the applications actually did.
They created:
- application mind maps
- structural decompositions
- Gherkin test cases
- Known Issues
- exploratory testing reports
- UAT scenarios
- UAT reports
AI helped, but the early experiments also demonstrated why context matters.
Copilot could generate tests, but it couldn’t log into an MFA-protected application and understand everything on its own. Without enough context, it could also generate irrelevant scenarios.
The solution was to turn the QA process into a system. The workflow evolved through several stages.
Standardization
Project requirements were encoded in copilot-instructions.md, giving AI persistent knowledge of the required architecture and coding standards.
Azure DevOps + MCP
An MCP server connected Copilot directly to Azure DevOps.
AI could retrieve the next test case, its expected results, test data, and locators — and update the automation status after successful execution.
Local test registry
All relevant test cases could be exported into a local JSON/SQLite registry, enabling batch processing and roadmap planning.
Exploratory discovery
Scripts could first scan an application and build a map of its menus, URLs, DOM structures, forms, and navigation.
Copilot then worked from the real application map, rather than guessing the UI.
This reduced locator-related errors by approximately 70%.
AI needs engineering standards too
The AQA project also showed that AI-generated code becomes much more useful when the architecture is explicit.
The team established strict rules for the Page Object Model:
- no locators in test files
- no assertions in test files
- no hardcoded values
- no unnecessary parameters passed into Page Objects
- no business logic in test files
- standardized authentication
- consistent naming
- standard Playwright locators
- no artificial waits
The result is not simply “AI writes tests.”
It is closer to:
AI generates tests inside an established engineering system.
We applied the same idea to CI/CD. Instead of having Copilot generate an entire pipeline configuration for every application, we extracted common Playwright pipeline logic into a shared template. New applications only need to supply a few project-specific variables.
The lesson is subtle but important:
Don’t spend AI tokens generating things that humans have already standardized.
Build the reusable infrastructure once, then let AI operate inside it.
What JetConf 2026 was really about
Looking across all these talks, JetConf 2026 was less about individual AI tools and more about how work changes when AI becomes a permanent part of the workflow — across engineering, QA, security, product, and marketing.
Several principles appeared again and again.
Knowledge should become an artifact
- A migration bug becomes a rule.
- A design becomes a specification.
- A test case becomes structured data.
- A security remediation becomes a runbook.
- A company process becomes a repository.
- A marketing decision becomes a reusable context.
The more knowledge exists in explicit artifacts, the less AI has to guess.
Context is an engineering resource
Giving AI access to the right repository, test system, design specification, security report, or company process can be more valuable than simply switching to a more powerful model.
Determinism matters
AI itself is probabilistic. The systems around it don’t have to be.
Build gates, linters, Git diffs, schemas, thresholds, scanners, and validation rules can provide deterministic boundaries around probabilistic generation.
Humans should own ambiguity
AI can generate, transform, search, compare, and automate. But when the question becomes “is this actually the right thing to do?”, human judgment still matters.
Every useful AI workflow is a feedback loop
- A failed migration teaches a rule.
- A bad code-review comment becomes feedback.
- A missing Figma section becomes a lint rule.
- A failed test becomes context.
- A security remediation becomes a reusable pattern.
- A marketing revision becomes part of the system’s knowledge.
The system improves because it captures experience instead of forgetting it.
A few words about JetConf
JetConf is ultimately about sharing that experience.
As an internal JetRuby conference, it gives teams a place to show not only successful demos, but also the problems, failed approaches, architectural compromises, and lessons behind them.
And that may be the most valuable part of this year’s conference.
The message wasn’t that AI can magically solve legacy code, replace QA, design applications, or run a company.
It was that we can redesign our processes so AI becomes genuinely useful inside them.
From CompanyOS to Agentic Marketing.
From Figma → Code to AI Code Review.
From security compliance to AQA.
From new mobile screens to 20-year-old Struts applications.
Different departments. Different problems. The same direction.
Make knowledge explicit. Make context available. Automate the predictable. Measure the result. Keep humans responsible for the decisions that matter.
That is what JetConf 2026 was really about — not simply putting AI into existing workflows, but redesigning the workflows themselves so AI can become genuinely useful inside them.
Different problems. The same direction.
Make knowledge explicit. Make context available. Automate the predictable. Measure the result. Keep humans responsible for the decisions that matter.
That is what JetConf 2026 was really about – and it is also where we see the next stage of engineering at JetRuby.
And this was only part of what we explored at JetConf 2026.
There were many more interesting talks, ideas, experiments, and practical lessons shared throughout the conference — from AI-powered development workflows to new approaches to architecture, product, and engineering.
We’ll share more of them in upcoming posts.
Stay tuned!
